Module 4: The agentic workflow: Explore → Plan → Code

When to Start a New Session vs Continue the Current One

Overview

Every time you run claude in the terminal, you start a new session. That session has its own conversation, its own context, and its own history. You can pick up previous sessions with claude --continue or claude --resume, but the real question isn't how — it's when.

The decision looks trivial and it has a direct impact on the quality of your results. Continuing a session poisoned with irrelevant context produces worse answers than starting from scratch with CLAUDE.md as your base. But starting from scratch when you're carrying valuable accumulated context forces you to rebuild everything. The trick is knowing when the cost of keeping the context outweighs the benefit.

In this capsule you'll learn a clear decision framework: when to continue, when to start fresh, how to summarize previous sessions, how to work with multiple sessions in parallel, and the commands you need to manage sessions like a professional.

Sessions in Claude Code: The Mental Model

What a session is

A session is one instance of a conversation with Claude Code. Each session has:

A unique ID — an internal identifier
A conversation history — every message sent and received
Accumulated context — files read, commands run, code generated
CLAUDE.md loaded — always present as the base

Terminal A                    Terminal B
┌──────────────┐              ┌──────────────┐
│  Session #1  │              │  Session #2  │
│              │              │              │
│  CLAUDE.md ✓ │              │  CLAUDE.md ✓ │
│  Context:    │              │  Context:    │
│  - auth bug  │              │  - new       │
│  - fix JWT   │              │    endpoint  │
│  - tests     │              │  - API docs  │
│              │              │              │
└──────────────┘              └──────────────┘
    ↑ same CLAUDE.md ↑            ↑ same project ↑

Sessions are independent. Session #2 knows nothing about what happened in Session #1 (unless you use --continue or --resume).

Session recap (April 2026)

Claude Code now automatically generates a session recap when you resume an earlier session. Instead of scrolling through the whole history or asking Claude to "read the conversation", Claude Code hands you a structured summary:

Which files were read or modified
Which important decisions were made
Which tasks are still open
Which commands were run

The recap shows up at the start of the resumed session so you can pick the work back up quickly without losing context. It works with claude --resume and claude --continue.

How to start, continue, and resume

# New session (clean context + CLAUDE.md)
claude

# Continue the last session (pick up where you left off)
claude --continue

# Resume a specific session (choose from a list)
claude --resume

claude --continue picks up the last session exactly where you left it. All of that session's context is still there.

claude --resume shows you a list of previous sessions so you can pick which one to return to. Useful when you have several sessions and want to go back to a specific one.

A session's lifecycle

claude                    ← Starts a new session
  │
  ├── Message 1 → Response 1
  ├── Message 2 → Response 2
  ├── ...
  ├── /compact             ← Compresses context (the session stays alive)
  ├── Message N → Response N
  │
  └── Ctrl+C / exit        ← Session ends (it gets saved to history)
       │
       ├── claude --continue  ← Picks this session back up
       └── claude             ← New session (this one gets archived)

The Decision Framework

The central question

Before each session, ask yourself:

Does the previous session's context help me or get in my way?

If it helps → claude --continue
If it gets in the way → claude (new session)
If you aren't sure → probably a new session

When to continue the session

1. Same task, still in progress

# Previous session: you started implementing an endpoint
# You stopped to eat
# You come back and want to finish

claude --continue
# Claude remembers the endpoint, the design, the decisions

2. Direct follow-up

# Previous session: you implemented the endpoint
# Now you want to add tests for THAT endpoint

claude --continue
You: "Create tests for the endpoint we implemented."
# Claude has the full context of what it implemented

3. Debugging the same issue

# Previous session: you found a bug, you're investigating
# You stopped to read documentation
# You come back with new information

claude --continue
You: "I found something: the bug only happens when the user has
     more than 100 items. It's probably the LIMIT in the query."
# Claude has the full context of the earlier debugging

4. Iterating on what you built

# Previous session: you created a parseCSV function
# You want to add streaming support

claude --continue
You: "Convert parseCSV into a Readable stream."
# Claude knows the current implementation

When to start a new session

1. A completely different topic

# Previous session: you worked on authentication
# Now you want to work on the payments system

claude  # new session
You: "I need to implement payment processing with Stripe."
# You don't need any of the auth context

2. Poisoned context

# Previous session: you tried 5 different approaches to
# solve a problem. None worked. The conversation is
# full of wrong code and dead ends.

