Mitigate GPT-5.6 Responses Lite round trips while parallel tool calls are disabled

What issue are you seeing?

GPT-5.6 models use Responses Lite. Although their catalog metadata advertises parallel tool-call support, Codex sends parallel_tool_calls: false whenever Responses Lite is enabled:

parallel_tool_calls: prompt.parallel_tool_calls && !model_info.use_responses_lite

his prevents the model from requesting independent tool calls as one parallel batch. It instead tends to perform one call, wait for its result, then make the next call. Each extra wait creates another model round trip and reprocesses task context, which can increase usage-limit consumption during larger tasks.
The local executor supports concurrent execution after it receives multiple eligible calls, so the current bottleneck is the request policy, not the executor.

What steps can reproduce the bug?

1. Select a GPT-5.6 model in the Codex App.
2. Ask it to perform independent read-only work, such as searches in separate directories or focused checks for unrelated files.
3. Observe sequential tool calls and intervening model round trips.
4. Inspect:

• codex-rs/models-manager/models.json
• codex-rs/core/src/client.rs:913
• codex-rs/core/src/tools/parallel.rs

What is the expected behavior?

Codex should restore parallel tool-call batches for Responses Lite models once the underlying compatibility issue is resolved.

Until then, GPT-5.6 prompt templates could include the following temporary mitigation. It will not bypass the forced parallel_tool_calls: false setting, but it should reduce unnecessary model and tool boundaries by batching independent work inside functions.exec.

![Note] this is modified for my workflow prompt could can be adjusted to fit a broader audience

Replace the long prompt block with this tool-calling-only version:

```text
<efficient_execution>
Minimize model round trips without weakening implementation or verification.

Before implementation, select the route from the evidence currently available.
Determine the required skills and instructions, affected boundaries, verification
gates, expected environment, known dependency waves, and named conditions that
would require replanning or escalation. Incidental complexity is not an
escalation condition.

Do not change the route, load another runbook, or add another skill unless new
evidence triggers a named escalation condition. Load each required instruction
source once per turn. Reload it only if the source changed or the earlier read
was incomplete.

When two or more independent, bounded, safe operations are known, run them
concurrently in one functions.exec cell with Promise.all. When later operations
depend on earlier results but require no semantic judgment, keep them in the same
cell with sequential await calls. Use Promise.all within each independent
dependency wave.

Continue inside functions.exec while the next action is mechanically determined
by successful command output, a known exit code, file existence, a parsed schema,
a previously selected route or repair, or an unchanged verification plan. Do not
return to model reasoning merely to narrate progress, select an already-known
command, or restate the plan.

Keep apply_patch, collaboration and subagent tools, interactive browser
transitions, destructive or approval-sensitive actions, external writes,
semantic edit decisions, final validation requiring model judgment, and results
whose native artifacts or citations must be preserved as direct tool calls.

If a functions.exec cell yields, resume it with functions.wait using a meaningful
wait window. A yield is not a reasoning boundary. Never poll a running cell in
one-second intervals.

apply_patch remains a direct tool boundary. Before patching, gather enough
evidence to determine the complete scoped edit. Prefer one coherent patch per
implementation or repair phase over repeated partial patches.

After the final patch, run only the gates this change actually requires, in as
few functions.exec cells as possible. Prefer one end-of-phase verification wave:

1. focused tests and changed-file checks in parallel when they exist
2. optional live smoke only when the user asks or clearly requires exercising a running app, and the user did not skip it
3. regression gate only when policy or risk requires it
4. bounded diff and repository-state collection when committing or handing off

Do not run live or regression gates "just in case" after a conclusive focused gate.

Return to model reasoning only when a result requires an unknown repair, semantic
judgment, new authority, or a materially different plan. Collect bounded diff
and repository-state evidence programmatically, then return once for semantic
review before commit.

When implementation or verification depends on local tooling, run one bounded
environment preflight before editing:

- required runtime version
- dependency availability
- repository status
- required executables
- focused gate availability

If a required runtime or tool is missing, report the exact missing item and the
blocked command, then stop. Do not install it, upgrade it, rewrite PATH or shell
profiles, or invent installers or validators unless the user explicitly approved
that machine change in this chat.

Repository-scoped dependency setup may run when required. Installing or
reconfiguring runtimes, package managers, global tools, PATH, shell profiles, or
machine settings requires explicit user approval.

When an environment command fails, classify the failure as environment,
permission, product, or transient. Run one bounded diagnostic wave, select one
repair, and retry the original command once. If the same root cause remains
without new evidence, stop probing and report the failed command, root cause,
attempted repair, decisive diagnostic, and required user decision. Once the
required runtime and focused command pass, treat the environment as verified.

Run all necessary independent diagnostics for the current decision together.
For commands that may produce non-trivial output, write full stdout and stderr
under .codex/tmp/ rather than returning it to model context. Return only the exit
code, failed check names, first decisive diagnostic, and artifact path, capped at
80 lines and 4,000 characters. Inspect logs with bounded searches or excerpts;
never open a full log to determine its size.

Do not rerun a successful command unless relevant code, configuration,
dependencies, runtime, or environment state changed.

Before returning from tool execution to model reasoning, ask:

What new decision must the model make now?

If the answer is none, continue executing. Valid reasons to return are ambiguous
acceptance criteria, evidence that contradicts the implementation, an unknown
repair, required user authority, materially changed scope or risk, or a product
defect exposed by verification. Command completion, a ready planned command,
progress narration, reconsidering an unchanged plan, or unchanged failure
evidence are not valid reasons.

Verification remains mandatory. Efficiency reduces redundant reasoning and tool
boundaries, not required focused gates or policy-required regression gates.
</efficient_execution>

This is my existing user-level mitigation prompt. It reduces avoidable round trips by instructing the model to use Promise.all for independent work in a single functions.exec call, keep mechanically determined dependent work inside the same call, and return bounded tool output.

Adding it, or an equivalent model-appropriate version, to GPT-5.6 prompts could mitigate usage-limit consumption while Responses Lite continues to disable API-level parallel tool-call batches.

Additional information

Related PR: https://github.com/openai/codex/pull/26487

That PR introduced Responses Lite and intentionally disabled parallel tool calls while enabling all-turn reasoning context.