Logan Kelly

74 Agents, 5.39B Tokens: Why AI Agent Cost Control Misses the Delegation Tree

74 Agents, 5.39B Tokens: Why AI Agent Cost Control Misses the Delegation Tree

One Codex task spawned 74 subagents and 5.39B recorded tokens. Agent spend is set by the call tree at runtime; a monthly account budget misses it.

Waxell blog cover: dark canvas with the title "The score held. The layer broke." over a faint technical grid.

Between 15 and 17 August 2026, one Codex coding task turned into 74 subagents. The developer who filed issue #38989 against openai/codex reconstructed the tree from local session telemetry: 75 execution threads counting the root, 82 spawn attempts, recursion three levels deep, and 5,389,446,245 recorded tokens, of which 4,977,729,875 came from the subagents. A limit did exist — seven spawn attempts failed with "agent thread limit reached" — and the tree still got to 74. What ended it, on the reporter's account, was a sentence typed into the running session: "Continue, but do not create any more subagents." After that, no further spawn attempts occurred and the remaining work finished in about three and a quarter hours.

AI agent cost control is the practice of bounding what a run is allowed to spend while it is still running. It is a different thing from cost optimization, which makes each call cheaper, and from cost visibility, which prices calls once they are already billed. The distinguishing property is the unit: an agent decides at execution time how much work to create, so a control that binds anything larger than the run — a credential, an account, a calendar month — is measuring a quantity the architecture does not produce.

The reporter's caveats are worth carrying: this is usage recorded in local and backend session telemetry, not billed subscription usage, and it is not a controlled benchmark. The tree itself is not an estimate — it was reconstructed from spawn edges, cross-checked against the local state database, and all 74 subagent token values matched.

Why does agent spend scale with the shape of the run rather than the size of the task?

Because, in the words of the issue title filed against openai/codex, each agent pays a fixed context, tool and skill overhead — and pays it again every time one is spawned.

A companion issue on the same repository, #39808, names the mechanism precisely. Each subagent is a new model context that may need to carry or reconstruct system and developer instructions, repository instructions, available tool schemas, the skill catalog and its metadata, environment and repository discovery, the delegated task instructions, and — when the context is forked — the parent thread's history. Its author's summary is the line worth pinning above a cost dashboard: "Without visibility into the fixed cost of a subagent, spawning one feels nearly free. Architecturally it is not." The issue calls the result a bad optimization trap, because the pattern users are encouraged to adopt to save money is the pattern that multiplies the baseline.

The 74-agent run puts a number on the forking half of that. Grouped by fork mode, the 30 agents that inherited history accumulated roughly 4.824 billion tokens; the 44 that started context-free accumulated about 153 million. Same session, same task, two orders of magnitude apart. The reporter notes those groups did different work, so the gap is not attributable to forking alone — but the direction is hard to argue with.

Anthropic measured the same shape from the other side. Its engineering write-up of the multi-agent Research system reports that "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats," and that token usage by itself explains 80% of performance variance on the BrowseComp evaluation. In Anthropic's own analysis, multi-agent architectures work largely because they spend enough tokens to solve the problem. Spending is the mechanism, not the side effect.

Arize's write-up of the same problem is blunt about the shape of the curve — "Agent costs scale non-linearly with traffic" — because context accumulates across turns, so a tool returning a large payload is paid for again on every subsequent step of the same trace.

Who decides how many agents to spawn?

The model does, mid-run, and the common answer to that today is a prompt.

Anthropic is explicit that this needed managing: early versions of its research system "made errors like spawning 50 subagents for simple queries," and the fix was to embed scaling rules in the prompt — one agent and three to ten tool calls for simple fact-finding, more than ten subagents for complex research. Those heuristics work. They are also advice given to a non-deterministic system, not a bound enforced on it.

The Codex report shows what happens when the advice does not hold. Of the 74 subagents, 53 carried names containing review, rereview, audit or preflight, and one subtree, task4_design_review, expanded on its own to 39 agents and roughly 3.263 billion accumulated tokens. The rollout logs contain at least 18 full pytest -q runs; one identical set of controller tests ran 13 times. The reporter's read is that an iterative implement-test-review-fix chain was converted into a recursive tree — "more agents produced substantially more work, but not necessarily more useful parallelism."

Notice where the error in a forecast like this actually sits. A number produced for a coding job is not wrong about the coding job. It is silent about a tree of review loops that did not exist when the number was written, and could not have, because the tree is a runtime artifact.

Why does the budget you already have miss it?

Because it is scoped to a billing period and an account, and the tree lives inside a single run.

IDC's Future Enterprise Resiliency and Spending Survey, Wave 4, fielded in July 2026, puts average monthly spend on agent inference and related orchestration, among enterprises with visibility into their own agent costs, at $117,558. Against that, 67% of enterprises ran over their agent spend budget by more than 10% in the past 12 months: 43.1% moderately over by 10% to 25%, 18.5% significantly over by 26% to 50%, and 5.4% past forecast by more than 50%.

The paradox IDC draws out of its own data is the part that should sting. 61.8% of organizations rate their cost governance as "defined" or "optimizing," while 45.4% have real-time dashboards tracking token consumption and cost by workflow. Two thirds believe their governance is mature; two thirds missed budget. IDC's recommended fixes are pointedly operational — replace the monthly invoice review with real-time cost visibility, and fund cost governance as an engineering discipline, because the controls that work best are built rather than written into a policy memo.