claude  # new session
You: "I need to solve X. I already tried A, B, C (they didn't work).
     The approach I want to try is D."
# Clean context + the lessons learned in your message

3. After an important milestone

# Previous session: you finished the whole feature, made the
# commit, tests pass.

claude  # new session for the next feature
# A clean slate for the next task

4. Context full / degraded

# Previous session: you're 30+ messages deep, you ran /compact
# twice, the answers are still generic.

claude  # new session
# Sometimes the best compaction is starting over

5. A different area of the codebase

# Previous session: you worked on the backend (Express, PostgreSQL)
# Now you want to work on the frontend (React, CSS)

claude  # new session
# The backend context contributes nothing to the frontend

6. After significant external changes

# Previous session: you worked on a branch
# Another developer merged 20 files into main
# Your previous session holds an "old photo" of the codebase

claude  # new session
# Claude will read the updated files

Decision Tree

Are you going to work on the same thing as the previous session?
│
├── YES
│   │
│   ├── Does the previous session have clean, relevant context?
│   │   │
│   │   ├── YES → claude --continue
│   │   │
│   │   └── NO (lots of noise, failed attempts, off-topic)
│   │       │
│   │       ├── Can you summarize what's needed in 2-3 sentences?
│   │       │   │
│   │       │   ├── YES → claude (new session, summary in the 1st message)
│   │       │   │
│   │       │   └── NO → claude --continue + /compact with a focus
│   │       │
│   │       └── (if the context is unsalvageable → claude, new)
│   │
│   └── Were there external changes since the last session?
│       │
│       ├── NO → claude --continue
│       │
│       └── YES (git pull, merge, etc.)
│           │
│           └── claude (new session to reflect the changes)
│
└── NO (different topic/area)
    │
    └── claude (new session)

The 2-3 sentence heuristic

If you can summarize everything Claude needs to know from the previous session in 2-3 sentences, start a new session and put that summary in your first message.

Example:

# Instead of claude --continue with 20 messages of poisoned context:

claude  # new session
You: "I'm implementing a nested comments system.
     I already created the Prisma model (Comment with parentId for replies)
     and the service in src/services/comment.service.ts. Still missing the
     controller and the routes."

Claude has everything it needs in 3 sentences. The clean context will produce better results than 20 accumulated messages.

Session Management

Viewing previous sessions

# List recent sessions
claude --resume
# Shows an interactive list of previous sessions
# with date, time, and a summary of the topic

Session history

Claude Code keeps a session history. Every session is recorded with:

Start and end timestamps
Number of messages
A summary of the topic (generated automatically)

Session context in practice

# A session saved in history:
# ─────────────────────────────────
# ID: abc-123
# Date: 2026-02-28 14:30
# Messages: 12
# Topic: "JWT authentication implementation"
# ─────────────────────────────────

# To pick it back up:
claude --resume
# → You select "JWT authentication implementation"
# → Claude loads all the context from that session

Comparisons and decisions

The cost of "context pollution"

Poisoned context = context that holds irrelevant information, failed attempts, off-topic conversation, or stale data.

# A "poisoned" session:
┌────────────────────────────────────────────┐
│ CLAUDE.md                          [2K]    │
│ Auth exploration (relevant)        [10K]   │
│ Fix attempt 1 (failed)             [8K]    │
│ Fix attempt 2 (failed)             [12K]   │
│ Off-topic naming discussion        [5K]    │
│ Fix attempt 3 (worked)             [6K]    │
│ Logging refactor (another topic)   [15K]   │
│ ──────────────────────────────────────     │
│ Total: 58K tokens                          │
│ Relevant to the current task: ~16K (28%)   │
│ Noise: ~42K (72%)                          │
└────────────────────────────────────────────┘

# A new session:
┌────────────────────────────────────────────┐
│ CLAUDE.md                          [2K]    │
│ Your first message with context    [500]   │
│ ──────────────────────────────────────     │
│ Total: 2.5K tokens                         │
│ Relevant: 100%                             │
│ Noise: 0%                                  │
└────────────────────────────────────────────┘

72% noise vs 0%. Which one is going to produce better answers?

Continued session vs new session: a comparison table

