DEV Community: Tomás Alcalde

The note was fine; finding it was the problem

Tomás Alcalde — Tue, 13 Oct 2026 13:42:10 +0000

I work with a coding agent that keeps what it learns in text notes: one per topic, with a
current state at the top that gets rewritten and a dated history at the bottom that only grows.
Today there are 220 notes and almost a million tokens. Nobody loads them whole. On every message a
word-based search suggests which ones might help, the agent asks for a map of sections with the
cost of each, and fetches only the one it needs. I have been calling that the ladder.

In the previous article I put it next to Mem0, Zep,
claude-mem and Letta, and concluded that it was missing nothing. That was a comparison of pieces:
this is equivalent to that. The other comparison was missing, the one their benchmarks make. Given
a question, does the line that answers it reach the agent's view, and how many tokens did it cost
to bring it? This article is that measurement.

The short version

With the right note in hand, reading its state and one section found the answer in 32 % of the questions with 2.7k tokens. No number of loose fragments reached that, even with three times the budget.
The search puts the answer's note first only one time in three. With that routing, the ladder loses by a small margin against fragments.
The current state is always found; the dated history, one time in five. And half of the answers were in the history.
The 76 % hit rate I published before measured something else: whether some useful note was
opened, not whether the fact arrived.
32 % ladder hit rate with the right note, at 2.7k tokens
1 in 3 times the search puts the answer's note first
18 of 18 answers found when they were in the current state
21 of 95 when they were in the dated history

What memory benchmarks measure

LongMemEval, LoCoMo and the benchmark Mem0 publishes measure against the answer, not against the
document: whether the evidence that answers reached the model (or whether the answer came out
right), and how much context it cost. Mem0, for example, publishes the tokens it spends alongside
the hit rate. Two numbers together, because loading everything always hits and is never useful. I
measured the evidence part: whether the line that answers ended up inside what was read.

My previous bench measured something else. For each message of mine, it looked at which notes
had actually been opened to answer it and whether the search had suggested them among the top
four. It gave 76 %. But opening a note is not finding the answer: the note can have 300 lines, and
if the agent reads the state and the answer was in an entry from a month ago, the suggestion was
right and the fact did not arrive.

A bench built from the transcripts

I did not want to write questions by hand, because you write the ones your system answers well.
The bench comes from the session logs that Claude Code keeps on disk. In each turn I gather the
memory lines the agent read, and a line counts as an answer if at least three of its uncommon
words reappear in what the agent replied and were not in my message or in the three before it. The
second condition matters: if the word was already in the question, the match is an echo, not a
recollection.

I removed the turns where the agent writes memory, because there what it says matches the line
since it has just drafted the line itself. I also removed each note's header, which already comes
with the search suggestion. That left 191 pairs over 70 notes. I checked a sample of 15 by hand
and about 12 were truly the answer: the method has noise, but it points the right way.

Then each line is searched verbatim in today's notes. The ones that no longer exist are
discarded, and that was the first odd finding: 372 lines that were answers are no longer written
the same way, almost twice as many as remain. The notes get rewritten faster than the bench can
stabilize. A hand-made memory bench, on a system that is edited every day, goes stale in
weeks.

Four ways to read, the same budget

On those pairs I simulated several reading policies, all of them single-pass over the current
notes:

The ladder with the real routing. The production search picks one or two notes, and from each one I read the current state and the section that best fits the question, plus the cost of the map.
The ladder with the right note given. The same, but handing it the note where the answer was. It separates the error of choosing the note from the error of choosing the section.
Loose fragments. The notes are split into paragraphs (5,159) and the 5, 10, 20 or 40 that fit best are injected, without going through notes. It is the shape of Mem0 or of a typical RAG, with one caveat: I use the same word-based search (BM25), not embeddings.
Everything in context. The LongMemEval baseline: it hits 100 % at a cost of 977k tokens per question.

Each point is a policy. Up and to the left is better: more answers for fewer tokens.
191 questions, notes as of October 6, 2026.

Policy	Hit rate	Tokens per question
Ladder, right note given	32 %	2.7k
Fragments, the 40 best	26 %	8.7k
Fragments, the 20 best	19 %	4.3k
Ladder with real routing, 2 notes	17 %	6.1k
Fragments, the 10 best	14 %	2.2k
Ladder with real routing, 1 note	11 %	3.3k
Fragments, the 5 best	7 %	1.1k
Everything in context	100 %	977k

Both halves are there. With the right note, the ladder is the most efficient policy in the
table: 32 % with 2.7k tokens, against 26 % for fragments with more than three times as many. Grouping what is
known by topic, with the current state on top, works. With the real routing, the same ladder falls
below the fragments curve: 11 % with 3.3k, against 14 % with 2.2k.

The structure of the notes is not the problem. The problem is the step
before: choosing which one to open. And I had measured that step with a yardstick that could not
see the difference.

