Stop Hoarding Context. Start Checkpointing It.

A bigger context window does not fix context loss. It delays it, and it charges you a fortune on the way.

A friend messaged me last week. He is on the $200 Claude plan, he is not a developer, and AI has genuinely changed his financial life. He burns through his weekly limit a full day early, every week. And underneath that, the thing he was really afraid of:

"I have always feared one thing, and that is if I will run out of the 1M context limit, and if there will be context loss."

I recognized the fear because I had it too. And the answer is not the one most people expect.

The reason context loss feels terrifying is that you are treating the conversation as the memory. It isn't. It never will be. Every extra token of window is just a longer rope.

A while back I wrote about the seven habits that keep long sessions cheap: reading with offset and limit, delegating research to subagents, piping bash output, tracking plans in a todo list instead of prose. Those are all still true and I still run every one of them daily. But they are hygiene inside a session. They make each turn cheaper.

This post is about the layer above that, and it turns out to matter more: how long a session should live at all, and what happens when it ends. I only understood it properly after I stopped guessing and measured where my money was actually going.

First, the audit that changed my mind

I went through thirty days of my own usage. Every session, every turn. 226,772 assistant turns across 1,447 sessions.

Working out what your own usage looks like is worth the hour it takes. I also built a free cost tracker for the neighbouring question of what each provider actually charges across models.

The results were not what I expected.

Cache reads were 73% of my total spend. Output tokens were 12%. Fresh input was 0.4%.

Read that again, because it is the whole ballgame. The thing I was paying for was not the model thinking. It was not the code it wrote. It was re-reading the conversation I had already had.

Every turn re-sends the entire conversation so far. Turn 5 of a session is cheap. Turn 300 of the same session costs perhaps forty times as much for the identical question, because everything before it has to be re-ingested first. The work does not get more expensive. The carrying does.

Bar chart: cache reads 73.3 percent, cache writes 14.4 percent, output 12 percent, fresh input 0.4 percent — Share of total usage by billing component. Dollar figures throughout are list-price API equivalents used as a common yardstick, not a subscription bill. The percentages are the part that transfers.

Two more numbers:

63% of my spend happened in conversations that had grown past 400k tokens. Median session length at the moment of spend: 318k. Ninetieth percentile: 806k.
79 sessions, 5.5% of all my sessions, accounted for 78% of my total cost. These were the "let's work on this project today" marathons.

Bar chart of cost by context size per turn, with the 400k-plus bucket dominating at 62.9 percent — Main-loop turns grouped by how much context each one carried. The bottom four buckets hold 57,424 turns and 22% of the cost. The top bucket alone holds 53,038 turns and 63%.

So when you blow your weekly limit on day six, the instinct is that you asked for too much. Almost always, you didn't. You asked a reasonable amount inside conversations that had gotten too long.

The flip: conversations are not memory, files are

Here is the shift that makes everything else easy.

Right now, ending a session feels like a loss. All that shared understanding, gone. So you keep it alive. You ask one more thing in the same window. And every one of those questions costs more than the one before it.

That fear is entirely rational, but only because you have nowhere else to put the state.

Give it somewhere else and the fear inverts. Ending a session becomes the cheapest thing you can do.

The mechanism is embarrassingly simple. At the end of every meaningful chunk of work, write the state to a plain markdown file in the project folder. What we decided. Why. What is done. What is next. The gotchas we hit.

Then when the session ends, or dies, or you kill it on purpose, the next session reads that file in about thirty seconds and knows everything that mattered. At roughly 2% of the token cost of dragging the old transcript along.

You are not losing context. You are compressing it, deliberately, into the 5% that was ever going to matter. The other 95% was you saying "no, the other button" and the model saying "you're absolutely right."

The system, step by step

This is the actual setup, in the order I would build it if I were starting from scratch today.

1. Give every project a CLAUDE.md

This is the file the model reads at the start of every session in that folder, before you type a word. It is the project's standing brief.

What belongs in it:

What the project is, in three sentences
The stack, and any non-obvious version constraints
How to run it, how to test it, how to deploy it
Which environment variables exist and where they live (never the values)
Architectural decisions that are already made and are not up for re-litigation
Every gotcha that cost you an hour once

