[FEATURE] Hot-Context Checkpoints for Faster Forked Agent Workflows
Resolved 💬 1 comment Opened May 15, 2026 by Nubarc Closed Jun 14, 2026
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Example:
/checkpoint ready-to-build
Later:
/resume ready-to-build
/fork ready-to-build
/fork ready-to-build as worker-a
The main goal is to save a clean conversation state after the agent has already loaded and understood the important project context, so future forks can benefit from cache hits, avoid re-reading the same information, and start much faster.
Problem
For large projects, a lot of time and tokens are spent loading the same context repeatedly:
project structure
docs
conventions
relevant files
prior planning
current implementation strategy
There is often a perfect point where the agent is “ready to build.” I want to mark that state and return to it later.
Current forking from the latest conversation state is not enough, because the conversation may later include failed attempts, abandoned ideas, unrelated discussion, or messy context.
I want to fork or resume from the clean checkpoint, not from the current polluted state.
Minimal Useful Version
/checkpoint <name>
/resume <name>
/fork <name>
Final Request
Please add named hot-context checkpoints so users can resume or fork from a previously marked clean state, preserving cache benefits and avoiding repeated context loading.
### Proposed Solution
Desired Workflow
1. Agent loads and understands the project context.
2. User runs:
/checkpoint ready-to-build
3. Conversation continues.
4. Later, user runs:
/fork ready-to-build as worker-a
/fork ready-to-build as worker-b
/resume ready-to-build
5. Each fork receives only a small task instruction.
6. Each fork benefits from the already-loaded hot context/cache.
Why It Matters
This would improve:
cache hits
speed
token efficiency
parallel agent workflows
recovery from bad paths
consistency across forks
time wasted re-reading the same files/docs
Proposed Commands
/checkpoint <name>
/resume <name>
/fork <name>
/fork <name> as <agent-name>
/checkpoint list
/checkpoint delete <name>
Expected Behavior
A checkpoint should preserve the conversation state exactly up to that point, including loaded context, summaries, plans, assumptions, and files already read.
It should not include messages or decisions made after the checkpoint.
Key Difference From Normal Forking
This is not just:
/fork current state
It is:
/fork from a named earlier hot-context state
That earlier state is valuable because it may be cleaner, faster, and more cache-friendly.
### Alternative Solutions
The current method is to /resume and ESC ESC back to where the right ammount of context is loaded.
### Priority
High - Significant impact on productivity
### Feature Category
CLI commands and flags
### Use Case Example
Example:
```text
/checkpoint ready-to-build
Later:
/resume ready-to-build
/fork ready-to-build
/fork ready-to-build as worker-a
### Additional Context
_No response_This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