The token economics of a coding agent.

The cost of software is going up. Not because infrastructure got more expensive, but because the primary consumers of compute have changed. In the first wave of generative AI, humans sent prompts and read responses. In the wave we're in now, autonomous agents send thousands of requests to complete a single task, with no human in the loop until the result lands.

That shift makes token economics a board-level concern, not a billing footnote. When agents are the primary consumers, the correction overhead of probabilistic AI — extra turns spent on bad context, hallucinated dependencies, incomplete blast-radius estimates — shows up directly on the invoice. Fluency in how tokens are counted, priced, and structured is no longer a niche skill for API integrators. It's a prerequisite for any engineering leader scaling AI-driven workflows with a serious eye on ROI.

This post breaks down where token costs actually land in a coding agent loop, why the context-gather phase is the least controlled of all of them, and what changes when that phase is backed by a deterministic graph instead of search-and-read.

The four token categories, and what they mean in practice

Every LLM API call breaks into some combination of these four types.

Input tokens. Everything sent in a request: system prompt, conversation history, tool definitions, file contents, the user message. In a coding agent, input grows with every turn — each prior exchange gets re-sent as context for the next one. Tool definitions add a fixed per-turn overhead that accumulates invisibly. If the agent reads three source files to understand a module, those files go into the next request's input too.

Output tokens. Everything the model generates: response text, tool call parameters, reasoning steps. Output is always priced higher than input, typically 3x to 5x depending on provider and tier, because generation is sequential and compute-intensive, unlike the parallel forward pass used for input. In a coding agent, the model generates a tool invocation for every context-gathering step it takes. A 15-turn session with 4 tool calls per turn is 60 rounds of tool-invocation output before the agent writes a single line of code.

Cache write tokens. The first time you store a static prefix — system prompt, tool definitions, architectural context — for reuse. Slightly above standard input pricing, one-time per unique content block.

Cache hit tokens. Every subsequent request that reads that stored prefix instead of reprocessing it. Typically 10-15% of standard input pricing. The cheapest token category, and the highest-leverage one when your static context is large and your request volume is high.

What a token is

A token is roughly 4 characters of English text, or about 0.75 words. Code tokenizes differently from prose because of indentation, symbols, and identifier naming. Common approximations for a coding context:

The comparison in that table matters. An agent reading 8 source files to understand a module's dependencies has consumed roughly the same tokens as enola's full architecture digest for an entire codebase. The 8-file read produces an incomplete picture. The digest is deterministic and complete.

Where a coding agent actually spends tokens

A typical coding task — “refactor this module without breaking anything that depends on it” — breaks into three phases. Token spending is not evenly distributed.

Context-gather is the least controlled phase. The agent doesn't know upfront what files it needs. It discovers them by searching, reading, and following imports. Each discovery step adds input tokens (the file contents) and output tokens (the tool invocation that triggered the read). The agent stops when it thinks it has enough, not when it actually does.

More precisely: it stops when its approximation of the codebase structure feels complete. That approximation may or may not match what's actually there. When it doesn't, the verify phase catches the failure, the agent loops back, and the context-gather cost repeats.

The context-gather phase is where the context gap opens

An agent searching and reading files to understand a codebase is doing something specific: building a mental model of the architecture from a sample of the code that fit in its context window, filling the gaps with pattern-matching. That's not the same as having the architecture. It's a probabilistic approximation of it.

The mismatch surfaces in three concrete ways.

Missed dependents. An agent grep-searching for callers of a function will miss callers that invoke it through a method on a type, without naming the function directly. Those callers exist in the codebase; they just don't appear in a string search. The blast-radius estimate comes back smaller than reality.

Stale context. In a long session, early file reads get compacted or cleared as context fills. The agent continues reasoning from what it remembers of those reads, not from the reads themselves. If the remembered version is incomplete, the plan it produces is based on incomplete information.

Non-repeatable answers. Ask the same architectural question in two different sessions and the agent can return different dependency lists — not because the code changed, but because different files happened to get sampled this time. A refactor plan built on a result that doesn't repeat is a refactor plan built on uncertain ground.

Each failure mode adds turns. More turns means more input tokens (growing context re-sent each time), more output tokens (the agent reasoning its way to the correction), and more latency before the task is done. That's the correction overhead, measured in tokens and in engineering time. The context gap opened in the gather phase compounds through everything that follows.

What changes when the context-gather phase is backed by a graph

Enola closes the context gap before the agent's first tool call. It generates a deterministic dependency graph from your codebase — parsed from real ASTs, not inferred from samples — and exposes it as an MCP tool the agent calls instead of running a search-and-read loop.

The token implications are concrete.

A single impact_analysis call replaces a search-and-read loop of indeterminate length. The result is ~800-1,200 output tokens: a structured, bounded list of every module transitively dependent on the target, grouped by hop distance, including callers that only reference the target through a method. No grep would have found all of them. No number of file reads would have traced 56,308 dependent nodes across 50+ packages. The graph call does it in one turn.

Input token growth slows. Because the agent isn't accumulating file reads across turns to build its picture, input doesn't balloon through the context-gather phase. The graph response is compact and structured; it doesn't need to carry along the raw files it was derived from.

Cache the graph digest, not the codebase. Enola's llm_context.md is a 16,000-token architecture digest: module layout, dependency hotspots, cyclic dependency warnings, entry points. Cache it in your system prompt. Every turn in every session reads that 16,000 tokens at cache-hit pricing instead of standard input pricing, and the agent starts with the full architectural picture before the first tool call.

The answer is the same every time. Running impact_analysis on the same commit returns the same 56,308 nodes every time. That's a guarantee on the input the agent reasons from. Probabilistic input guarantees that some of the agent's confident-sounding conclusions are wrong in ways neither the team nor the agent can detect without running the whole thing again. Closing the context gap before the agent starts is the only way to remove that correction overhead rather than manage it.

FAQ

Where do coding agents spend the most tokens?

The context-gather phase — searching and reading files to build an understanding of the codebase — typically drives the most uncontrolled token spend in a coding agent loop. Each discovery step adds input tokens (file contents) and output tokens (tool invocations), and the number of steps is determined by how much the agent doesn't know upfront. An agent with access to a pre-built dependency graph answers structural questions in a single tool call instead of a multi-step search-and-read loop.

Why do output tokens cost more than input tokens?

Input tokens are processed in parallel as a single forward pass through the model. Output tokens are generated sequentially, one at a time, each depending on the previous one. Sequential generation requires more compute per token and cannot be parallelized. Most major providers price output at 3x to 5x the input rate as a result.

What is the context gap in an AI coding agent, and what does it cost?

The context gap is the difference between what an agent infers about a codebase's architecture through search-and-read and what the architecture actually is. When the gap exists, it produces correction overhead: re-runs, correction loops, and failed verifications that add input tokens (re-sent context) and output tokens (the agent reasoning toward the correction). A deterministic graph closes the context gap before the agent's first tool call, replacing probabilistic inference with an exact computation.

What is prompt caching and how does it help coding agents?

Prompt caching lets you store a static prefix — system prompt, tool definitions, architectural context — so subsequent requests read it from cache at roughly 10-15% of standard input pricing instead of reprocessing it at full price. For a coding agent with a large, stable architectural digest, caching converts the dominant per-request input cost from standard to cache-hit pricing on every turn after the first.

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh