Support global/default model configuration for subagents in config.toml
What variant of Codex are you using?
codex app
What feature would you like to see?
Currently, subagents (including built-in ones like explorer, worker, or custom agents) primarily inherit the main agent's model or require per-agent TOML files in ~/.codex/agents/ (or project-level .codex/agents/).
There is no simple way in the global ~/.codex/config.toml to set a default model (and optionally reasoning_effort) that applies to all subagents unless they explicitly override it in their custom agent definition.
This leads to several pain points:
- When I want most subagents to use a cheaper/faster model (e.g.
gpt-5.5-miniorgpt-5.5-codex-spark) while keeping the main agent on a stronger model (e.g.gpt-5.5), I have to create multiple custom agent files or rely on inconsistent inheritance behavior. - Managing model choice for subagents becomes scattered across many TOML files instead of having a clean global default.
- For users who frequently use multi-agent workflows, this adds unnecessary friction.
Describe the solution you'd like
Add support for a dedicated section in ~/.codex/config.toml (and project-level overrides) to configure the default model and reasoning effort for subagents.
Proposed configuration example:
model = "gpt-5.5" # main agent model
[agents]
max_threads = 8
max_depth = 2
# Global default for all subagents (Unless it is overridden in a custom proxy TOML or specified when the main proxy is created.)
[subagents]
model = "gpt-5.5-mini" # or "gpt-5.5-codex-spark", etc.
reasoning_effort = "medium" # low | medium | high
# Optional: service_tier, temperature, etc.
### Additional information
This feature would make multi-agent workflows much more practical and cost-efficient, especially for large codebases where many lightweight exploration or verification subagents are spawned.
It aligns with existing issues around subagent configuration and would provide a much cleaner user experience.
Thank you for the great work on subagents — they're already very powerful!This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