I was looking for the problem among the agents, but it was sitting right next to me.
I have two Claude Max 20x subscriptions, and both of them have a weekly limit. For a while it would run out somewhere around Thursday, and after that I either waited or worked through the paid API. At some point I got tired of this, and I decided to figure out where the tokens actually go.
A bit of context first: Swarmery is a program that runs on my computer next to Claude Code. Claude Code saves a full record of every session to disk, and Swarmery reads these records into its own database: every model response, how many tokens it took and which agent gave it. So I didn't have to guess, I could just look.
In short:
- Hundreds of background sessions ate less than two percent of the tokens.
- One session in five went past 300 thousand tokens, and those sessions ate four fifths of everything.
- What helped was not a new tool but a habit: closing the session when a phase of work ends.
Hundreds of sessions that cost almost nothing
The first thing I thought of was background sessions. Swarmery starts some of them itself: there is a judge that evaluates how the agents did their work, there is a session that writes notes for handing work over, and a few more like that. I should say right away that these are not the subagents people usually argue about online, I will get to those later.
These are small sessions that nobody started by hand, they just show up on their own, and there were hundreds of them on the dashboard. One day in July there were 305 of them, while my own sessions in projects that day were 28. The day before there were 30 background sessions, the day after there were 55, so that day was clearly not a normal one.
And the reason turned out to be pretty funny: there was a bug where the judge was evaluating its own evaluation sessions, and then evaluating the sessions where it evaluated those, and so on in a circle.
The judge evaluated its own evaluations, and then evaluated those, and so on.
I fixed the bug, and then out of curiosity I counted how much those 305 sessions ate. All together, less than two percent of the tokens that day. The rest, more than 98%, was eaten by my 28 sessions.
So the number of sessions tells you nothing at all. And then I looked not at how many sessions there were, but at what kind of sessions they were.
Long sessions ate four fifths of the tokens
I took eight weeks and sorted the working sessions by how big their context got. Context is everything the model has to read before it answers: the whole conversation, files, command output. The models I use accept up to a million tokens, so a session can grow for a very long time, and nothing stops it.
The picture turned out very simple:
- More than half of the sessions never went past 150 thousand tokens, and all together they cost almost nothing.
- One session in five went past 300 thousand, and those sessions ate four fifths of all the tokens.
- Such a session lives fourteen hours on average and has hundreds of model responses.
The problem was not how many sessions I had, but how long they lived.
The same question, but in the long session the model first has to read through everything that came before.
Why a long session is so expensive
The model remembers nothing between responses. Every time, before it answers, it reads the whole conversation again from the start. Claude Code keeps this text in a cache, and one read from the cache is cheap. But it happens before every single response, and the conversation keeps growing.
And when I measured it, it turned out that the same response in a session of 300 thousand tokens costs three times more than in a fresh one. And if you count tokens instead of cost, cache reads are 98% of everything that went through the system. What I actually type is a tenth of a percent.
And here is the catch: the cost doesn't grow in a straight line. If the conversation is twice as long, every answer costs about twice as much, and there are also about twice as many answers, so the whole session costs not two but about four times more. That is why one session of fourteen hours can cost more than a whole day of short ones.
Imagine a meeting where, before anyone says a new sentence, the secretary reads the whole protocol out loud from the first minute. In the first hour nobody notices, but by the evening nobody is working anymore, everyone is just sitting and listening to the protocol.
Before every new answer, the whole protocol is read again from the first minute.
I checked subagents separately, because that is what people write about most as the thing that burns tokens. And yes, in sessions where the main agent hands out work for hours, they really do make up the bigger part. But half of my most expensive sessions are just me and one very long conversation, without any subagents.
And both kinds ended up on the list for the same reason: they are long.
Handoff notes in Swarmery
First I did a simple thing: every session card now has a context badge, yellow from 150 thousand tokens and red from 300 thousand. Just to see it, instead of guessing.
But the main thing is the handoff. When a session goes past 150 thousand, Swarmery writes a short note by itself:
- what the goal was;
- what state the work is in now;
- which files were changed;
- which decisions were made;
- what the next step is.
If the session grows another 75 thousand, it writes a fresh one. It writes the note from its own database, not from the transcript, because reading a 400 thousand token transcript in order to save tokens is like treating a disease with something more expensive than the disease. Then I take this note, close the session and continue in a new one, where the context is small.
A short note is enough to carry the work over into a new session.
And here I have to be honest: at first this didn't work. The note would show up on the card, and I kept working in the same session. I checked the data: in most cases, after the note was ready, the session lived for another hundred responses or more.
I know the reason in myself. When the task is big, it feels like you will lose something important with a new session, and it's a pity.
What helped was to stop tying the handoff to the size of the context and to tie it to the structure of the work instead. In Swarmery a big task is a plan split into phases, and each phase is a separate document with a list of items. The end of a phase is a natural place to stop: everything you need to know next is already written in the plan, not in the head of the session.
The end of a phase is a natural place to stop.
The reason this works is simple for me: a short session is not only cheaper, it is also smarter. A model that reads 100 thousand tokens keeps in its head what matters right now. A model that reads 500 thousand also keeps in its head all the wrong moves, old versions of files and command output that nobody has needed for a long time.
How to check this on your own machine
If your limit also runs out in the middle of the week, I wouldn't start by counting agents. I would look for the few sessions that lived the longest. You don't need Swarmery for that: Claude Code keeps one file per session in ~/.claude/projects, and the biggest files are where it makes sense to start.
After that the question is not about the tool but about the habit: stop when a part of the work is finished, not when the tokens are finished.
The Swarmery code is open on GitHub, and the script that calculates all the numbers in this post is right next to the article.
This post was first published on my Substack, where I write about building Swarmery, a local control plane for Claude Code agents. If you want the next posts, you can subscribe there.
Top comments (2)
Your three times lines up with what I measured on my own logs: a reply in a long session cost about 3.3 times one in a short session. The thing that moved my week most was a different cut, though. Code reviews were the biggest eater, and moving them to a second model took about 71% off Claude tokens per review. A review reads a lot of files before it writes a word, so it’s the first part of a phase I’d split out. In your long sessions, was it mostly building, or review and fix rounds?
Usually the limit goes on input tokens, not on the answers. Each request sends the session's earlier messages again, so one long session can use more of the weekly budget than several short ones.