GPT-5.6 Sol cannot specify subagent models, forcing all subagents to also be Sol instances

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31097

Powered by Codex Action

Independent reproduction on codex-cli 0.144.0 on macOS. This also reproduces with a project-scoped custom agent whose registration and role file resolve correctly.

Configuration shape:

# .codex/config.toml
[agents.code_explorer]
description = "Read-only codebase explorer"
config_file = "agents/code-explorer.toml"

# .codex/agents/code-explorer.toml
name = "code_explorer"
description = "Read-only codebase explorer"
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
developer_instructions = "Explore the codebase read-only."

GPT-5.6 Sol / V2 result

In a fresh GPT-5.6 Sol session:

• turn_context.multi_agent_version is v2.
• The visible collaboration.spawn_agent schema contains task_name, message, and fork_turns, but not agent_type, model, or reasoning_effort.
• Even when explicitly instructed to use agent_type="code_explorer" with fork_turns="none", the generated function call necessarily omits agent_type because it is absent from the schema.
• Spawning with task_name="code_explorer" produces child metadata with agent_path="/root/code_explorer" but agent_role=null.
• The child inherits gpt-5.6-sol at the parent's reasoning effort instead of using gpt-5.6-terra at medium effort.

This confirms that task_name is only the canonical task path; it does not resolve a configured role.

Setting this for a fresh session does not provide a usable workaround:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false

The first request then fails before inference with:

Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.

V1 control

As a control, a fresh gpt-5.5 session selected V1. Calling multi_agent_v1.spawn_agent with agent_type="code_explorer" and fork_context=false produced:

• agent_role="code_explorer"
• model gpt-5.6-terra
• reasoning effort medium

So the registration and role TOML are valid; the behavioral difference is isolated to the model-selected V2 tool surface and its reserved schema.

Could a maintainer clarify the intended contract?

1. Is selecting configured [agents.<role>] entries intentionally unsupported for GPT-5.6 Sol / MultiAgent V2, or is this a rollout regression?
2. What is the supported V2 mechanism for targeting a configured custom role? task_name does not do it, and agent_type is hidden.
3. Is model-catalog multi_agent_version = "v2" intentionally authoritative over the user's local feature selection?
4. If hide_spawn_agent_metadata = false is intended as the workaround, which client/backend combination supports the expanded reserved collaboration.spawn_agent schema without the 400 above?
5. Should the custom-subagents documentation currently state that named role selection is V1-only for model-selected V2 sessions?

This appears related to #20077, #31097, #31864, and the V1-only restoration in #26599.

I reached the same issue. All agents spawned from the sol xhigh are sol xhigh. This is ridiculous. Simple tasks spawned from sol xhigh or higher should use a lighter model.

Independent confirmation on Linux with Codex CLI 0.144.0 and personal agents under ~/.codex/agents/. GPT-5.6 exposes the restricted V2 schema, task_name does not select the configured role, and the child inherits the parent model and reasoning effort. GPT-5.5/V1 correctly applies the same role configuration. Setting hide_spawn_agent_metadata = false produces the same reserved-schema 400. Additional details are in duplicate #31893.

You can do this to stay on v1:

# ~/.codex/config.toml
model_catalog_json = "~/.codex/models-v1.json"

[features]
multi_agent = true
multi_agent_v2 = false

Then create ~/.codex/models-v1.json from the current model catalog and change only these fields:

"slug": "gpt-5.6-sol",
"multi_agent_version": "v1"

and optionally:

"slug": "gpt-5.6-terra",
"multi_agent_version": "v1"

You can also optionally instead set version as "null" for all three Sol, Terra, and Luna, so that multi-agent schema version is defined by features config, not model catalog, but that's up to you.

sol 5.6 spawned recursive sub-agents and burned a billion tokens in 20 minutes lol. tibo reset the limits so i'm okay but this doesn't seem ideal :D.

Here's some stuff autogenerated by Codex from the affected app state.

Independent impact evidence from Codex App 26.707.31123 on macOS:

• The root was deliberately configured to use gpt-5.6-sol at xhigh. Sol's quality is not the complaint.
• The model-visible spawn_agent schema exposed task name, instructions and forked-context controls, but no agent_type, model, reasoning_effort or service_tier.
• When I asked the parent to use cheaper workers, it therefore had no way to select Terra or Luna. The spawned workers I checked recorded gpt-5.6-sol at xhigh.
• The affected local state recorded 8 lead/lane roots plus 24 descendants: 32 threads and 700,462,321 tokens in total. Descendants accounted for about 75% of that total. This is a local recorded-token total, not a billing assertion or a claim that the configured thread/depth limits were violated.
• “A billion” above is the human rough description; 700,462,321 is the total I could verify from the local thread records.

The right fix looks like the one proposed here: restore explicit per-spawn routing inputs by default, or provide a clear worker policy/default, and separate metadata hiding from functional routing capability. The parent should be able to keep the lead on Sol/xhigh while choosing Luna or Terra at an appropriate reasoning level for bounded workers.

A related safety improvement would be a root-plus-descendant usage budget tied to the account's remaining limits, with aggregate live usage and a warning or stop before further fan-out. That is additional guardrail work; it does not replace restoring the missing routing controls described in this issue.

Feedback/session ID: 019f480a-707c-7ef3-a43a-16753ce54715.

Independent Linux/Codex Desktop reproduction with measured root-plus-descendant
usage impact.

Environment

• Ubuntu 24.04, x86_64
• Codex Desktop using codex-cli 0.144.0-alpha.4
• Parent model: gpt-5.6-sol
• Multi-agent version recorded in child session metadata: v2
• No local features.multi_agent_v2 override during the affected run

Measured usage impact

One affected orchestration tree recorded the following local cumulative token
totals:

| Scope | Local recorded tokens |
|---|---:|
| Sol/high root | 87,536,271 |
| Seven Sol/high descendants | 293,405,016 |
| Root plus descendants | 380,941,287 |

Across all ten affected Sol/high children active during the incident window:

| Token category | Count |
|---|---:|
| Input | 299,133,092 |
| Cached input | 294,369,792 |
| Uncached input | 4,763,300 |
| Output | 471,696 |
| Reasoning output | 37,643 |
| Total | 299,604,788 |

The three dominant ranking workers made 1,779 model invocations. Their first
requests were approximately 21K input tokens, but average request contexts grew
to 131K-182K and maximum contexts reached 251K-286K. The workers repeatedly
replayed growing session context while being forced to remain on Sol/high.

The routing regression compounds that context-growth problem: workers suitable
for Terra or Luna instead inherited Sol/high, so the allowance impact was much
higher than the raw-token counterfactual alone suggests.

019f4820-dcde-7832-a7c7-3ad977e27a67

A work around:
use gpt-5.5-low(or any other model that can use subagent properly) to dispatch a subagent (e.g gpt 5.4)

This ensures that all necessary subagent-related information is injected into the current session context.
For the remainder of the session, the model will now dispatch subagents correctly.

Optional: You can rewind the session to the first message(not /clear) to get a clean gpt-5.6-sol session

Fedora / Codex Desktop 0.144.1 reproduction with a registered named agent

I can confirm this on Fedora Linux x86_64 with Codex Desktop (session metadata reports codex-cli 0.144.1) and a model-selected MultiAgent V2 session.

The model-visible spawn_agent schema exposes only:

• task_name
• message
• fork_turns

There is no agent_type, custom-agent selector, model, reasoning-effort, service-tier, or sandbox input.

Clean named-agent probe

A valid project custom agent is registered as:

name = "observer"
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

I then spawned the minimal child with task_name = "observer". The child replied normally, but its sanitized session metadata was:

{
  "originator": "Codex Desktop",
  "cli_version": "0.144.1",
  "agent_path": "/root/observer",
  "agent_role": null,
  "model": "gpt-5.6-sol",
  "effort": "high",
  "multi_agent_version": "v2",
  "sandbox_policy": "danger-full-access"
}

So task_name becomes a task path, but it is not resolved against .codex/agents/observer.toml. The configured role, Terra model, reasoning effort, and read-only sandbox were all not applied.

The same behavior was also observed in a three-child concurrent burst: every V2 child had agent_role = null and inherited the Sol parent configuration.

V1 control