I tried two obvious fixes. One, searching inside the note for the rarest words of the question,
which is what the agent really does when the map does not help: it gave 10 % and 15 %, no change.
The other, routing by paragraph and then reading the note that gathered the most score, a hybrid
of the two worlds: 7 % and 14 %. Neither moves the needle, because both depend on the same
search.

Why the search fails right here

The search puts the answer's note in first place in 32 % of these pairs, and among the top four
suggestions in 53 %. In the previous bench, over all my messages, it gave 76 %. The difference is
in which messages end in a fact. They are the vaguest ones: "carry on with whatever you
recommend", "how do we move forward?", "check that everything came out right". They bring nothing
to search with. The agent manages anyway because it has the rest of the conversation and can ask
for another note if the first does not work, but every round trip is one more call, and every call
re-reads the entire context.

That is what this measurement does not count. The simulated policies read once and keep what
they brought. The real agent, by construction, reached all of these answers: if not, they would
not have made it into the bench. What the simulation shows is how much it costs to get there, not
whether it gets there. Putting in the same table the calls the agent pays to compensate for the
routing is what is still missing.

History is the weak zone

With the right note, the ladder finds the answer depending on where it was:

Ladder hit rate with the right note given, by zone of the note where the answer
was.

The current state is always read, so it always hits. History is read by section, and the
question almost never names the date or the episode: it says "that thing from last week" or says
nothing. LongMemEval has a category for this, temporal reasoning, and it is one of the hardest for
the systems it evaluates. In my data half of the answers lived there.

That changes how I think about the note. The current state works because it is short and gets
rewritten: if something from the history is asked often, its place is the state, not a dated entry
that has to be guessed. History is for auditing why something was decided, not for answering
quickly.

What I am correcting from part two

I wrote that the system was "already on par" with the memory projects and that word-based
routing "was already hitting 75 %". The first was true in design and is half true in outcome: it
wins with the right note and loses at the choice. The second measured whether a useful note was
suggested, not whether the fact arrived. By the benchmarks' yardstick, the routing gets the note
right in first place a third of the time.

I am not changing systems because of this. Installing Mem0 or a vector database adds fixed text
at the start of every session, which is what gets paid for most often, and the advantage of
fragments with the real routing is a few points. The lesson is smaller and more useful: before
saying something is on par, measure it with the same question the others ask themselves.

The limits, so nobody takes the numbers too far

Lexical against lexical. The fragments use BM25, not embeddings, because I do not have them installed. A semantic search could raise the fragments curve and also the ladder's routing.
A hit is not a correct answer. I measure whether the line ended up inside what was read, not whether the model used it well.
A single pass. The real agent compensates with calls that are not charged here.
Exact match. A line rewritten in other words counts as lost, so the bench discards cases that would in practice be answered.
One person. These are my notes, my messages and my way of asking, which is vague when the conversation already has context.

The script for this bench is not in the
context-economy repository, for the same
reason as the routing one in part two: it depends on my notes reader and would not run on another
machine. The method can be redone with what is described above, on your own transcripts.

Frequently asked questions

Is it better to give the agent loose memory fragments, Mem0-style, or whole notes?

In my data it depends on whether the note is chosen well. With the right note, reading its current state and
the section that fits best found the answer in 32 % of the questions with 2.7k tokens; the
40 best fragments reached 26 % with 8.7k. With the real routing, which gets the note right in
first place only a third of the time, fragments win by a small margin at an equal budget.

How do you build a memory test bench without writing questions by hand?

From the transcripts. In each turn you take the memory lines the agent read, and you mark as answers the ones with at least three uncommon words that reappear in what the
agent replied and that were not in the question. You discard the turns where the agent writes
memory, because there the match is with what it has just drafted itself.

Why is the history of the notes the hardest zone to find?

Because the question almost never names the date or the episode. With the right note, the current
state was found in 18 of 18 cases and the dated history in 21 of 95. It is what LongMemEval
calls temporal reasoning, and in my data half of the answers lived there.

Keep going. This series is the basis of chapter 7 of Claude Code en serio, the practical guide I am writing in Spanish. That chapter, on where the tokens go and how to bring the cost down, is a free PDF in English: Claude Code token costs: where they go and what works.

Use it in your own setup. What I learned measuring these sessions is packaged as the Claude Code Cost Kit: seven hooks and a status line, an audit skill and a document style guard, for Windows, macOS and Linux. 29 USD, single-user license. Three of the hooks are free and open source: claude-code-cost-hooks on GitHub.

Originally published at talcaldeg.github.io.

Measuring was the product: almost every lever was small

Tomás Alcalde — Tue, 13 Oct 2026 13:42:04 +0000

In the previous article I explained that 94 % of what I
spent working with a coding agent went into re-reading context, and I closed with four habits
to bring it down. After publishing it I kept measuring. The idea was simple: take every lever
that came up (in my notes, in forums, in what the agent-memory projects do), estimate the most
it could possibly yield, apply it and measure again.

