
The Context Tax: Why Your Coding Agent Reads The Same 600 Lines 400 Times
About this episode
This story was originally published on HackerNoon at: https://hackernoon.com/the-context-tax-why-your-coding-agent-reads-the-same-600-lines-400-times.
Discover how SemSitter powers Sonar Vortex with a codebase graph that gives coding agents precise context across files, documentation, and languages.
Check more stories related to undefined at: https://hackernoon.com/c/undefined.
You can also check exclusive content about #performance, #programming, #api, #artificial-intelligence, #backend-development, #career, #semantic-navigation, #good-company, and more.
This story was written by: @sonarsource. Learn more about this writer by checking @sonarsource's about page,
and for more stories, please visit hackernoon.com.
Discover how SemSitter powers Sonar Vortex with a codebase graph that gives coding agents precise context across files, documentation, and languages.
Get every episode summarized
Each time The Good Tech Companies publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
Transcript ready
127 searchable segments. Every word is indexed and playable.
Full transcript
The Good Tech Companies — The Context Tax: Why Your Coding Agent Reads The Same 600 Lines 400 Times. Machine-transcribed; use the interactive transcript above to jump the player to any line.
This audio is presented by Hacker Nune, where anyone can learn anything about any technology. The context tax. Why your coding agent reads the same 600 lines 4.00 times. Bicener, when a coding agent works in a codebase that doesn't fit in its context window, it navigates the only way a shell can. Then read a file. Then read a bigger slice of the file. Every one of those reads stays in the conversation and is rebuilt on every later turn. On one ordinary approximately 800 line pull request in our own codebase, that added up to 156 million context tokens in a context window that peaked at 459k tokens, for a change whose final diff a person could read in five minutes. Sonar Vortex is our enterprise harness for AI coding agents, guiding them with the right context and verifying every change in real time. To provide guidance, it works inside the agent's loop and answers navigation questions from a graph if your codebase instead of from raw file reads. That graph is built by Sam's Sitter, our in-house semantic navigation engine,
which keeps a local unified dependency graph, UDG, of the repository updated instantly on every change. Instead of Grep, then a slice, then a wider slice, the agent queries the graph for a specific node and gets back that node plus its type relationships. The measurable effects are less context carried per task, fewer round trips, and, in a repository larger than the window, call sites or reg X would not have matched. The story of a refactor that shouldn't have hurt, we build Sam's Sitter with coding agents. That makes it a great candidate to show how agent navigation capabilities can make the difference. A recent PR taught Sam's Sitter's Python analyzer to do call site resolution, that is, for a method call, record which type owns the method and what the call returns. The C-sharp analyzer already did this, so the job was to mirror it in Python. Will into the change, the agent had to work with this line of Sam's Sitter's own code. To touch it safely, the agent needed the answer to the most ordinary question in programming.
The one your IDE's, go to definition, gives you for free. For the call, what type is, where is defined, and what does it return? The honest answers, is a, the method lives in, and it returns. The agent had no index of its own, so it did what a shell allows, one, and got back a definition in every backend at once. Python, TypeScript, Java, Rust, C-sharp, and a shared core. The reg X cannot say which one this call binds to. Two, open to read the definition. It doesn't know where the function starts or ends, so it reads a generous slice, or the whole file. Three, the return type is produced by a helper. Grap for that, open that file, read another wide slice. Four, is really a, Grap for the field, open the struct, repeat. Each of those reads is now permanently in the conversation, and you are going to pay for it, over and over again, until the conversation is over. There is a small irony here worth stating plainly. The agent was building the exact capability it
was missing. CallSideResolution is, given this call, hand me its owner type and return type. The agent needed precisely that to navigate the code, and, lacking it, fell back to Grap and whole file reads. What did actually cost us, with real numbers? While building Semiciter with coding agents, we keep the full traces. So we can measure the tax precisely. Here's one full request from the Semiciter repo. A backend change of about 800 lines that added CallSide Resolution. More on that below, metric. One PR, measured, value model round trips in the session 512 context window at its peak 458,700 tokens fresh input tokens 106K cash red tokens. The rebuild transcript. 152. 8 million cash right tokens 3. 1 million output tokens 289K total context tokens build approximately equals 156 million approximately. Cost of the session approximately equals 41 dollars the line that matters is cash red 152. 8 million tokens.
Here's why it's so large. The mechanism context is a tax you pay every TURNA coding agent doesn't read a file once. On every new step, the model is recent the entire conversation so far as input. PromptCaching makes those repeated tokens cheap per unit. Approximately equals 10% of the input price, but you still pay for them on every single turn. So the true cost of a token isn't its size. It's its size times the number of turns it survives. Read a 600 line file on turn 40 of a 512 turn session and you haven't paid for 600 lines. You've paid for 600 lines times approximately 470 more turns. One over read, traced and T.O. end early in that PR. The agent needed to understand one helper. It approximately 67 line function that, given a value, works out its type name. To find it, the agent read the whole 618 line file, 6472 tokens. Instead of the 67 lines it used,
approximately 700 tokens. Wasted immediately, approximately 5,770 tokens. That read entered the conversation around turn 42 and stayed for the remaining 470 turns. Rebuild as a cash read each turn. 5,770 times 470 approximately equals 2. 7 million tokens of pure waste. At current cash read pricing, $tilde.0.20 million. That's approximately equals $0.54 for one unnecessary file read. 54 cents sounds trivial, but this PR did that approximately 10 times, plus dozens of blind tree wide greps, several of which returned nothing and forced a second, wider grep. Add it up and the avoidable navigation overhead alone runs into several dollars on a single 41 dollars PR, and it scales with the size of the repo, not the size of your change. And this is not one unlucky PR across 18 comparable single ticket PRs in the same repo. The average was,
approximately 234 million context tokens per PR. Tilde $65 per PR, median $ tilde $52. Approximately 700 model round trips per PR. Context windows routinely peaking between 450K and 975K tokens. Brushing the 1M ceiling, at which point the agent is forced to compact and lose earlier context entirely. That last point is the second, quiet or failure mode. In a repo too big for the window, doesn't just cost tokens. It misses. A reg X finds the strings you thought to search for, not the call that reaches your function through an interface, an alias, or another programming language. Mist call sites become failed builds, another round trip to see, and more re-work, each with its own fresh context tags. What Semiciter in Sonar Vortex does instead? This is what Sonar Vortex does instead, using Semiciter, the navigation engine underneath it. Semiciter builds a unified dependency graph, UDG, of the codebase. Every function, method, class, field, and parameter as a
node, and the relationships between them are typed edges. Calls, references, returns, has param, is type, contains, extends. How we build that graph accurately, across languages, leveraging parallelism and incrementality while scaling to millions of nodes, is the interesting part we keep under the hood. The point for the agent is simple. It no longer asks the file system, which files mention, it asks the graph a precise, semantic question. Give me the definition of that this call binds to, the type that owns it, its return type, and its colors. And gets back exactly that. The one method body, plus the edges that answer the rest, with no surrounding file, no six-way grip, and nothing to widen. That is, in fact, the feature the PR was building. For the call, the graph records which type owns the method, a edge from two, because is a, and what it returns, carries an edge to. The agent gets, where is this defined, on what type, and what comes back, as data, not as a page of text it has to read and then carry forever?
The graph the agent navigates when the agent touches, the graph hands at the small, exact neighborhood shown above. Compare the two ways of answering the same three questions. Question Grap plus Reed-Sem's sitter, graph. Which does this call bind to? Grap returns one per backend. Open files to guess one edge right pointing arrow the Python, what does it return? Read the file until the signature is in view one edge right pointing arrow who calls it, and on what type? Grap again, profile. Hope the regx matched upstream plus owner edges. Complete tokens dragged through the rest of the chathausans, profile. Times every later turn the one method body, once same answers. One is a page of text you repay for on every turn and that still misses the indirect collars. The other is a handful of typed edges that are incomplete by construction. Why the gains compound? Beyond code to code, structural edges, calls, returns, references, are only the first layer. The Samograph carries two more kinds of relationship, and each multiplies the savings own exactly the tasks that hurt most today.
Code right pointing arrow text. Every code node can be linked to the specific piece of documentation that governs it. The one paragraph of a design doc, the one ADR, the one section of the readme. This is the misleading docs problem turned on its head. Instead of the agent scraping a wiki and being led astray by a stale page, touching surfaces the note on how is built from the collis annotations. A few hundred exact tokens instead of a document dump and the right few hundred. Text right pointing arrow text. Documentation, tickets and design notes are linked to each other by meaning, so the agent can follow. This rule is refined by that ADR without a full text search that returns 50 near misses. Code right pointing arrow code, across programming languages. The same idea implemented in two languages can be linked even when the names differ. This PR was mirroring C sharp, S call site resolution in Python, and C sharp, S return type logic lives in a function called not. A GREP for one name will never surface the other.
Across language rename or contract change, today one of the most token expensive, error prone things you can ask an agent to do, because it means grepping several backends in several syntaxes becomes follow the edge. Both ends arrive in context together, and neither is missed because the other language happened to use a different word. In the diagram above, those are the green edge and the dashed edge to the C sharp backend. Each one is a navigation the shell simply cannot make, cannot cross from code to pros, and it cannot connect in the Python backend to in the C sharp one. The graph can, and it hands the agent only the node it asked for. The takeaway, the bottleneck for AI coding agents in real, large code bases isn't reasoning. It's navigation, and navigation by GREP has two costs that don't show up until you measure. One. Token cost, every blind read is rebuilt on every later turn. On one ordinary PR that was 156M context tokens and tilde dollar 41. Across a batch it average tilde dollar 65 a PR, with context windows brushing the 1M ceiling.
Two, correctness cost, finds strings, not meaning. What it misses becomes rework and extra trips to see, each paying the token tax again. SimCitter, our in-house code navigation engine powering sonar vortex, turns navigation from a text search into a graph query. The agent carries the nodes I tasked for rather than the files it had to scan, and it can follow relationships across files, docs, and languages that a reggaex cannot express. The result is lower context cost per change and fewer call sites missed, and both effects grow with the size of the code base. If your agents work in a code base bigger than their context window, this tax is already on your bill. Sonar vortex is how you stop paying it. Thank you for listening to this Hackernoon story, read by artificial intelligence. Visit Hackernoon.com to read, write, learn, and publish.
More episodes
More from The Good Tech Companies

Protection Funds, Insurance and FDIC/SIPC: What Actually Covers What
The Good Tech Companies

Credible Captain Launches Independent Consumer Review Platform Focused on Transp...
The Good Tech Companies

4 Ways to Win a Hackathon (None of Them Is Writing Code)
The Good Tech Companies

Tokenized Stocks vs Real Stocks vs Stock Futures: Wall Street Without Walls and...
The Good Tech Companies