An older Codex Desktop control on codex-cli 0.142.3 / MultiAgent V1 recorded a non-null agent_role = "mechanic" for a typed spawn. This shows that Desktop previously had a role-binding path; the current V2 surface does not expose an equivalent.

This also connects the routing-control regression here with the named custom-agent gap in #15250.

Requested connection

Please provide a supported custom-agent selector in the reserved MultiAgent V2 schema, equivalent to V1 agent_type, and resolve it against project/user .codex/agents/*.toml entries.

Selecting a named agent should apply its full configuration layer:

• developer_instructions
• model
• model_reasoning_effort
• sandbox_mode

The spawn receipt/session metadata should also expose the resolved custom-agent name and configuration source. If task_name is intentionally only a task-path label, it should remain separate from the role selector.

The official subagent documentation describes custom-agent name as the identifier and supports per-agent model/effort configuration, so the current Desktop V2 tool surface appears disconnected from that documented configuration layer:
https://learn.chatgpt.com/docs/agent-configuration/subagents

It may have been buried in the initial message a bit, but my workaround is to add this config:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false

It quite cleanly fixes the problem.

I would presume that this feature exists to allow for automatic routing at some point. Why is is even accessible now is a good question.
And, why it is on by default is a question that only @jif-oai can answer.

It may have been buried in the initial message a bit, but my workaround is to add this config: `` [features.multi_agent_v2] hide_spawn_agent_metadata = false `` It quite cleanly fixes the problem. I would presume that this feature exists to allow for automatic routing at some point. Why is is even accessible now is a good question. And, why it is on by default is a question that only @jif-oai can answer.

This isn't working for me in the desktop app (ChatGPT / Codex combo app released today):
Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.

It may have been buried in the initial message a bit, but my workaround is to add this config: `` [features.multi_agent_v2] hide_spawn_agent_metadata = false `` It quite cleanly fixes the problem. I would presume that this feature exists to allow for automatic routing at some point. Why is is even accessible now is a good question. And, why it is on by default is a question that only @jif-oai can answer.

Sadly, that was one of the first things I tried. 😦 Similar to jcarioti, on the codex CLI on Linux it ends up giving:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.",
    "param": "tools"
  },
  "status": 400
}

@lholden @jcarioti I ran into that problem too and filed it here: https://github.com/openai/codex/issues/31864

The fix is another config flag:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

same issue.

Independent reproduction on macOS (VS Code–originated sessions, codex-cli 0.144.1) with measured root-plus-descendant impact over a single 5h window.

Schema / inheritance observation

Local rollout records for every spawn in the affected window show spawn_agent calls carrying only task_name, message/items, and fork_turns — no model, reasoning_effort, agent_type, or service_tier, consistent with the hidden V2 schema described above. All 12 descendants recorded gpt-5.6-sol at ultra. Notably, one root ran at xhigh while its three descendants recorded ultra — descendants did not even track their parent's lower setting, so the effective policy is "maximum tier for every worker".

Measured usage impact (2026-07-10, ~04:25Z–05:49Z)

Three ordinary tasks (a design task, an OCR + web-research task, a code-review task): 3 roots + 12 descendants, 888 model invocations.

| Metric | Value |
|---|---:|
| Total input tokens | 103.6M |
| Cached input | 97.5M (94.1%) |
| Uncached input | 6.10M |
| Output | 0.45M (incl. 0.23M reasoning) |
| Avg request context (main threads) | 138K–165K |
| Max request context | 318K |

The primary 5h meter went from ~57% to 100% in ~85 minutes; the weekly meter only reached 24% — a single-window burn, not sustained usage.

Decomposing the uncached/billable side supports the context-replay pattern @ajhcs measured: first-call (fork/cold-start) uncached input ≈ 0.50M (7.7%), while mid-run fresh input ≈ 5.59M (85.4%) — workers replaying ever-growing contexts on a model tier they never needed. The design task alone (6 descendants, all forced to Sol) accounted for 42.5% of the window's uncached-input + output total.

Client-side mitigation is not possible under V2

One additional data point: a client-side PreToolUse hook that rejects spawns lacking reasoning_effort cannot work here — the model can't supply a field that is absent from its visible schema, so enforcement degenerates into a deny-loop. Routing control has to come back at the schema level, which is why the fixes proposed in the OP (restore routing inputs by default, or split output redaction from input capability) seem like the right shape.

Root thread IDs, if useful server-side:

• 019f4a44-64ff-76e1-8d3e-22a5c787d55b
• 019f4a7a-7c0e-7e23-a621-b1a773c3fd1b
• 019f49c3-cb6d-78e2-a9b4-53a3569acdd4

same issue.

In a previous project setup involving multiple custom sub-agents—where the primary agent used the gpt-5.5 xhigh configuration and sub-agents used gpt-5.5 high—execution allowed for a clear view of the prompts and configurations used when the primary agent spawned sub-agents, resulting in an excellent user experience. However, with the current setup—using gpt-5.6-sol max for the primary agent and gpt-5.6-terra high for sub-agents—execution no longer provides a clear view of the prompts and specific sub-agent configurations (which inherit from the primary agent) used during the spawning process. It feels like a "black box"; one has to inspect specific *.jsonl files to see the prompts used for spawning. Additionally, the sub-agents appear to be handling tasks intended for the primary agent, likely due to the configuration inheritance.

Confirmed on the newly integrated ChatGPT desktop app for macOS.

Environment:

• ChatGPT desktop app: 26.707.31428 (build 5059)
• Bundled Codex CLI: 0.144.0-alpha.4
• Parent model: gpt-5.6-sol
• Platform: macOS on Apple Silicon
• multi_agent: stable and enabled
• multi_agent_v2: reported as under development and disabled by features list

Observed behavior:

• The model-visible collaboration.spawn_agent schema exposes only task_name, message, and fork_turns.
• agent_type, model, reasoning_effort, and service_tier are absent.
• A valid personal ~/.codex/agents/explorer.toml exists and overrides the documented built-in explorer role, but the current tool surface provides no way to select it.
• Spawning tasks named explorer_probe_* creates generic subagents; naming the task does not activate the configured Explorer role or its pinned model/sandbox.

Expected behavior:

• gpt-5.6-sol should be able to select the documented built-in or custom explorer agent type, including the model, reasoning, sandbox, and developer instructions defined by the agent profile.

This reproduces the issue after the July 2026 ChatGPT desktop integration. I have not yet tested the proposed hide_spawn_agent_metadata = false workaround.

@lholden @jcarioti I ran into that problem too and filed it here: #31864 The fix is another config flag: `` [features.multi_agent_v2] hide_spawn_agent_metadata = false tool_namespace = "agents" ``

This worked for me on my MacOS, with the new ChatGPT/Codex updated desktop app.

Confirmed on codex-cli 0.144.1 with gpt-5.6-sol. This installation had the reduced schema before adding the workaround.

Clean-config reproduction:

$ codex exec --ignore-user-config --ephemeral --skip-git-repo-check -m gpt-5.6-sol "Inspect the spawn_agent tool schema visible to you. Do not call any tools. Reply with exactly one line: spawn_agent properties: followed by the property names in schema order, comma-separated."
spawn_agent properties: fork_turns, message, task_name

After adding:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

a fresh ephemeral session on the same installation reported:

spawn_agent properties: agent_type, fork_turns, message, model, reasoning_effort, service_tier, task_name

As an A/B check, overriding only the flag back to true returned the reduced schema again:

$ codex exec --ephemeral --skip-git-repo-check -c 'features.multi_agent_v2.hide_spawn_agent_metadata=true' "Inspect the spawn_agent tool schema visible to you. Do not call any tools. Reply with exactly one line: spawn_agent properties: followed by the property names in schema order, comma-separated."
spawn_agent properties: fork_turns, message, task_name

Same here!!

@spadaval We found an additional usage-related behavior in MultiAgent V2. Codex v0.144.1 defaults fork_turns to all, resolves that to FullHistory, and initializes the child from the parent’s persisted history. Therefore, unless fork_turns: "none" or a bounded turn count is explicitly supplied, spawned agents receive the parent conversation history.
After restoring the spawn controls and switching fresh workers to fork_turns: "none", we observed substantially lower usage. For one affected orchestration tree, local telemetry recorded 380.9M cumulative tokens. A conservative bounded-context counterfactual estimates 63M–105M tokens for the same work, corresponding to approximately 276M–318M fewer tokens, or a 72%–83% reduction.

Same problem, My Sol Medium using Codex decided to get around it to just call the codex harness to do it. Then it can call other agents and efforts.

This is becoming a huge problem in terms of token burn - This wasn't an issue with 5.5 because 5.5 just wasn't as token hungry in general. But with 5.6, it's nearly impossible to run orchestration frameworks because there is no control over the amount of burn that it's going to initiate. We really need a better way for the advisor loop to control the effort and the model in the spawned agents.

https://github.com/openai/codex/issues/31814#issuecomment-4932285996

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

this fix did NOT work for me on existing threads, i think you might need a new thread for it to pick up. so until an update lands, your existing threads seem a bit cooked

@ajhcs Huh, so that's why I had to specify in my AGENTS.md to turn off fork_turns.
Good to know.
It sure feels like V2 is still rough and that forcibly opting all users into it is a mistake.

Hope it fix soon, i use reset 2 times :'(

One additional data point for external-provider custom agents:
In the previous 24 hours, GPT‑5.6 Sol/Luna parents successfully spawned eight MiniMax/MiMo children through V1. Their session metadata confirmed the correct agent_role, external model_provider, and model, and all completed normally. This rules out our provider, auth, and agent TOML configuration.
With V2, the default schema hides agent_type as reported here. Enabling:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

did create a correctly bound MiniMax child (provider=minimax, model=MiniMax-M3), but its task arrived only as encrypted_content; the external model could not see the delegated packet and returned NEED_PACKET.
So external providers appear to hit two V2 regressions: hidden custom-agent selection, then unusable encrypted task delivery even when selection is restored. This connects this issue with #26753 and #17598.

Huge problem in tokens burn. Sol told me it can't specific the type of subagent to use.

Been burning through my 5 hours windows in less than 2 hours. My weekly limit down to 50% in less than 24 hour. to the point that last night I had to ask it it to in "tokens conservation mode"

I suspected something was happening with sub-agents so i asked, and it said that it's not able to setup the model.

Told me for subsequent work to tell it "* If delegation is genuinely unavoidable, use only two subagents at a time with fork_turns: "none" and a short, self-contained prompt."

Since the fix, I’ve had zero issues and the usage lasts the entire 5 hour window as opposed to be gone in 30 minutes.

@notque What Fix ?

The fix listed in here. 2 settings for the codex harness

[features.multi_agent_v2]
enabled = true
max_concurrent_threads_per_session = 2

The fix listed in here. 2 settings for the codex harness

sorry, but it does not help if you want to use a non-OpenAI agent. Task sent to subagent is encrypted_content, does not actually contain the task in plaintext.

Viable fixes:

• Encrypt only when the selected child provider is OpenAI.
• Let custom providers opt out of encrypted tool parameters.
• Provide a supported backend decryption/relay mechanism.

Confirming an additional downstream impact on Linux with codex-cli 0.144.1.

The model-visible collaboration.spawn_agent schema contains only task_name, message, and fork_turns. It does not expose model or reasoning_effort.

When a reusable skill requires a particular reviewer configuration, the orchestrator cannot express that through native spawn_agent. It therefore falls back to wrapping another Codex process, approximately:

codex -m <model> \
  -c 'model_reasoning_effort="<effort>"' \
  -s workspace-write -a never exec \
  --ephemeral -C <workspace> -o <result-file> -

That workaround is materially worse than native delegation: the outer command/tool captures the nested Codex execution stream, so the parent agent consumes the raw nested trace in its own context instead of receiving only a bounded subagent result. It wastes context, complicates reusable review/planning skills, and encourages brittle shell orchestration solely because native per-spawn routing controls disappeared from the visible schema.

Expected: expose supported model and reasoning_effort parameters on collaboration.spawn_agent (with the correct fork_turns contract), so skills can use native isolated agents and remain model-agnostic by default. If routing must be restricted, the tool should provide a documented supported mechanism rather than causing agents to launch nested codex exec processes.

I built an experimental, project-scoped stopgap for this specific V2 routing gap:

https://github.com/carltonawong/sol-ultra-workaround

It does not restore the missing per-spawn model fields. Instead, it keeps SOL Ultra as the orchestrator and declares Terra High as the project's default isolated subagent. The managed policy requires a compact handoff with fork_turns="none", treats completed subagents as terminal, and checks rollout evidence before accepting their output.

Fresh Codex 0.144 canary:

• SOL Ultra / Ultra orchestrator
• two sequential, distinct Terra High / High subagents
• isolated context and exactly one turn each
• zero completed-subagent follow-ups

In a separate 13-subagent implementation run, 11/13 started Terra High, 9 stayed Terra-only, and 15/19 subagent turns used Terra. Isolated subagents began with 22.9% less context on average in that sample.

This is a reversible configuration-and-policy workaround, not an upstream fix, hard routing lock, or quota guarantee. Tests, methodology, and limitations are documented in the repo.

Workaround

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

After applying this workaround, it seems to be working and will spawn subagents with the correct configuration, but it will not allow you to switch to those subagents using the /agent command

I'm confused why so many people "fix" by staying on v2 multi-agent. Update your models.json via custom copy from the bundled one - switching the multi agent version field to null or v1 and disable deferred tool search (search_tool_supported), and you have normal subagent v1 work in 5.6 like on 5.5 - any model, any reasoning, any configuration.

v2 is still marked "Under development" and should not be used for serious usage...

v2 is still marked "Under development" and should not be used for serious usage...

If v2 is not ready, maybe it should not be enabled by default?

@ignatremizov modifying the model catalog to remove the forced-v2 behavior is a quite invasive change.
You will no longer recieve model catalog updates from either Codex CLI updates or from the backend.
It is entirely on you to add new models or modify feature flags for models as new things come up or features become more stable.

If you intend to take complete control over models and config (perhaps because you don't trust OpenAI anymore to provide sane config), then overriding the catalog is a fine solution.
But, I think it is perfectly reasonable to not want to take so much ownership of Codex internals.

If you want to just throw a few lines in your config and get back to work, this config tweak is the best solution, at least for the moment.

@spadaval I completely agree. Obviously, this would be meant as a temporary solution and workaround until v2 is stable or config once again takes precedence instead of the model catalogue, after which the custom catalogue would be unnecessary and the workaround removed. I check each commit pushed to main to monitor for such changes.

I think it would be useful to update the issue with the second workaround for those who want to stay on the stable v1 path.

@ignatremizov do you have an example in how you did that?

I've also been using this so called "workaround"

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

but this doesn't work. It's still burning tokens like crazy. I don't think it's working right.

Also, been using these as instructions now in all my conversations.

``Instructions going forward:
Default children inherit too much context.
The current spawn_agent interface defaults fork_turns to "all". Your orchestration skills never set it, so independent researchers can receive the parent’s entire conversation rather than a bounded task packet.Required policy:
fork_turns: "none" — independent research, review, tests, log analysis
fork_turns: "1" — "3" — tasks needing the latest decision or artifact
fork_turns: "all" — only genuine continuation of the parent’s work
A self-contained child prompt should carry the goal, scope, constraints, relevant paths, expected output, and success criteria.``

@ignatremizov do you have an example in how you did that? I've also been using this so called "workaround" `` [features.multi_agent_v2] hide_spawn_agent_metadata = false tool_namespace = "agents" ` but this doesn't work. It's still burning tokens like crazy. I don't think it's working right. Also, been using these as instructions now in all my conversations. ` Default children inherit too much context. The current spawn_agent interface defaults fork_turns to "all". Your orchestration skills never set it, so independent researchers can receive the parent’s entire conversation rather than a bounded task packet.Required policy: fork_turns: "none" — independent research, review, tests, log analysis fork_turns: "1" — "3" — tasks needing the latest decision or artifact fork_turns: "all" — only genuine continuation of the parent’s work A self-contained child prompt should carry the goal, scope, constraints, relevant paths, expected output, and success criteria.` ``

I built a workaround for this https://github.com/carltonawong/sol-ultra-workaround

The enforcement required is a bit more complicated but still possible. I've been able to have my children agents run at Terra High once the parent agent spawns them.

Having to invent adhoc solutions for such things feels odd though. Ability to spawn subagents is one of the key use cases for the CLI tool, right? And this is not the first time a release introduces regressions. One would expect there to be a test suite or something to catch these sort of issues before they go public.

I wonder if there’s a better way to do this. Maybe there is, sort of, a stable release branch or LTS for those who don’t want their processes to be broken, and “nightly” builds for those who like the YOLO approach? Or maybe there is a known way to confidently tell the versions apart? E.g., all major versions are guaranteed to be stable?

What is crazy to me is that this issue is still not assigned / reviewed and there has been no official comment from OpenAI on this token burns. This is clearly a major regression, me and plenty others see their 5 hours limit burned by this very quickly. Yet no public comments that I know of.

I believe Tibo has address this problem on this post: https://x.com/thsottiaux/status/2075641131002700120

I noticed also subagents spawn with priority tier. Be careful.

@sfourdrinier

https://github.com/ignatremizov/skills/commit/6363178cd4d063065c27b469b75414c4b5f08d0d - custom models.json with "multi_agent_version": null for the gpt-5.6 family so that I can use multi_agent = true + multi_agent_v2 = false via config.

https://github.com/ignatremizov/skills/commit/0f9b7cfb571ec86ddd8c3339410ae421988ca9c2 - "tool_mode": "code_mode_only" -> "tool_mode": null, (codex did not ship with required codex-code-mode-host binary - no longer necessary because fixed already in https://github.com/openai/codex/pull/31899, but had to override at the time)

https://github.com/ignatremizov/skills/commit/04f79a98c4e73b6095cb17ffae07f84ac9e04a38 - disabled supports_search_tool for the gpt-5.6 family (Responses Lite API used by gpt-5.6 does not expose tool_search in tools, meaning deferred discovery was broken and v1 multi agent tools were inaccessible) (issue opened here https://github.com/openai/codex/issues/32086)

https://github.com/ignatremizov/skills/commit/ed49b805948415b8d993c1dae051dba46fad4c0d - restore gpt-5.3-codex-spark model catalogue (without the model catalogue it falls back to gpt-5 base model catalog which erroneously says the model supports image handling, which gpt-5.3-codex-spark does not and would fail on every request) (issue opened here https://github.com/openai/codex/issues/32132)

Hope this helps.

@sfourdrinier I would also like to note I pointed out the full-context fork / token burn problem back in March in https://github.com/openai/codex/issues/14981. In v1, fork_context defaults to false when omitted, but the model can explicitly choose true (because the surface is exposed in the tool description, and models like to in, idk, about 15% of cases to set implicitly fork_context=true because why not). In v2, omitted fork_turns defaults to all, which also seems to exacerbate the issue people are hitting in this thread.

I made a patch in my fork (https://github.com/ignatremizov/codex/commit/5495d67167419e19d60b9b98f0dedf9792b500db) to make omitted v2 fork_turns default to none.

The v1 behavior is also a little confusing because https://github.com/openai/codex/commit/776246c3f5f931a72ebe41f52ef719e3b413371d from https://github.com/openai/codex/pull/17247 rejects a full-history fork when agent_type, model, or reasoning_effort is supplied, and since configured-role v1 calls normally include agent_type, when the model tries to pass fork_context=true it gets an error and so retries with fork_context=false, which creates a pointless bounce. But a bare explicit fork_context=true still works with a default worker role, so that commit did not fully solve the original #14981 concern, even if it does close it in my day to day. If we get a quota limit reset again, I might handle it tomorrow to add explicit config.

If you maintain your own fork, could be useful to take a look.

> @ignatremizov do you have an example in how you did that?

I built a workaround for this https://github.com/carltonawong/sol-ultra-workaround

Sounds interesting, read the different files. But why use Ultra? In my limited experience so far Medium or High have been working very well. I'm concerned about token burn.

Also Luna has worked great as an agent in xhigh or max. Been trying with "manual prompting"

### Workaround [features.multi_agent_v2] hide_spawn_agent_metadata = false tool_namespace = "agents"

Note that with this workaround, if your orchestration agent uses followup_task turns to continue interacting with the sub-agent, the followup_task turns silently inherit the orchestration agent's model and effort. In my observed run, an agent initially spawned as gpt-5.6-terra / high silently ran subsequent followup_task turns as the orchestration agent’s current gpt-5.6-sol / medium configuration.

but this doesn't work. It's still burning tokens like crazy. I don't think it's working right.

@sfourdrinier - this could explain what you're seeing. Ask codex to verify in JSONL that the subagents are using the requested model / effort.

> ### Workaround > [features.multi_agent_v2] > hide_spawn_agent_metadata = false > tool_namespace = "agents" Note that with this workaround, if your orchestration agent uses followup_task turns to continue interacting with the sub-agent, the followup_task turns silently inherit the orchestration agent's model and effort. In my observed run, an agent initially spawned as gpt-5.6-terra / high silently ran subsequent followup_task turns as the orchestration agent’s current gpt-5.6-sol / medium configuration. > but this doesn't work. It's still burning tokens like crazy. I don't think it's working right. @sfourdrinier - this could explain what you're seeing. Ask codex to verify in JSONL that the subagents are using the requested model / effort.

I have confirmed this as well. Even using this workaround the subagent is spawned as gpt-5.6-terra but the next interation (followup_task) changed the model to the one used in the parent agent (sol).

I am using another workaround which is defining agents in ~/.codex/agents:

~/.codex/agents/tier-middle.toml:

name = "tier-middle"
description = "Balanced agentic coding model for multi-file implementation and bounded edits with a clear spec"
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
developer_instructions = "Implement exactly the requested scope. Report diffs and verification commands run. Do not spawn subagents."

~/.codex/config.toml:

[agents.tier-middle]
description = "Balanced agentic coding model (gpt-5.6-terra) for multi-file implementation and bounded edits"
config_file = "/Users/henriquearthur/.codex/agents/tier-middle.toml"

You can set this up yourself or use this skill for an agent do it for you: https://github.com/fernandoeeu/codex-minions

I also have a skill which defines Tiers for different tasks in order to use different models. It contains instructions for the agent to use fork_turns: "none" in order to prevent using the previous turns from the orchestrator.

UPDATE:

So apparently this does not solve entirely. Even using the tier-middle agent I just had a session where Sol spawned subagents with Terra, but followup_task changed to Sol again.

It even injected this prompt in the followup turns:

<model_switch>
The user was previously using a different model. Please continue
the conversation according to the following instructions: ...
</model_switch>

I'll try to steer the model to never use followup_task in a subagent and always spawn new agents. That's probably cheaper than use Sol in the followup (and probably invalidates all cache as well).

Anyway, too many workarounds. We need a fix.

Independent reproduction on the current Windows desktop integration:

Environment

• ChatGPT/Codex Desktop: 26.707.31428
• Bundled runtime in rollout metadata: codex-cli 0.144.0-alpha.4
• Windows host, local WSL workspace
• Parent: gpt-5.6-sol
• Multi-agent metadata: V2

Reproduction

Three personal agent TOML profiles were present, pinned respectively to:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

The model-visible collaboration.spawn_agent schema exposed only:

• task_name
• message
• fork_turns

It exposed no agent_type, model, reasoning_effort, profile, or equivalent selector.

I launched three minimal children, using task names corresponding to the intended Sol, Terra, and Luna probes. Raw child rollout JSONL—not the task names, UI labels, or agent self-reports—showed:

• all three children had a non-empty session_meta.parent_thread_id linking them to the same parent;
• all three had agent_role = null;
• all three recorded turn_context.model = "gpt-5.6-sol".

Thus task_name only labeled the child path; it did not select the matching agent profile. This creates a material auditability risk: a child can be named “Terra” or “Luna” while actually consuming Sol.

Expected: V2 should expose a supported typed-agent/profile selector and apply the selected profile's model, reasoning effort, sandbox, and instructions. The resolved model should remain directly verifiable in the child rollout metadata.

Privacy note: local usernames, project names, absolute paths, thread/session IDs, and usage totals are intentionally omitted because they are not needed to reproduce the schema/inheritance bug.

My latest workaround is to have codex create agents using new threads rather than subagents; these are retaining their model settings. It makes the UI a bit more noisy but I also have codex managing the thread lifecycle (archiving when finished). All attained through chatting with the orchestration agent, nothing fancy. Avoiding subagents until there is a real fix.

I believe the documented workaround fixes custom-role resolution and rollout
metadata, but may not fix the model actually used for inference.

Environment:

• Codex CLI: 0.144.1
• Parent: gpt-5.6-sol
• Multi-agent version: v2
• Custom role: luna_high
• Configured child model: gpt-5.6-luna
• Configured effort: high

Configuration:

[features.multi_agent_v2]
enabled = true
hide_spawn_agent_metadata = false
tool_namespace = "agents"
````

The expanded `agents.spawn_agent` tool successfully accepts:

```text
agent_type = luna_high

The child rollout records appear correct:

agent_role = luna_high
model = gpt-5.6-luna
reasoning_effort = high
multi_agent_version = v2

<img width="781" height="446" alt="Image" src="https://github.com/user-attachments/assets/dab582c7-a91a-4693-87ad-e12f63113978" />

However, independent inspection of the actual model-request traffic shows that
the child inference requests still use gpt-5.6-sol:

<img width="448" height="420" alt="Image" src="https://github.com/user-attachments/assets/8d3a2f80-e24b-4ea6-8ef9-ab866eaf3646" />

All observed requests are Sol requests, including the turns correlated with the
luna_high child.

This suggests the role-specific model is applied to the local resolved config
and persisted rollout metadata, but is later replaced or ignored when the
actual inference request is constructed or dispatched.

This may be a V2 regression or continuation of #14671, which was previously
addressed by #14807.

The rollout metadata alone therefore may not be sufficient evidence that the
configured child model was actually used.

My Workaround For Now

Tell the main agent to use codex_app_create_thread to create agent.

• Native spawn_agent: child metadata can say Luna/high, but outbound traffic may still route to Sol due to the runtime bug.
• codex_app__create_thread: creates a separate user-visible Codex task and accepts explicit settings:

{
  "model": "gpt-5.6-luna",
  "thinking": "high"
}

It appears in the sidebar as “Sent by Codex from another task.” It is a separate task, not a native parent-child subagent, so result collection and follow-up happen through the thread ID.
<img width="343" height="118" alt="Image" src="https://github.com/user-attachments/assets/629ad7b0-7ecb-4faf-92da-397aec09bf8f" />

Outbound traffic with this workaround:

<img width="383" height="393" alt="Image" src="https://github.com/user-attachments/assets/d006e143-e986-4cb5-9b35-0489736f549c" />

Use wording like:

Create a separate Codex task using gpt-5.6-luna with high reasoning.
Do not use native subagent dispatch.
Handle this task: ...

Post-update retest on 2026-07-13, with an important distinction between the default behavior and the compatibility workaround.

Default control still reproduces

The installed runtime still reports codex-cli 0.144.0-alpha.4. A fresh ephemeral Sol session launched with --ignore-user-config reported exactly:

spawn_agent properties: fork_turns, message, task_name

So the default reduced schema remains; this issue should not be considered fixed or closed based on the app update alone.

Workaround now verified end to end

With a fresh Desktop session and:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

the callable spawn surface exposed agent_type, model, and reasoning_effort.

From one active gpt-5.6-sol parent, I then launched three minimal children using explicit pinned agent types and explicit model overrides:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

Raw child rollout metadata—not task names or self-reports—confirmed:

• all three children linked to the same Sol parent through session_meta.parent_thread_id;
• each child recorded the requested exact turn_context.model;
• each child used low reasoning effort;
• the configured agent_role was preserved.

A local accounting parser independently read the three real rollouts and assigned each child's tokens and API-equivalent cost to the correct Sol/Terra/Luna rate.

Conclusion

The compatibility configuration is now a verified workaround on this installation, including true heterogeneous Sol → Terra/Luna routing. The default --ignore-user-config behavior is still broken, so the underlying issue remains open.

Privacy: local paths, project names, thread/session IDs, account details, and aggregate usage totals are omitted.

@jif-oai can you please weigh in and tell us if we need to start migrating away, and if the v2 spec is locked or being refined?

cc: @tibo-openai

🙏

Confirmed in Codex Desktop on macOS with codex-cli 0.144.0-alpha.4.

I registered a custom role in the main config:

[agents.research_analyst]
description = "Read-only documentation and research specialist."
config_file = "agents/research-analyst.toml"

The referenced role config contained:

model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

After fully restarting Codex Desktop and starting a new task, I spawned the role using the exposed collaboration.spawn_agent interface with task name research_analyst.

The agent completed its assignment, but session metadata showed:

agent_role: null
model: gpt-5.6-sol
effort: medium
sandbox_mode: workspace-write

So the task name was used only as the agent path/name; the registered role and its model/sandbox configuration were not selected. The model-visible spawn interface did not expose a role/model/effort selector that could invoke this configuration.

Expected: the registered research_analyst role runs with gpt-5.4-mini, medium effort, and read-only sandbox.

Actual: it inherited the parent Sol model and workspace-write sandbox.

Retested on the released Codex CLI 0.144.2 after updating from 0.143.0. The default MultiAgent V2 control-surface regression is still present.

Environment

• macOS
• codex-cli 0.144.2
• npm package: @openai/codex@0.144.2
• Tests used codex exec --ephemeral --ignore-user-config --ignore-rules --enable multi_agent --json -s read-only
• No workspace or configuration files were changed

Same-binary A/B test

I gave both parents the same instruction: spawn exactly one worker using gpt-5.4-mini with high reasoning, without using shell/files, and report the exact spawn_agent arguments.

Sol / V2

Parent model: gpt-5.6-sol

The callable spawn arguments were limited to:

{
  "fork_turns": "none",
  "message": "Reply with exactly PROBE_OK and nothing else. Do not call any tools.",
  "task_name": "probe_worker"
}

model and reasoning_effort were not available in the exposed schema, so the parent could not express the requested override.

Luna / V1

Parent model: gpt-5.6-luna

The spawn completed successfully and the parent used:

{
  "agent_type": "worker",
  "model": "gpt-5.4-mini",
  "reasoning_effort": "high",
  "message": "Reply PROBE_OK without tools."
}

This demonstrates that natural-language model/effort steering still translates into explicit spawn arguments under V1, while the same request cannot be represented under the default V2 schema.

Source check

The relevant spawn schema is unchanged between rust-v0.143.0 and rust-v0.144.2. V2 still defines model and reasoning_effort internally, then removes them (along with agent_type and service_tier) when spawn metadata is hidden:

https://github.com/openai/codex/blob/rust-v0.144.2/codex-rs/core/src/tools/handlers/multi_agents_spec.rs#L595-L642

The default also remains hide_spawn_agent_metadata = true:

https://github.com/openai/codex/blob/rust-v0.144.2/codex-rs/core/src/config/mod.rs#L1159-L1178

This also conflicts with the current documentation, which says users can steer model/reasoning choice in the prompt:

https://learn.chatgpt.com/docs/agent-configuration/subagents#choosing-models-and-reasoning

Conclusion

0.144.2 does not fix the default V2 model/reasoning selection regression. V1 can still express the requested heterogeneous child configuration; default V2 cannot.

This A/B test verifies the exposed schema and spawn arguments. It does not claim to independently verify the downstream outbound inference model, which is a separate concern already documented in this thread.

MultiAgent V2 custom-agent routing reproduction

I reproduced this on Codex CLI 0.144.3 in a tool-backed MultiAgent V2 session.

This is specific to Sol and Terra. Luna can launch spawn subagent with specified model and effort

The project contains a valid custom agent at .codex/agents/reviewer_scoped.toml:

name = "reviewer_scoped"
model = "gpt-5.6-luna"
model_reasoning_effort = "xhigh"
sandbox_mode = "read-only"

The project skill explicitly instructs Codex to use reviewer_scoped. However, the exposed collaboration.spawn_agent schema only accepts:

task_name
message
fork_turns

It exposes no agent_type, custom-role selector, model, or reasoning-effort field.

I ran two controls:

1. Spawned a fresh child with task_name: "reviewer_scoped" and fork_turns: "none".

agent_path: /root/reviewer_scoped
agent_role: null
model: gpt-5.6-luna
effort: high

The task name became only the child path. The configured role was not selected, and the configured xhigh effort was not applied.

1. After the parent was running as gpt-5.6-terra / high, I started three team-review workers whose prompts explicitly requested reviewer_scoped.

All three recorded:

agent_role: null
model: gpt-5.6-terra
effort: high

This demonstrates that the children inherit the live parent model and effort rather than loading .codex/agents/reviewer_scoped.toml. Prompting for the custom agent and matching its name through task_name do not bind the configured role.

Expected:

agent_role: reviewer_scoped
model: gpt-5.6-luna
effort: xhigh

Actual:

agent_role: null
model/effort: inherited from parent

This appears to be the same MultiAgent V2 schema/routing problem described in #32587 and #32782.

The closed #26363 should not be treated as resolving this V2 behavior: PR #26599 explicitly restored selector visibility for V1 while retaining the hidden-metadata behavior for V2. The currently documented custom-agent configuration remains inaccessible through the default V2 collaboration.spawn_agent surface.

Additional persisted-JSONL control focused on configured custom-agent instructions:

• CLI 0.141.0 / MultiAgent V1: spawn_agent used agent_type with fork_context: false; the child recorded the selected custom role. One developer content item was byte-exact to the configured 7,216-byte instruction body (SHA-256 3181f9717ec96043519ac43c8c961364ffbaf9693301946177a75f0923ea9e85).
• CLI 0.144.1 / Sol-selected MultiAgent V2: the call exposed/used only task_name, message, and fork_turns: "none"; payload.source.subagent.thread_spawn.agent_role was null. None of six developer text items equaled or contained the configured instruction body.

Because fork_turns: "none" was already used, the failure is not explained by the full-history default. This extends the existing role/model evidence by showing that the configured developer-instruction layer was also not selected. Related umbrella: #32705.

This is a persisted V1/V2 control, not a claim that CLI version alone is the causal variable.

This should be fixed by https://github.com/openai/codex/pull/32749

This should be fixed by #32749

The solution does NOT support Luna, and Luna xhigh is 40% cheaper and faster than Sol on similar intelligence

Additional Codex Desktop / Windows production case:

I have a production skill with 10 registered [agents.*] profiles in config.toml. Each profile defines a specialized role with its own instructions, model/reasoning settings, and tool permissions.

In the current Multi-Agent V2 surface, spawn_agent exposes only:

• task_name
• message
• fork_turns

It does not expose agent_type, profile_id, or another configured-role selector. Using the profile name as task_name does not resolve the profile; it only labels the child task. Therefore, the role instructions, reasoning configuration, and tool allowlist are not reliably applied.

PR #32749 is an important partial fix because it restores explicit model and reasoning_effort overrides. However, it still does not restore configured custom-agent selection. Explicit model/effort overrides alone are insufficient for this workflow because the profiles also carry role-specific instructions and tool permissions.

Expected behavior:

spawn_agent should expose a supported agent_type or profile_id selector that resolves [agents.<role>] from config.toml and applies the complete profile:

• developer instructions
• model
• reasoning effort
• tool permissions / allowlist
• sandbox configuration
• role identity in child metadata

This currently blocks the full 10-agent workflow from running as designed in Codex Desktop.

The solution does NOT support Luna, and Luna xhigh is 40% cheaper and faster than Sol on similar intelligence

The model catalog is managed by the OpenAI service and currently uses Multi-Agent v1.
If you switch Luna to Multi-Agent v2 with a customized model catalog (via model_catalog_json config), Luna subagents work as expected. This has been tested with Codex 0.145.0-alpha.9.

This is funny. Tibo mentioned "slightly more usage of multi-agent than intended in high and xhigh reasoning effort", but the real issue might be just that the main agent cannot set a lower reasoning effort for subagents. This should have broken the workflow of many users.

@AtkinsChang @i-oliva

Or... just set model catalog to null/v1. Custom subagents work perfectly and better than v2 and you won't have this issue.

Retested on v0.145.0-alpha.7 containing #32749. The new manual model and reasoning_effort fields are present, but the registered profile is still not selectable: the V2 child has agent_role: null, does not apply the profile’s configured model/effort, and does not contain the configured developer payload. Full evidence is cross-posted to #32782.

Confirmed on codex-cli 0.144.4, macOS arm64, with a gpt-5.6-sol parent.

Without the workaround, the model-visible collaboration spawn call only contained task_name, message, and fork_turns. A valid personal custom agent at ~/.codex/agents/luna_medium.toml was silently ignored:

agent_role = null
model = gpt-5.6-sol
reasoning_effort = low

Using task_name = "luna_medium" only renamed the task; it did not select the role.

After adding:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

and starting a fresh session, the first full-history spawn attempt correctly rejected the incompatible combination of agent_type plus full-history inheritance. The retry without a full-history fork succeeded, and the child rollout recorded:

agent_role = luna_medium
model = gpt-5.6-luna
reasoning_effort = medium
sandbox = read-only

This confirms that the custom-agent TOML and Luna model are valid, and that hidden spawn metadata is the direct cause. The current default silently defeats documented role-specific model/reasoning settings, so exposing these routing fields by default (or clearly warning when a named role cannot be selected) would prevent unexpected Sol usage.

Independent reproduction on Linux/WSL with Codex CLI 0.144.4.

Environment:

• Client: codex-tui on WSL/Linux
• Configuration: multi_agent = true
• Parent configuration checked locally: model = "gpt-5.6-luna", model_reasoning_effort = "low"

Controlled comparison from fresh sessions:

| Parent model | turn_context.multi_agent_version | Model-visible spawn inputs | Result |
|---|---|---|---|
| gpt-5.6-luna | v1 | agent_type, reasoning_effort, fork_context (plus send_input, resume_agent, close_agent) | The orchestrator can request a worker with reasoning_effort: "low" and fork_context: false. |
| gpt-5.6-sol | v2 | Only task_name, message, fork_turns | No way to select agent_type, model, or reasoning_effort; children inherit the Sol parent configuration. |

The difference was observed with the same CLI release and the same local multi-agent setting. In the affected Sol/V2 surface, putting “use a cheaper model” or “use low effort” in the task message is not equivalent to a runtime override: the fields are absent from the callable schema.

Sanitized runtime observations:

CLI: 0.144.4
Parent: gpt-5.6-sol
multi_agent_version: v2
spawn_agent inputs: task_name, message, fork_turns
Control: gpt-5.6-luna / multi_agent_version v1
V1 spawn inputs include: agent_type, reasoning_effort, fork_context

Impact: choosing the stronger Sol parent removes heterogeneous delegation and prevents explicit control of child cost, latency, model specialization, and reasoning effort. This forces a choice between the stronger parent and useful per-subagent routing.

Expected behavior: a parent should be able to choose each child’s role, model, and reasoning_effort, independently of the parent model. At minimum, fork_turns: "none" should preserve that capability. Switching to a higher-capability parent should not reduce the functional delegation contract.

This is related to #20077, but distinct: #20077 describes override arguments that are present and rejected by the default full-history fork. This report demonstrates that Sol/V2 can remove those routing fields from the model-visible schema entirely, so even a fork_turns: "none" call cannot request them.

Please clarify whether the Luna/V1 versus Sol/V2 routing split is deliberate, a rollout, or a regression, and expose which multi-agent protocol is active in the client/session diagnostics.

This will be fixed here and will be in the next release: https://github.com/openai/codex/pull/32749

This will be fixed here and will be in the next release: #32749

Use case: GPT-5.6 Sol is used as the primary agent, while GPT-5.6 Terra is used as a subagent. GPT-5.6 Sol/Terra/Luna is configured through .codex/agents/custom.toml, where the subagent's role and responsibilities are defined. Question: It seems that this use case is still not addressed by #32749. A similar setup worked well with GPT-5.5. If #32749 does not resolve this scenario, then the subagent configuration file may still not be taking effect.

Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible

The best with 5.6 models is to let the model handle its sub-agents as much as possible

pardon, but EXACTLY this is the issue 😂

Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible

_"The best with 5.6 models is to let the model handle its sub-agents as much as possible"_
Sorry but this would make agentic frameworks like GSD-CORE (6.6k ⭐) or Superpowers (255k ⭐) completely unusable/useless with GPT-5.6... I would maybe reconsider since these are popular context engineering frameworks used by many (not counting people who spent time creating their own custom agents army)

> Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible _"The best with 5.6 models is to let the model handle its sub-agents as much as possible"_ Sorry but this would make agentic frameworks like GSD-CORE (6.6k ⭐) or Superpowers (255k ⭐) completely unusable/useless with GPT-5.6... I would maybe reconsider since these are popular context engineering frameworks used by many (not counting people who spent time creating their own custom agents army)

Agree, allowing custom sub-agents enables people familiar with their own workflows to maximize their potential.

Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible

Thank you for working on the follow-up PR.

I agree that model-managed delegation can remain the default and may provide the best global performance for many users. However, deterministic custom-agent selection is still essential as an explicit opt-in mode.

In structured and high-stakes workflows—such as document production, independent review panels, compliance audits, and reproducible agentic pipelines—the orchestrator must be able to select a registered role and verify that its complete profile was applied. This includes the role instructions, model, reasoning effort, sandbox, and supported tool policy. Allowing the model to choose everything autonomously cannot replace these guarantees, because role independence, audit separation, cost control, and reproducibility are part of the workflow’s correctness rather than merely performance preferences.

For reference, the GPT-5.5 / Multi-Agent V1 behavior already worked reliably for this use case: the orchestrator could select registered custom-agent roles and preserve role-specific delegation. It therefore provides a useful compatibility baseline. Ideally, Multi-Agent V2 should retain these deterministic V1 capabilities while adding the newer model-managed delegation features.

Users who enable this mode can knowingly accept any performance trade-off. Ideally, autonomous delegation and deterministic profile-based delegation should coexist instead of one replacing the other.

I described the full use case and the remaining requirements in #33314, including full-profile application, observable runtime metadata, explicit failure instead of silent fallback, continuation consistency, and deterministic lifecycle handling. I would greatly appreciate it if the follow-up PR could take these requirements into account.

Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible

Why? Trying to understand the reason behind the performance degradation to decide if it's worth the trade off

> Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible Why? Trying to understand the reason behind the performance degradation to decide if it's worth the trade off

I believe it's just a general statement, based on the fact that the model itself has a good enough judgement of when/how/why to spawn each sub-agent, + multiagents v2 provide (well, at least in theory as of now) pretty good knobs that the agent can very dynamically use, + the upside there is that it can tailor the delegation dynamically to the specific task at hand, which rigid configuration obviously can't do.

That said, I wouldn't treat their word as gospel. Case in point: Tibo said this a few days ago in response to the alleged usage drain in gpt-5.6 (paraphrasing, cannot find the tweet):

Do not manually cap the context window of gpt-5.6 to 272k to combat usage drain. The size of it's context window has been set deliberately so that it works just right.

Also tibo, literally a day later:

"We noticed that by changing the context size limit in the product to 372k for GPT-5.6 Sol, up from 272k for GPT-5.5, it resulted in more usage being charged than intended. We have reverted to 272k."

Also, I still don't understand the warning in codex when switching models mid-session, which says that it might degrade performance. That has never, ever been the case for me, not in Codex with OpenAI models, and not with any combination of public-weight LLMs. Quite the opposite, actually. It feels like when you switch to a dumber model from a smarter one, it keeps some of that mojo.

Point is: If it feels better for you, don't shy away from doing it your own way.

Configuration file for sub-agent will come in a follow-up PR. I'm on it. But this might have a negative impact on some global performance if used. The best with 5.6 models is to let the model handle its sub-agents as much as possible

@jif-oai , This is exactly the current issue. EVERY agent spawned is the same as the parent agent so users (like me!) are UNEXPECTEDLY burning through tokens at an incredible pace. The model should be able to delegate to smaller and less expensive models for thing like tests, easy changes, summarization, etc. However, in the current system by default Sol will AWLAYS spawn Sol.

Frustration well noted. Thanks for all your feedback

What will be possible in the next release:

• The agent can spawn sub-agents with different model or reasoning levels if you ask for it
• There will be 2 new parameters in the config to set the default model/reasoning effort for sub-agents
• We restore the "role" capabilities. A role is basically a config overlay to apply on a sub-agent (it is in the doc and I'll make sure the doc get updated with all of this)

2 limitations to note:

• 5.6 models will only be able to spawn 5.6+ models (e.g. 5.6-sol can spawn 5.6-luna but not 5.5)
• those capabilities will be "explicit" only. This means you will have to ask the model use different model, reasoning effort or role. This can be done through any information given to the model (i.e. prompt, skill, ...). The reason for this is that the model is not good enough yet to judge.

Does this work for you folks?

YES! Thank you Jif!

@jif-oai why the arbitrary restriction? surely 5.6 can spawn any agent/model. v2 is only a tools surface. You just need to revert #32751

To be precise, #32751 does not enforce a real “5.6+” model capability boundary. It filters models according to whether their catalog multi_agent tag matches the parent turn’s active backend. That is a client-side routing restriction, not an inherent limitation of MultiAgent v2 or the Responses API.

In any fork you can remove that gate while retaining unknown-model, reasoning-effort, and service-tier validation. A v2 parent can successfully spawn any model loaded in the catalog, including an untagged gpt-5.4 or any other model.

The limitation is not necessary for the v2 tool surface. Reverting #32751 would preserve defaults without preventing advanced users from selecting valid loaded models.

@jif-oai why the arbitrary restriction? surely 5.6 can spawn any agent/model. v2 is only a tools surface. You just need to revert #32751

Restricting the main agent and sub-agents to the same model series may be for better compatibility and performance.

@ignatremizov the reason is that multi-agent v2 can't be used by older models. The way it has been built and train is very different and an older models are just not able to deal with it (I won't go too deep into the details)

Lifting this restriction would just make a 5.5 sub-agent useless

@jif-oai why the arbitrary restriction? surely 5.6 can spawn any agent/model. v2 is only a tools surface. You just need to revert #32751

@jif-oai

Yes, @ignatremizov is right! We need it to work just the way it was, as many devs use Codex with obra/superpowers and similar frameworks. And to save costs, it is absolutely necessary for the main thread running Sol, for example, to be able to spawn gpt-5.4-mini for simple and well-defined subtasks.

Frustration well noted. Thanks for all your feedback What will be possible in the next release: The agent can spawn sub-agents with different model or reasoning levels if you ask for it There will be 2 new parameters in the config to set the default model/reasoning effort for sub-agents We restore the "role" capabilities. A role is basically a config overlay to apply on a sub-agent (it is in the doc and I'll make sure the doc get updated with all of this) 2 limitations to note: 5.6 models will only be able to spawn 5.6+ models (e.g. 5.6-sol can spawn 5.6-luna but not 5.5) * those capabilities will be "explicit" only. This means you will have to ask the model use different model, reasoning effort or role. This can be done through any information given to the model (i.e. prompt, skill, ...). The reason for this is that the model is not good enough yet to judge. Does this work for you folks?

Yes. In such shape, the behavior is fully overridable and steerable, and I am fine with 5.6-only. I disagree on the default restrictions, but that's out of scope.

One thing I would like to confirm though: will context forking (/ the turn-based context sharing thing in V2) be changeable by the model as well?

Restricting the main agent and sub-agents to the same model series may be for better compatibility and performance.

@xiaobing318 That assumes a compatibility constraint without identifying one. GPT-5.5 spawned subagents across different model families (and even providers) without issue. The rollout format is the same regardless of the selected model.

"Better performance" of what, specifically? Model quality, cost, latency, and orchestration behavior are properties users can evaluate for their own workloads. People already run heterogeneous setups such as Fable orchestrating GPT-5.6 agents, or the reverse. Advanced users should be allowed to make and monitor that trade-off themselves.

MultiAgent v2 is a tool surface, not a model compatibility boundary. Its encrypted inter-agent communication is another unnecessary restriction, but I won't get into that too much here since this issue is about other model spawing ability.

Frustration well noted. Thanks for all your feedback What will be possible in the next release: The agent can spawn sub-agents with different model or reasoning levels if you ask for it There will be 2 new parameters in the config to set the default model/reasoning effort for sub-agents We restore the "role" capabilities. A role is basically a config overlay to apply on a sub-agent (it is in the doc and I'll make sure the doc get updated with all of this) 2 limitations to note: 5.6 models will only be able to spawn 5.6+ models (e.g. 5.6-sol can spawn 5.6-luna but not 5.5) * those capabilities will be "explicit" only. This means you will have to ask the model use different model, reasoning effort or role. This can be done through any information given to the model (i.e. prompt, skill, ...). The reason for this is that the model is not good enough yet to judge. Does this work for you folks?

@jif-oai Thank you — this direction would work well for my use case. The two stated limitations are acceptable: using only 5.6+ child models is fine, and explicit role/model/reasoning selection is actually preferable for deterministic, high-assurance workflows.

I would only ask that the restored role capability be treated as a complete and verifiable configuration overlay, rather than only a role label or partial model override. Could the follow-up implementation please also clarify or guarantee the following?

1. Selecting a role loads its complete configured developer instructions, not only its name, model, and reasoning effort.
2. The role’s sandbox and supported tool policy are applied correctly. If a parent/runtime policy overrides them, the precedence should be explicit and any partial application should be reported before the child begins work.
3. The spawn result or runtime metadata exposes the effective role, model, reasoning effort, and sandbox, so the parent does not need to rely on child self-report.
4. Follow-up or continuation turns preserve the same resolved role and effective configuration.
5. A missing, invalid, or incompatible role fails explicitly instead of silently spawning a generic child.
6. Multi-Agent V2 provides close_agent or a documented equivalent for deterministic finalisation, slot reclamation, and an observable terminal state.

These points are especially important for independent reviewer panels and other reproducible workflows in which role separation and permissions are part of correctness, not just performance preferences. They are described in more detail in #33314.

Thank you again for taking this feedback into account and for working on the follow-up release.

Lifting this restriction would just make a 5.5 sub-agent useless

@jif-oai That does not match the observed history. People used MultiAgent v2 with GPT-5.5 for months. It had issues because it was experimental, and marked as such, and Eric Traut told us to stop reporting those issues. Not because GPT-5.5 subagents were inherently useless.

Also, a GPT-5.5 child spawned by a GPT-5.6 parent is not itself required to orchestrate through v2. The parent invokes the v2 spawn surface; the child receives a task and runs a normal Codex session. Its own multi-agent surface can even remain v1 or disabled, depending on config.

PR #32751 conflates the parent’s orchestration-tool version with the child model’s runtime compatibility. If there is a concrete incompatibility beyond that (perhaps the unnecessary encrypted inter-agent payload) then expose it as an explicit constraint or allow plaintext delivery. But blocking every model tagged v1 is much broader than "this child cannot handle this particular feature."

will context forking (/ the turn-based context sharing thing in V2) be changeable by the model as well?

@AspireOne yes, the model can choose to fork or not and how many turns to fork

@zhang8630 I will look into this and answer in the dedicated issue

to be able to spawn gpt-5.4-mini for simple and well-defined subtasks

@osavoskin one point where I agree with the general Codex direction: I suggest trying the same task with GPT‑5.4 mini and GPT‑5.6 Luna to compare before you ossify GPT 5.4-mini.

OpenAI reports Luna as its fastest and most affordable GPT‑5.6 model to date. That's not nothing. In Artificial Analysis’s published chart, Luna high scores above GPT‑5.4 mini xhigh while costing roughly one-fifth as much per evaluated task. That is estimated task cost, not raw token pricing (where Luna is a bit higher), and results will depend on the workload, so I would still benchmark both on your actual subtasks. I bet Luna low or medium would easily and cheaply cover any GPT 5.4-mini task, excepting large data processing tasks (like, maybe don't hook it up to Sentry alerts or certain log monitoring tasks)

This is another reason the client should permit both models instead of enforcing the choice through a backend model tag.

This is another reason the client should permit both models instead of enforcing the choice through a model tag.

Is it? You just argued that gpt-5.6-luna fully replaces gpt-5.4-mini. In fact, all GPT-5.6 models fully replace any given previous generation in terms of both price and capability. I think keeping it 5.6-only is actually cleaner and more predictable (given jif-oai insists that older models would struggle with it).

> to be able to spawn gpt-5.4-mini for simple and well-defined subtasks @osavoskin one point where I agree with the general Codex direction: I suggest trying the same task with GPT‑5.4 mini and GPT‑5.6 Luna to compare before you ossify GPT 5.4-mini. OpenAI reports Luna as its fastest and most affordable GPT‑5.6 model to date. That's not nothing. In Artificial Analysis’s published chart, Luna high scores above GPT‑5.4 mini xhigh while costing roughly one-fifth as much per evaluated task. That is estimated task cost, not raw token pricing (where Luna is a bit higher), and results will depend on the workload, so I would still benchmark both on your actual subtasks. I bet Luna low or medium would easily and cheaply cover any GPT 5.4-mini task, excepting large data processing tasks (like, maybe don't hook it up to Sentry alerts or certain log monitoring tasks) This is another reason the client should permit both models instead of enforcing the choice through a backend model tag.

@ignatremizov I am not sure, they say Luna’s raw token price is 33% higher than 5.4-mini. I guess, we will just need to migrate and see if the test results in the article are real.. But I would rather avoid that artificial restriction to GPT-5.6 models if possible.

You just argued that gpt-5.6-luna fully replaces gpt-5.4-mini

@AspireOne I argue for freedom. That we shouldn't be blocked which model is a spawned sub-agent. To try both. That GPT 5-6 Luna is an upgrade for most cases that GPT 5-4-mini is used for, but not all. We need data, and for that, we need feature flexibility.

I'm currently having 5.6 use 5.5 threads/tasks as a workaround, 5.6 seems to have no problem driving 5.5 at the conceptual level. Limiting 5.6 to 5.6 subagents seems like a regression against the docs at https://learn.chatgpt.com/docs/agent-configuration/subagents?surface=app#choosing-models-and-reasoning:

If you don’t pin a model or model_reasoning_effort, Codex can choose a setup that balances intelligence, speed, and price for the task. It may favor gpt-5.6-terra for fast scans or a higher-effort gpt-5.6 configuration for more demanding reasoning. When you want finer control, steer that choice in your prompt or set model and model_reasoning_effort directly in the agent file.

There is no stated limitation and immediately after:

gpt-5.6: Start here for demanding agents. It’s strongest for ambiguous, multi-step work that needs planning, tool use, validation, and follow-through across a larger context. gpt-5.4: Use this when a workflow is pinned to GPT-5.4. It combines strong coding, reasoning, tool use, and broader workflows. gpt-5.6-terra: Use for agents that favor speed and efficiency over depth, such as exploration, read-heavy scans, large-file review, or processing supporting documents. It works well for parallel workers that return distilled results to the main agent. gpt-5.3-codex-spark: If you have ChatGPT Pro, use this research preview model for near-instant, text-only iteration when latency matters more than broader capability.

Also note that in terms of pricing, 5.6 models charge for cache writes, other models do not, so there is a material difference in cost to the user when spawning short lived subagents.

For me the issue with the proposed approach is not being able to spawn subagents using local/custom providers. I've built caara specifically to give Codex the ability to spawn Claude Code or Antigravity as a native subagent by exposing them using the Responses API. If Codex requires 5.6+ models for subagents, this completely breaks caara and that ability. It also breaks being able to run local/free models as subagents. This is a significant regression.

I updated the Codex app today and asked the 5.6 Sol model whether it currently supports specifying a sub‑agent model. The response said that it does support specifying one, but only for gpt‑5.6‑sol and gpt‑5.6‑terra, and not for gpt‑5.6‑luna.
Is it because the model‑specifying feature hasn’t been officially released yet, or is gpt‑5.6‑luna truly not supported anymore?

<img width="551" height="583" alt="Image" src="https://github.com/user-attachments/assets/80a91eac-d51a-478d-b2f0-dd307cbe275b" />

yes, the model can choose to fork or not and how many turns to fork

fork_turns defaults to "all", but in my testing the child did not reuse the parent’s prompt cache for the inherited history, despite sharing the session-derived prompt_cache_key. Is this intentional? If full-history forks cannot reliably reuse the parent’s cached conversation prefix, leaving the inherited context uncached, why does fork_turns default to "all"?

> Is it because the model-specifying feature hasn’t been officially released yet, or is gpt-5.6-luna truly not supported anymore?

gpt-5.6-luna is currently marked as multi_agent_version: "v1" in the model catalog, so a V2 parent cannot select it when spawning a sub-agent. @jif-oai, could you share the background on why Luna is not enabled for V2?