-
-
Notifications
You must be signed in to change notification settings - Fork 52
Feature: Message labels — named checkpoints for resuming and forking chats #395
Description
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:
- Start a chat
- Load the skills and rules the agent needs
- Give project-specific context and establish a working baseline
- 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
/resumeor/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