Running Claude Code for days on a clean context
What I’ve learned from letting one autonomous session build a project for a week, and the single prompt that sets it all up for you.
A record I don’t remember
I opened the talk by asking the room about their longest Claude Code session. Ten minutes, an hour, a day. Mine? I honestly don’t know, and I don’t want to remember. That isn’t a punchline. It’s the architecture.
One session, in the week before the talk, delivered 42 work packages across 3 milestones. I wrote zero lines of code and pasted one prompt. To me, it was just an ordinary week. Then I mentioned it to a friend, and the reaction was: wait, how did you do that? That reaction is the reason this exists.
The conversation is not the memory
If you keep one idea, keep this one: the context window will fill, so stop using it as storage.
The memory lives in files: a PROGRESS.md ledger, the git history and CLAUDE.md. Files survive compaction. Chat doesn’t. Everything else follows from that.
The shape
One session acts as the orchestrator. It’s a project manager who has never opened the repo, and that’s the entire point: it reads only the ledger, so its own context stays flat at roughly 6 to 10k tokens per package. The real work happens in fresh subagents.
ORCHESTRATOR ← reads only the ledger
(never reads code) ~6-10k tokens / package
│
┌──────────┼──────────┐
▼ ▼ ▼
implementer reviewer architect
(fresh) (fresh) (read-only)
│
▼
PROGRESS.md ── commit ── push
Eight rules
- The boss never opens the repo. The orchestrator writes no source code, so its context stays flat across dozens of packages.
- Fresh context per unit of work. Every implementer and reviewer starts clean. Quality drops noticeably past about 100 to 150k tokens in one window.
- State lives in files.
PROGRESS.md, git history andCLAUDE.mdare the memory. - Never trust the report. The orchestrator re-runs verification in its own shell. Agents report optimistically, like a junior dev at 17:55 on a Friday.
- A different agent reviews the work. A separate reviewer, with a bound: at most 3 rounds, then the package is marked BLOCKED.
- Push after every package. A crash then costs one package instead of a day.
- Write the resume note early. Before the conversation grows long, and read it first after any compaction. This is the survival mechanism.
- Blocked is not stopped. Write a blocker brief and take the next package. There is no “ask Jan”. Jan is asleep.
Launching it
Three things keep a multi-day run alive: tmux so a dropped terminal or SSH session doesn’t kill it, caffeinate so the Mac doesn’t sleep, and bypass mode so it never stops to ask.
tmux new -s claude caffeinate -dimsu claude --permission-mode bypassPermissions
Bypass mode means the agents can run anything: installs, Docker, pushes. Run it on a dedicated VM or user account, not on the laptop with your production keys.
What goes wrong
Autocompaction is not the enemy. It will happen, several times, and it’s supposed to. With the ledger and the resume note, the worst case is one repeated review round, and nothing gets committed until it’s green.
There is no budget cap. No per-agent limit, no “stop at $200”. On the API, a plan this size ran $500 to $2,000. On a subscription, you stall until the limit resets. You are the only brake.
It will land early. Not a crash: it decides it has done “enough” and writes you a tidy summary. This is the one failure that defeats the whole point of an unattended run. So you define done: the exit condition in the prompt is “loop until every work package is DONE or BLOCKED”, and a Stop hook refuses to let the session end while the ledger still holds a TODO row. The ledger turns “done” into a fact in a file rather than a feeling in the model. Leave it undefined and the model defines it for you, generously.
Things that killed my session: a screensaver, a closed laptop lid, a dropped SSH connection, a rate limit at 03:41, and “I have completed the implementation!”. That’s why the launch has tmux and caffeinate.
And the rest of the bill. Fresh contexts forget conventions from three packages ago, so expect a cleanup package per milestone. Weak test assertions pass both verification and review. And the 42-package plan was written before any code ran: it’s precise, and precision reads as accuracy, but some packages will turn out wrongly sized or ordered. It degrades gracefully, not to zero. Plan on reading the ledger once or twice a day.
The only thing worth remembering
Here’s the twist from the end of the talk. I didn’t invent any of these rules. I asked Claude Code, and what I showed was its answer. So you don’t need to memorise the list above. Open a fresh session in your project and type:
i want a long-running, several-days autonomous session with clean context. write me the prompt for my task.
It knows its own subagents, hooks, compaction and failure modes, and it will shape the prompt to your repo instead of mine. Prompt libraries go stale in weeks. Stop collecting prompts. Ask Claude how to Claude.