Skip to main content

​
Overview

A Checkpoint is a snapshot of a model’s configuration at a point in time. Checkpoints capture the complete state of a model — components, connections, parameter values, constants, schedules — and can be referenced from Experiments as a baseline for comparison. Whether a checkpoint can be modified depends on its type (see below). The platform uses checkpoints to decouple “the configuration I’m experimenting with” from “the working model” — you can continue modifying your working model, and a saved checkpoint keeps its version of reality for structured comparison.

​
Checkpoint Types

Checkpoints have two main types depending on who created them:
  • USER_GENERATED — created from the UI by you or a teammate. These are read-only from Dexter’s perspective. Dexter can reference them as experiment cases and compare against them, but can’t modify them.
  • AI_GENERATED — created by Dexter. These are fully modifiable: Dexter can extend, update, or iterate on them during a conversation.
The distinction matters in a practical case: if you create a checkpoint from the UI and then ask Dexter to “modify that checkpoint,” Dexter can’t — it’ll either explain the restriction or create a new AI-generated checkpoint based on the user one. If you want Dexter to iterate on a configuration, ask it to save the checkpoint for you (“save a checkpoint of this configuration”) and the result will be AI_GENERATED and fully editable. The constraint is a safety feature: a user’s explicitly named, manually captured configuration can’t be altered under them by an AI conversation they might not be watching. There’s also a third state, CURRENT, which represents the active working model state rather than a saved snapshot. It isn’t exposed as a named checkpoint in the checkpoints directory.

​
Creating Checkpoints

You create a checkpoint from the UI at any point, or ask Dexter to create one in a conversation. The UI path produces USER_GENERATED; Dexter produces AI_GENERATED. Create a checkpoint:
  • Before significant changes — a named baseline you can roll back to
  • As an experiment baseline — pin a configuration for use in experiment cases
  • When handing off — a named version is easier for a teammate to reference than “the version from last Tuesday”

​
Checkpoints and Experiments

Experiments are how you run structured comparisons across configurations. Each case in an experiment pairs:
  • A checkpoint — a specific model configuration
  • An optional schedule — the real-world timing anchor
This architecture matters: you’re not comparing “Run A vs. Run B,” you’re comparing “Configuration A with Schedule X vs. Configuration B with Schedule Y.” Each case is reproducible — the checkpoint is frozen, the schedule is named, and anyone else running the experiment will get the same conditions. When you set up an experiment, you pick which checkpoints to include as cases. You can modify the working model as much as you want between runs — the experiment references the checkpoints, not the live model.

​
When to Create Manual Checkpoints

  • Before significant changes — if you’re about to restructure a model, create a named checkpoint first. If the change doesn’t pan out, roll back cleanly.
  • As experiment baselines — if you want to include the current configuration in a future experiment, pin it with a named checkpoint so it won’t drift.
  • When handing off — a named checkpoint is easier for a teammate to reference than “the version from last Tuesday.”