The stronger tooling is honest about which half of the loop it closes. Arize's Cost Agent finds the expensive spans and ships the savings as reviewable pull requests — a proposal, not an action: engineers read the diff and decide. That loop makes the next run cheaper. Optimization and interdiction are different jobs, and the second one has to land while the run is still going.

What a control that binds the tree has to do

The Codex report effectively writes the specification in its own request for safeguards.

It binds the tree, not an agent. A ceiling applied to one agent is re-paid by its siblings; a ceiling applied to the root has to be inherited by descendants or it stops meaning anything at depth 2. The issue asks for a global per-root delegation budget — total descendants, spawn attempts, cumulative subagent tokens and nesting depth.

It is evaluated at the moment of the decision. Spawning and stepping are the last points at which the spend has not happened yet. A threshold checked afterwards describes an overrun; it does not prevent one.

It is a mechanism, not an instruction. The sentence that halted the 74-agent run worked because a human was awake and reading a transcript two days into the session. That is not a control, which is why the same report asks for a first-class setting to disable further delegation.

How Waxell handles this

Waxell Observe is the layer that can see the tree and act on it. Its product page states that it traces full agent execution trees, that parent-child relationships between agents are detected automatically, and that child agents, spawned workflows and tool calls are linked by session and lineage without manual wiring. On top of that telemetry it runs 50+ policy categories, enforced during execution rather than reviewed afterwards. Three are directly on point: the Cost category "set[s] spending and token limits. Per-agent, per-user, per-session"; Rate-Limit is described as preventing runaway loops, enforcing cooldowns and throttling expensive operations; Kill halts any agent or workflow immediately. When a policy triggers, the agent receives structured feedback — retry, escalate, or halt. Setup is two lines of Python, against 200+ auto-instrumented Python libraries and frameworks.

For workflows you build on the Waxell SDK rather than instrument after the fact, Waxell Runtime moves the same 50+ policy engine into the execution environment: in its own words, "Policies gate each step before it executes," with kill switches at the agent, workflow and session level and durable checkpointing so a halted run resumes from where it stopped instead of restarting and paying for the work twice.

Two scope limits, stated plainly: Observe governs agent processes you can install a Python SDK into, and Runtime governs agents built with Waxell's decorators. Neither reaches inside a third-party coding harness's own delegation loop, so the depth limit the Codex case needs has to come from Codex. Worth knowing either way — Waxell's pricing docs state that you bring your own provider keys and are "never charged for tokens by us; you pay your provider directly." The incentive is to make the run stop, not to make it longer.

FAQ

What is AI agent cost control?

Bounding what an agent run is allowed to spend while it runs, as opposed to reporting what it spent afterwards. The distinction matters because agents generate their own workload: the same task can cost one model call or several billion tokens depending on how much delegation the agent decides to do. A control that binds a month or an API key cannot express "this run may not exceed this much."

Why do subagents cost more than expected when they use cheaper models?

Because model price is one term among several. Each spawned agent starts a new model context that may have to carry or reconstruct system and repository instructions, tool schemas, skill metadata, environment discovery, and the parent history when the context is forked — before it does any useful work. Issue #39808 on openai/codex lays this out and notes the resulting trap: users are encouraged to delegate to smaller specialist agents to save usage, while the orchestration pattern can consume more than one larger agent working serially.

How much more do multi-agent systems actually cost?

Anthropic reports that agents use about 4× more tokens than chat interactions and multi-agent systems about 15× more. That is an average from one production system, not a law, and the spread depends heavily on how much history each child inherits: in the Codex report, 30 history-forking agents accounted for roughly 4.824 billion tokens against about 153 million for 44 context-free ones.

Is a cloud or provider spending limit enough?

It is a real backstop and worth having, but it is scoped to an account and a billing period — the wrong granularity for a failure that happens inside one run and is caused by that run's own structure. IDC found 67% of enterprises exceeded their agent spend budget by more than 10% over 12 months while 61.8% rated their cost governance mature.

What should I instrument first?

The tree. Per-agent and per-run token accounting with parent-child lineage — so you can see which branch spent the money — is the substrate the other controls depend on. IDC reports that 45.4% of organizations have real-time dashboards tracking token consumption and cost by workflow.

Does capping delegation make agents worse?

Sometimes, and the trade-off is real. Anthropic's finding that token usage explains 80% of performance variance on one browsing benchmark means spending less can mean performing worse on genuinely parallel work. The argument for a bound is not that fan-out is wasteful; it is that the decision to fan out should be reviewable and stoppable rather than discovered later in a token report.

Sources

Agent spend is decided by the shape of the run, hours before the invoice knows about it. Put the budget where the decision happens — start free with Waxell Observe and one governed MCP upstream.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

Compliance — NIST AI RMF · EU AI Act · SOC 2 Type II (in progress) · HIPAA (in progress)

Governed continuously in Vanta.

© 2026 Waxell. All rights reserved.

Patent Pending.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

Compliance — NIST AI RMF · EU AI Act · SOC 2 Type II (in progress) · HIPAA (in progress)

Governed continuously in Vanta.

© 2026 Waxell. All rights reserved.

Patent Pending.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

Compliance — NIST AI RMF · EU AI Act · SOC 2 Type II (in progress) · HIPAA (in progress)

Governed continuously in Vanta.

© 2026 Waxell. All rights reserved.

Patent Pending.