Subagent fan-out can increase usage because each agent pays fixed context/tool/skill overhead

Summary

Multi-agent workflows can unintentionally consume more Codex usage than a single-agent workflow, even when subagents use smaller models.

The likely reason is the fixed per-agent context cost. Every spawned subagent is a new model context and may need to carry or reconstruct some combination of:

• system/developer/Codex instructions
• AGENTS.md / repo instructions
• available tool schemas
• skill catalogue / skill metadata
• environment/repository context and discovery
• delegated task instructions
• parent thread history when context is forked
• its own subsequent tool results and reasoning history

With several small subagents, that fixed cost is multiplied. A workflow intended to save usage by delegating small tasks to cheaper models can therefore backfire if each child only performs a small amount of useful work.

For example, splitting one investigation into five agents for manifest, permissions, upstream bug research, tests, and platform behavior may require all five agents to load substantially the same baseline universe before doing relatively little unique work.

Prompt caching may reduce compute/cost internally, but from a user perspective the Codex allowance can still appear to drain dramatically faster under aggressive subagent fan-out. This creates a bad optimization trap: users are encouraged to use smaller specialized agents to conserve usage, but the orchestration pattern may consume more of their allowance than one larger agent doing the work serially.

Requested improvements

1. Show per-agent usage in the UI, including parent and each subagent.
2. Break usage down into cached input, uncached input, output/reasoning, and ideally fixed/bootstrap context.
3. Show whether a child inherited/forked parent context and approximately how much context that added.
4. Warn when spawning many agents is likely to cost more than keeping the work in the current thread.
5. Consider making lightweight/isolated subagents truly lightweight: minimal tool schemas, only explicitly relevant skills, and no parent history unless required.
6. Consider an orchestration heuristic that groups tiny related tasks into one subagent instead of fanning them out.

A UI like this would make the behavior obvious:

Parent              84k
├─ android-agent    31k
├─ tests-agent      27k
├─ research-agent   34k
└─ review-agent     29k

Total              205k
Cached input        ...
Allowance charged  ...

Why this matters

Without visibility into the fixed cost of a subagent, spawning one feels nearly free. Architecturally it is not. This makes it very easy for users to accidentally burn through a weekly Codex allowance much faster while believing they are optimizing usage.

Related issues exist around subagent model/usage visibility and token breakdown, but the specific concern here is the multiplication of fixed context overhead caused by subagent fan-out and the resulting incentive mismatch.

No files, tests, or entry points are named. Start by locating subagent fan-out, usage accounting, and the UI or telemetry paths that expose model usage. Done means users can distinguish parent and child usage, context overhead, and allowance charges, with an agreed approach for warnings or lighter child contexts.