Codex cli can no longer spawn subagents with specific models or reasoning

Codex
1

Up until the 5.6 drop, you could tell Codex to spawn a subagent with a specific model and reasoning effort. That no longer seems to be possible (despite the fact there are now so many new options for model and reasoning effort) and subagents just inherit model and effort from the parent. I tried looking into this (i.e. I asked codex to look into it) and it suggested that 144 changed the spawn_agent settings and removed some of the options.

Has anyone found a way around this? I think it’s a strange functionality to have removed since you can no longer have a more intelligent model plan and then delegate to a a faster and cheaper model fro implementation. And I am back to copy and pasting between different instances in the meantime so as not to burn through loads of tokens

2

apparently there is a new version of the subagents call version 2, I had to dig into the code with codex ti figure it out. That said, it doesn’t work the same… you can choose model and effort. However, the agents are completely behind the scenes. /agents doesn’t work with them any longer, I had codex give me a summary of the change for my plugins:

Yes—the change was for Codex MultiAgent V2. The central issue was that the old spawn pattern could appear to select a GPT‑5.6
child while actually inheriting the parent’s model and effort.

What changed:

image
image2376×548 62.4 KB

The required configuration became:

“[features.multi_agent_v2]”

hide_spawn_agent_metadata = false
tool_namespace = “agents”

The resulting dispatch flow is:

permission-appropriate parent
→ fresh spawn with agent_type + bounded fork
→ verify role/model/effort/permission in turn_context
→ accept the result or respawn

We standardized GPT‑5.6 into five managed execution profiles:

  • review_max: gpt-5.6-sol / max
  • review_high: gpt-5.6-sol / high
  • test_medium: gpt-5.6-terra / medium
  • scan_low: gpt-5.6-luna / low
  • monitor_low: gpt-5.6-luna / low

For generic children, we now pass both model and reasoning_effort; specifying only the model does not establish the compute
budget. We also avoid resumed children for budget-sensitive work because they can adopt the coordinator’s current model and
effort.

The permission limitation was important: reviewer/scanner profiles must run beneath a read-only parent, while test_medium runs
beneath a workspace-write parent. The child TOML cannot safely narrow a more powerful parent.

This also produced the operating policy now in your guidance: use Luna for bounded auxiliary work, Terra for ordinary
implementation, and Sol only for consequential or unusually difficult judgment. Settings remain “requested” until runtime
evidence proves them.

The change landed in PR #26, commit e27c6f9, and is documented in the docs/work-sessions/2026-07-11-verified-workflows-v2-
bootstrap.md and plugins/verified-workflows/README.md.

Separately, outcome.dispatch.v2 is the launch-acknowledgement protocol. It is related modernization work, but it is not the
mechanism that enabled GPT‑5.6 profile selection.

repo: infiquetra/infiquetra-codex-plugins

3

I reproduced a Codex multi-agent regression on Windows with Codex CLI 0.144.5 and found a working workaround.

Although my configuration explicitly contained:

[features]
multi_agent = true
multi_agent_v2 = false

codex features list confirmed that V2 was disabled, but fresh GPT-5.6 Sol and Terra sessions still exposed the V2 spawn_agent schema containing only task_name, message, and fork_turns. The schema did not expose agent_type, model, or reasoning_effort.

Before applying any workaround, the model catalog showed:

gpt-5.6-sol    multi_agent_version: v2
gpt-5.6-terra  multi_agent_version: v2
gpt-5.6-luna   multi_agent_version: v1

A fresh gpt-5.3-codex-spark xhigh session provided a useful control test. It used the V1 behavior and displayed the spawned child role, model, and reasoning effort:

Spawned Aristotle [worker] (gpt-5.3-codex-spark xhigh)

This behavior matches the configuration-precedence problem reported in github issue: the model catalog can select V2 even when features.multi_agent_v2 is false, and the selected schema remains pinned to the thread.

I restored V1 by creating a local snapshot of the current model catalog, changing only the Sol and Terra multi_agent_version values to v1, and configuring:

model_catalog_json = 'C:\Users\<username>\.codex\models-v1.json'

[features]
multi_agent = true
multi_agent_v2 = false

After restarting Codex and opening a fresh session, Sol, Terra, and Luna all reported V1, and the original V1 subagent controls were available again.

One Windows-specific detail is important: the JSON catalog must be UTF-8 without BOM. Some PowerShell versions write a BOM with Set-Content -Encoding utf8, which Codex rejects at line 1, column 1. Writing the file with UTF8Encoding(false) avoids that failure.

The workaround has one significant limitation: a local model_catalog_json is a static snapshot of the entire catalog. It must be regenerated when OpenAI updates model metadata.

It may also interfere with Ultra. Sol and Terra advertise Ultra support and were originally assigned V2, while the official documentation describes Ultra as capable of proactive subagent delegation. If that orchestration path depends on MultiAgentV2, forcing V1 could disable proactive delegation, degrade coordination, or cause a runtime/tool-schema mismatch. A successful ordinary V1 subagent test does not prove that Ultra remains fully functional.

There is also an interesting but unconfirmed correlation. Sol and Terra originally used V2 and supported Ultra, while Luna used V1 and did not support Ultra. Official documentation says Ultra can proactively delegate work to subagents. MultiAgentV2 may therefore be related to Ultra orchestration, but I have not found evidence establishing that as the reason for V2, and full Ultra behavior under the V1 override has not been tested.

Users who depend on Ultra should treat this workaround as experimental, test Ultra separately, and keep a rollback path available.