Recovery over persistence

Anthropic's documented rule is exact: after correcting the model more than twice on the same issue in one session, the context is cluttered with failed approaches, and the recommended action is to clear it and re-prompt more specifically.¹ Whether resetting is actually cheaper than continuing to correct is not something any comparison in the sources measures, and the threshold itself is vendor guidance rather than a value derived from a measured optimum.

The reason clearing is recommended at all is mechanical rather than stylistic. Anthropic states that most of its practices follow from one constraint: the window fills fast and "performance degrades as it fills".¹ Its engineering write-up calls that decline context rot and treats context as a finite attention budget that every token depletes.² Chroma evaluated eighteen models and found performance varies with input length even on simple retrieval and text replication, and that a single distractor reduced accuracy.³ Failed approaches sitting in the window are distractors you added yourself.

Anthropic documents four escalating recovery controls: stopping mid-action preserves context, a rewind restores earlier conversation and code state, asking the model to undo its own changes reverses a specific mistake, and a full clear discards the most and costs a fresh brief.¹ That rewind can also perform a partial recovery on its own, summarising from or up to a chosen message; an instructed compact is a separate partial-recovery mechanism that directs what the summary keeps.¹ Checkpoints back the rewind: one per turn, with files snapshotted before each change, letting a session return to earlier checkpointed conversation and code state, which Anthropic frames as licence to attempt a risky approach rather than plan every move. The documented limit is sharp. Checkpoints track only changes made through the model's own file-editing tools, not Bash commands or external processes, and they do not replace git.¹ What survives compaction is also documented: the project instruction file and a plan reload from disk, while path-scoped rules and the conversation itself are summarised away.⁴

The diagram clarifies recovery escalation and the documented limits of rewind.

graph TD
  W["Session off track"] --> E["Stop: context kept"]
  E --> R["Rewind: restore state"]
  R --> U["Undo: reverse a change"]
  U --> Z["Clear: re-brief cost"]
  R -.-> CMP["Compact: partial, instructed"]
  R --- K["Checkpoints back rewind"]
  K --> L["Limit: file edits only"]

Figure: Recovery escalates from stopping through rewind and undo to clearing; compaction is partial, and checkpoints cover only model-tool file edits. Two parts of this judgement rest on nothing measured. No controlled study was found comparing a restart against persisting with corrections, so the more-than-two-corrections threshold is vendor guidance and not a measured optimum. No source quantifies how much output quality a compaction pass costs against a clean restart with a written spec, which is exactly the comparison a reader wants. The mechanics above are also Claude-Code-specific: no vendor documentation at this level of detail was found for Cursor or Copilot recovery controls, so do not assume equivalent commands or the same checkpoint limits exist in another tool.