Issue on parallel tool calls using GPT models through codex-pooler

[mattew113]

I'm still debugging this issue to give a more detailed root cause, but I noticed when using OpenCode with direct Codex OAuth this problem does not happen.

OpenCode running GPT models through codex-pooler are unable to deploy parallel subagents, always deploying them sequentially, regardless of how you enforce it in their prompt.

Using direct Codex OAuth this doesnt happen.

Is this expected behavior from this gateway? Found nothing on the docs regarding it.

Is this a known issue or perhaps expected due to the gateway parsing the Codex OAuth backend API into a OpenAI compatible endpoint?

Example below, on the left using Codex OAuth and on the right Codex-pooler. Same agent, prompt, model etc.

[mattew113]

Looks like this was decided in #134 fix that defined parallel_tool_calls=false

[mattew113]

@masterkain could we turn this into a configuration to choose wether to use use_responses_lite=true / use_responses_lite=false, as multi tool invocation is not available on lite responses?

[masterkain]

thanks — the diagnosis is correct at the protocol level

we reproduced this against the same live upstream assignment, keeping the model, prompt, tools, tool choice, and request builder fixed

• standard Responses returned all three sibling function calls in 3/3 trials
• Responses Lite returned one function call in 3/3 trials
• every request completed successfully with HTTP 200

so this is a real capability difference between the two request dialects, not generic serialization inside codex-pooler

a few details from the investigation may be useful for anyone following this:

• outside trusted Lite selection, codex-pooler preserves the client's parallel_tool_calls value, so the OpenAI-compatible adapter is not generically serializing tool calls
• Responses Lite is a coupled request dialect, not just a concurrency flag: openai/codex#26487 introduced catalog-driven use_responses_lite, persistent reasoning.context=all_turns, and the parallel-call override; openai/codex#27946 also moved Lite tools and instructions into input items
• this is why a model can advertise supports_parallel_tool_calls=true while a Lite request still forces parallel_tool_calls=false: the first describes model capability, while the second is a constraint of the selected request dialect
• parallel_tool_calls=false prevents multiple sibling tool calls from being emitted in one Responses turn, but it does not by itself prevent a client from running independent child sessions concurrently. OpenCode's flat task tool relies on multiple calls in the parent turn for immediate fan-out, while official Codex has its own child-session runtime
• in the OpenCode revision we inspected, direct Codex OAuth used the ordinary Responses path. OpenCode briefly added a Luna-specific Lite workaround in anomalyco/opencode#36685 for anomalyco/opencode#36140, then removed it in #36750 after the server-side problem was fixed
• the screenshot is consistent with this explanation, but UI ordering alone is not deterministic timing evidence; the controlled same-assignment request comparison above is the stronger protocol-level reproduction

#134 implemented the upstream Lite contract by disabling parallel tool calls, matching the official Codex client behavior. It did not establish sequential foreground agents as an intended product policy

we should not expose this as an untrusted per-request header or body toggle, since that would let clients bypass the assignment's selected protocol contract

the appropriate enhancement is a trusted, persisted per-model serving mode in the Pool configuration: auto | lite | full, defaulting to auto, with full documented as an advanced override

one limitation remains: the upstream catalog advertises Lite and does not formally document a full-mode opt-out, although the same-account backend accepted full requests and emitted all three calls in every controlled trial

the implementation is non-trivial because the decision must stay consistent across catalog metadata, HTTP and websocket dispatch, retries, failover, and multi-node operation, but we are actively working through it

no need to spend time preparing a PR for this one right now, we will keep the issue updated as the implementation progresses

keeping this open as an enhancement for the operator-controlled override and documentation

[mattew113]

In case you change your mind on the PR, I'll be happy to help, mate. Awesome project overall alternatives there is in GH right now, but I had to switch, cause those extra turns in my opencode instances were causing me to drain my quota faster as I end up spending more input tokens than necessary on my orchestration workflows. Thanks for the support and for the project nonetheless.