Marathon tasks — checkpoints, compaction & resume
Long work is the honest stress test of any agent. A ten-minute task hides nothing; a ten-hour task exposes every shortcut in the design. Sonderr's answer is a set of unfashionable, durable mechanics — checkpoints written to disk, compaction that admits it is a lossy hint, and a resume offer that treats a crash as a when, not an if.
Everything in this guide exists for one reason: context windows end before projects do. Sonderr does not pretend otherwise — there is no claim of infinite memory here. Instead the runtime is built to lose almost anything and keep the work: the goal, the evidence and the next action survive on disk even when the conversation itself is gone.
1 · The checkpoint — a durable resume point
A checkpoint is written automatically by substantial Build work. It is a small, structured record with five fields: the goal in one line, the current milestone, the verified evidence so far (what was actually run or produced, not what was claimed), the decisions made along the way, and one exact next action — specific enough that a cold start can act on it without re-reading anything. Checkpoints are the spine of the marathon task: everything else in this guide is either a reader or a writer of that spine.
2 · Compaction — a lossy hint, honestly labeled
When a provider conversation grows too large, Sonderr shrinks it: the original request, recent activity and the latest checkpoint carry forward; bulky old tool outputs drop. That summary is called compaction, and the design treats it with useful disrespect — compactions are untrusted hints. The agent re-checks reality instead of trusting the summary: files are re-read, claims are re-verified, the checklist is authoritative. If a compaction ever contradicts what is on disk, disk wins. This is the opposite of a hidden memory that silently rewrites your project's history.
3 · The 72-hour marathon
A marathon task is a long-running Build task — up to 72 hours — held together by checkpoints and bounded provider chunks rather than one continuous context. The task keeps a live task list you can watch: steps tick from queued to running to done, evidence attached where it lands. Between chunks, the runtime re-derives state from the checkpoint, so an unlucky provider cutoff costs a chunk, not the project. Marathons respect the same access gates as any Build turn; long does not mean unsupervised.
| Mechanism | What it holds | What it never claims |
|---|---|---|
| Checkpoint | Goal, milestone, evidence, decisions, next action — on disk. | That it remembers the conversation. |
| Compaction | A short summary carried forward between chunks. | That the summary is trustworthy — it is a hint, re-checked. |
| Live task list | Step states and attachments as work progresses. | That a ticked step was verified without evidence. |
| Resume offer | The checkpoint, re-offered after an interruption. | That nothing changed while you were away. |
4 · Resume after a crash
If the runtime or the machine dies mid-task, the recovery path is one offer: Resume interrupted task. It reads the newest checkpoint, shows you the goal, the evidence so far and the one next action, and picks up from there — in a fresh conversation, because the old one is gone and pretending otherwise would be a lie. Sessions themselves live under ~/.sonderr/ on your machine; what a crash destroys is context, not work. For the full session model, see Sessions, checkpoints & long tasks.
5 · Working with long tasks
- Write briefs for a stranger. A marathon will outlive its context; the brief is what future chunks re-read. Outcome, audience, constraints, references — the four-part brief from Prompting & task briefs is not optional at this length.
- Let evidence accumulate. Each verified step strengthens the checkpoint. Do not delete intermediate artifacts "to clean up" mid-run — they are the proof the work happened.
- Interrupt deliberately. Stopping at a milestone boundary gives the cleanest checkpoint. Stopping mid-edit is survivable — that is what the next action field is for — but messier.
- Plan for chunks, not heroics. If a task is shaped so any chunk can end anywhere, any provider hiccup is boring. That is the goal: boring reliability over dramatic streaks.
For the workflow surface these mechanics live in, read Web workspace handbook. For turning a marathon into a project with milestones and a definition of done, see Planning a project end to end and Studios — goal to deliverable.