Codex Subagents: How They Actually Work

OpenAI says this quite directly in product language. In the Codex app announcement, the company says the app is built to manage multiple agents at once, run work in parallel, and handle long-running tasks. [4] This is not just a new switch in the UI. It is a change in how Codex expects larger engineering work to be split up.

The technical docs explain the practical reason even more clearly. Even with large context windows, the main conversation starts to degrade if you keep pushing logs, traces, intermediate hypotheses, and test noise into it. OpenAI names two concrete problems: context pollution and context rot. [1]

That also lines up with independent research. Chroma's Context Rot report shows that reliability declines as context grows, especially on harder tasks. [8] In practice, Codex subagents are OpenAI's product answer to that engineering reality.

Anthropic describes a very similar pattern from another angle in its Agent SDK materials: subagents are useful for parallelization and context management because they work in their own isolated context windows. [11] So this is not an OpenAI-only idea. It is becoming a common pattern for long-running agent workflows.

If you strip away the branding, the model is straightforward: one parent thread orchestrates, one or more child threads perform clearly bounded tasks, and then the parent pulls everything back into a final answer.

This part matters because subagents no longer look like hidden internal magic. OpenAI has now documented both the built-in roles and the configuration surface around them.

Teams often get this wrong. On paid ChatGPT plans, the practical pain is usually not raw API token math. It is how quickly subagents burn through included limits or credits.

Subagents are not a universal upgrade. They are a coordination tool.

The most common mistake here is simple: people ask for subagents too vaguely. The working pattern is always the same: describe the split, give each child thread clear boundaries, and explain what exact output should come back to the main thread.

For PR review, a good prompt can look like this:

Spawn three subagents.
Agent 1: review security issues and secret handling.
Agent 2: review race conditions and concurrency risks.
Agent 3: review test gaps and flaky cases.
Return one merged summary with the most important findings first.

For implementation work, it is important to separate ownership:

Use two subagents.
Agent 1 owns the API handler and schema changes.
Agent 2 owns the frontend form and validation wiring.
Do not edit the same files. Summarize conflicts before making final edits.

For research-heavy tasks, it makes sense to request a cheaper child runtime immediately:

Spawn one explorer subagent per document.
Extract only the constraints, breaking changes, and migration risks.
Use `gpt-5.4-mini` for all child threads, then summarize in the main thread.

The key is the structure. One subagent, one narrow task, one clear output, and as little overlap with other threads as possible. [1][2][11]

Below is a practical set of recommendations for using subagents in Codex. The algorithm is fairly simple.

The first mistakes are usually predictable. Almost all of them happen when subagents are treated like free extra labor instead of an orchestration tool.

This article is based on current OpenAI documentation and product pages for Codex, pricing, changelog, and speed, plus external research on context degradation and Anthropic materials on the Agent SDK.