The Context Budget: How We Stopped Making Our AI Agents Read the Whole Codebase

Ask an AI coding assistant to make a change in a real codebase and watch what it actually does. It globs for filenames. It greps for a symbol. It opens a 400-line file to use twelve lines of it. It opens three more files to figure out who calls the first one. Somewhere after all that, it writes the change you asked for.

Most of the bill is spent looking, not building

Every one of those steps costs tokens, and the cost is worse than it looks. The 388 lines the agent didn't need don't disappear after it finds the twelve it wanted; they stay in the context window for the rest of the session, crowding out room for the actual work. On a Kotlin Multiplatform monorepo with an Android app, an iOS client, and a shared backend, an agent can burn most of its window orienting itself before it changes a single line.

We test our own tooling before we bill anyone for the time using it. This is the part of AI-assisted development nobody shows in the demo, and it decides whether the tooling is economical on a real client project or only on a toy one.

Search-by-reading is the problem

The default exploration loop, glob, grep, read, repeat, has one property that makes it expensive: its cost is unbounded and it is re-paid every session.

Unbounded, because the agent can't know in advance how many files will match or how big they are. We watched an agent spend $0.40 in tokens just opening files to find where a specific API key was initialized. With a graph, that costs $0.01.

Re-paid, because none of that work persists. The structural understanding an agent builds in one conversation is thrown away when the session ends. The next session starts from zero and greps its way back to the same conclusions.

That's the actual inefficiency. Not that the model is slow, but that it keeps re-deriving facts about the codebase that haven't changed.

What a knowledge graph changes

We started using Graphify, an open-source tool that maps a project, code, docs, SQL schemas, configs, PDFs, into a queryable knowledge graph. It registers as a skill in Claude Code, Cursor, Copilot, and Gemini CLI, so the agent queries the graph instead of grepping the filesystem.

The mechanism is what convinced us. Four properties matter:

• Structure is extracted once, not re-derived. Code is parsed with a tree-sitter AST, deterministic, no model involved, nothing leaving the machine. Session two doesn't repeat session one's exploration.
• Retrieval cost is bounded by construction. A graph query accepts an explicit token budget. The agent asks a question and gets back a traversal capped at that size, regardless of how many files would have matched a text search.
• "What breaks if I change this?" is answered by traversal, not reading, a reverse walk over the graph's edges. The alternative is opening every caller's caller, exactly the unbounded read pattern we were trying to escape.
• Every edge is labelled as extracted or inferred. Connections read directly out of the source are tagged separately from ones the tool resolved itself. An agent that can't distinguish a fact from an assumption will confidently refactor against a guess.

How it compares to the alternatives

We didn't adopt this because it beats everything. We adopted it for an honest read of where it fits:

• Plain grep and file reads: zero setup, never stale. Still the right tool for small, local, one-file questions.
• Vector / RAG indexing: strong at fuzzy recall ("find me something like this"), but similarity search returns snippets, not relationships. It cannot answer "what depends on this module."
• Hosted code intelligence and LSPs (Sourcegraph, Serena, and similar): great at scale, but often require sending code to hosted servers or lack support for non-code files like PDFs and configs. Much of our work is client code under NDA. Graphify's code pass runs locally without a model call, meaning the parsing never leaves the machine. That single property settles the decision for our situation.

Where it sits in how we work

We run a multi-agent setup: an orchestrator that routes work and specialist agents that own a lane. The read-only agents among them, the ones that explore, plan, and review, get graph queries as their exploration tool.

The practical effect is that an agent planning a cross-platform architectural change can map the system without loading the system. It asks the graph what connects to what, gets a bounded answer, and spends its remaining context on the actual design problem instead of on filesystem archaeology.

The agent isn't reading faster. It's reading less.

The honest limits

We'd rather write this part than have you discover it yourself:

• The graph goes stale. After a significant refactor it has to be updated, or the agent is reasoning about a codebase that no longer exists.
• The non-code pass isn't free. Code parsing is local and deterministic, but documents and PDFs are analysed semantically, that uses a model, and it costs tokens.
• Inferred edges are inferences. Marked-as-uncertain is not the same as correct. They still need judgment.
• There's per-repository setup cost. Small, but non-zero.

A tool that reduces token spend while introducing maintenance overhead is a trade, not a free win. We think it's a good trade for the size of the codebases we work in.

Our Approach

This obsession with tooling efficiency is how we operate at TRIUUM. By keeping our AI agents focused on writing code rather than finding it, we build complex mobile and cross-platform architectures faster and with fewer billable hours wasted on friction. If you're looking for an engineering partner that deeply understands modern development workflows and respects your budget, let's talk.

Graphify is open source, and worth twenty minutes of your time if your agents are spending more of their context finding code than changing it: github.com/Graphify-Labs/graphify.