Making Claude work for days

What it is and why it matters

A big job doesn't fit in a single conversation. Claude works inside a limited memory, the context window: it holds the chat, the files it has read, the output of the commands. The further you go, the fuller it gets.

When it gets close to the limit, Claude Code compacts it on its own: it summarizes the conversation. Your requests and the important code stay, but instructions you gave at the start can get lost. And every new session starts from scratch, without the previous conversation.

So if the plan lives only in the chat, a day later it's gone. I keep it in a file in the project: every session reads it at the start and updates it at the end. The file is the memory, the sessions are work shifts. Then an alarm restarts the work when it stalls.

1. The logbook file

In the project folder, create a file called LOGBOOK.md with this content:

# Goal
[One sentence. E.g.: "New pricing page, live, tested on a phone".]

## Done
- [ ] (the sessions tick off here what they finished, with the date)

## To do
- [ ] [first piece]
- [ ] [second piece]

## Decisions made
- (each session writes here what it decided on its own and why)

## Where I stopped
(the last session writes here the exact point to pick up from)

The goal is a single sentence, and it has to say when the work is really finished. “New pricing page, live, tested on a phone” is different from “make the pricing page”: the first one has an end, the second doesn't.

Under “To do” put small pieces that one session can close in one go: a screen, a connection, a fix. If a piece is “build the whole payment flow”, it's too big. If you don't know how to break it down, have Claude do it before you start:

Read LOGBOOK.md and the project's code. Rewrite the 'To do' section as small pieces in order, each one small enough to finish in one session and to be tested. Don't write any code.

“Decisions made” is, in my opinion, the most useful part. When you come back after two days and find a strange choice, the reason is written there. And the next session doesn't undo it.

2. The sentence that opens every session

Every time you open a session on this job, the first thing you write is this:

Read LOGBOOK.md before doing anything. Work only on the first item under 'To do'. When you finish it and the tests pass, move it to 'Done' with the date, write down the decisions you made and update 'Where I stopped'. If the conversation gets too long, update the file and stop: another session will pick up from there.

“Before doing anything” stops Claude from changing files before it knows where things stand. “Only on the first item” keeps the session short. “The tests pass” means the piece works, not just that it's written: if you have no tests, put in your own check, like “the page opens without errors”.

The last sentence is the one that makes the work last for days. The session doesn't have to reach the end at all costs: it has to leave the file in order, so whoever comes next starts clean.

If you have to close it yourself halfway through a piece, ask this first:

Stop here. Update LOGBOOK.md: under 'Where I stopped' write the exact point, what you've already changed and what the next step is. Don't leave anything only in the chat.

If you don't want to paste the sentence every time, you can write it in the project's CLAUDE.md file: Claude Code reads it at the start of every session and loads it again after a compaction too.

3. When the memory fills up

You don't need a very long session: close it and open a new one with the same sentence. It starts again from the file, not from the chat.

Claude Code has three commands that help:

• /context shows you how full the memory is and what's taking up space.
• /compact summarizes the conversation and frees up space, staying in the same session. You can give it a focus, like /compact keep the decisions.
• /clear opens a new, empty conversation. The old one isn't lost: you find it again with /resume.

For a job that lasts days I prefer /clear and the opening sentence. With compaction, Claude Code decides what to keep. With the file, I know exactly where it starts again from.

To reread an earlier conversation, from the terminal claude --continue reopens the most recent session in the folder and claude --resume lets you pick from a list. To move forward, though, you start again from LOGBOOK.md.

4. The alarm

The alarm is an automatic check that every so often looks at whether the work has stalled and restarts it. In the video I put it like this:

every hour check LOGBOOK.md; if 'Where I stopped' hasn't changed and 'To do' isn't empty, open a new session with the opening sentence

Claude Code can start work on its own on a schedule, in three ways. What changes is where it runs and what has to stay on.

In the desktop app: a scheduled task

This is the one I use for this. In the desktop app, in the Code tab, open Routines, create a new routine and choose Local. Write the instructions, pick the project folder and the frequency, for example Hourly. It runs on your computer, so it sees your files, LOGBOOK.md included.

There's one detail that changes the prompt: every time it runs, the task already opens a new session by itself. So in the instructions you put the check and the work directly:

Read LOGBOOK.md. If 'To do' is empty, do nothing and stop. Otherwise work only on the first item under 'To do'. When you finish it and the tests pass, move it to 'Done' with the date, write down the decisions you made and update 'Where I stopped'. If the conversation gets too long, update the file and stop: another session will pick up from there.

It only runs with the app open and the computer awake: if the computer is asleep, that run is skipped. And if the previous run is still going, the new one doesn't start. Before you leave it alone, press Run now and approve the permissions it asks for with “always allow”, or it stops at the first request and waits for you.

In the terminal: /loop

If you work from the terminal, /loop repeats a prompt at intervals as long as the session stays open: for example /loop 1h followed by the check to do. But it doesn't open a new session, the prompt comes back into the same conversation. It stops if you close the terminal and switches itself off after seven days. It's fine for a working day, less so for leaving it to run on its own.

In the cloud: routines

With /schedule you create a routine that runs on Anthropic's servers, even with your computer off, at most once an hour. Each run is a new session, but on a fresh copy of your GitHub repository, not on the files on your computer: LOGBOOK.md has to be in the repository. The changes go to a separate branch and the next run starts again from the main branch, so say in the prompt which branch to work on.

No magic: a logbook and an alarm.

Common mistakes

• Keeping the plan only in the chat: after a compaction or a new session it's gone. Write it in LOGBOOK.md.
• Pieces under “To do” that are too big: the session fills up halfway through. Break them down until each one closes in a single session.
• Closing the session without updating the file: the next one starts in the dark. Before closing, always have “Where I stopped” updated.
• Not saying when a piece is finished: Claude moves it to “Done” as soon as it's written. Ask for the tests to pass, or put in your own check.
• Leaving the scheduled task alone without trying it first: it stops at the first permission request. Start it once with Run now and approve what it needs.

Checklist

• LOGBOOK.md is in the project folder
• The goal says when the work is finished
• Every item under “To do” closes in one session
• Every session starts with the opening sentence
• Before closing, “Where I stopped” is up to date
• The alarm has been tried once by hand

Frequently asked questions