When to /clear vs When to Continue

The Problem

You're 30 messages deep in a coding session. The agent is now slower, making strange assumptions, and suggesting code that contradicts what you built 20 messages ago. You add more context to "clarify" but it gets worse. The conversation is polluted with dead context.

Should you /clear and start fresh, or keep pushing through?

Most developers continue too long, dragging poisoned context into every new task. Others /clear too eagerly, losing valuable session state. Both waste time. The key is knowing exactly when the context has become a liability instead of an asset.

The Core Insight

Context is not append-only memory - it's a working set with a quality decay function.

Think of context like RAM: every piece competes for attention, older entries get "paged out" mentally, and fragmentation slows everything down. When context quality drops below a threshold, continuing costs more than restarting.

The decision isn't "am I done?" - it's "will the next task benefit from this context or be hurt by it?"

The Walkthrough

The Seven /clear Triggers

Use /clear immediately when you hit any of these:

When to Continue Instead

Keep going when:

• Iterative refinement: Making small adjustments to working code
• Debugging in progress: Agent has context about the error state
• Momentum is high: Each response builds cleanly on the last
• Shared state matters: You've established conventions or patterns worth keeping

Pre-Clear Preservation Strategy

Before you /clear, capture what matters:

1. Save decisions to files: Write design choices to DECISIONS.md or code comments
2. Commit working state: Git commit so you can reference "what worked"
3. Extract reusable prompts: Save successful prompt patterns to a .txt file
4. Document context manually: Quick bullet list of "what we established"

# Example pre-clear capture
# CONTEXT-SNAPSHOT.md

## What We Built (Session 2024-01-15)
- Implemented user auth with JWT
- Decided on bcrypt over argon2 (performance on our instance)
- Error handling pattern: throw errors, catch in middleware
- Database: PostgreSQL with connection pooling (pg library)

## Next Session Should Know
- Auth tokens expire in 24h (see config/auth.js)
- Email validation uses validator.js
- Tests use Jest + supertest
- Still TODO: password reset flow

Failure Patterns

1. The Endless Continue

Symptom: 50+ message thread, agent is hallucinating APIs that don't exist.

Fix: /clear when you hit message 30 or first notice quality drop. Save state first.

2. The Premature Clear

Symptom: You /clear every 5 messages and keep re-explaining the same architecture.

Fix: Write a PROJECT-CONTEXT.md that you @-mention at session start. /clear less, context better.

3. The No-Save Clear

Symptom: You /clear and immediately regret losing the agent's understanding of your system.

Fix: Always commit or capture state before /clear. Make it a habit.

4. The Context Hoarding

Symptom: You refuse to /clear because "the agent knows the codebase now."

Fix: The agent re-learns fast. Better to restart with 5 key files than continue with 50 messages of noise.

Advanced: Context Refresh Without Full Clear

Sometimes you want to prune context without losing everything:

Technique: The Summary Restart

1. Ask agent: "Summarize what we've accomplished and what's next"
2. Copy the summary
3. /clear
4. Start new session: "Here's where we are: [paste summary]"

This gives you a compressed, high-quality context snapshot without the pollution.

Technique: The Surgical Continue

Instead of continuing everything, explicitly scope the next request:

# Bad (continues all context)
"Now add error handling"

# Good (scopes to relevant context)
"Add error handling to the auth.js file we just modified.
Ignore the earlier database migration discussion."