The result is not the one I expected. Almost every lever was small. Several moved nothing. A
couple came out negative. And the biggest correction of the month was not a technique for
saving, but an error in the yardstick I was using to measure everything else.

The short version, for anyone without twelve minutes

My meters counted every call 1.9 times. The totals in the previous article halve; its conclusions do not change.
The levers left after the first diagnosis yield, almost all of them, less than 2 % of the spend. Abbreviating and dropping accents yield nothing.
What did pay off was mechanism (a hook, a command that does three steps in one). A rule written into the agent's instructions lasted three days.
With sessions that are already short, cutting sessions comes out negative, and sometimes
the opposite pays: keep going in the same one.
1.9× how much my meters inflated each call before I fixed them
3 days how long a written rule lasted before it stopped being followed
< 2 % ceiling of almost every lever measured
-2.7 % what cutting sessions mid-task yielded

A note on units before going on. When I say "% of the spend" I mean weighted cost, not
volume: each kind of token is weighted by its relative price in the API, with input at 1,
output at 5, cache reads at 0.1 and cache writes at 2 (one hour) or 1.25 (five minutes). Volume
tells you how much was re-read; weighted cost, how much it weighs. Almost all the volume is cache
reads and, even so, they are less than half the cost.

First the yardstick had to be fixed

Mid-month, going over eight days of usage, the totals did not match the number of calls. The
cause was trivial and had been there for weeks. Claude Code writes one line in the transcript for
each block of the response (the text, each tool call) and repeats the same usage
block in all of them. My scripts added up lines. Each call was counted, on average, 1.9
times.

The fix was to group by requestId and count once. Those eight days went from
reporting 1,003 million tokens to 540 million. The drag from tool results fell almost by half,
because the later turns were also being counted twice.

That affects the previous article. Its absolute figures were computed with the old scripts.
With the same window and the corrected count, the 313 sessions become 294, the 2,356 million
tokens become 1,212, re-reading goes up from 94 % to 96 %, the curve's exponent goes from 1.20
to 1.19, and reading whole files is still 55 % of the drag. The totals halved; the shape
of the argument did not move. I point it out here because those figures are still
published, and the repository already prints the corrected ones.

The second correction to the yardstick came from somewhere else. To estimate how much the
agent's memory notes weighed, I converted characters to tokens with the rule that gets passed
around, about 3.5 characters per token. Calibrated against my own data (the jump in context
between two consecutive calls, which is exactly what was added), the model gave 2.1 characters
per token for prose in Spanish. With that, memory was not 7 % of the spend, as I had calculated,
but 10 %. The tool-result meter divided by 4, and I only fixed that on 25 September: the figures in the first part that depended on that conversion are now corrected there.

Neither correction changed a conclusion. Both changed how much each
lever could gain, which is the only thing that helps decide which one to work on.

Measure the regime, not the history

The second mistake was subtler. When you change something in the agent's setup (an
instruction, a hook, a reading script), the average over the last 45 days mixes two regimes and
describes neither.

It happened to me with the memory notes. Over the full history, the diagnosis was clear: almost
half of what was read from them was accumulated history that was not needed, and the obvious fix
was to split each file in two, one with the current state and another with the history. But
three days earlier I had changed the way they were read. Instead of opening the whole file, the
agent first asked for a map of sections with the cost of each one, and then fetched only the one
it needed. Measured only from that change, there were 2 whole-file reads against 198 by map or by
section, and the waste of that ladder, compared with having read the whole file in that same
session, was 1 %. Splitting files would have been work with zero return.

Since then every meter accepts --desde and --hasta (from and to)
with a time, and they cut by call, not by session. With both you can isolate a regime that has
already ended and compare it with the next one. And there is a separate script,
regimen.py, that warns above the figures when the window crosses a configuration
change.

The first time I used it to check a change, the estimate missed on both sides. I had applied
three cuts together. One of them, logging the memory notes at the end of the session with a
single command instead of reading and editing several files, I had estimated at 0.9 points of
the spend; it yielded 3.4 (memory writes dropped from 4.5 % to 1.1 %). Another, shrinking one
project's instruction file to a third, promised about 8 thousand fewer tokens per call and gave
6 thousand, with four sessions before and three after. And the total dropped 26 %, which I cannot
attribute to anything: the new window had ten long sessions against 35 short ones in the previous
one. The only thing that holds up when comparing windows that different is what is measured per
call and per session on the pieces the change touched.

What paid off was mechanism, not text

The big improvements of the month have something in common: none of them depends on the agent
remembering anything. They are code that runs on its own.

The cost ladder. The concrete problem was a memory note of 564 lines, about 17
thousand tokens, with 29 sections. Faced with a specific question about one of them, the only
realistic way out was to open it whole. Two options were added to the reader: one that lists the
sections with their line range and what each one costs, without reading any of them (about 1,200
tokens), and another that fetches a single section (about 1,300). The principle that stuck is that
you see the cost before paying it, and that each rung is worth roughly a tenth of the
next.

