The Rent You Pay Every Turn

• 16.2Btokens in 3 months
• $16.7KAPI-equivalent cost
• 86%of cost was context, not output
• 500Kavg context per call, big sessions

Nobody's remembering anything. You're re-sending it.

Here's the thing that took me embarrassingly long to internalize: the API is stateless. There's no conversation sitting on a server somewhere that the model can glance back at. Every single call re-transmits the whole pile: your chat history, every file it's read, every screenshot you took, every command's output. Caching makes that re-send about ten times cheaper per token, and it's still the biggest line on the bill, because the volume is enormous.

So I've started thinking about context as rent. When you pull a file into a session, you haven't paid for it once. You've signed a tenant. It sits in the window and you re-pay for it on every call that follows, right up until the session ends or the context gets purged. Read a 50,000-token file early in a session that runs a thousand calls, and you'll have paid roughly 50 million tokens for it by the end.

Output was 13% of my bill. The other 86% was re-reading stuff I'd already read.

The sawtooth, or what a marathon session really looks like

My biggest session ran 6,940 API calls and burned 3.56 billion tokens. Book editing, builds, scrapes, quick fixes, all of it living in one window that never ended. The chart below is that session's actual per-call context, pulled straight from the transcript. Watch it climb to the million-token ceiling, hit auto-compaction (where the tool summarizes old history to make room), and then climb right back up. Eight times.

Every tooth tells the same story. Rent compounds until the landlord forces a reset. The average call in there was hauling around 500K tokens of context, and most of it was stale tool output and files whose moment had passed hours earlier.

Now for the sneaky part. Plot that session cumulatively and you get a beautiful straight line, which reads as "all good here." A straight line just means the per-call cost pinned itself at the maximum and stayed there. An efficient session draws a straight line too, five to ten times shallower. The slope is the whole diagnosis.

Three shapes a session can take

What clicked for me is that "use fewer tokens" isn't a real instruction. Different work wants a differently shaped session, and the money leaks when you mix the shapes without noticing. Almost everything I do fits one of these three.

The Marathon

Anti-pattern

• One window for everything: edits, builds, scrapes, random questions
• Context rides at 500K to 990K and compaction keeps firing at the ceiling
• Your two-minute questions end up paying the big task's rent

My Jul 16 session: 3.56B tokens. Same work, split across five sessions, would've cost a fraction.

The Assembly Line

Default

• One task, one session. Ship it, checkpoint it, start fresh
• Agents do the reading and hand back conclusions
• Grep to find the spot, then read the section instead of the file
• Purge when a task ends, not when the window fills up

My median session: 36M tokens, about 1% of a marathon. The shape already worked. It just wasn't the habit.

The Studio

Declared, deliberate

• For judgment work that genuinely needs the whole corpus in the room: a manuscript's voice, a system's architecture
• Load exactly that corpus up front, then quit adding to it
• Batch your questions, since every turn re-pays the full window
• Near the ceiling you stop, checkpoint and close it rather than pushing on

Big context on purpose is money well spent. Big context by accident is a leak. The trick is knowing which one you're in.

Where the tokens sneak in: the Read multiplier

Across 20,487 tool calls, one humble tool accounted for 87% of everything that entered my contexts: plain old file reads. 2,733 of them pushed about 37M tokens of file text into sessions, and every one of those then sat in the window collecting rent for hundreds of calls afterward. The tool built to prevent exactly this, handing the reading to a subagent whose context gets thrown away, got used 451 times in three months. My least-used lever was my highest-value one.

The eight habits, and what each one actually fixes

I run automated guardrails now: a hook that warns me when context crosses 300K, 600K and 850K, plus a forced purge at 250K instead of riding to the million-token ceiling. Automation caps the damage. It doesn't do the work. Every real saving below comes from a decision a human makes at one of three moments: before a session starts, before a file gets read, and after something ships.

1. Pick the shape before you type a word

Fixes: small tasks inheriting a big task's rent

This is the one that cost me the most. My marathon session was doing careful book editing, which legitimately needs a huge window, and then in the same window I'd run a build, debug a scraper, ask a quick question about an invoice. Each of those little jobs got charged the book's 500K context, on every call, for no benefit whatsoever. The book work wasn't the problem. Hosting the other five jobs inside it was.

So now there's a ten-second decision at the top: is this assembly line work or studio work, and does the session I'm currently in actually serve it? If the context in front of me doesn't earn its keep for the new task, that task gets its own session. "While I've got you here" is the single most expensive phrase in this whole game.

What it looks like

Before starting: "New task, new session. This one is assembly line: fix the scraper's date parsing, nothing else."

2. Grep first, then read the part you need

Fixes: the 87% Read line, directly

Reading a whole 2,000-line file to change one function is the most common way people quietly torch a budget. The file lands in context at maybe 25K tokens, you use 40 lines of it, and then you pay for all 2,000 lines again on every subsequent call. Searching first turns that into a couple hundred tokens of match output plus a 60-line read.

