The rediscovery tax: where your coding agent actually spends your tokens

If you’re building with coding agents, you may be on the bandwagon of anxiously watching your token limits get closer but your todo list isn’t done yet. We had a hunch that token spend wasn’t just getting drained on actually doing the tasks, but rather on completely unnecessary rediscovery of information.

You’ve probably watched your agent do a ton of searching and then come back to tell you a fact that isn’t even right. Not only did it just waste a ton of your token limit, but what it found was a) wrong and b) something you could have told it quickly.

Last week I set up some benchmarks to see if we could put some numbers around this. Turns out a massive chunk of token waste goes to exactly that… things you’ve told the agent before or that literally any person on your team would have known to not waste time on. Your agent is re-reading a ton of your codebase, the surrounding docs, etc., trying to piece together all the collateral information it needs in order to come up with a technical plan.

I’ve been calling it the rediscovery tax.

We all know better context helps… so aren’t we done here?

“Give the agent more context” is common advice by now, but we’re also starting to see that all context is not created equal.

Your agent can already read your code, and the models are getting better at that in every release. The rediscovery tax isn’t just the agent rediscovering the technical details it can find by searching through the codebase, it’s spent piecing together the nonobvious information. The stuff that’s actually not easily found during implementation, or obvious to any software engineer who looks at the code.

It’s the layer around the code. The architecture, how your repositories fit together, the rules and conventions your team operates by, who your users are and what they care about, and what you were actually trying to build. None of that is written plainly in any one file. A senior engineer carries it in their head because they’ve worked through it. The agent hasn’t, and doesn’t, so it tries to reconstruct it from scratch every session.

We set up a handful of tests to see if we could get numbers around this idea.

An actual test

We asked an agent to add a per-attendee booking cooldown to Cal.com… basically, stop the same person from booking two slots too close together.

Sounds simple. The cooldown logic doesn’t seem too crazy, but the agent had to rediscover how a booking request actually moves through the system before it reaches the database, and which conventions it has to respect on the way.

These are the types of things that our new hires begin to construct as mental models as they get familiar with the product, or things that the engineers who have been on the team for a while will tell the new hires about up front to save them a bunch of time and get their mental model in the right shape.

We don’t really think about an agent needing the same type of onboarding, and they don’t consume it the same way. So the agent has to go on a hunt.

Where the tokens actually go

Working without that context, the agent burned about 5.5 million input tokens in a single session, almost all of it re-reading code to rebuild an understanding it had no way to keep. Remember it’s not just the code it needs to understand, but the concepts that aren’t obvious from the lines of code. It takes a lot of reading of different files, looking at commits and comments, and reasoning to land on these facts.

It’s not just expensive, it’s also super unstable. In one session the agent may nail it… it found the right pieces of info and came to the right conclusion. But the next time they may miss something or forget altogether, and now you have to do rework.

In our tests, the agent working without this curated context only accounted for about a third of the rules and memories that need to be considered when building. Which means that the work the agent implemented would have needed a refactor (in one case it missed a convention for splitting reads and writes… inconsistent with the codebase, adds tech debt, and ultimately adds chaos, risk, and rework cost).

The difference when it had our opinionated context easily accessible

Then we gave the agent the nonobvious knowledge up front (the architecture, how things connect, the rules) and re-ran the same work.

On our tests for codebase comprehension, the median spend per session went from about $1.45 to about $0.42. Input load went from around 5.5 million tokens to under 200 thousand (!!!). The gap scaled with the codebase: on a small, well-documented repo it was a more modest 1.3x, and on a big, deep one it was around 4.3x. The messier and less documented the code, the more the agent had been paying to rediscover it, and the more there was to save.

A small interesting detail: the agent with context actually took more turns, not fewer. Eight versus six. But each turn was a tiny, dense query instead of a massive re-read. The lever isn’t fewer steps. It’s cheaper ones.

Efficient access to relevant information.

And none of this was tied to one provider. The same pattern held on Claude and on Codex. This is my favorite detail… the models and agents have their own personalities and skills, so being able to plug them into your team to handle tasks that they’re good at without sacrificing on their context/onboarding is a huge win.

Some more data

We ran this with and without gjalla (the harness plus maintained context), on both Claude and Codex, so the result wasn’t tied to one model. A few medians from the codebase-comprehension tasks:

Metric (per session)	Claude	Codex
Cost	~71% lower with gjalla	~77% lower
Input tokens read	~5.5M down to ~180K	~77% lower
Share of the codebase’s rules it knew	~60% up to ~100%	~70% up to ~100%

On Claude that’s about $1.45 down to $0.42 a session, and the gap widens on bigger, messier repos… up to ~4.3x cheaper. If you’re using a subscription, these token savings result in increased capacity for you within your subscription limits.

So what do you do with this

If you’re running agents across a team, the question worth asking is how much you’re paying them to relearn what your team already knows. You may have even started to set rules in your CLAUDE.md, but a) you have to define them for every codebase and b) they aren’t really able to capture the meta-context.

We’re at the point where if you’re not getting good results from coding agents, a newer model is not going to make much of a difference. Better context will. The correct context. Efficient and relevant context which speeds up the agent’s nonobvious knowledge about the environment it’s operating within.

That’s what gjalla does. Software engineering has never been 100% about the lines of code, and it turns out that all the other stuff makes a massive difference in how efficiently and effectively agents are able to build.