Blocking re-reads. Auditing a month of memory reads, 47 % were of the same file
in the same session: text that was already in the context. It was solved with a hook that denies
the second full read of the same file. It is the only block that cannot lose information, because
what it blocks is already loaded.

Routing. A hook suggests, on every message, which memory notes might help.
It used to match the message against hand-written trigger lines; now it runs BM25 against the body
of the notes and against the three previous messages in the session. To know whether it worked I
built a test bench from the transcripts themselves: for each of my messages, which notes were
actually opened to answer it. On the cases where routing is the only way in, the hit rate within
the top four suggestions went from 41 % to 76 %, with half the tokens per message. The number
looked too good to me, so I counted only the notes that were not in the context yet (suggesting
one that is already open saves nothing): 68 % against 43 %. The advantage did not come from
repeating what had already been read.

That bench also corrected a figure I had taken as solid. I had written that no word-based
routing could get past 70 % accuracy, because almost a third of the messages bring nothing to
search with ("check that everything came out right"). I had measured it looking at each message
on its own. With the two previous ones alongside, many of those messages do have something to
search with, and the installed routing gets past that supposed ceiling. Where the real ceiling
is, I do not know.

And one thing I decided not to do. Fourteen notes had never been opened in 393 sessions, and
pruning them seemed obvious. Looking at them one by one, "never opened" was not "redundant": two
were in the index that is always loaded and work precisely without being opened, and several held
rules that were not written anywhere else. They had not been opened because the topic had not come
up. Deleting them meant losing knowledge to save tokens that, as long as they are not opened, cost
nothing.

Written rules wear off

The flip side of the above. Every API call re-reads the whole context, so one extra call costs
more than almost any file. I measured how many calls the agent made per message of mine and wrote
an explicit rule into its instructions: chain into a single command whatever does not depend on a
previous result, and launch independent tools together.

Ten days later, calls per message had not gone down. They had doubled.

Window	Mean per session	Median	Overall
Before the rule	18.2	13.5	14.6
Ten days with the rule written	24.3	19.5	23.0
Next regime	32.7	27.0	29.2

That number is a little misleading. Messages per session had fallen from 1.7 to 1.1: I was
sending longer tasks in a single message. Calls per message measures the size of the task as much
as discipline, so it works as an alarm, not as a verdict. What is comparable is the behavior the
rule asked for. Shell commands with two or more chained steps were 84-87 % before writing it and
86 % after: they were already chained. And calls with more than one tool rose to 47 % in the three
days after writing the rule, only to go back to 18 % and then to 10 %. Three good days and it wore
off. The same thing had already happened to me with another rule a few weeks earlier.

Share of calls that send two or more tools together, which is what the rule asked
for. It went up in the three days after it was written and went back to its level.

I also tried the reverse mechanism: taking instructions out of the file that is always loaded
and putting them in a file that Claude Code loads only when working on certain paths
(.claude/rules/ with paths:). It works, but only reading or editing with
the file tools triggers it. If the agent reads through the shell, it does not load. Over a month,
of the sessions that touched that folder, in 78 % the rule would not have come in. It is useful
for reference guides tied to files that get edited, never for a rule that must not be broken.

The conclusion I drew: a written instruction yields what it yields in
its first days, and then the usual behavior comes back. If something matters, it goes in as
mechanism (a hook that blocks, a command that does three steps in one), not as one more line of
instructions.

The table of small levers

This is what the rest of the month measured. The ceiling column assumes full compliance, which
does not exist. The cost column is what you pay for trying.

The ceiling of each lever, as a percentage of weighted cost. The colored bar is the only
one measured after applying it, and it belongs to the batch described above.

Lever	Ceiling	What it costs or what happened
Batch independent reads into one call	1.5-1.8 %	A warning after every lone read costs 0.25 % and only breaks even at 15 % compliance.
Shrink tool arguments (long scripts, files written whole)	2.7 %	That is the total of all arguments. The "edit instead of rewrite" rule touches ~0.1 %.
Load instructions by path only	0.2 %	Does not load if the agent reads through the shell.
Trim the global instruction file	0.18 % per 10 %	Discarded.
Split the large memory notes	~1 %	The ladder had already solved it.
Don't search in the wrong place (another inbox, another folder)	0.25 %	It is a floor. Justified by quality, not by tokens.
Locate files with a folder map instead of searching	1.07 %	Includes the searches that were necessary.
Abbreviate the instructions	0	4.8 % fewer characters, 0.6 % more tokens.
Write without accents or ñ	0	1 % more tokens.
Drop the cache from one hour to five minutes	n/a	On a subscription, one hour is already the default.

