The Good Tech Companies - The Context Tax: Why Your Coding Agent Reads The Same 600 Lines 400 Times

Episode Date: September 3, 2026

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.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. The context tax why your coding agent reads the same 600 lines 400 lines 4.000 times. Bisoner, 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 rebuild 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 Sem 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 a reg X would not have matched. The story of a refactor that shouldn't have hurt. We build Semsiter with coding agents. That makes it a great candidate to show how agentic navigation capabilities can make the difference. A recent PR taught Semsiter'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. Well into the change,

the agent had to work with this line of Semsitter's own code. To touch it safely, the agent needed the answer to the most ordinary question in programming, the one your IDEs, 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 back end 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. Grep for that, open that file,

read another wide slice. Four, is really a? Grep for the feet. 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. Call site resolution is, given this call, hand me its owner type and return type. The agent needed precisely that to navigateeth code, and, lacking it, fell back to grep and whole file reads. What it actually cost us? with real numbers. While building Semsiter with coding agents, we keep the full traces. So we can

measure the tax precisely. Here's one pull request from the Semsiter repo, a backend change of about 800 lines that added call site 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.41 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 T, URNA coding agent doesn't read a file once. On every new step, the model is re-sent the entire

conversation so far as input. Promf caching makes those repeated tokens cheap per unit. Approximately equals 10% of the input price, but you still pay for them own 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 NTO end early in that PR, the agent needed to understand one helper, a approximately 67 line function that, given a value, works out its type name. To find it, the agent read the whole 618 line file, 6,472 tokens, instead of the 67 lines it used approximately 700 tokens wasted immediately approximately 5,770

tokens that red entered the conversation around turn 42 and stayed for the remaining 470 turns rebuild as a cash red each turn 5,770 times 470 approximately equals 2. 7 million tokens of pure waste at current cash red pricing, tilda dollar 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. Added up and the avoidable navigation overhead alone runs into several dollars on a single

$41 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 dollar 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 the second quieter failure mode in a repo too big for the window doesn't just cost tokens it misses a regex finds the strings you thought to search for not the call that reaches your function through

an interface an alias or another programming language missed call sites become failed builds another round trip to see and more rework each with its own fresh context tax what semsiter in sonar vortex does instead this is what sonar vortex does instead using semsitter the navigation engine underneath it. Semsiter builds a unified dependency graph, UDG, of the code base. 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 the point for the

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 callers. And gets back exactly that. The one method body, plus the edges that answer the rest, with no surrounding file, no six-way grep, 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 a 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 grep plus read sem citter, graph. Which does this call bind to? GREP returns one per back end. 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? Grep again, for file.

Hope the reg X matched upstream plus owner edges. Complete tokens dragged through the rest of the cha thousands per file. 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 callers. The other is a handful of typed edges that are recompete by construction. Why the gains compound, beyond code to code, structural edges, calls, returns, references, are only the first layer. The sammograph 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 SOTR, the one Santeeing 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 collie's 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-C-C-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. A cross-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 back-end. Each one is a navigation the shell simply cannot make, cannot cross from code to prose, and it cannot connect in the Python backhand two in the C-sharp 1. 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 codebases isn't reasoning. Its navigation, and navigation by grep has two costs that don't show up until you measure. One token cost. Every blind read is rebuild on every later turn, on one ordinary PR that was 156M context tokens and tilda dollar 41. Across a batch it averaged tilde $65 a PR, with context windows brushing the 1M ceiling. 2. Correctness cost, finds strings, not meaning. What it misses becomes

rework and extra trips to see, each paying the token tax again. Semsitter, 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 regex cannot express. The result is lower, context cost per change and fewer call sites missed, and both effects grow with the size of the codebase. If your agents work in a codebase 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.