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

[spadaval]

What issue are you seeing?

GPT-5.6 Sol selects MultiAgent V2 through its model metadata (multi_agent_version = "v2"), independently of the features.multi_agent_v2 feature toggle. MultiAgent V2 then defaults hide_spawn_agent_metadata to true.

Despite its name, this setting does more than hide metadata in output. It removes these functional inputs from the model-visible spawn_agent schema:

• agent_type
• model
• reasoning_effort
• service_tier

The default was false (which I believe is correct), but was changed to true in PR #26114 by @jif-oai with the rather cryptic message For MAv2 CBv9.

Why is this a problem?

Sol's most important use case is as a subagent orchestrator.
This setting makes it impossible to use Terra/Luna subagents.

Steps to reproduce

1. Start a fresh session using gpt-5.6-sol with default MultiAgent V2 configuration.
2. Inspect the model-visible spawn_agent schema.
3. Observe that agent_type, model, reasoning_effort, and service_tier are absent.
4. Spawn a subagent and observe that it inherits the Sol parent configuration.
5. Set the following configuration and start a fresh session:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false

6. Observe that the routing fields are now exposed.

Expected behavior

GPT 5.6 Sol sessions should, by default, be able to spawn subagents with explicit models.

Possible fixes include:

• defaulting hide_spawn_agent_metadata to false;
• splitting output/description redaction from input capability controls;
• replacing the boolean with an explicit routing policy or model allowlist; or
• providing a documented subagent default model while preserving explicit overrides.

At minimum, the setting should be renamed and documented to make clear that it removes subagent routing capabilities.

Related issues

• Allow per-subagent model/provider/profile selection #14039 requests broader per-subagent model/provider/profile selection.
• Add global subagent runtime defaults for model, provider, and reasoning #26767 requests global subagent runtime defaults.
• Custom .codex/agents no longer selectable in CLI v0.137.0; subagents spawn generic and inherit parent model #26363 and Custom subagent roles not exposed in spawn_agent schema on Windows/Ubuntu, only default spawn available #26828 cover regressions and custom-role visibility caused by related hiding behavior.
• [CLI] GPT-5.5 forces MultiAgentV2 despite disable and hides documented custom-agent controls #31097 documents the forced V2 selection behavior.

Those issues are adjacent, but none addresses the specific default behavior of model-selected V2 on GPT-5.6 Sol.

Workaround

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

(note: the tool_namespace flag fixes the other common issue Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.)

[github-actions]

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

• [CLI] GPT-5.5 forces MultiAgentV2 despite disable and hides documented custom-agent controls #31097

Powered by Codex Action

[lightninglu10]

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.

[winoros]

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.

[lholden]

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.

[ignatremizov]

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.

[joshp123]

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.

[ajhcs]

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

[dazuiba]

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