Why AI Coding Agents Burn Tokens on Large Codebases, and How a Shared Index Cuts the Cost

If you run AI coding agents across an enterprise codebase, your token bill is not mostly spent on writing code. It is spent on rediscovering the codebase from scratch: once per session, once per agent, once per developer, across every repository you ship.

This post is about the mechanism behind that cost, why large and multi-repo codebases make it worse, and what changes when the agent queries a pre-built index instead of re-deriving structure every time. We are not going to quote you a savings percentage. The size of the win depends on your codebase, and we would rather explain why the savings exist than hand you a number you can’t reproduce.

Where the tokens actually go

Give an agent a task on an unfamiliar codebase, something like “add a retry to the payments client,” “find where we validate JWTs,” or “what breaks if I change the orders service,” and watch what it does before it writes a single line:

• It greps for a symbol, gets forty hits, and reads several whole files to figure out which one matters.
• It finds its way around the directory tree to learn the layout.
• It opens a file, sees an import from another module, and reads that too.
• It repeats this until it has reconstructed enough of a mental model to act.

Every one of those steps pulls raw bytes into the context window: entire files where three functions were relevant, directory listings, transitive imports. The agent is doing expensive, token-heavy archaeology to recover structure that already exists and never changes between sessions.

And it has no memory. The next task starts the dig over from zero, even five minutes later, even when a teammate asks the same question.

Why large, multi-repo codebases make it worse

The cost of rediscovery is not linear in codebase size. Three things compound it in exactly the environments enterprises run:

Large repositories blow the context window. When the relevant code is spread across a dozen files, the agent either reads them all and pays for every token, or guesses with partial context and gets it wrong, which costs a second expensive round. The bigger the file, the worse the ratio of relevant to read tokens.

Multiple repositories break the agent’s reach entirely. A grep can only see what’s checked out on disk. The moment a question crosses a service boundary, say “who calls chargeCard” or “what depends on the orders service,” the agent is blind to every repository the developer hasn’t cloned. It can’t pay its way to an answer at any token price, because the bytes aren’t local.

The cost multiplies across the team. Every developer’s agent, the CI bot, the reviewer’s agent: each one re-derives the same structure independently. You are paying for the same map to be drawn thousands of times because nobody gets to keep it.

The mechanism: build the index once, query it many times

The fix is not a bigger context window or a cheaper model. It is to stop making the agent re-derive what can be computed once.

Ingest the codebase ahead of time into a structured index: symbols and their call graph, service-to-service edges across every repo, API contracts, ownership, the tickets and design docs behind the code. Then expose that index to the agent as a small set of tools over MCP, the protocol coding agents already speak.

Now the agent’s behavior inverts. Instead of grepping forty files to find a caller, it asks the index “who calls chargeCard?” and gets the precise call sites (file, line, signature, across every repository) in one tool call returning a few kilobytes, not hundreds of kilobytes of file dumps it has to read and discard.

The structural reasons this lowers token usage:

• Pre-narrowed results, not raw files. The tool returns the answer, not the haystack. The agent reads what’s relevant instead of paying to read and discard the rest.
• Cross-repo answers without local clones. A multi-repo question is one query against the index, not an impossible grep across repos that aren’t on disk.
• The index is built once and shared. Every agent, every developer, and the CI bot all query the same pre-computed structure. The map is drawn once, not per-session and per-person.

An illustrative example

The numbers below are illustrative arithmetic to show the shape of the saving, not measured results.

Take “who calls chargeCard across the codebase?”

• Grep-and-read path: a broad search, then reading, say, ten candidate files averaging a few hundred lines each to confirm the real call sites. Most of those tokens are bytes the agent reads only to rule out, plus the follow-up reads when a caller lives in a repo that wasn’t cloned (or a wrong answer because it couldn’t be).
• Index path: one tool call returning the confirmed call sites with file, line, and signature. Kilobytes, cross-repo, no discarded haystack.

The win isn’t a constant factor. It scales with how much the agent would otherwise have read to rule things out, which is exactly what grows with codebase size and repository count. That is why the effect is largest precisely where enterprises feel the pain.

What this does not help

Being honest about the boundary matters:

• If the agent already knows the one file to edit, an index call is overhead. The win is in discovery, location, and impact questions, not “change this known line.”
• It doesn’t replace the model’s reasoning. It replaces the agent’s expensive groping toward context.
• Liveness questions (“did this PR merge?”) are a different shape. A pre-built index is for structure, not minute-to-minute state.

The bottom line

Stop paying the agent to rediscover your codebase, and the rediscovery tokens go away. The bigger and more fragmented your codebase, the more of your token budget that archaeology represents, and the more a shared index gives back.

If you want to see the tool surface an agent queries instead of grepping, the Oracus MCP server is the place to start: one mount, every repo, every ticket, queried by every agent in your org.