The night the AI got cut off: how the work carried on (Behind the behind, episode 4) | The paper plane: a film and the system that made it

This lesson shows how the build of Allan’s film carried on after the AI doing the work was cut off in the middle of the night, and what had been written down so that a fresh session could pick it up. After it you should be able to set up the same safety net for any long job you give an AI.

The AI here is Claude, which Allan used to build Behind the paper plane. The key fact: an AI session can stop at any moment, and a new session remembers nothing of the old one.

Cut off at 05:49

At eleven minutes to six in the morning, Claude stopped in the middle of its work. It had used up its usage for that session. Four helpers it had running were cut off, and nobody was awake to start them again.

A frame from the film. The Claude Code chat inside a code editor, its clock at 05:49. Four glass helper cards, each with a thin progress line, have frozen and gone grey. Under them a grey system line reads: You've hit your session limit, resets 7:50am (Europe/Copenhagen). The message box below is empty. — 05:49: four helpers frozen and the usage limit notice. Nobody there to answer it.

The question before bed

At one minute to midnight, Allan had asked what would happen if the usage ran out while he slept. Would it wait for him, or start again by itself? The answer: it stops, and it cannot start itself again. But it could set a timer and check on the build regularly.

Each check would read three things:

The build’s own log (progress.md), where every step is written down.
The review log (REVIEW.md), where every decision is.
The last saved steps, the five most recent commits in git (the version history).

Then it would find the next unfinished step in the plan and carry on. Allan said yes, asked for every thirty minutes instead of every hour, and went to bed.

A frame from the film. The clock reads 00:32 and a small timer dial sits beside it. In the file list on the left, three files are lit and labelled in large type: progress.md, the plan 2026-10-21-behind-the-plane.md, and REVIEW.md. A terminal panel at the bottom holds blurred rows of recent commits. — What each check reads: the build’s log, the plan, the review log, and the last saved steps below.

The night, and a timer that could not help

The timer rang through the night and the helpers kept building. Just after five, the film’s first part was finished. At 05:49 the usage ran out.

By then, sixty-three steps had been saved since Allan’s last message. Four pieces of work had not: two scenes for the film’s second part, half written, and two new styles for its fourth part, one nearly done and one barely begun. They were on the disk and nowhere else.

At 06:13 the timer rang. The only answer was the notice: limit reached, back at ten to eight. Half an hour later, the same, and twice more. The timer worked, but it rang inside the same session that had run out. It could knock. It could not open the door.

One line in the log

At ten to eight the limit lifted. At eight, the old session wrote one line in the build’s log: where it stopped, what was left half done, and “Resume in a fresh session.”

A close-up of the build's log at 08:00. One line reads sharp: STOPPED at usage limit (session limit, resets 07:50). Below it, five highlighted rows listing the unfinished work are lit but blurred, and the line ends with Resume in a fresh session. — The last line in the build’s log: where it stopped, what was left, and how to go on.

A fresh session reads, and builds on what is there

A fresh session knows nothing: not the night, not the plan, not one word Allan wrote. Everything it knows, it reads.

At twenty past eight, a new session was told to read the plan, the review log, the build’s log and the state of the files on disk. It was also told that a usage limit may have cut off earlier work, left unsaved in the files: build on that work, do not start over.

A frame from the film at 08:20. A fresh, empty chat window has slid in on the right. In the file list, the build's log, the plan and REVIEW.md are lit. Three unsaved items are marked and labelled in large type: worlds/bts-map/, worlds/bts-media/craft.js and worlds/bts-prep/. — The new session finds the half-written work still on disk: two scene folders and one style file, not yet saved.

That session’s own helpers were stopped too, for a different reason. Just after a quarter past nine, a third session read the same files. It found the two half-written scenes, with twenty-two of their checks already passing. It kept all of it and finished them. Before half past nine both scenes were saved, and by ten to eleven the second part of the film was done. That evening another session found the nearly finished style, checked it and saved it.

The next night the limit came again, at a quarter to four, and lifted five minutes later. At 04:04 a timer the session had set for itself went off, this time after the limit had lifted. The stopped helper was picked up again and finished. No one had to do a thing.

Set up the same safety net

Every new session starts empty. The project remembers, in three places: the build’s log, the review log and the saved steps. So a new session never starts over. It starts from the last line.

For your own long AI jobs:

Keep a build log the AI appends to after every step, and have it write down where it stopped.
Keep a review log of decisions, so nobody has to remember why.
Save small steps often. That night sixty-three were saved; only the four unsaved pieces depended on a later session finding them on the disk.
Write the restart instructions in advance: which files to read, and “build on the unsaved work, do not start over”.
A check-in only helps if it runs once the limit has lifted. The one that rang inside the stopped session could only knock.