Abbreviating deserves one more line, because it is the question I get asked most. My
instructions are written in Spanish, and the tokenizer splits by vocabulary pieces, not by letter.
Que, memoria or después were already one token; q,
mem or dsp still cost one, and odd symbols ("c/", "x") added pieces. The
correctly accented form turned out to be the most frequent one in the vocabulary, which is why
stripping the accents made it more expensive. You cut by removing content, not by compressing
it.

And I mention searching in the wrong place because I was surprised at how little it weighed.
Of 2,064 searches in two weeks, 99 failed, and I labeled them by hand one by one because the
automatic classification confused a retry with different words with giving up. The ones that went
to the wrong source (looking for a personal email in the work inbox, mostly) added up to 0.25 % of
the spend, about two calls a day. It is worth fixing anyway, but because concluding "there is
nothing" after looking in the wrong place is an error of content, not of cost.

Splitting sessions does not pay (and here I contradict myself)

In the previous article the number one lever was opening a new session when changing topic. A
month later, the measurement says that cutting mid-task comes out negative, and that sometimes the
opposite pays.

The math is this. Cutting forces you to write the session prefix to the cache again (the
instructions, the tool definitions, what the agent needs to get started), and writing costs 2
where reading costs 0.1. What you save is re-reading the accumulated excess on every following
call. Cutting only pays when that excess, multiplied by the calls left, goes past about 19 times
the size of the prefix. With sessions like mine, almost never.

I simulated it on the transcripts. The rule "cut when the excess goes past 25 thousand tokens"
gave -2.7 %; with 50 thousand, -0.6 %; from 75 thousand on it no longer cut any session. An oracle
that cuts at the best moment, knowing the future and without paying the cost of reorienting,
reached 2.9 %, and only in four sessions.

What did pay was the reverse: carrying on with the next task in the same session when it is
still light (under 20 thousand tokens above the floor, same folder, less than an hour between the
two). The first day I measured it, it gave +2.2 %. Then I found that the simulation accepted
merging sessions that had actually run in parallel, and without them it came to +1.7 to +1.9 %.
The second day gave +0.5 %: that day the work was already chained in long sessions and there was
hardly anywhere to merge.

Simulated savings on the transcripts, as a percentage of weighted cost. The oracle is
an impossible ceiling: it cuts at the best moment, knows the future and does not pay the cost of
reorienting.

There is no contradiction underneath, there is a change of regime. The first article measured a
period of sessions hundreds of turns long, where cutting saved a third. The habit worked: in the
regime I measured, 43 of 54 sessions had a single message, with a median of 13 calls. With
sessions that short, the margin is on the other side. I do not recommend it yet: it is two days of
different regimes, it describes rather than recommends, and it does not measure the other cost of
merging topics, which is the quality of what an agent answers with two matters mixed in its
context.

The cache, at the prices actually paid

In the current regime, cache reads are 46 % of weighted cost and cache writes, 36 %. Writes weigh
more than they seem because they are paid at double price: all of them are one-hour. I wanted to
try dropping to five minutes, which costs 1.25 instead of 2 in the API, and it turned out that on a
subscription one hour is the default for included usage. The surcharge in my estimate was the
API's, not what gets billed.

Broken down by origin, writes were 36 % session start and 64 % new content. Rewrites due to an
expired cache were zero in that regime. And the start is not writing the whole prefix: the first
call reads about 42 thousand tokens from the cache, which is the prefix shared across sessions and
survives even more than an hour without activity, and writes about 22 thousand of the session's
own. Even so, the start weighs 14 % of the cost, because most of my sessions are short. It is the
same math that makes cutting them negative.

Against the pioneers

Mid-month I reviewed how the most cited projects handle memory, among them Anthropic's guides on context
engineering and its memory tool, Manus (stable prefix and the file system as memory), claude-mem
(progressive disclosure in three layers), Letta (consolidation while the agent is idle) and Mem0 and
Zep, whose benchmarks cannot be reproduced from one harness to another.

The surprise was that the system I had put together measurement by measurement was already on
par. The routing that suggests, the section map and reading a single section are the same
progressive disclosure as claude-mem, with the cost in view at every rung. Separating, in each
note, a current state that gets rewritten from a history that only grows does what Zep does with
temporal validity. I ruled out installing any of them, or a vector database: they all add fixed
text at the start of every session, which is exactly what gets paid for most times, and the
word-based routing was already hitting 75 %.

Note from October 6, 2026: this comparison was by design. Measured by
outcome, the way memory benchmarks measure it, the ladder wins given the right note and loses at
picking the note, and the 75 % was measuring something else. It is in
the third part.

And with the token calibration corrected, the whole memory (instructions, index, reads, writes
and routing) weighed 10 % of the cost, and what could be trimmed within that, between 2.5 and 3 %.
It was applied, and it was the batch I talked about above.

What to measure, and with what

If anything stuck from this month, it is the order. Before applying a lever: measure its ceiling
with your own transcripts, assuming full compliance. If the ceiling is small, it is not even worth
the text that explains it. If it is big, prefer a mechanism to an instruction. And after applying
it, measure only from the moment of the change.

