claude-code - 💡(How to fix) Fix [FEATURE] Hot-Context Checkpoints for Faster Forked Agent Workflows

/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_