# Codex cli can no longer spawn subagents with specific models or reasoning **URL:** \ **Category:** Codex\ **Created:** [July 10, 2026, 11:47am UTC](https://community.openai.com/t/codex-cli-can-no-longer-spawn-subagents-with-specific-models-or-reasoning/1386290 "2026-07-10T11:47:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![joeb92](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/joeb92/32/511264_2.png) [@joeb92](https://community.openai.com/u/joeb92)\ **Post date:** [July 10, 2026, 11:47am UTC](https://community.openai.com/t/codex-cli-can-no-longer-spawn-subagents-with-specific-models-or-reasoning/1386290/1 "2026-07-10T11:47:03Z")
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 ---
**Author:** ![Jeffrey\_Cox](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/jeffrey_cox/32/749968_2.png) [@Jeffrey\_Cox](https://community.openai.com/u/Jeffrey_Cox)\ **Post date:** [July 14, 2026, 3:23am UTC](https://community.openai.com/t/codex-cli-can-no-longer-spawn-subagents-with-specific-models-or-reasoning/1386290/2 "2026-07-14T03:23:16Z")
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](https://us1.discourse-cdn.com/openai1/original/4X/0/d/4/0d47249374a9776f225496f46e06e0ace94a328d.png) 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 ---
**Author:** ![Xiaohan\_Huang](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/xiaohan_huang/32/523031_2.png) [@Xiaohan\_Huang](https://community.openai.com/u/Xiaohan_Huang)\ **Post date:** [July 16, 2026, 7:29am UTC](https://community.openai.com/t/codex-cli-can-no-longer-spawn-subagents-with-specific-models-or-reasoning/1386290/3 "2026-07-16T07:29:16Z")
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: ```toml [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: ```plaintext 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: ```plaintext 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: ```toml model_catalog_json = 'C:\Users\\.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. ---
**Author:** ![hieuphung97](https://avatars.discourse-cdn.com/v4/letter/h/8797f3/32.png) [@hieuphung97](https://community.openai.com/u/hieuphung97)\ **Post date:** [September 3, 2026, 12:51am UTC](https://community.openai.com/t/codex-cli-can-no-longer-spawn-subagents-with-specific-models-or-reasoning/1386290/4 "2026-09-03T00:51:07Z")
Hit the same wall. What I settled on was to stop using subagents for this at all. Instead of spawning a child inside the session, I launch a separate CLI session for the phase and pin the model and effort on the command line at launch. The parent never spawns anything. It writes a short brief to a file, opens the other session, and watches it. Model and effort are whatever I pinned for that phase, because it is a fresh process with its own flags. The side effect I did not expect was the context. A subagent inherits the parent’s history whether you want it to or not. A separate session starts from the brief and nothing else. For review work, that turned out to matter more than which model I picked. Here’s what it looks like running, if it helps: hxxps://youtu.be/6pRWkhlQSAc (replace “xx” with “tt”), the dispatch at 2:39 is the part relevant to the topic, where the phase gets handed off with its own model pinned. ![dely-demo](https://us1.discourse-cdn.com/openai1/original/4X/8/9/a/89a0779a17926730c35d8adbbcba6d267e606e6e.gif) The honest downside is that you now need something to open and watch those sessions. I use Orca for that, and I wrote the dispatch layer as a plugin: hxxps://github.com/hieuphung97/dely (replace “xx” with “tt”) It drives Codex, Claude Code, Cursor, and a few others, so the review phase can run on a different vendor entirely, which sidesteps the inheritance problem by construction rather than by config.