The rule I use: any file over about 300 lines gets located before it gets opened. Search for the symbol, get line numbers back, read a window around them. If it turns out you need more, you can always read more. You can't un-read.

Instead of "read src/parser.py"

rg -n "def parse_date|DATE_FMT" src/parser.py
# then read only around the hits
sed -n '140,205p' src/parser.py

3. Send an agent to do the looking

Fixes: exploration becoming a permanent tenant

Investigations are where context goes to die. "Where is X handled?" means opening six files, five of which turn out to be irrelevant, and all six stay in your window for the rest of the session. A subagent runs that same search in its own throwaway context and hands back the two sentences you actually wanted. The six files never touch your main window at all.

My rule of thumb is anything spanning more than two or three files gets delegated. My data says I did this 451 times in three months when it should have been thousands. If you change one habit off this list, make it this one.

The prompt shape

"Use an agent to find every place we validate uploaded file types.
Report back: file paths, line numbers, and which validator each one uses.
Don't paste the file contents, just the findings."

4. Purge on your schedule, not the window's

Fixes: the sawtooth, and bad summaries

Auto-compaction fires when the window is full, which means it's summarizing at the worst possible moment: mid-task, with no idea which threads still matter. You get a summary that keeps whatever fits. Compacting yourself right after something ships gives you a summary built around a natural boundary, when the finished work is genuinely finished and safe to compress.

Milestone lands, write the state to a file, purge, start the next thing. That single sequence is what turns the sawtooth into the flat assembly line pattern.

The boundary ritual

1. "Update SESSION_STATUS.md with what we just shipped."
2. /compact  (or /clear if the next task is unrelated)
3. Start the next task with a fresh brief

5. Batch your questions when the window is heavy

Fixes: paying full freight for one-line questions

In a studio session carrying 600K of context, every message you send re-pays that whole 600K. Five drive-by questions asked one at a time cost five times what the same five questions cost bundled into one turn. It feels chattier to fire them off as they occur to you, and it's the most expensive kind of chatty there is.

I keep a scratch note open during heavy sessions and let questions pile up until I have three or four, then send them together. Same answers, one fifth the cost.

One turn, four questions

"Three things on chapter 9: (1) does the Dmitri callback land or repeat ch4?
(2) is the pricing anecdote too long? (3) name a better section title.
Answer all three, then wait."

6. Results go to disk, not into the chat

Fixes: using the transcript as a filing cabinet

Anything an agent produces, any report, any draft, belongs in a file. Then the main session reads back the two-paragraph synthesis rather than the twelve pages that produced it. The full output is still there when you want it, sitting on disk where it costs nothing per call instead of in a window where it costs on every call.

There's a second payoff. Saved state is exactly what makes the next fresh session cheap to start, which is what makes habit one affordable in the first place. The two habits hold each other up.

Standing instruction

"Write the full analysis to notes/audit-2026-08.md.
In chat, give me the three findings that change what I do next."

7. Match the model to the job

Fixes: paying scalpel prices for chopping vegetables

Renaming variables, reformatting a file, tagging a list, running a bulk edit: none of that needs the top tier. Blended across my three months, the cheap tier ran about $0.38 per million tokens and the frontier tier ran $1.77. Same job, four and a half times the price. Subagents take a model setting, so the cheap tier can do the grunt work inside a session that's otherwise on the good model.

Where it pays to spend up is judgment: architecture, debugging something genuinely weird, writing that has to be good. The chart below shows how the tiers actually shook out for me.

Tiering in practice

Mechanical (rename, reformat, categorize, bulk edit) → cheapest current tier
Daily driver (features, fixes, research) → newest mid tier
Hard judgment (architecture, prose, weird bugs) → frontier tier, sparingly

8. Prune whatever loads automatically

Fixes: overhead charged on call one of every session forever

Your project instructions file, your memory index, every connected tool's schema: all of it gets injected before you've typed anything. It's small per session and you have hundreds of sessions, so it compounds quietly in the background. Mine had accumulated a year of one-off notes that no longer described anything true.

Once a month I read the instruction file top to bottom and cut anything that isn't still load-bearing, then check which connected tools are actually earning their schema. Fifteen minutes, and it pays out on every session I run after it.

Monthly, on a Friday

Re-read CLAUDE.md and the memory index. Cut anything stale.
Audit connected tools: disconnect what you haven't used this month.

Model choice, and why the newest one usually wins

Three months of blended cost, meaning what my tokens genuinely cost per million across cache reads, writes and output, makes this part simple. Within any given tier the newer generation comes out ahead: same or lower effective price, plus it's smarter, and the smart part compounds in a way the price tag never shows. A sharper model finishes in fewer calls, wanders down fewer dead ends and re-reads less, so you're buying efficiency alongside the intelligence.

The scoreboard

None of this asks you to be less ambitious or work shorter days. The same three months of output, shaped properly, runs about half the cost, and the model gets to think with a cleaner window the entire time. That second part might matter more than the money.

Coming next: two follow-ups that get specific. Building the assembly line, with the folder structure, the search commands and the exact prompts I use. Then running a studio session properly, which is a different discipline entirely.