The one word that ate 20% of my five-hour allotment

I typed one word into a long-running Claude session — “go” — and watched it eat a fifth of my five-hour usage allotment in a few seconds.

I’d been away from the session about an hour. The message was one word. That bill made no sense to me until I dug into how these sessions are actually metered. The mechanics turned out to be simple and predictable, and if you work in long agent sessions you should know them cold. Here’s the whole thing.

The mechanics

Four facts. The trap falls straight out of them.

1. The model is stateless. There’s no session on the server. Every time you hit send, the client uploads the entire conversation history plus your new message. Turn eleven carries the ten turns before it. Turn fifty carries forty-nine. This is true for claude.ai, Claude Code, and anything else built on the API. The upload hasn’t gotten smarter. The full history goes up every turn.

2. Input billing is linear. A turn that processes 50,000 tokens of history costs about 50 times a turn that processes 1,000. What you just typed is a rounding error. The history is the bill.

3. Caching is what makes this survivable. The server caches the stable prefix of your conversation and bills repeat content at roughly a tenth of the normal input rate. Important detail: the cache is metering, not transport. Your machine still uploads everything; the server just recognizes the prefix and charges you the discount instead of re-processing it.

4. The default cache TTL is five minutes. That’s the whole trap. There’s an extended one-hour TTL behind a beta header on the API, but five minutes is what you get by default.

Put them together. Work steadily and every turn lands inside the TTL — the history re-bills at the discount and turns stay cheap. Step away past the TTL — lunch, a meeting, overnight — and the cache ages out. The next turn re-processes every token of accumulated history at full rate. My “go” wasn’t a one-word purchase. It was a re-purchase of everything above it.

Why it blindsides you

The cost of a message looks like the message. One word should be the cheapest possible turn, and it would be if the meter were measuring what you typed. It’s measuring the prefix. The prefix only feels free while the cache is warm, and nothing about the interface tells you the cache went cold while you were at lunch.

The client does try to warn you. Newer Claude clients flag a turn that’s about to send a large prompt, and that warning fires on exactly this case — the first turn of a resumed session. I used to dismiss it, because I’d just typed something short and the warning seemed miscalibrated. It isn’t. It’s the one moment you can still choose.

You can also confirm the trap after the fact. On the API, every response carries usage fields — input_tokens, cache_read_input_tokens, cache_creation_input_tokens. A cost spike where cache_read sits at zero is this trap, verified. In Claude Code, /cost shows you the shape mid-session.

What to do about it

I’m not going to pad this out with generic token-saving tips. For this specific trap there are three moves, and all of them happen at the moment of resume:

Resume inside the TTL when you can. Under five minutes away, the cache is warm and the turn is cheap. A coffee refill is free. A meeting isn’t.

If you’ve been gone longer, treat the next send as a purchase decision. Sometimes re-buying the history is right — the accumulated context is worth it and you keep going. Fine. Just make it a decision instead of a surprise.

Or restart from a summary. A short “where we left off” note runs a few percent of the size of the full history and carries most of what matters. If the session’s context was mostly spent anyway, this is close to free and you skip the re-bill entirely.

That’s the whole playbook. Everything else you’ve read about trimming context is fine advice for a different article.

The lesson

The cost of a turn is the history behind it, not the message in it. The first turn after any break is the expensive one. Watch that turn.

SOs

SOs — standing orders you can lift and prime your own agent with. (New here? The convention started with the Neverland post.) Paste them into a session for a one-time dose, or commit them to your CLAUDE.md / AGENTS.md and they stay in force.

STANDING ORDERS — The resume-after-break trap
Source: "The one word that ate 20% of my five-hour allotment" — bensimon.dev

1. Before the first turn of a resumed session — any gap over five minutes —
   state the size of the history about to be re-billed and offer the choice:
   proceed, restart from a summary, or branch fresh.

2. Treat a large-prompt warning as a decision point, never noise. When it
   fires, name what's driving the size and what the options are.

3. Never attribute a cost spike to the visible message. Attribute it to the
   prefix behind it, and say so in your report.

4. When cost is questioned, check the usage fields — cache_read vs input —
   and report whether the turn paid cache rate or full rate.

5. Keep a running "where we left off" summary current so a summary-restart
   is always available at resume time, not something to reconstruct after
   the bill lands.