Factor	Continue the session	New session
Prior context	All available (noise included)	Only CLAUDE.md
Setup time	Zero — you pick up where you left off	You need to re-contextualize
Answer quality	Depends on the quality of the context	High (clean context)
Risk	Context pollution	Losing valuable context
Token cost	Already spent, you reuse them	You spend tokens re-reading files
Ideal for	Direct follow-ups	New tasks or poisoned context

The "clean slate advantage"

Claude Code with a well-configured CLAUDE.md has a unique advantage: starting from scratch isn't really from scratch. CLAUDE.md gives it:

The project conventions
The tech stack
The folder structure
The patterns to follow
The things to avoid

# "From scratch" in other tools:
# Claude knows nothing → you have to explain everything

# "From scratch" in Claude Code with CLAUDE.md:
# Claude knows the project's rules → you only need to
# explain the specific task

That dramatically reduces the "cost" of starting a new session. If your CLAUDE.md is good, a new session with a good first message is nearly as productive as a continued one — and without the noise.

Common patterns

Pattern 1: "Session per Feature"

One session per feature. You finish the feature, commit, new session.

# Feature: Comments system
claude
You: "Implement the comments system..."
# ... 8-12 messages ...
# Feature complete, tests pass, commit made
# Ctrl+C

# Feature: Notifications system
claude  # new session
You: "Implement the notifications system..."

Advantage: The context is always relevant. No cross-feature contamination.

When to use it: When the features are independent.

Pattern 2: "Morning Fresh, Afternoon Continue"

Each day starts with a new session. During the day, you continue.

# Monday 9:00 AM
claude  # new session
You: "Today I'm going to work on the payments system..."

# Monday 12:00 PM (after lunch)
claude --continue  # pick the morning back up

# Monday 5:00 PM
# Ctrl+C — end of day

# Tuesday 9:00 AM
claude  # new session
You: "Yesterday I made progress on payments: I created the model and the service.
     Today I'm implementing the controller and the tests."

Advantage: Each day starts fresh. The summary in the first message works like a "standup for Claude".

Pattern 3: "Parallel Sessions"

Multiple simultaneous sessions for different parts of the project.

# Terminal 1: Backend
claude
You: "Work on the API endpoints..."

# Terminal 2: Frontend
claude
You: "Work on the React components..."

# Terminal 3: DevOps
claude
You: "Set up the Dockerfile and the CI/CD..."

Advantage: Each session has focused context. You don't mix backend with frontend.

With tmux:

# Create tmux sessions
tmux new-session -s backend -d
tmux new-session -s frontend -d
tmux new-session -s devops -d

# In each window, run claude independently
# Switch between sessions: Ctrl+B, then s to select

When to use it: Large projects where you work across several areas at the same time.

Pattern 4: "Explore then Execute"

An exploratory session, separate from the implementation session.

# Session 1: Exploration (read-only, no changes)
claude
You: "Analyze how the current payments system works.
     Don't modify anything, just explain it to me."
Claude: [analyzes and explains]
You: "Where should I add subscription support?"
Claude: [suggests a location and an approach]
# You take notes on the conclusions
# Ctrl+C

# Session 2: Implementation (with clean context)
claude  # new session
You: "I need to add subscription support to the payments system.
     The payments module is in src/payments/. I want to add a
     subscription.service.ts that follows the same pattern as
     payment.service.ts. Use the Stripe Subscriptions API."
# You implement with focused, clean context

Advantage: Exploration sometimes generates a lot of context (it reads many files). Separating the sessions keeps that "heavy" context from polluting the implementation.

Pattern 5: "Resume for Long Projects"

For multi-day projects, use --resume to go back to specific sessions.

# Monday: You worked on auth
claude  # session A
# ...

# Tuesday: You worked on payments
claude  # session B
# ...

# Wednesday: You need to go back to auth for a fix
claude --resume
# You select the auth session A
# Claude has all the auth context from Monday

Real scenarios with recommendations

Scenario 1: "I finished a feature, I need to start another"

Context: You just finished the authentication system. Commit made. Now you need to implement the dashboard.

Recommendation: New session.

claude
You: "I need to implement the admin dashboard. The backend has
     the endpoints ready (GET /api/stats, GET /api/users). Create
     the dashboard page in src/pages/dashboard/ with React."

The auth context contributes nothing to the dashboard.

Scenario 2: "Tests failed, I need to debug"

Context: Ten minutes ago you implemented an endpoint. You ran tests and 3 fail.

