Codex subagents are getting config files and model selection

Codex is readying a configurability update that lets you define custom subagents in a config file. Each subagent can be named with its own role, instructions, model, and reasoning level—making it easier to split planning, orchestration, and execution.

Codex subagents are getting config files and model selection

TL;DR

  • Custom subagents via config file: Create, define, and launch subagents through simple config edits
  • Per-subagent model and reasoning: Select model/reasoning level individually for each subagent
  • Configurable identity and guidance: Set name, role, instructions to organize parallel agent workflows
  • Richer definitions: Include description, rules, prompt, plus model/reasoning level for skill-like behavior
  • Workflow pattern: Plan with one model, orchestrate with another, execute with Spark for focused tasks
  • Observability: Use the /agent command to review and watch complete agent threads

Subagents in Codex are about to get a lot more flexible, with a configurability update scheduled to “launch tomorrow”. The headline feature is straightforward but meaningful for agent-heavy workflows: custom subagents defined in a config file, with the ability to choose model and reasoning level per subagent.

That shift effectively turns subagents into first-class, user-shaped components—useful any time planning, orchestration, and execution benefit from different tradeoffs in speed and depth.

Custom agents, defined (and named) by config

The update centers on making subagents something that can be created, defined, and launched via a simple config edit. Alongside basic wiring, subagents can also be given a name, role, and instructions, which should make multi-agent setups easier to organize when many specialized threads are running in parallel.

Mixing models by task: plan, orchestrate, execute

A key idea in the posts is splitting work across models:

  • Plan with one model
  • Orchestrate with another
  • Execute with Spark (mentioned as an example execution target)

The suggested pattern is to keep the smartest model in the main thread for orchestration, while delegating “singular focused tasks” to Spark subagents—especially when Spark is given “a lot of really good upfront context” so it can avoid heavy exploration.

That combination—high-intelligence coordination paired with faster subagent execution—is positioned as the practical win of the configurability update.

What a subagent definition includes

Beyond name/role/instructions, subagents can be defined similarly to skills, with:

  • A description that tells Codex when it should call the subagent
  • Rules for how it should behave
  • Prompt
  • Model/Reasoning level

There are also hints at broader subagent support: when asked whether custom subagents will get support (including bringing over “librarian/oracle”), the response was an unambiguous “Yes they will!”

Watching what agents are doing

One practical note surfaced around observability: for checking what agents did and how they interacted, the thread points to the /agent command, which can be used to “review and watch the whole thread(s).”

Original source

Continue the conversation on Slack

Did this article spark your interest? Join our community of experts and enthusiasts to dive deeper, ask questions, and share your ideas.

Join our community