Context Rot Is Not a Session Hygiene Problem. It Is an Architecture Problem
You start a session clean and the first few responses are sharp. An hour later the agent contradicts a decision you made at the start, reintroduces a pattern you both discarded, and forgets the naming convention it was using twenty minutes ago. The code still runs perfectly well. It reads as though a different agent wrote it.
The name for that is context rot, and by now it is the most discussed failure mode in agentic coding. Most of the advice about it concerns discipline. Keep your sessions short, compact aggressively, write cleaner instruction files, and start fresh more often.
That advice works, and it is treating a symptom. The reason the window fills with low value tokens in the first place is that the agent is rebuilding an understanding of your codebase from raw source on every task, and it throws that understanding away when the session ends.
What the measurements show
The effect is quantified well enough now that it no longer needs to be argued.
A 2026 study across 4,416 trials at six conversation depths found compliance with an agent’s own explicit constraints dropping from 73% at turn 5 to 33% at turn 16 with no memory mitigation applied. Adherence to context files follows the same curve, running above 95% in the first two messages and falling to between 50% and 60% by message ten.
The mechanism is not mysterious. In a transformer, attention operates across the whole context, so as context grows the weight available to any individual token falls proportionally. The lost in the middle finding compounds it, since models retrieve reliably from the beginning and the end of a long context and systematically underweight what sits in the middle.
There is also a compaction result that deserves more attention than it gets. Measured sessions of Claude Code’s native auto compaction reduced 132,000 tokens of accumulated message state to roughly 2,300 tokens, a 98% reduction. The token saving is real and so is what goes with it, because the summary necessarily loses most of the architectural understanding and convention knowledge built up over the session. The next session then starts from nothing and pays to rebuild it.
That is the part the bill never itemises. The token count after compaction is small, which makes the operation look purely like a saving. What was destroyed was hours of expensive reasoning about your system, and it gets bought again tomorrow morning.
Why bigger windows do not fix it
The instinct is to wait for the frontier, and it is a reasonable prior rather than a lazy one, because almost every capability complaint about these models has been answered by the next release.
The arithmetic says this one will not be. At a conservative 1,000 tokens per source file, 10 million files is roughly 10 billion tokens of code. A 200,000 token window holds 0.002% of that. A 1 million token window holds 0.01%. A 10 million token window holds 0.1%. The gap is four orders of magnitude, and it is not one model generation away or two.
Worse, quality per token moves the wrong way as the window grows. Scaling the window increases the number of plausible distractors competing with the answer, and the accuracy drop from similar distractors widens as input grows. More room makes the retrieval problem harder rather than easier.
The fix is to stop rebuilding the understanding
The reason a fresh session is expensive is that meaning has to be re-established before anything can be decided. Read a file, form a hypothesis, search to check it, read three more files, revise. Each step can go wrong, and the growing context degrades per step accuracy while it happens. That chain is where the tokens go and where the errors come from, and it runs again every single time.
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files, and it exists to make that chain unnecessary.
Cheap open source models read every file once at indexing time. An agent detects the boundaries of each language element, stores them separately, then analyses each one in the context of its file, its module, its repository and across every repository. For each file the layer records what it does, why it exists in business terms, what users lose if it fails, the capabilities it provides, its edge cases, the contracts it provides, its preconditions, and the exact places where the behaviour is genuinely undecided. All of it in plain English with the file and the line kept on every claim.
The understanding is established once, carefully, before any question exists. After that it simply persists. It does not live in a session, it does not get compacted away, and it does not have to be rebuilt at nine the next morning.
Why the retrieved shape is better than a summary
This is the part that surprised us, and it holds up.
A compaction summary is coherent prose about your codebase, and a well written architecture file is the same thing. Coherent prose is a distractor factory by construction, because every paragraph in it is a plausible near match for any question about that codebase.
Chroma compared a haystack preserving natural flow of ideas against one where sentences were randomly reordered, expecting coherence to win. It went the other way, with structural coherence consistently hurting performance across all 18 models tested. The reading with most support behind it is that logical document flow produces more plausible seeming distractors.
A graph slice returning a dozen facts with a file and a line attached carries almost no narrative coherence, which places it nearer the condition that measured better. The effect is described as slight though consistent, and the experiment ran on essays rather than source code, so it belongs in the argument as support rather than as proof.
What it costs to stop paying repeatedly
Indexing runs about $13 per 1,000 files, once, with only what changes re-derived on each commit.
After that, a query touches a handful of pre-digested graph nodes rather than a window full of raw files. On a traced run, tracing a change end to end across 32 impacted files in 4 repositories took 4 minutes 9 seconds and cost 30 for the same work by brute force. A full test generation and review pass came to 87,001 tokens at $0.11.
Accuracy of code holds above 93% while token spend drops by roughly 80%. Those two move together because the model reading the layer never runs the inference chain, and that chain is where both the cost and the errors accumulate.
The layer is served over MCP, so the same index feeds Cursor, Claude Code, Windsurf and the extension without re-indexing per tool or warming up per session.
The session hygiene advice is still worth following
Short sessions, deliberate compaction at clean milestones, and small focused instruction files all help, and none of that becomes unnecessary. Discipline is real and this is not an argument against it.
The point is that discipline manages the symptom while the underlying cost keeps being paid. If the understanding of your codebase is rebuilt from scratch on every task, the only variable you control is how long you can hold it before it degrades.
The honest limitation
Persistence is not the same as currency. Our index re-derives on every commit, which is fast, and there is still a window after a push where a claim can lag the branch. If your workflow depends on sub second index freshness during active editing, test that specific behaviour rather than taking our word for it.
A derived layer can also be wrong about what code means in ways a parser cannot, which is why every claim carries a file and a line. We also do not cover every language, and Mojo is not indexed today.
This is what ByteBell builds
The thing to notice tomorrow morning is small and hard to unsee afterwards. When you open a fresh session on the same repository you worked in yesterday, count how many turns pass before the agent is useful again. Every one of those turns is you paying a second time for something that was already worked out.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, a one time pass where a model reads every file and lowers it into a verifiable code IR capturing purpose, business context and cross repository relationships, on your own infrastructure through Docker, with your source never leaving your environment. Every engineer, on any copilot, queries the same representation through a single MCP url, and every agent edit is checked against it before it lands, using per file SHA-256 diffing so only what actually changed gets examined again. Across 46 Kubernetes ecosystem repositories and 150,000 files we measured roughly 10% higher accuracy at 70% lower cost, on about a fifth of the tokens.