Recommendation: Continue the session.

claude --continue
You: "3 tests fail. Here's the output: [paste output].
     Investigate and fix it."

Claude has the context of what it implemented. That's far more efficient than starting over.

Scenario 3: "I'm back from vacation and picking the project back up"

Context: You were away for a week. Other developers made changes. You want to resume your work.

Recommendation: New session.

claude
You: "I just ran git pull. What changed in src/ since my
     last commit [hash]? Summarize the relevant changes."

Your previous session holds an "old photo" of the codebase. Better to start fresh.

Scenario 4: "The conversation went off the rails"

Context: You started working on an endpoint but ended up discussing architecture, then naming conventions, then testing tools. You're 25 messages deep and the endpoint isn't done.

Recommendation: A new session with a summary.

claude
You: "I'm implementing GET /api/products/search. Decisions already
     made: use ILIKE for text search, Zod for validation,
     cursor-based pagination. I need to finish the service and the tests."

25 messages of rambling → 3 sentences of clean context.

Scenario 5: "I need to work on frontend AND backend at the same time"

Context: You're implementing a feature that touches the backend (API) and the frontend (UI). You need to go back and forth.

Recommendation: Two parallel sessions.

# Terminal 1
claude
You: "Backend: create the POST /api/comments endpoint..."

# Terminal 2
claude
You: "Frontend: create the CommentForm component in React..."

If you used one session, the backend context would pollute the frontend decisions and vice versa.

Scenario 6: "I want to try a different approach"

Context: You're 10 messages into one approach to a problem. It isn't working. You want to try something completely different.

Recommendation: New session.

claude
You: "I need to implement rate limiting. I already tried express-rate-limit
     but it doesn't work with our load balancer setup because it doesn't
     share state across instances. I want to try Redis
     as a centralized store."

The context of the failed approach only gets in your way. But the lesson you learned ("it doesn't work with a load balancer") goes into the first message.

Pitfalls and edge cases

Pitfall 1: Continuing out of inertia

# You finish a task. Without thinking, you run:
claude --continue
You: "Now I need to work on something completely different..."

# Claude drags along all the context from the previous task.
# Wasted context + possible contamination.

# The fix: Pause for 2 seconds and ask yourself
# "do I need the previous context?" If not → claude (new)

Pitfall 2: Starting fresh without transferring knowledge

# Previous session: you found a subtle bug in the ORM
# that affects every query with a JOIN.
# You start a new session without mentioning that bug.
# Claude generates code with the same bug all over again.

# The fix:
# 1. Add it to CLAUDE.md: "Known bug: the ORM generates incorrect
#    JOINs on tables with underscores. Use raw SQL."
# 2. Or mention it in the new session's first message.

Pitfall 3: Parallel sessions stepping on each other

# Terminal 1: Claude modifies src/auth/login.ts
# Terminal 2: Claude also modifies src/auth/login.ts

# Result: conflicts, overwrites, bugs

# The fix: Parallel sessions must work on
# different files/areas of the codebase

Pitfall 4: --continue after a long gap

# Original session: 3 days ago
# Since then: 15 commits from other developers
# You run claude --continue

# Claude holds a "mental map" of files that no longer exist
# or that changed significantly. It'll generate code based
# on an old version of the project.

# The fix: If more than a few hours passed and there were
# significant changes, start a new session.

Pitfall 5: Too many parallel sessions

# Terminal 1: auth
# Terminal 2: payments
# Terminal 3: notifications
# Terminal 4: logging
# Terminal 5: tests
# Terminal 6: docs

# Problem: every session burns API tokens.
# Your token limit runs out 6x faster.
# On top of that, it's hard to keep so many sessions coherent.

# The fix: 2-3 parallel sessions max.
# Work through the rest serially.

Edge Case: Sessions with shared state

# Session 1 creates a database migration
# Session 2 creates code that depends on that migration

# Does Session 2 know about the migration?
# → Only if the migration already ran (it's in the schema)
# → Or if you tell it explicitly

# Sessions don't share conversational context.
# They DO share the filesystem (the same files on disk).

Complete worked example

Scenario: A 3-day project with session management

# ═══════════════════════════════════════════════
# DAY 1: Setup and data model
# ═══════════════════════════════════════════════

