GPT-5.6 Sol rarely parallelizes programmatic tool calls, multiplying model turns and quota usage

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.41301 (build 5103)

The packaged Codex binary reports codex-cli 0.144.0-alpha.4. The analyzed long-running session was originally created with session metadata cli_version: 0.142.2.

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS 26.5.1 (build 25F80)

What issue are you seeing?

In a long Codex Desktop thread that used both gpt-5.5 and gpt-5.6-sol, GPT-5.6 Sol's Responses Lite / code-mode path almost never ran independent nested tool calls concurrently.

This is not only a model-behavior difference. The two models receive different parallelism instructions and use different tool interfaces:

• GPT-5.5 is explicitly instructed to parallelize common independent file reads and to use multi_tool_use.parallel.
• GPT-5.6 Sol receives only a generic instruction to prefer parallelization.
• GPT-5.5 uses ordinary direct function calls.
• GPT-5.6 Sol is configured as code_mode_only with Responses Lite. Top-level parallel tool calls are disabled by request serialization, so its practical concurrency mechanism is model-authored JavaScript such as Promise.all([...]) inside exec.
• The exec tool description explains how to call nested tools but does not mention Promise.all or concurrent nested calls.

In the analyzed trace, GPT-5.6 Sol produced 739 exec cells, but only 5 used Promise.all (~0.7%). This coincided with substantially more model round trips, repeated long-context processing, and very rapid depletion of the 5-hour usage allowance.

This is related to the usage symptom in #32250 and the Responses Lite tool path in #31894, but neither issue describes this prompt/tool-interface mismatch or its measured usage amplification.

What steps can reproduce the bug?

Analyzed session ID: 019f03c9-089a-7701-b70a-c60a89a819cd

1. Start or continue a long-context Codex Desktop task.
2. Ask for several independent read-only diagnostics, such as inspecting unrelated files, querying separate metadata sources, or running independent searches.
3. Run comparable tool-heavy work with gpt-5.5, then with gpt-5.6-sol.
4. Inspect the rollout JSONL:

• turn_context.payload.model identifies the model used for each turn.
• GPT-5.5 emits direct function_call items such as exec_command, often in batches before the next model response.
• GPT-5.6 Sol emits custom_tool_call: exec cells and calls nested tools.* methods from JavaScript.
• Search GPT-5.6 exec input for Promise.all.

1. Compare token_count and rate_limits events for each tool-bearing turn.

Trace scope:

| Metric | GPT-5.5 | GPT-5.6 Sol |
|---|---:|---:|
| Total turns in the session segment | 179 | 12 |
| Tool-bearing turns sampled | 133 | 9 |
| Reasoning efforts present | xhigh | xhigh, ultra, max |
| Reported model context window | 258,400 | 353,400 |

What is the expected behavior?

For GPT-5.6 Sol programmatic tool calling:

• The base instruction or exec tool description should explicitly tell the model to group independent read-only calls with Promise.all or an equivalent concurrency primitive.
• Dependent calls, writes, and approval-sensitive actions should remain serial.
• Code mode should minimize unnecessary model round trips and repeated long-context processing.
• Switching from native function calling to code mode should not dramatically increase allowance consumption solely because independent operations are serialized.
• Telemetry should distinguish model turns, nested tool calls, retries, cached input, and quota weighting.

Top-level parallel_tool_calls: false may be intentional for Responses Lite. The expected behavior is therefore not necessarily to enable top-level function batching; it is to make the supported nested concurrency path explicit and use it reliably.

Additional information

Prompt and tool-path differences

The current model metadata in codex-rs/models-manager/models.json and the local model cache agree:

| Property | GPT-5.5 | GPT-5.6 Sol |
|---|---|---|
| Parallelism instruction | Explicitly says to parallelize common file reads and names multi_tool_use.parallel | Generic “prefer parallelization over sequential tool calls” instruction |
| Mentions code-mode concurrency / Promise.all | No, because it uses the native tool path | No, despite code mode requiring it for nested concurrency |
| tool_mode | normal/direct tool mode (null) | code_mode_only |
| use_responses_lite | false | true |
| supports_parallel_tool_calls metadata | true | true |
| Observed call envelope | direct function_call items | top-level custom_tool_call: exec, then nested tools.* calls |
| Practical concurrency mechanism | native/top-level tool batches | JavaScript Promise.all inside exec |