The scripts are in context-economy,
which now has six. They read the .jsonl files Claude Code leaves on disk and send
nothing anywhere.

python medir_consumo.py --desde "2026-09-21 11:44"
python medir_tool_results.py --desde "2026-09-21 11:44" --top 25
python medir_paralelismo.py --desde "2026-09-21 11:44" --muestra pares.csv
python medir_juntar.py --desde "2026-09-21 11:44"

medir_consumo.py gives the spend per session, with volume and weighted cost.
medir_tool_results.py ranks tool results by drag. medir_paralelismo.py
computes the ceiling of batching reads and leaves a sample to check by hand how wrong its heuristic
is (in my case, quite: of 30 pairs it marked independent, 12 and a half were). medir_juntar.py
simulates carrying on in the same session instead of opening another. regimen.py runs
inside the others and warns if the window crosses a configuration change.

There are two figures in this article that cannot be reproduced with that repository: the routing
hit rate and the cost of searching in the wrong place. They come from two scripts that depend on my
notes reader and on the structure of my folders, and publishing them would mean publishing something
that does not run on another machine. What can be redone is the method, which I described above: the
routing bench is built from your own transcripts (each message against the notes that were actually
opened to answer it), and failed searches are detected by empty result and classified by hand. The
session-cutting simulations and the cache breakdown are not in the repository either, since they ran
once on one window; the session-merging one is, because I am going to repeat it.

These figures belong to one person and their way of working, just as in the previous article.
The message I take away does not depend on that. Once the first diagnosis has been applied, what is
left to gain is small and spread out, and the only way not to spend a month on 0.2 % levers is to
know how much each one yields before moving it.

Frequently asked questions

Why do scripts that add up the usage block in the transcripts come out double?

Because Claude Code writes one line per content block of each response (text, tool call) and repeats the same usage in all of them. Adding up lines counted each call about 1.9 times. You have to group by requestId, or by message.id when it is missing, and count once.

Is it better to cut the session or keep going in the same one?

It depends on how long your sessions are today. With sessions that were already short, cutting mid-task came out negative (between -2.7 % and -0.6 % depending on the threshold), because every new session writes the prefix to the cache again. Carrying on with the next task in the same session, when it was still light, paid between +0.5 % and +1.9 % depending on the day.

Does abbreviating or dropping accents save tokens?

No. Measured on the same instruction text, written in Spanish, the abbreviated version had 4.8 % fewer characters and 0.6 % more tokens; without accents or ñ, 1 % more. The tokenizer splits by vocabulary pieces, not by letter. What moves the spend is how much text goes in and how many calls re-read it.

Does it work to tell the agent in its instructions to batch reads into a single call?

It worked for three days and then wore off. Calls with two or more tools went up to 47 % and fell back to 10-18 % from the fourth day on. The ceiling was small anyway: batching every independent read would have saved between 1.5 % and 1.8 % of the spend.

Keep going. This series is the basis of chapter 7 of Claude Code en serio, the practical guide I am writing in Spanish. That chapter, on where the tokens go and how to bring the cost down, is a free PDF in English: Claude Code token costs: where they go and what works.

Use it in your own setup. What I learned measuring these sessions is packaged as the Claude Code Cost Kit: seven hooks and a status line, an audit skill and a document style guard, for Windows, macOS and Linux. 29 USD, single-user license. Three of the hooks are free and open source: claude-code-cost-hooks on GitHub.

Originally published at talcaldeg.github.io.

What makes an agent expensive is not what it does, it is what it remembers

Tomás Alcalde — Tue, 01 Sep 2026 21:04:09 +0000

Correction, September 2026. The scripts behind this
article counted each model call about 1.9 times. With the corrected count, the same window gives
294 sessions, 1,212 million tokens, 96 % re-reading and an exponent of 1.19. The totals halve
and the diagnosis holds. What did change was the advice to cut sessions: a month later, with
sessions already short, cutting mid-task came out negative. The details, and what I measured
afterwards, are in the second part. A second correction, on 25 September: to go from characters to tokens I used 4 characters per token, and my data gives 2.1. That made each result about 1.9 times too small, close to how much the double count inflated the turns, so the published 380 million carry was near the mark by accident: with both fixes it is 345. The figures that depended on that conversion, and the split between short and long sessions, are now corrected in the text.

The bill started to hurt before I understood why. The work was the usual: queries against a
production database, reports, some automation, email. Nothing that sounded expensive. But the
consumption kept climbing and it did not match the feeling of asking for very little.

So I measured it. Coding agents store every session as a .jsonl file on disk,
with the token accounting of each call to the model. They are sitting right there, for free,
and almost nobody opens them. I wrote two scripts that read those files and answer two
different questions: how much did each session spend, and which specific call
inflated the context. What came out changed how I work, and it forced me to correct a rule
I had written down wrong myself.

