›_ Codex Issues
Codex Issues / #34301

GPT Sol and Terra threads cannot spawn Luna subagents because of Luna Multi Agent version

Open 💬 11 comments Opened Jul 20, 2026 by QuinnISHE
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.144.6

What subscription do you have?

Prolite

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Windows

What terminal emulator and version are you using (if applicable)?

Terminal app

Codex doctor report

What issue are you seeing?

gpt-5.6-sol and gpt-5.6-terra models are unable to use the spawn_agent tool to create gpt-5.6-luna subagents

What steps can reproduce the bug?

  1. Start gpt-5.6-sol thread
  2. Ask it to create a default gpt-5.6-luna subagent

What is the expected behavior?

Luna subagents should be available to spawn from Sol/Terra parents

Additional information

I believe this issue stems from the commit `92938d880e`, where it says "Restrict spawned-agent models to the active backend", luna is classified as using multi_agent version v1, instead of v2 like its other 5.6 counterparts. The v2 check is in codex/codex-rs/core/src/tools/handlers/multi_agent_common.rs on line 33:

pub(crate) fn model_supports_multi_agent_backend(
    model: &ModelPreset,
    multi_agent_version: MultiAgentVersion,
) -> bool {
    multi_agent_version != MultiAgentVersion::V2
        || model.multi_agent_version == Some(multi_agent_version)
}

But the correct behavior patch would be to change gpt-5.6-luna to use multi_agent v2 if thats the intended future route, or switch gpt-5.6-sol and gpt-5.6-terra to multi agent v1

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34024

Powered by Codex Action

DengNaichen · 1 month ago

Confirmed on macOS as well.

Environment:

  • macOS 26.5.2 (25F84)
  • codex-cli 0.145.0
  • Parent model: gpt-5.6-sol

Reproduction:
```text
spawn_agent(model="gpt-5.6-luna")

Result:

Unknown model gpt-5.6-luna for spawn_agent.
Available models: gpt-5.6-sol, gpt-5.6-terra

This confirms the issue is not Windows-specific and is consistent with the V2 parent filtering out Luna
because it is classified as V1.

RasputinKaiser · 1 month ago

Confirmed independently on macOS with the final codex-cli 0.145.0, and I traced the rejection through current main.

Controls

  • The active model catalog lists gpt-5.6-luna as picker-visible and API-supported.
  • A V1 child pinned to gpt-5.6-luna starts successfully on the same installation.
  • An isolated V2 child pinned to gpt-5.6-terra starts successfully and preserves the requested reasoning effort.
  • Switching only the requested child model to gpt-5.6-luna fails before a child is created:
Unknown model `gpt-5.6-luna` for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra

This rules out a general subagent, V2, role-file, or entitlement failure on this machine.

Source diagnosis

Current main still has the same behavior introduced by #32751:

  • gpt-5.6-sol and gpt-5.6-terra carry multi_agent_version: "v2".
  • gpt-5.6-luna carries multi_agent_version: "v1".
  • model_supports_multi_agent_backend() requires an exact V2 metadata match when the parent turn uses V2.
  • find_spawn_agent_model_name() applies that predicate before creating the child, producing the error above.

This is also inconsistent with the stated resolution of #31814. An OpenAI contributor said the next release would allow different child models and specifically gave 5.6-sol spawning 5.6-luna as the supported example. The final v0.145.0 now exposes the controls, but the catalog/backend filter still prevents that example.

The cost impact is material, not cosmetic. OpenAI documents Luna as the most cost-efficient GPT-5.6 tier at $1/M input and $6/M output, versus Terra at $2.50/$15 and Sol at $5/$30:

https://openai.com/index/gpt-5-6/

Suggested resolution

If Luna is compatible with the V2 agent-message transport, update its active and bundled catalog metadata to multi_agent_version: "v2" and add a regression covering a V2 parent spawning Luna.

If Luna must remain a V1 orchestrator, the current single metadata field is conflating two capabilities. In that case, split parent orchestration-backend selection from child-spawn compatibility so a V2 parent can launch a Luna child that does not itself need to orchestrate with V2.

At minimum, please document the restriction and reconcile it with the v0.145 promise and the #31814 resolution. Simply removing the compatibility check without confirming transport support would be riskier than fixing the catalog/capability model at its source.

Related final-release reproduction: #34700.

dhruv-openlane · 1 month ago

Facing the same issue on MacOS

  • Codex app build: 26.715.72359
  • Bundled CLI: 0.145.0-alpha.30
  • Terra/Sol parent: only Terra/Sol children
  • GPT-5.4 or Luna parent: Luna and GPT-5.4-mini children
  • multi_agent = true; V2 currently not explicitly configured
QuinnISHE · 1 month ago

There should probably just be a user config option to switch multi agent version, I compiled a modified Codex CLI with a way to switch multi agent versions in config, and it seems like theres nothing hard configured for models to use a specific version, older models can use v2 and newer models can use v1.

hitrich · 1 month ago

Follow-up with a tested implementation path:
I first tried the obvious bundled-catalog change, but that alone does not fix current ChatGPT users. OpenAiModelsManager::apply_remote_models() treats a non-empty ChatGPT /models response as authoritative, so a remote or cached catalog that still marks Luna as V1 continues rejecting Sol/Terra → Luna.
I now have a focused patch that:

  • marks bundled gpt-5.6-luna as V2;
  • retains the general V2 compatibility gate;
  • adds a narrow compatibility fallback for the exact gpt-5.6-luna slug when an authoritative catalog still reports it as V1;
  • keeps GPT-5.4 and other incompatible models rejected;
  • includes a ChatGPT-auth integration regression that deliberately serves Luna as V1 and verifies that the actual spawned child request uses gpt-5.6-luna.

The focused regressions, formatting, scoped Clippy, and all 41 model-manager tests pass locally.
If this matches the intended compatibility model and the issue is prioritized, would a maintainer please explicitly invite me to submit the focused PR? The patch is ready locally.

sbking · 22 days ago

I just spent 60% of my weekly usage in 12 hours because of this. My main loop didn't tell me that Luna was unavailable for spawn_agent, so it fanned out a ton of work to agents with its own model (Sol at xhigh).

austinbutler · 22 days ago
I just spent 60% of my weekly usage in 12 hours because of this.

Sounds like this issue is good to close as "working as intended" then.

sandipb · 9 days ago

According to the announcement on X, has this now been fixed?

QuinnISHE · 8 days ago

Yes this is fixed I believe

pomazanbohdan · 7 days ago

Conclusion: We have already fixed the direct Sol → Luna scenario.
Local Codex Desktop: package 26.818.2441.0.
Built-in codex.exe: 0.148.0.
Two child agents have already been successfully created in our task using gpt-5.6-luna/xhigh; there was no “Unknown model ... for spawn_agent” error.
PR #36892 has been merged and adds support for leaf models: a V2 parent can launch Luna as a worker, even if Luna itself does not have V2 capability. This has been included in CLI 0.147.0+. Issue #37536