To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Users accessing recent Codex models through OpenAI OAuth/ChatGPT subscriptions currently get serial tool execution in ECA. Independent operations such as reading several files require a separate model continuation for each tool call.
The tools often finish in milliseconds, while every model continuation can take several seconds. This makes ECA noticeably slower and may consume more tokens or subscription quota than executing a batch concurrently. Subagents using the same models are affected as well.
ECA's executor already runs tool-call batches concurrently when a provider supplies several calls at once. The limitation occurs earlier: gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna use Codex Responses Lite, which requires:
{:parallel_tool_calls false}Sending true returns HTTP 400:
X-OpenAI-Internal-Codex-Responses-Lite requires
`parallel_tool_calls` to be false.
The official Codex CLI nevertheless performs concurrent work with OAuth accounts. It also sends parallel_tool_calls=false, but current models use Codex Code Mode: one outer exec call can invoke several nested tools concurrently.
This may be a broader provider-design problem rather than an OpenAI-specific request flag. Supporting composite or nested tool calls could affect provider adapters, approvals, hooks, cancellation, UI state, and persistent chat history.
A naive solution would be an ECA-specific batch function containing an array of tool calls. ECA could expand it through the existing concurrent executor and aggregate the results into one provider-visible output. However, this risks adding provider-specific behavior and requires decisions about history, partial failures, approvals, and model reliability. Full Codex Code Mode compatibility would be cleaner parity but substantially larger in scope.
It would be useful to decide on an ECA-level design for enabling concurrent tool execution when a provider cannot express it through ordinary parallel function-call batches.
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Users accessing recent Codex models through OpenAI OAuth/ChatGPT subscriptions currently get serial tool execution in ECA. Independent operations such as reading several files require a separate model continuation for each tool call.
The tools often finish in milliseconds, while every model continuation can take several seconds. This makes ECA noticeably slower and may consume more tokens or subscription quota than executing a batch concurrently. Subagents using the same models are affected as well.
ECA's executor already runs tool-call batches concurrently when a provider supplies several calls at once. The limitation occurs earlier:
gpt-5.6-sol,gpt-5.6-terra, andgpt-5.6-lunause Codex Responses Lite, which requires:{:parallel_tool_calls false}Sending
truereturns HTTP 400:The official Codex CLI nevertheless performs concurrent work with OAuth accounts. It also sends
parallel_tool_calls=false, but current models use Codex Code Mode: one outerexeccall can invoke several nested tools concurrently.This may be a broader provider-design problem rather than an OpenAI-specific request flag. Supporting composite or nested tool calls could affect provider adapters, approvals, hooks, cancellation, UI state, and persistent chat history.
A naive solution would be an ECA-specific batch function containing an array of tool calls. ECA could expand it through the existing concurrent executor and aggregate the results into one provider-visible output. However, this risks adding provider-specific behavior and requires decisions about history, partial failures, approvals, and model reliability. Full Codex Code Mode compatibility would be cleaner parity but substantially larger in scope.
It would be useful to decide on an ECA-level design for enabling concurrent tool execution when a provider cannot express it through ordinary parallel function-call batches.