Summary
Per-edit commit checkpointing is the practice of committing every change an AI coding agent lands, so each modification is an atomic, bisectable commit rather than part of a larger uncommitted working-tree state. The commit boundary — whether it is the individual edit, the step, or the whole task — is the key design choice that determines how much work survives when a long agent run is cut short by budget or failure.
Key Points
- The three harnesses compared (Aider, Cursor, Claude Code) differ most in how they treat the working tree, and this difference governs loss on interrupted runs.
- Aider commits after every edit the model lands; each AI change becomes an atomic, bisectable commit. The boundary is the edit, not the task.
- Cursor writes straight to the working tree, so a long run accumulates good and regrettable changes with no natural boundary.
- Claude Code defaults to Cursor's behaviour but ships a hook system; a few lines of
PostToolUseconfig can stage and commit after every successful edit. Most users never set this up. - When the commit boundary is the task, a task that is 95% done and loses its last 5% to budget exhaustion loses 100% of its diff — the work existed but was never committed.
- A per-edit or per-step commit boundary converts this total loss into partial landing: completed edits persist even if the overall task fails.
Concepts
- Commit boundary — the unit of work at which changes are persisted (edit, step, or task).
- Atomic, bisectable commit — a self-contained commit that can be individually inspected, reverted, or bisected.
- Working tree — the uncommitted state where Cursor (and Claude Code by default) accumulates changes.
- PostToolUse hook — Claude Code's mechanism for running config after a tool (edit) succeeds, used here to auto-commit.
- — the three harnesses compared.