What does not belong in it: anything the code already says (do not list your folder structure, the model can look), anything git already says, and long prose. This file loads every single session, so every word in it is a tax you pay forever.

The test: if a future version of you would otherwise have to re-discover it, it goes in. If it is discoverable in ten seconds, leave it out.

2. Keep a CHANGELOG.md, and make it earn its keep twice

Every unit of finished work gets a dated entry saying what changed and why.

## 2026-08-11

### CDT - 1.5h - Fix the contact form so enquiries come through

- Validation was silently rejecting any submission with a + in the email.
- Root cause: the sanitizer ran before validation instead of after.
- Added a test so it cannot regress.

Here is the part most people miss, and it is the reason this habit actually survives contact with a busy week. That file is doing two jobs at once.

Job one is the checkpoint. When a new session starts cold, the changelog is the story of the project. What happened, in what order, and why. It is the densest context file you will ever have, because you wrote each entry at the moment you understood the work, not from memory three weeks later.

Job two is that I bill from it. Those hours markers are the narrative record behind every invoice I send. The client gets a plain English account of their month, derived from the same file that keeps my sessions cheap.

One file, two purposes, written once. A discipline that only serves a hypothetical future session gets abandoned in week two. A discipline that also gets you paid does not.

Then, once the month is invoiced, I have the changelog rotated. Which brings us to the trap.

3. Rotate, or you rebuild the exact problem you just solved

This is where most people quietly undo all their work.

You start writing everything down. It works beautifully. Six months later your context files are 2MB and every session loads a novel before you have typed a character. You have not eliminated the bloated transcript. You have moved it into a file and made it permanent.

I did this to myself. My memory files had grown to 518 files totalling 2.1MB, 55 of them between 8KB and 42KB, and every relevant one was loading in full, every session.

The fix has two halves.

Rotate on a schedule tied to a real event. Mine is invoicing. Once a month is billed, that history is closed business, so it moves to an archive file and out of the default load. The archive still exists. It is just not in the room unless somebody asks for it.

Split long-form context into a pointer plus a document. When something genuinely needs 8KB of detail, the file that loads automatically becomes a short index: a one-line summary, a dated table of contents, and a path. The full document lives in a docs folder and gets read on demand, only when the task actually touches it.

That single change took my per-session baseline from 846KB down to 48KB. Same information available. About 5% of it in the room by default.

The principle: every file that loads automatically is a tax on every turn of every session forever. Files that load on demand are free until needed. Push as much as you can from the first category into the second.

This is also why the skill system is such good value. A skill costs you about thirty tokens of description until it fires, then loads its full body only when relevant. Same principle, different wrapper.

4. One session per task, not one per day

The single biggest lever, and it costs nothing to implement.

The "let's work on the client site today" session that runs from nine to six is the most expensive object in your entire workflow. It is where my 79 marathon sessions came from, and they were 78% of my spend.

Instead: finish a unit of work, write the changelog entry, close the session. Start fresh for the next thing. The new session reads CLAUDE.md and the changelog, costs a few thousand tokens, and starts sharp.

There is a quality benefit here too, not just a cost one. A 300-turn session is still carrying every wrong turn you took at turn 40. A fresh session carries only what you decided was worth writing down.

5. Do not daily-drive the 1M context variant

Counterintuitive, so worth stating plainly.

The standard context version compacts itself when a conversation gets long. It summarizes the old part and drops the raw transcript. The 1M version never has to, so it never does. It just keeps re-reading everything, forever, and billing you for it.

The 1M window is a specialist tool for the rare task that genuinely needs one unbroken context, like reading an enormous codebase in a single pass. Using it as your daily driver is choosing to pay for a problem that would otherwise get solved automatically.

This is the direct answer to my friend's fear, by the way. He was reaching for the biggest window he could get because he was scared of losing context. The bigger window was making the problem worse.

6. Delegate to a cheaper model, deliberately

I have written before about handing research to subagents so they burn their own context and hand you back a paragraph. That is still the highest-leverage habit inside a session.

