Codex Subagent Models with multi_agent_v2

The expensive default

If you run Codex with multiple agents, the default can be surprisingly expensive: a helper may inherit the parent model and reasoning effort even when the job is only search, triage, or a test run.

Eidzoku (@evi77ain) spotted the missing controls in spawn_agent:

In that setup, spawn_agent did not expose a model or reasoning-effort field. A helper launched by a Sol Ultra session therefore ran at the same tier as its parent—even when the work did not need it.

That defeats one of the useful parts of orchestration: matching the cost of each agent to the job.

The configuration

A follow-up in the thread shared the feature configuration that exposes the missing spawn metadata:

Eidzoku@evi77ain
You want this in your config.toml: [features.multi_agent_v2] hide_spawn_agent_metadata = false tool_namespace = "agents"
Eidzoku@evi77ainThere's a flaw in Codex's (or should I say ChatGPT's?) subagent orchestration. The spawn_agent tool doesn't let you choose the model or reasoning effort. Therefore, every time 5.6 Sol Ultra spawns a subagent, you're getting another Sol Ultra instance. That's why your quota
Jul 10, 2026255 likes8 replies

Add this to your Codex config.toml:

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

The post in the thread only includes the final two keys. I include enabled = true because the installed Codex CLI lists multi_agent_v2 as an under-development feature and reports it as disabled by default.

Restart Codex after changing the file. In a new session, the agent-spawn tool should expose optional model and reasoning-effort fields. That lets the parent keep a stronger model while assigning routine work to a faster one.

Verify it on your machine

First, check the installed version and feature state:

codex --version
codex features list | grep multi_agent_v2

After enabling the block and restarting Codex, start a fresh multi-agent session and inspect the available spawn_agent arguments. You are looking for model and reasoning-effort controls—not merely confirmation that the feature name exists.

If Codex rejects the keys or the fields still do not appear, remove the block rather than assuming it changed runtime behavior. The public Codex configuration reference remains the source of truth for supported settings.

Why it matters

Multi-agent coding only pays off if routine steps can stay routine. A parent that plans and reviews should not force every explorer and test runner onto the same tier.

In practice that looks like:

Role	What you want
Parent / orchestrator	Strong model, higher reasoning
Codebase explorer	Smaller / faster model
Test runner / summarizer	Minimal reasoning effort

Without model selection on spawn, every row can inherit the parent tier. Quota becomes the bottleneck long before orchestration helps.

A few notes from the thread

The original report describes observed behavior, not a documented guarantee across every Codex surface.
The installed CLI calls multi_agent_v2 an under-development feature, so its name and behavior can change.
A successful config parse does not prove model selection is active. Confirm that the spawn tool actually exposes the fields.
Restart Codex after editing config.toml; an existing session may keep its original tool schema.

Bottom line

If Codex usage jumps whenever it fans out work, check whether subagents inherit the parent model. On builds that support it, multi_agent_v2 can expose the controls needed to choose models and reasoning levels per helper.

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

Small config change, but verify the resulting tool schema before counting on the savings.