Relevant source evidence at commit 9e552e9d15ba52bed7077d5357f3e18e330f8f38:

• Responses Lite request serialization forces parallel_tool_calls to false: prompt.parallel_tool_calls && !model_info.use_responses_lite.
• The exec description says it orchestrates nested tool calls and shows a sequential await tools.exec_command(...) example, but gives no concurrency guidance.
• The code-mode test demonstrates that concurrent nested calls with Promise.all are supported by the runtime.

Therefore the runtime supports nested concurrency and both models advertise parallel-tool support, but GPT-5.6 Sol's actual interface removes native top-level batching without adding an equally concrete instruction for the replacement mechanism.

Observed trace-level behavior

| Metric | GPT-5.5 | GPT-5.6 Sol |
|---|---:|---:|
| Tool calls | 3,104 | 764 |
| Primary observed tool envelope | 2,072 direct exec_command calls, plus other direct tools | 739 exec cells + 25 wait calls |
| Model response/token-count steps | 2,192 | 783 |
| Model requests per tool-bearing turn | 16.5 | 87.0 |
| Total tokens per tool-bearing turn | ~2.25M | ~17.88M |
| Calls inside native/top-level parallel batches | ~43.6% | Structurally disabled by Responses Lite |
| Nested exec cells using Promise.all | Not applicable | 5 / 739 (~0.7%) |

Normalized per tool-bearing turn, GPT-5.6 Sol used:

• about 5.3x more model round trips
• about 7.9x more total tokens

The different context windows and reasoning efforts are important confounders. The GPT-5.6 segment processed about 1.5x as many tokens per model request, while the number of model requests per tool-bearing turn was about 5.3x higher. That decomposition is consistent with both a larger context and much more serial orchestration contributing to the ~7.9x per-turn token difference.

The rough tool-error proxy was lower for GPT-5.6 Sol (~1.8%) than GPT-5.5 (~4.6%), so the additional round trips do not appear to be primarily retries after tool failures.

About 94% of GPT-5.6 input tokens were reported as cached, but allowance depletion was still rapid.

Rate-limit impact observed

The rollout field is rate_limits.primary.used_percent, which rises as allowance is consumed. To express depletion in the same direction as remaining allowance, the values below are calculated as 100 - used_percent.

Examples of the remaining 5-hour allowance falling during individual GPT-5.6 Sol tool-heavy turns:

• 88% -> 33%
• 32% -> 0%
• 99% -> 3%
• 99% -> 16%
• 98% -> 0%
• 99% -> 20%

The raw weekly used_percent also rose materially; equivalently, the remaining weekly allowance fell during these turns.

Likely mechanism

With GPT-5.5, several independent direct calls can be emitted before another model response. With GPT-5.6 Sol Responses Lite, native top-level parallel calls are forced off. If the model writes one nested call per exec cell instead of one exec cell containing Promise.all, every independent operation requires another model step.

In a long thread, that repeatedly processes a large context. The trace therefore provides a plausible mechanism connecting the serial code-mode behavior to the rapid allowance depletion in #32250 and the broader token-consumption report in #32161.

A low-risk prompt/tool-description fix would be to add an explicit instruction such as:

When nested tool calls are independent and read-only, run them concurrently in one exec cell with Promise.all. Keep dependent calls and writes serial.

A runtime-side batching or linting mechanism could be considered as well, but prompt/tool-description parity with the old direct-tool path is the smallest first step.

Caveat

This is an observational comparison from one long thread, not a controlled benchmark. GPT-5.6 turns were sometimes larger, used a larger reported context window, and included different reasoning efforts, so the measurements do not prove that seriality alone causes the full usage difference.

The narrower claims are directly verifiable:

1. The prompts and tool interfaces differ.
2. Responses Lite forces top-level parallel calls off.
3. Code mode supports nested Promise.all.
4. The observed GPT-5.6 trace used that mechanism in only 5 of 739 exec cells.
5. The same segment had far more model steps, token processing, and allowance consumption per tool-bearing turn.

A controlled internal replay can separate task complexity, reasoning effort, context size, cache accounting, and orchestration effects.

Related issues

• #32250 — GPT-5.6 Sol Medium depletes Pro 5-hour usage allowance extremely quickly
• #31894 — GPT-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec
• #32161 — Perceived regression in Codex quality and higher token consumption with GPT-5.6