The expensive part of restarting an AI coding session is not losing the transcript. It is losing the distinction between facts, decisions, failed paths, and guesses. A long transcript can preserve all four while making them progressively harder to tell apart.
I now restart based on context integrity, not token count. When the next safe action depends on history that the current session can no longer restate as checkable facts, the session has become a liability. The remedy is a checkpoint that another operator can verify, followed by a clean start.
- Pattern
- Checkpoint before context decay
- Output
- Restart protocol
- Use when
- The session is carrying stale decisions, repeated dead ends, or uncertain runtime state
A clean window can still carry dirty state
One session in the source material was restarted with what looked like a thorough handoff. The summary preserved the intended conclusion and the next task, but it did not preserve the commands and outputs that established the current state. The new agent treated the conclusion as evidence, continued from it, and repeated a path the previous session had already invalidated.
Nothing was wrong with the fresh context window. The state transfer was wrong.
That incident changed the restart question for me. "Is this conversation long?" is weak because length is only a proxy. The useful questions are:
- Can the session name the current branch, changed surface, and runtime state without contradiction?
- Can it separate an observed fact from an inference made several turns ago?
- Can it explain why the obvious alternative was rejected?
- Can another engineer reproduce the last meaningful proof?
- Is there one next action whose success or failure will reduce uncertainty?
If two of those answers are missing, I checkpoint and restart. Continuing may feel cheaper, but it spends the next turns rediscovering which parts of the context are trustworthy.
The checkpoint is an operator interface
A useful handoff is not a prose recap. It is the smallest control surface from which another engineer or agent can resume safely.
OBJECTIVE
What outcome is still being pursued?
OBSERVED STATE
- Repo and branch:
- Changed files or resources:
- Runtime/deploy state:
- Checks run and exact result:
DECISIONS
- Chosen approach and why:
- Alternatives rejected and the evidence against them:
UNCERTAINTY
- Assumptions not verified:
- External state that may have changed:
- Claims that rely on a prior summary rather than source evidence:
NEXT PROBE
- One safe next action:
- Expected result:
- Stop condition:The NEXT PROBE field matters more than a long to-do list. A fresh session should begin by reducing uncertainty, not by accepting a queue assembled under uncertain state.
I also keep negative evidence. "Tried the same command three times" is not useful, but "this route cannot work because the credential lacks the required scope" prevents the next session from re-running an attractive dead end. That is operational state, not historical trivia.
Restart when the state changes class
There are four moments when a restart usually pays for itself:
| Trigger | What changed | Why a clean session helps |
|---|---|---|
| Research becomes implementation | The task moves from interpretation to mutation | The execution context can start with explicit scope and permissions |
| Local work becomes production work | The evidence surface changes from files and tests to live state | Old local conclusions no longer get mistaken for runtime facts |
| The same failure recurs | More attempts are not producing new evidence | A checkpoint exposes the shared dependency instead of preserving retry momentum |
| The objective materially changes | Previous constraints and decisions may no longer apply | The new task can discard irrelevant reasoning without losing verified state |
This is also why I do not automatically restart after a fixed number of turns. A long, read-only investigation with a stable evidence ledger can remain coherent. A short session that has mixed two branches, one deploy, and three unlabelled assumptions may already be unsafe.
What a restart cannot solve
A checkpoint adds process cost. It interrupts flow, and writing one well can take longer than another tool call. It can also create false confidence if the author compresses uncertainty into polished prose. A cleanly formatted handoff with no source references is still an unverified summary.
For high-risk work, the receiving session should validate the checkpoint before acting:
- Inspect the named branch or resource.
- Re-run one cheap check that anchors the current state.
- Confirm that the proposed next action is still reversible.
- Downgrade any claim that cannot be reproduced to an assumption.
The point of restarting is not to erase complexity. It is to convert hidden conversational state into an artifact that can be challenged.
The team rule I would standardize
Do not ask an agent for "a summary for the next session." Ask for a restart checkpoint with observed state, rejected paths, unresolved assumptions, and one next probe. The receiving agent should verify one anchor before it writes or deploys anything.
That protocol costs a few minutes. It is cheaper than giving a fresh agent a confident version of an old mistake.