# The Hidden Cost of Running Autonomous Coding Agents: A Seven-Week Audit
## Introduction
Running AI-powered coding agents at scale introduces a set of invisible overheads that are easy to ignore when you’re operating under a flat monthly subscription. At a small consultancy, one team decided to audit their internal agent orchestration system over a seven-week period to understand the true financial and operational cost of delegating development work to autonomous agents.
The investigation covered 44 development cycles between early July and early September, examining token usage, agent dispatch patterns, review overhead, and context management. What emerged was a sobering picture of a system that worked functionally but was rapidly approaching unsustainability from a cost perspective.
—
## What Drives Agent Autonomy
When designing a control plane for coding agents, three factors naturally determine how much freedom you give them:
– **Blast radius of errors.** In mature production systems, a single mistake can have offline consequences that ripple through live services. Early-stage prototypes carry far less risk.
– **Project context.** Legacy codebases lack the embedded architectural knowledge that agents rely on to make probabilistic decisions. Newer projects tend to follow established patterns that agents can recognise and replicate.
– **Project maturity.** Greenfield projects follow predictable design patterns, making them far easier for agents to navigate. Established projects carry accumulated complexity and technical debt that obscures the agent’s decision-making.
These factors are well understood. But what is often overlooked is the **cost of running the system itself**. For a consultancy operating on a fixed monthly subscription rather than pay-per-use APIs, the marginal cost of poor decisions is measured in time. Understanding whether the system can genuinely scale without breaking the budget requires honest data.
—
## The Numbers: Utilisation and Pricing Reality
Over the seven-week audit window, 44 development cycles were analysed. To understand the true cost, every token was converted to input-token equivalents using the following multipliers:
– Cached reads: **0.1x**
– Cached writes: **1.25x**
– Output tokens: **5x**
At standard API rates, the utilisation would cost **22 times more** than the current subscription price. For a growing consultancy, this is a figure that quickly becomes untenable — approaching the salary of a mid-level engineer.
The data made one thing clear: proving that a system works is fundamentally different from proving that it is affordable to run at scale.
—
## The Bottleneck Nobody Expected: Adversarial Review
One of the most surprising findings involved the adversarial review process. The initial hypothesis was that a single expensive review agent was creating the bottleneck. In reality, the problem was **volume**.
Across the audited cycles, the system dispatched **242 adversarial reviewers** compared to **204 implementation agents** — a ratio of 1.19x. More reviewers were being sent than builders. Furthermore, 26% of those reviewers demanded changes, which triggered additional remediation agents and spawned further review cycles.
The data showed that adversarial review was costing more in agent-hours than direct implementation:
| Metric | Adversarial Review | Implementation |
|—|—|—|
| Agents Dispatched | 242 | 204 |
| Cost Units | 234.8M | 339.6M |
| Agent-Hours | 28.0 | 39.2 |
| Median Per Agent | 825k units, 5.6 min | 1.12M units, 7.8 min |
The root cause was structural. When a reviewer flags an issue and a remediation agent is dispatched, that remediation in turn triggers another adversarial review. If the second or third round does not resolve the problem, the system keeps cycling rather than stepping back to reassess the approach. This creates a rabbit-hole effect that consumes significant resources without converging on a solution.
Additionally, the review was scoped to the entire diff of each increment, meaning the reviewer agent was asked to assess all changed code rather than focusing narrowly on the specific modifications. This broad scope increased the likelihood of finding spurious issues that were not actually part of the intended change.
—
## Architecture: The Controller and Worker Model
The orchestration system follows a simple but effective architecture. Each run has a single **controller** agent and multiple **worker** agents:
– The controller reads the build plan and tracks the state of each increment.
– It dispatches one worker per increment.
– It validates whether each increment is completed, under review, or failed.
– It dispatches the next task based on the current state.
The controller is the only agent that persists for the entire duration of a run. This design choice was intentional: it prevents a common failure mode in plan-and-build systems where a worker both reports progress and advances the plan. When a single agent handles both roles, incorrect progress statements cascade into incorrect task completions. By separating the controller from the workers, the system introduces an independent arbiter that verifies the truthfulness of each worker’s claims.
The controller’s contract is explicit: it never implements code on the happy path. Its role ends at evidence gathering. It does not advance task trackers, post status updates, declare runs complete, or dispatch the next increment — those responsibilities belong entirely to the controller.
—
## Where the Money Actually Goes
The most expensive component in the entire system was not the implementation workers. It was not the adversarial reviewers. It was the **controller** — the agent that writes no code at all.
The controller consumed more in token usage than implementation, planning, and review combined. The primary driver of this cost was **context bloat**. The system was designed to include per-commit compaction to manage context windows, but the compaction mechanism was not firing reliably.
Across all 44 controller instances, only **34 compaction events** occurred. That means 75% of controllers were never compacted at all. The controller handled an average of **25,878 API calls** and carried a context window that grew roughly linearly with session duration, peaking at nearly **1 million tokens**.
The problem was compounded by how context was being used. Controllers were spending the majority of their token budget re-reading their own previous outputs — tool arguments, dispatch briefs, and task state updates — rather than focusing on the current increment they were working on.
Workers, by contrast, operated on far tighter contexts. The median worker context per call was **101,000 tokens**, compared to **312,000 tokens** for the controller. Workers were also compacting on their own, opening at around 38,000 tokens and closing at 103,000 tokens. The controller, left uncompacted, ended up carrying the full state of every worker in memory.
—
## The Root Cause: Self-Generated Metadata
The biggest surprise of the audit was discovering what was actually filling the controller’s context window. It was not the planning documents — the architecture specifications, technical specs, implementation scopes, and build plans together accounted for roughly **2%** of a median controller turn, or about 8,000 tokens.
Instead, the controller was filling its context with its own outputs. Specifically:
– **Tool call arguments** made up **37.7%** of everything the controller accumulated.
– **Dispatch briefs** — the instructions sent to workers for each increment — numbered **698** across the corpus, with a median length of **1,390 tokens** and a maximum exceeding **6,000 tokens**.
These briefs were being persisted and re-read on every subsequent increment, even though they were scoped only to the specific increment they were written for. The system was essentially building an ever-growing stack of instructions that it kept re-ingesting instead of marking them as completed and discarding them.
Two deliberate design choices made this worse:
1. **The controller validates every worker result itself**, which means all evidence must be kept in the controller’s context.
2. **The task list is re-rendered on every state change** for human review, which means task metadata and completion status accumulate across the entire run.
Combined, these decisions created a coding agent that hoards metadata, grows heavier with every completed increment, and never sheds weight.
—
## Three Changes to Make the System Sustainable
The audit identified three concrete interventions that could dramatically reduce context bloat and, by extension, cost.
### 1. Pass Briefs by Reference, Not by Value
Rather than embedding the full dispatch brief in the controller’s context on every turn, the system should store briefs in a persistent run record and pass only a pointer to the current state. The controller only needs to know the most recent state of each increment to make decisions. All previous states can be verified against the source of truth — the build plan and run record — without being re-read in full.
This would reduce the controller’s accumulated metadata to a small footprint and a set of references.
### 2. Compact at Increment Boundaries
Once an increment reaches a terminal state, its implementation transcript is no longer relevant to the next decision. The controller can rehydrate from the build plan and run record at each boundary, creating a **sawtooth pattern** where context resets after every increment rather than growing monotonically.
With roughly sixteen dispatches per session, this would bring a typical controller turn from around 360,000 tokens down to approximately 100,000 tokens — a reduction of over 70%.
### 3. Scope Reviewers by Attempt, Not by Increment
The first review of an increment should see the full diff. Subsequent reviews after remediation should be scoped to only the remediation diff and any remaining open findings. This mirrors how a human code reviewer works — narrowing the focus as issues are resolved — and would reduce the ratio of reviewers to executors over time.
—
## Frequently Asked Questions
### Why is the controller more expensive than the workers?
The controller persists for the entire duration of a run and accumulates context across every increment. Workers are short-lived and operate on narrowly scoped diffs. The controller’s context grows linearly over time, and without compaction it eventually carries millions of tokens — mostly its own previous outputs — on every single API call.
### What is adversarial review and why does it cost so much?
Adversarial review spins up a separate agent to attack every code commit, searching for logic errors, type issues, and edge cases. It is expensive because the system dispatches more reviewers than implementers, and when reviewers flag issues, remediation agents are triggered, which in turn spawn additional review cycles. This creates compounding overhead that is disproportionate to the actual implementation work.
### Could switching to a pay-per-use API model fix the cost problem?
Switching to API pricing would make the cost immediately visible and potentially more controllable, but it would not fix the underlying context bloat. At 22 times the current subscription cost, the system would be paying for inefficiency at a much steeper rate. The root cause — uncontrolled context growth — would persist regardless of pricing model.
### Is the planning chain a significant source of context bloat?
No. The architecture specification, technical specification, implementation scope, and build plan together total under 8,000 tokens — roughly 2% of a median controller turn. The planning chain is well-designed and reliable. The actual bloat comes from the controller’s own generated outputs: tool arguments and dispatch briefs that are retained rather than discarded.
### What happens if context windows keep growing without compaction?
As context windows saturate, LLMs experience degraded performance, increased hallucination rates, and slower response times. This affects both the cost and the reliability of the system. Agents become less accurate at longer contexts, which can introduce new bugs and require additional review cycles — compounding the problem further.
### Were the proposed fixes tested in production?
No. The three interventions described — passing briefs by reference, compacting at increment boundaries, and scoping reviewers by attempt — are proposed based on the audit findings. The cost projections cited are estimates derived from measured data, not results from a live deployment. Further testing would be needed to validate the savings in a production environment.
—
## Conclusion
The audit revealed that a system designed to make development faster and more reliable was quietly becoming unsustainable — not because of flawed architecture, but because of accumulated context that was never being cleaned up. The controller, the single most expensive component, was consuming more tokens than all the implementation and review work combined, not because it was doing more work, but because it was holding onto everything it had ever done.
The good news is that the architecture itself is sound. The problems are localised and well-defined: increment state is being retained in the global run context when it should be ephemeral, and dispatch briefs are being re-read long after they are relevant. Addressing these two issues — compacting at boundaries and referencing rather than copying briefs — would reduce context overhead by more than 70% and bring the system within a range that could be sustained at scale.
This exercise underscored a broader lesson: the most dangerous blind spots in engineered systems are the ones we assume we have already addressed. The team believed compaction was working and that the planning chain was the bottleneck. Neither assumption was true. Honest measurement, without relying on prior beliefs, is the only way to find where the real cost lies.
The system is functional today. The question is whether it will remain affordable tomorrow — and the audit provides a clear path toward answering yes.
Thank you for reading