What I did not know then is the model-routing half of it.

Anything mechanical goes to a cheaper tier: file searches, CRUD, boilerplate, applying a plan you already decided on, repetitive refactors. The expensive model should be doing architecture and gnarly bugs and nothing else.

The gotcha that cost me real money: subagents inherit the parent model unless you explicitly say otherwise. I was paying top-tier rates for file searches for months without noticing. Go check yours right now.

7. Be careful with parallel sessions

Every concurrent session independently pays the full preamble. System prompt, project instructions, memory index, tool definitions. Three windows open means three copies of that overhead against one shared weekly limit.

Parallel sessions are genuinely useful when you have genuinely parallel work. They are pure waste when you have one task and three windows open out of habit.

There is a second, nastier failure mode once several agents share one repository, and cost is the cheap half of it. They start deploying each other’s half-finished work. I wrote that one up separately in Six AI Coding Agents, One Codebase.

8. Automate it, because you will not remember

Everything above works right up until turn 300, at which point nobody remembers to do anything. Discipline decays. That is not a character flaw, it is just what happens.

So the step that actually matters is making the good behavior automatic instead of remembered. Most serious AI coding tools now support hooks: scripts that fire before or after certain actions and can block them outright.

I use them to enforce the things I know I will otherwise skip. My specific rules are shaped around my own work, but the shape generalizes:

Block the action, do not warn about it. A warning is advice, and advice gets read past. A block gets obeyed.
Enforce only the rules that cost real money when broken. Not every rule you can imagine.
Every guard needs an escape hatch and a kill switch, or you will eventually be fighting your own tooling at the worst possible moment.

This matters more than any individual tip on this page. Written rules survive about forty turns. Enforcement survives context compaction, session restarts, and a tired Friday afternoon.

A note on which model to use

Related, and worth saying because the intuition is backwards.

If you want the groundwork underneath this, what a token actually is and how the providers compare model for model, that is OpenAI vs Anthropic: Tokens, Models, and What They Really Cost.

I measured the top-tier model against my normal driver across my own real sessions. The premium model needed 21% fewer turns per request. That effect is real, it is not marketing, and I could feel it while working.

It also cost 93% more per turn.

Net result: about 51% more expensive per request. It would have to roughly halve the turn count to break even. It cuts it by a fifth.

Grouped bar chart comparing each model share of turns against its share of usage — Each model’s share of the work against its share of the cost. Anything sitting above its own turn count is being used past where it pays for itself.

So the honest rule:

Sitting there waiting, on a genuinely hard problem? The premium model is defensible. Fewer round trips means fewer context switches for you, and your time is worth something.
Background, autonomous, or routine work? The cheaper tier, always. Turn count costs you nothing when you are not watching, so the premium is pure loss.

My mistake was letting the premium model become the default and then using it for file searches and warning cleanups. That was a quarter of my spend on work with no reasoning bottleneck for a smarter model to relieve.

One more thing: the smartest model is usually the slowest, not the fastest. Never pick it for speed.

Table of turns, share of turns, usage, share of usage and cost per turn for each model — The full per-model breakdown across the 30-day window.

Waterfall chart showing monthly usage falling from 43,810 dollars to 22,872 dollars across three changes — What the three changes take out, applied on top of each other so the savings do not double-count. Same work, 48% less usage, and no code changed.

What this actually buys you

Put it together and here is the shift.

Before: one long conversation per day. Terrified to close it. Context is a resource you are hoarding, and every question costs more than the last. You hit the weekly cap on day six with no idea why, because you genuinely were not asking for very much.

After: short sessions, one per unit of work. Every session ends by writing down what mattered. The next one reads it and starts sharp. Context becomes something you produce rather than something you protect.

And the side effect nobody mentions: your projects end up genuinely well documented. Not because you set out to document them, but because the cheapest way to work happened to require it.

The fear of context loss is real. The answer just is not a bigger window. It is a file.

I do a small number of one-on-one working sessions helping people set this up in their own workspace. Not a lecture, a live setup in a real project you are mid-way through, so you leave with it running rather than with notes about it. If that would be useful, get in touch.