# ─── Session 1A: Design (9:00 AM) ───
claude
You: "I'm starting a task management API project.
     Stack: Express, TypeScript, Prisma, PostgreSQL.
     Design the data model: Users, Projects, Tasks,
     Comments. Design only, don't implement."

Claude: [designs the schema]
You: "Adjust it: Tasks needs a priority (enum), a deadline,
     and an assignee (relation to User)."
Claude: [adjusts]
You: "Perfect. Save the design decisions to CLAUDE.md."
Claude: [updates CLAUDE.md]
# Ctrl+C — session ends

# ─── Session 1B: Model implementation (10:30 AM) ───
claude  # NEW session — the design lives in CLAUDE.md
You: "Implement the Prisma schema based on the design
     decisions in CLAUDE.md. Create the initial migration."

Claude: [implements the schema, creates the migration]
# ... 6 refinement messages ...
# git commit -m "feat: initial schema and migration"
# Ctrl+C

# ─── Session 1C: Users CRUD (2:00 PM) ───
claude  # NEW session — new feature
You: "Implement full CRUD for Users: controller, service,
     routes, validator. Follow the pattern in the CLAUDE.md docs."

# ... 8 messages ...
# git commit -m "feat: users CRUD"
# Ctrl+C


# ═══════════════════════════════════════════════
# DAY 2: Main features
# ═══════════════════════════════════════════════

# ─── Session 2A: Projects and Tasks CRUD (9:00 AM) ───
claude  # NEW session
You: "Implement CRUD for Projects and Tasks. Follow the same
     pattern as Users (already implemented in src/modules/users/)."

# ... 12 messages, compaction halfway through ...
# git commit -m "feat: projects and tasks CRUD"
# Ctrl+C

# ─── Session 2B: Bug fix (2:30 PM) ───
# The Projects tests are failing
claude
You: "The Projects tests fail with this error: [error].
     I implemented that CRUD a little while ago."

Claude: [investigates, finds the bug]
You: "Fix it."
Claude: [fix]
# git commit -m "fix: project foreign key constraint"
# Ctrl+C

# ─── Session 2C: Comments (3:00 PM) ───
claude  # NEW session — new feature
You: "Implement Comments with nested replies (parentId).
     Same pattern as the other modules."

# ... 8 messages ...
# git commit -m "feat: nested comments"
# Ctrl+C


# ═══════════════════════════════════════════════
# DAY 3: Polish and deployment
# ═══════════════════════════════════════════════

# ─── Session 3A: Integration tests (9:00 AM) ───
claude
You: "Create integration tests for the whole API.
     I want tests that cover the full flow:
     create user → create project → create task → add comment."

# ... 10 messages ...
# git commit -m "test: integration tests for full flow"

# ─── Session 3B: Deployment (2:00 PM) ───
# In parallel, in another terminal
claude
You: "Create a multi-stage Dockerfile and a docker-compose.yml
     with the app and PostgreSQL."

# ... 6 messages ...
# git commit -m "chore: docker setup"

Total: 8 sessions across 3 days. Each one focused, with clean context. CLAUDE.md as the thread connecting them.

Practice exercises

Exercise 1: Practice the continue vs new decision

For each scenario, decide: claude --continue or claude (new)?

You just created an endpoint. You want to add tests.
You just created an endpoint. You want to create a completely different one.
You're 20 messages into debugging. The bug still isn't solved. You want to try another approach.
You implemented something 5 minutes ago and a test fails.
You implemented something 3 days ago and a test fails.
You explored somebody else's codebase for 15 messages. Now you want to start implementing.

Answers

--continue — The tests are a direct follow-up. Claude knows what it implemented.
New session — Different endpoint = different context. The previous session contributes nothing.
New session — 20 messages of failed attempts are noise. Start clean with the lessons learned.
--continue — Fresh, 100% relevant context.
New session — Three days have passed, the codebase probably changed. The context is stale.
New session — The exploration generated a lot of context (files read). To implement, you want clean context focused on the specific task. Put the exploration's conclusions in your first message.

Exercise 2: The 2-3 sentence heuristic

Think about your last working session (real or hypothetical). Try summarizing what Claude would need to know in 2-3 sentences:

Did you manage it? → You could start a new session with that summary
Couldn't manage it? → You should probably --continue

Practice with these scenarios:

A session where you implemented JWT login
A session where you explored 10 files with no clear conclusion
A session where you debugged a memory leak

