Checkpoints
A checkpoint is a snapshot of the project's files, written every time an edit is applied. Reach for one when a change went wrong and you want the files, or the files and the conversation, back where they were.
Quick start
Open the control in the header that shows your extension's name. The list holds every checkpoint under the prompt that made it. Press Restore last known good to go back to the newest checkpoint whose build passed, or pick any row to restore it.
How it works
What writes a checkpoint
Each applied edit writes one: an agent turn's writes, a chat answer's operations, and a Save & rebuild in the Code tab. Seeding a template writes one too, and so does a restore, which first saves the files you are leaving as Before restoring: <label>. The checkpoint <message> command records one under your own message. A project keeps its 50 newest.
The build's verdict
A checkpoint is stamped with the build's own conclusion once the compile finishes: success or failed, with the error count. Restore last known good picks the newest checkpoint whose build succeeded, excluding the one you are on. A checkpoint with no verdict is one whose files were never built.
Rewind the conversation too
A checkpoint written by a terminal turn carries a chip with the turn that produced it. On the first checkpoint of each turn the row offers Resume fx here. Take it and two things happen together: the files go back to that checkpoint, and the conversation goes back to that turn. The confirmation names the turn and counts the turns you are about to leave behind.
The turns you leave are parked as a branch. The branch appears in the same list as a row reading Branch from turn 2, 3 later turns with Resume this branch. Resuming a branch is a swap: the live conversation becomes a branch, the branch becomes live, and the files go back to the last checkpoint that branch recorded.
Three branches are kept per project. When a fourth would be created the oldest is dropped, and the confirmation says so before you press the button.
After a rewind the agent does not remember the turns past the checkpoint and is told not to cite them. It still reads the files in front of it. If you want it to know something from a parked branch, say it again.
Where checkpoints live
Checkpoints are stored in the browser that made them, not with the draft on your account. Every checkpoint has an address, /drafts/<id>/c/<n>, that shows its message, when it was saved, and its file list, with Restore this checkpoint and Open project. Open that address on another device and it says the checkpoint is not there.
Reference
| Control | What it does |
|---|---|
| Restore last known good | Restores the newest checkpoint whose build succeeded |
| A checkpoint row | Restores those files |
| Resume fx here | Restores the files and rewinds the conversation to that turn |
| Resume this branch | Swaps the live conversation with a parked branch |
checkpoint <message> | Records a checkpoint under your message |
| Limit | Value |
|---|---|
| Checkpoints kept per project | 50 |
| Parked branches per project | 3 |
| Address of the nth checkpoint | /drafts/<id>/c/<n> |
When it fails
- A row reads
Older than fx remembers. The conversation has compacted past that turn, so there is nothing to resume from. The files still restore. Pick a later row to rewind the conversation. - Restore last known good is missing. No checkpoint other than the current one has a passing verdict. Pick a row by its message instead.
- The checkpoint address says it is not on this device. Checkpoints live in the browser that made them. Open the draft in that browser, or restore from the draft on your account and build again.
- The agent cites a turn you rewound past. It should not, and the files are the shared memory. Say the fact again in the next prompt.
Next
- Terminal for the turns a checkpoint is tied to
- Drafts for what syncs to your account and what stays here
- The Code tab for the save that writes a checkpoint