313 sessions measured, the 120 days before 27 August 2026
2.36 B tokens consumed in total
94 % of that total is re-reading context already accumulated
0.8 % is what the model actually wrote

First: what you pay for is not the work

The natural intuition is that an agent costs in proportion to what it produces. It is exactly
the other way around. Out of 2.36 billion tokens, what the model wrote (the code, the answers,
the analysis) came to 19 million. Less than one percent.

The 2.36 billion tokens split by type. The coloured band is cache_read:
context that was already there and gets read again on every turn.

The reason is structural, and it holds for any conversational agent, not just this one.
Models have no memory between calls: on every turn the whole conversation is sent again. Turn
40 means reading the previous 39 turns one more time. Prompt caching makes that re-reading a
lot cheaper, but it does not remove it, and above all it does not change the fact that the
amount grows on its own while you work.

The mechanism: the same work, more expensive each time

This is the chart that organised the diagnosis. I took the 45 sessions longer than 120
turns, split each one into ten equal stretches, and averaged how much context the model read in
each stretch.

Context read on each turn, by progress through the session. Average of 45 long
sessions. The last stretch costs 2.9 times the first one, doing the same kind of work.

A session starts out reading around 69 thousand tokens per turn and ends reading 200
thousand. Nobody asked for anything bigger at the end than at the beginning. It is the same
question, with more history behind it.

Averaged over the whole curve: each turn of a long session costs close to twice what that
same turn would cost with the session freshly started. That is the tax, and it is paid without
ever showing up anywhere as a separate line.

What I believed, and got wrong

After the first measurement I wrote down a rule that sounded right: cost grows with the
square of session length. The reasoning was clean. If context grows linearly with turns
and every turn re-reads all of it, the sum is quadratic. A 300-turn session should cost five
times what four 75-turn sessions cost.

When I fitted the curve against the 313 real sessions, the exponent did not come out at 2.
It came out at 1.20.

Each dot is a session. On a log scale a power law shows up as a straight line and
the slope is the exponent. Fit over 313 sessions, R² 0.97.

The gap between 2 and 1.2 is not a blackboard detail, it changes the recommendation. At
exponent 2, splitting one long session into ten saves 90 %. At 1.2 it saves about a third.
Still a lot, and a third of the bill is a third of the bill, but it is a different conversation.

Why did the theory overshoot? Two things it ignored. There is a large fixed floor: the first
call of every session already starts at 59 thousand tokens on median, before you type anything,
because the preamble with the project instructions and the tool definitions always travels.
That floor is paid by every session, short or long, and it dilutes the part that grows. And
long sessions do not grow forever either: they hit the context window and the history gets
compacted.

I am leaving this in because it is the part that normally does not get
published: the rule I was applying came from correct reasoning on an incomplete assumption. The
number corrected it. A mental model that nobody checks against their own data turns into
technical folklore fairly quickly.

Where the volume comes from

Knowing that you pay for re-reading does not tell you what to stop reading. That is what the
second measurement is for, and it is the one that actually drives decisions.

Every tool result (the contents of a file, the output of a command, an email search) enters
the context and stays there. Its real cost is not its tokens: it is its tokens multiplied by
the turns that came after it. A 20-thousand-token dump on turn 3 of an 80-turn session costs
more than a 100-thousand-token one on the last turn. I call that carry, and
sorting by that column instead of by size completely rearranges the list of culprits.

345 million tokens of carry over the window measured, split by type of call.
Reading whole files takes more than half.

54 % is reading whole files. And inside that, the biggest surprise: a good part of it was not
code files but the agent's own memory files. The notes you accumulate so the
assistant knows how the business works. Every time one of those notes becomes relevant it gets
loaded in full, and the ones I had let grow unchecked were over 15 thousand tokens each. The
system that existed to make the agent more efficient was the main source of variable cost.

The pattern: filter before it enters, not after

All of the above converges on a single operating rule, and it is boringly simple:
whatever enters the context is paid for many times, so it has to be filtered before it
gets in. Not afterwards, not by summarising it on the next turn. Once the file is
inside, the damage is done for the rest of the session.

In practice that meant writing a thin filtered-reading layer. A reader that searches by
regular expression with surrounding context, with a hard character cap on what reaches the
screen and the full content dumped to a temporary file in case it is needed. It is very little
code and has no intellectual charm whatsoever. The effect does:

Listing the last six emails	tokens entering the context
Standard mail connector	5,178 (average of 171 calls)
Local filtered reader	495

An order of magnitude, for the same data on screen. And because the saving multiplies across
every turn that comes after, in a 100-turn session that single decision is around 470 thousand
tokens you never pay.

The other three that stuck as habits, in order of how much they returned:

A new session per topic. By far the biggest lever, and the hardest one to obey, because the accumulated context always looks like it is about to be useful. It almost never is, and it is paid in full on every turn until the end. In my data, the 196 sessions of 30 turns or fewer are 67 % of all sessions and 18 % of the spend; the 20 longest take 40 %.
Large outputs go to a file, never into the conversation. A report, a table dump, a log: to disk, and into the conversation only the summary or a head. I found a single tool result of 25 thousand tokens in one turn; that poisons everything that follows.
Search instead of read. grep with line numbers and then the exact range, rather than opening the whole file to change three lines. Broad searches go to a subagent, which works in its own context and returns only the conclusion.

One I evaluated and dropped: compacting the history pre-emptively at half the window. It does
save, but it compresses exactly the fine detail (precise figures, file state) and in work with
production data that detail is the one thing I cannot afford to lose to a mediocre summary. It
also treats the symptom. If a session is getting heavy, ending it and opening another beats
summarising it blind.

How to measure your own

None of this needs special instrumentation or a vendor that hands you telemetry. The
transcripts are on your disk and they carry the usage block of every call, with
input, output and tokens read from cache. A two-hundred-line script walks them and builds the
session ranking. Another one attributes each tool result to its call and multiplies it by the
turns that followed.

What matters is not the script but the order of the questions, and there are three:

What share of the spend is re-reading rather than producing? (If you get less than 80 %, check the measurement.)
How much does context per turn grow within a single session, start to finish? That is the tax, and it is what decides whether cutting sessions is worth it.
Which specific calls carry the most? That is your list of things to learn to read filtered.

Mine are in this repository,
together with the script that draws these four charts. It runs with a fixed cut-off date, so the
window is reproducible rather than drifting on every run: python graficos_articulo.py --dias 120 --hasta 2026-08-27. None of the three is long, around two hundred lines each,
and the questions above matter more than the code: what is worth having is the ranking of your
own transcripts, not mine.

Why this matters outside my machine

These measurements come from one person working at a company in southern Chile. They are not
a study. But the mechanism does not depend on scale, and the companies that started putting
agents to real work this year are going to run into the same thing when the first bill arrives
that does not match the intuition.

What I take away is that context discipline looks far more like 1990s memory management than
like prompt engineering. It is not about writing better instructions. It is about deciding,
deliberately and sometimes painfully, what does not get in.

And about measuring it, because whoever does not measure their context ends up paying to read it.

Frequently asked questions

The questions that came back after publishing this, each with the figure that answers it. All of them come from the same measurement described above.

Why does a coding agent get more expensive as the session goes on?

Because the model has no memory between calls: every turn resends the whole conversation. Measured across 45 long sessions, the context read per turn goes from 69 thousand tokens in the first tenth of the session to 200 thousand in the last one, doing the same kind of work. That is 2.9 times more expensive purely for carrying more history behind it.

How do you cut token usage in Claude Code or any AI agent?

Four measures, ordered by what they actually returned: start a new session when the topic changes; send large outputs to a file instead of into the conversation; use grep and read the exact range rather than opening whole files; and filter what enters the context before bringing it in, not by summarising it afterwards. Replacing a mail connector with a filtered local reader took the same on-screen data from 5,178 tokens down to 495.

Is it better to end the session and open a new one, or keep going?

It depends on how long your sessions run. Cost per session grows with turns raised to 1.20 (fit over 313 sessions, R² 0.97): with sessions of hundreds of turns, like the ones in this measurement, splitting them saved around a third. With sessions that are already short the sum flips, because every new session writes the instruction prefix to the cache again: in the September measurement, cutting mid-task came out between -2.7 % and -0.6 %. Also beware the rule of thumb that growth is quadratic: an exponent of 2 would promise 90 %, and against real data the exponent is not 2.

Does prompt caching not solve this?

It makes it cheaper, it does not remove it. In the measurement, 94 % of the tokens measured is cache_read: context that was already there and gets read again every turn. Caching lowers the unit price, but it does not change the fact that the volume grows on its own while you work.

Do the agent's memory files help, or do they cost?

Both, and it has to be measured. Reading whole files accounts for 54 % of the carry, and much of it was not source code but the agent's own memory notes: each one loads in full whenever it becomes relevant, and the ones left to grow unchecked were over 15 thousand tokens each. Split them into sections and read only the section you need.

How do you measure where an agent's tokens go, without vendor telemetry?

The transcripts are on your own disk as .jsonl files, carrying the usage block of every call with input, output and cache-read tokens. A script of about two hundred lines builds the session ranking; another attributes each tool result to its call and multiplies it by the turns that came after, which is the carry. All three are published in context-economy.

Keep going. This series is the basis of chapter 7 of Claude Code en serio, the practical guide I am writing in Spanish. That chapter, on where the tokens go and how to bring the cost down, is a free PDF in English: Claude Code token costs: where they go and what works.

Use it in your own setup. What I learned measuring these sessions is packaged as the Claude Code Cost Kit: seven hooks and a status line, an audit skill and a document style guard, for Windows, macOS and Linux. 29 USD, single-user license. Three of the hooks are free and open source: claude-code-cost-hooks on GitHub.

Originally published at talcaldeg.github.io.