Example summaries

JWT login (easy to summarize → a new session is viable): "I implemented login with JWT in src/auth/. The token is generated with jsonwebtoken, expires in 1h, refresh token in Redis with a 7-day TTL. Still need to implement the refresh endpoint."

Exploring 10 files (hard to summarize → maybe --continue): Hard, because the exploration was non-linear. You could say: "I explored src/payments/ and found it uses an event sourcing pattern with EventStore in src/events/." But if there are more nuances, --continue may be better.

Memory leak debugging (depends on progress): If you found the cause: "Memory leak caused by event listeners that never get removed in the WebSocket component. The listener registers in onConnect but isn't cleaned up in onDisconnect. File: src/ws/handler.ts line 47." If you didn't find it: Harder. --continue to keep the debugging thread alive.

Exercise 3: Parallel sessions

Open 2 terminals. In each one, start Claude Code with a different task from the same project:

Terminal 1: Work on the backend (a new endpoint)
Terminal 2: Work on documentation (README, API docs)

Observe:

Do they interfere with each other? (they shouldn't, if they work on different files)
Does one's context affect the other? (it shouldn't)
What happens if they both try to modify the same file?

What to watch for

The sessions are completely independent
Each one has its own context and its own load of CLAUDE.md
If both modify the same file, the second one to save "wins" — the first gets overwritten
To avoid conflicts: assign different file areas to each session
Both sessions burn tokens from your account, so consumption multiplies

Exercise 4: Knowledge transfer between sessions

Start a session. Ask Claude to analyze some aspect of your project
Claude discovers something interesting (a pattern, a convention, a potential bug)
Ask it to save that to CLAUDE.md
Close the session
Start a new session
Without mentioning the finding, ask Claude to work on something related
Check whether Claude uses the knowledge saved in CLAUDE.md

What to watch for

If you saved it correctly to CLAUDE.md, Claude in the new session should:

Know the finding without you reminding it
Apply it automatically in its work
Refer to it when relevant

If it did NOT get saved to CLAUDE.md:

Claude has no idea about the finding
You could repeat the very mistakes the previous session uncovered

This exercise demonstrates why CLAUDE.md is the "bridge" between sessions.

Exercise 5: Measure the impact of clean context

Do the same task two ways:

Way A: After a long session (20+ messages with mixed topics), ask for the task.

Way B: In a clean new session, ask for the same task with a well-contextualized first message.

Compare:

Response speed
Quality of the result
How many corrections were needed

What to expect

Generally, Way B produces:

Faster answers (less context to process)
Higher quality (no noise from earlier conversations)
Fewer corrections needed

Way A can work fine if all the accumulated context is relevant, but that's rare after 20+ messages with mixed topics.

Takeaway: Don't be afraid to start new sessions. With a good CLAUDE.md and a well-written first message, the "cost" of starting over is minimal and the benefit is significant.

Summary

Every claude starts a new session. claude --continue picks up the last one. claude --resume lets you pick an earlier one.
Continue when: same task, direct follow-up, debugging in progress, clean and relevant context.
New session when: different topic, poisoned context, after a milestone, external changes, a different approach.
The 2-3 sentence heuristic: If you can summarize what Claude needs to know in 2-3 sentences, start fresh with that summary.
CLAUDE.md is the bridge between sessions. Every important finding has to be persisted there.
Clean slate advantage: A new session + a good CLAUDE.md ≈ a continued session without the noise.
Parallel sessions for different areas of the project (backend/frontend/devops). 2-3 simultaneous max.
Session per feature is the safest pattern: feature complete → commit → new session.
Poisoned context (failed attempts, off-topic, stale data) lowers the quality of the answers.
Don't continue out of inertia. Pause for 2 seconds and ask: "do I need the previous context?"

Additional resources

Claude Code Interactive Mode — Anthropic Docs — Session management, shortcuts, and task management
Claude Code CLI Reference — Session flags: --continue, --resume, --print
Claude Code Best Practices — Recommended workflows and context management strategies
Claude Code Memory System — CLAUDE.md as persistent context across sessions
Claude Code Overview — Platforms, capabilities, and the session model
tmux Cheat Sheet — A quick reference for managing multiple terminals with tmux

← PreviousContext Window and Compaction: Managing Claude Code's Memory Next →Module 5: Skills and Hooks — automating your workflow