pastepile_checkpoint

Updates one existing memory and saves its previous title and content in Pastepile's version history first. The URL stays stable, search sees the current revision, and the history remains available from the paste page.

This is the zero-friction path for a conversation that keeps growing. Assistants are instructed to checkpoint after a debugging breakthrough, an architecture decision, a large code generation, a long research result, or before context compaction, without waiting for you to remember.

Parameters

Example

Checkpoint our incident investigation before the context window fills up.

{
  "name": "pastepile_checkpoint",
  "arguments": {
    "slug": "aB3xY9z",
    "title": "api incident 42",
    "content": "## Current state\n\nRoot cause isolated...",
    "language": "markdown"
  }
}

{
  "checkpointed": true,
  "slug": "aB3xY9z",
  "url": "https://www.pastepile.com/p/aB3xY9z",
  "previous_version": 4,
  "credential": "api_key",
  "note": "The current memory is updated. Its previous title and content were preserved as version 4..."
}

Behavior notes

• With PASTEPILE_API_KEY configured, no edit_key is needed for a paste that the same key saved. This is what makes checkpoints work after the original conversation is gone.
• The previous revision is inserted into the existing paste_versions timeline before the current revision changes. Concurrent checkpoints for one paste are serialized, so version numbers cannot collide.
• A checkpoint is not marked destructive because it preserves the content it replaces. It is not idempotent: repeating the same call creates another history entry, so clients should not retry a lost response automatically.
• Reusing one slug avoids duplicate memories and keeps every checkpoint behind one stable URL.

Errors