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
- Show per-agent usage in the UI, including parent and each subagent.
- Break usage down into cached input, uncached input, output/reasoning, and ideally fixed/bootstrap context.
- Show whether a child inherited/forked parent context and approximately how much context that added.
- Warn when spawning many agents is likely to cost more than keeping the work in the current thread.
- Consider making lightweight/isolated subagents truly lightweight: minimal tool schemas, only explicitly relevant skills, and no parent history unless required.
- 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.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is why you are getting codex-limit drains.
Additional anecdotal data point from the reporter: after disabling the broad plugin/skill setup and turning off the recent multi-agent-heavy workflow, Codex usage dropped to roughly 1% over ~4 hours of continued use.
Before that change, usage had been draining much faster under a configuration with every suggested plugin enabled, ~53 skills, and frequent agent fan-out.
This is not a controlled benchmark and does not isolate which component is responsible, but it is a strong enough before/after signal that it may be worth instrumenting specifically. In particular, it would be useful to compare:
The concern is not only user quota consumption: if repeated subagents are each processing large baseline contexts/tool schemas/skill metadata for small delegated tasks, there may also be unnecessary backend inference/GPU cost despite prompt caching.
The biggest product issue is that users are being encouraged to enable skills/plugins and use agents as an efficiency pattern, while the current UI provides no way to see whether that configuration is actually more expensive than a simpler single-agent setup.
In version 0.148.0, the context window sizes for the main thread and sub-threads could be configured separately. However, why was this reasonable and excellent design removed in version 0.149.0? This forces the entire sub-thread to be enabled if I want to open a larger context window, such as 1,000,000. Is this to make users pay more for OpenAI?
@urays I think this may be an important clue and could explain why the behavior suddenly became so noticeable.
One distinction worth making: a 1,000,000-token context window does not itself mean every sub-agent consumes 1,000,000 tokens. The window is capacity, not necessarily actual input size.
However, if the change from 0.148.0 → 0.149.0 removed the ability to configure a smaller context window for sub-threads independently of the main thread, that could absolutely be the trigger for the regression we're observing.
The mechanism I'm concerned about is this:
So the two observations may fit together rather than conflict:
For example, if a parent has accumulated 100k–200k of effective context, previously a constrained child may have received a compacted subset. If the child can now accept the whole thing, spawning 5–10 agents can suddenly become dramatically more expensive even though none of them is anywhere near the full 1M limit.
This would also explain why the regression could appear suddenly around a version/configuration change even though multi-agent support itself already existed.
It would be extremely useful if the Codex team could instrument/confirm across 0.148.0 and 0.149.0:
Right now we can only infer this from the usage meter, but @urays' version-specific observation gives a very concrete place to investigate.
@ChrisMasterton Actually, I think the context window, whether it's the original default 272K, the current 1M, or 512K, isn't the problem. The key is how to intelligently determine when to compress.
Unfortunately, I haven't seen a mature approach on Codex or other agent harnesses... However, if the Codex team does it, it would be a truly groundbreaking breakthrough.
Agreed that by itself isn’t a problem, it’s the compounding effect of more
context and tokens being introduced, easily and without transparency.
Potentially (again, compounded by) a lack of prompt caching on new agents,
new /side-chats (?).
To me that explains why we see such different patterns with some draining
limits in hours and others seemingly not affected. If you work for OAI you
have infinite tokens so you are literally not going to see the issue unless
you have tests in place to count token in/out on the same repeated tasks.
On Fri, Aug 21, 2026 at 7:04 AM urays @.***> wrote: