Tool tutorial · XiaoHu Explains

Codex Multi-Agent V2 in practice: splitting tasks, assigning models, and controlling costs

Eric Provencher from the OpenAI Codex DX team shares a multi-agent orchestration approach: first decide whether a task can be split cleanly, then configure models, reasoning effort, communication, and context, and finally track both time and token budgets.

One-minute overview
  • The value of multi-agent setups is overlapping independent work. Tasks that are tightly coupled, must run sequentially, or involve heavy shared edits usually shouldn't be split.
  • Use three checks before parallelizing: independent completion, independent verification, and low write conflicts. Then assign reasoning effort to Scout, Worker, and Smart worker based on difficulty.
  • The lead agent keeps ownership and final sign-off. Dependencies can be sent directly between agents, and context is trimmed to match task dependencies. Platform security boundaries still apply.
  • Multi-agent setups can reduce wall-clock time, but total token usage and coordination overhead usually go up. Always validate with a real task, checking time, duplication, conflicts, and rework.

Eric Provencher on the OpenAI Codex DX team recently published a practical guide to multi-agent workflows. It details how, under Codex's Multi-Agent V2, you can split a complex task across different agents without creating duplicate investigation, bloated context, or overlapping changes.

The real value here isn't the advice to "spin up more agents." It's the recommended configuration order: first decide whether the work can be split, then determine who does what, how much reasoning to use, and how much context to carry. Only then do you codify the rules into a Skill. The core principle isn't "switching models saves money" but rather reduce unnecessary reasoning first, then use parallelism to cut down on unavoidable wait time.

Codex's Ultra mode makes agent coordination the default behavior. It's suited for work with high ambiguity, scattered context, or significant risk; routine tasks don't need Ultra from the start. Eric's alternative is to stay on Sol Medium and use a short prompt or Skill to define the orchestration rules explicitly: the lead agent continues to communicate with the user, delegates background work, and only raises the reasoning effort for the genuinely hard parts.

Decide whether to split first, then assemble the team, then tally the cost The seven questions aren't seven isolated tips—they form a configuration chain with a deliberate order.
  1. 1Why do you need multiple agents?
  2. 2Which tasks can be split?
  3. 3Which model should handle each piece?
  4. 4How should agents coordinate?
  5. 5How much context should each agent get?
  6. 6How do you turn this into a reusable Skill?
  7. 7What do you save, and what does it cost?
Look at task structure before talking models or parallelism; otherwise every later configuration may rest on a faulty split.

Why multi-agent

A single agent completing a complex task typically works through a sequence: read the code, check tests, confirm boundaries, implement, then verify. The problem isn't that each step is slow—it's that many investigations that could happen in parallel are forced into a queue.

Time structure

Each step isn't faster—overlappable waits get stacked together

The same four pieces of work, with the only difference being whether the first three must queue.
Single agentWaits on each item
Check codeVerify permissionsFind testsIntegrate
Multiple agentsIndependent investigations overlap
Check codeVerify permissionsFind testsIntegrate
What actually shrinks is wall-clock timeOnly independent steps can overlap; final judgment and integration still have to happen.
Diagram isn't a fixed timing model. The time benefit of multiple agents depends on how cleanly the task can be divided.

The first benefit of multiple agents is overlapping independent waits: one scout traces the call chain, another checks permissions and test coverage, while the lead agent confirms scope with the user. Once the evidence comes back, the implementation phase avoids a detour.

But if the work is tightly coupled, adding agents is pointless. When the next step depends on the previous result, everyone needs to modify the same core code, or the final answer can only be judged as a whole, a single agent is usually faster. Whether to parallelize depends on the task structure, not on how many agents your tool can launch.

What tasks can be split