Skip to main content
This article walks through checkpoints — an automatic feature that snapshots your workspace after each tool use in a task. Checkpoints capture incremental changes (file edits, terminal commands, assistant messages), let you inspect diffs, and provide quick rollback options so you can experiment without losing prior work. Checkpoints complement Git. Cline stores snapshots in a shadow Git repository after every tool use, which enables fine-grained comparisons, restores, and replays while leaving your primary Git workflow untouched. You can continue using Git as usual and selectively commit the stable changes you want to keep.
A dark-mode screenshot of a documentation webpage (docs.cline.bot) showing the "Viewing Changes & Restoring" and "Restore Options" sections, with a central content area and navigation menus on the left and right. The page includes an embedded UI mockup for an API request and file restore.
How you interact with checkpoints in the UI
  • Click “Compare” to inspect changes between snapshots.
  • Click “Restore” to reveal options and revert to a previous snapshot.
  • Use the restore variants to restore files only, conversation history, or both.
Typical development flow where checkpoints are helpful:
  1. Create a feature branch.
  2. Ask the assistant to scaffold a web interface for an existing API.
  3. Approve or modify generated files and iterate.
  4. If something breaks, restore the workspace to a previous snapshot and try again.
Quick example: creating a branch and verifying status in the terminal
Context window: what it contains and why it matters
  • The context window aggregates file contents read by the assistant, terminal commands, prompts, and assistant responses.
  • Everything shown in the UI (colored assistant messages vs. terminal output) contributes to the rolling context.
  • Models have context limits; Cline supports up to ~200K tokens for some models. When you approach that limit, start a fresh conversation or include only the relevant portions of history.
Create directories for the Flask scaffold (example of the command Cline might run):
Representative Flask scaffold code Below are the main files shown so you can see how the pieces fit together. These snippets reflect typical generated files and are safe to inspect or restore from checkpoints.
  • api_client.py — a small API client used by the Flask app:
  • templates/casting_detail.html — Jinja template (kept as a code block so template tags are preserved):
  • app.py — minimal Flask app that uses the API client and serves templates:
Runtime feedback when Cline generates and runs servers
  • When the FastAPI backend responds, you might see output like:
  • If Flask wants to use a different port (for example when 5000 is occupied), a scaffolded run may display:
With the web app running, you get a simple search UI and an API status indicator.
A webpage titled "Chevy Casting Lookup" with a search box to enter casting numbers, buttons for advanced search and browsing all castings, and an API status indicator.
View results and details directly from the interface.
A screenshot of a "Chevy Casting Lookup" web page showing search results in a table with columns for casting number, years, CID, power range, main caps, and action buttons. The header shows "Found 50 result(s)" and each row has a blue "View Details" button.
Selecting a row opens a detailed view for that casting.
A webpage titled "Chevy Casting Lookup" showing casting details for casting number 3794460. It lists basic info like production years (1968–69), displacement (327 CID), and engine power values (250).
Prompt scope and generated features
  • Because the assistant was given a broad prompt (“create a web interface”), it added convenience features: “browse all”, “search similar”, and filtering by year/power.
  • Narrow prompts yield more deterministic results; broad prompts enable creative additions.
  • If the generated app doesn’t match your intent, restore to a snapshot and re-run with a refined prompt.
Restore options — what you can revert Common failure example (missing template):
When you encounter errors like this, restoring to the last working snapshot lets you fix prompt instructions or add missing files without redoing unrelated changes. Committing produced files to Git After you’re satisfied with the scaffolded changes, commit them to your branch. Example commit output:
Checkpoints provide fine-grained rollback and experimentation support while preserving your normal Git workflow. Use checkpoints to iterate quickly, then commit to Git when you have a stable, intentional batch of changes.
Summary
  • Checkpoints capture each tool use (file edits, commands, assistant messages) in a shadow repository for quick diffs and restores.
  • They complement — not replace — Git: commit stable snapshots to your main repository as usual.
  • Monitor context window size; when limits are near, start a fresh conversation or trim history.
  • Use checkpoints to experiment with generated code safely, and restore when needed to refine prompts or correct mistakes.
Links and references This workflow reduces risk when working with generative tools and accelerates iterative development by making exploration and recovery fast and straightforward.

Watch Video