Skip to content

Feature: Message labels — named checkpoints for resuming and forking chats #395

@ovistoica

Description

@ovistoica

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

Context

Spawned from #388.

Problem

When building up context in a chat — loading skills, giving project background, establishing a working baseline — there is no way to bookmark that point. If I want to reuse that exact context in a new session a week later, I have to rebuild it from scratch. The longer and more involved the setup, the more painful this is.

This also means prompt caching benefits are lost. With Anthropic, a well-cached context prefix is extremely valuable — but only if you can actually resume from it.

Proposed solution: message labels

Allow the user to attach a named label to any message in the chat history. A labeled message acts as a named checkpoint that can be resumed or forked from directly.

Example workflow:

  1. Start a chat
  2. Load the skills and rules the agent needs
  3. Give project-specific context and establish a working baseline
  4. Label the last message: "Frontend agent — MyProject"

A week later, when frontend work comes up again:

  • Resume or fork directly from "Frontend agent — MyProject"
  • The agent starts with the full cached context already in place
  • No rebuilding, no re-explaining

What this is not

Labels are not a replacement for fork-from-any-message. Fork is point-in-time navigation; labels are named, intentional checkpoints that survive across sessions and are easy to discover and reuse. The labels should be searchable in eca-chat-timeline

Rough UX ideas

  • /label <name> slash command to label the current message
  • A label picker when starting /resume or /fork, showing named checkpoints alongside recent sessions
  • Labels visible as markers in the chat buffer (similar to the tombstone in the compaction proposal)

Notes

  • Labels should be stored server-side so they survive restarts and are available across clients
  • A label could be as simple as a metadata field on the message record in the DB
  • Pairs naturally with the compaction tombstone proposal: labeled checkpoints before a tombstone remain accessible even after compaction

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions