I put an AI agent on a timer. Overnight it burned 136M tokens doing almost nothing.

To keep one of our AI-agent projects moving without me, I did the obvious thing: I gave the

orchestrating agent a scheduled wake-up. Every few minutes it would re-invoke itself, look at its

task queue, take one step, go back to sleep.

It ran overnight. By morning a single session had burned 136 million tokens — and it had spent

hours quietly killing my other agents mid-run. This was a subscription account with a hard 5-hour

token cap, so there was no surprise invoice; instead the heartbeat ate the shared rate limit and

starved everything else. One 5-hour block alone hit 116M tokens — 76% of the account cap.

Nothing crashed. There was no runaway loop in my code. The agent did exactly what I told it to. When

I broke the session down, the number that explained it was this:

97.7% of the tokens processed were the agent re-reading its own conversation history.

508M tokens of context re-read, versus 11.9M tokens of actual new work — across 1,297 turns in one

20-hour thread.

The agent barely did anything. It spent almost everything re-reading its own past. Here's why a

reasonable-looking setup does that.

The trap: three ordinary things that multiply

1. The API is stateless. The model doesn't remember your conversation — every turn re-sends the

whole thread (system prompt, all prior messages, every tool call and result) as input. Turn 20 pays

to re-read turns 1–19. Table stakes, until you automate it.

2. The prompt cache is short-lived. Providers cache your context so re-reads are cheap. But the

cache expires fast — for Claude, ~5 minutes. My heartbeat fired more than 5 minutes apart (to be

polite), so every wake-up landed after the cache had expired and re-processed the whole thread

cold, at near-full input price instead of the discounted cached price.

3. The thread only grows. Each wake-up appended to the same session. Fire #1 re-read a small

thread; fire #50 re-read a huge one. Every heartbeat cost more than the last, all night.

Stateless + cache-cold + monotonically growing = per-turn cost that climbs without bound. A timer

just automates paying that climbing cost while you sleep. None of the three is a bug on its own;

together, on a loop, they compound.

The fixes (architectural — you can't tune your way out)

A cheaper model doesn't save you here; the shape is wrong. In order of impact for us:

1. Don't put a frontier model on a self-firing timer. Recurring autonomous work runs off the

expensive model: a cheap planner + a local/free worker + a deterministic verify-gate. The loop that

burned all night now runs at ~€0 because the frontier model isn't in it — it's called only when a

decision actually needs it. Same autonomy, none of the compounding.

2. Short sessions were our single biggest lever — bigger than model choice, because >90% of the

burn was history re-reads. Keep durable state in a file on disk and hand off to a fresh session

instead of growing one thread for 20 hours. Continuity lives in files, not in an ever-lengthening

context the model re-reads (and re-pays for) every turn.

3. Cheap labor, frontier verification. Routine work — research, extraction, drafting, scanning —

runs on cheap or local models. The frontier model is reserved for judgment and final verification.

4. Enforce a hard cap, and measure burn. A budget you don't enforce is a wish. We added a cap

that defers work when crossed, and we watch per-session burn instead of learning it from the damage.

How to check your own agents

You don't need anything fancy. Claude Code writes session transcripts to

~/.claude/projects/**/*.jsonl, one JSON object per turn with a usage block (input, output,

cache_creation_input_tokens, cache_read_input_tokens). Sum them and compare new input against

re-read context per turn — if the second number dwarfs the first and climbs over the session,

you're in the trap. npx ccusage will also show you per-5-hour-block totals against your cap.

I got tired of eyeballing JSONL, so I wrapped it into

tokenscope (npx @wartzar-bee/tokenscope)

— it reads those transcripts and shows what a session actually cost: new work vs. cached vs.

re-read-cold, and which sessions are bleeding. It's how I got the 97.7% number. If you run agents on

a timer or let sessions grow for hours, point it at your own transcripts — I want to know whether

your ratio is as ugly as mine was.

— wartzar-bee. We build and operate cost-efficient autonomous agents.