# Plan mode

In plan mode Claude reads and proposes while edits stay blocked. It pays when the approach is the risk, and wastes time when the diff would be one sentence.

## What plan mode does

In plan mode, Claude reads and proposes. Edits stay blocked until you approve the plan. Enter it with `Shift+Tab`, with `--permission-mode plan`, or with `/plan [description]`, which can take the task as its argument.

The mechanism is small but the effect is large: the first thing you review is the approach, not a diff. Changing a plan costs you a sentence. Changing a finished implementation costs you the work.

When the plan arrives, `Ctrl+G` opens it in your editor so you can edit it directly. When you accept it, the session gets a generated title, and the `showClearContextOnPlanAccept` setting adds a choice to clear the context before implementation starts.

## Three phases

Think of the work as three phases: explore, plan, implement.

```flow
Explore: read the code, no edits
Plan: propose the steps, you review
Implement: edits allowed, run the checks
```

The first two phases are where plan mode lives. Exploring is cheap and safe, because nothing changes. The plan is the artifact you can argue with. Only then do you leave plan mode and let edits happen.

One cost detail from the docs fits here: the `opusplan` model alias uses Opus while planning and Sonnet while executing. The thinking-heavy phase gets the stronger model, and the mechanical phase gets the cheaper one.

**Question:** What stays blocked in plan mode until you approve?

- Reading files
- File edits
- Asking questions
- Opening the plan in your editor

**Answer:** File edits. Claude may read and propose freely. Edits wait until you approve the plan.


## When planning pays

Plan first when the approach is the risk. Good signals:

- The change touches several files or modules, and a wrong first choice spreads.
- You are not sure how the existing code works, and the plan will show you what Claude understood.
- There is more than one reasonable design and you want to choose.
- The work is long, so you want an agreed script before it runs unattended.

For that last case there is also the interview pattern from the guide: ask Claude to interview you until it could write a spec, write `SPEC.md`, then build in a fresh session. The new session starts with the spec and nothing else.

## When planning is a waste

Skip it when the diff fits in one sentence. Fixing a typo, renaming a variable, or adding one log line does not need a proposal and an approval. You would spend more effort reviewing the plan than reviewing the change.

> **A rule of thumb**
If you could describe the exact change in one sentence and you would notice a wrong result in `/diff`, go straight to editing. If you could not describe it, plan.


A plan is also not a guarantee. In an interactive terminal where bypass is available, the edit block of plan mode is not enforced: Claude is told not to edit, but edits would run. If you need a hard read-only session, do not rely on plan mode with bypass enabled.

> **Plan mode is not a sandbox**
Read the mode line in the footer. A plan you trust only because the mode is called plan is a plan built on a hope.


**Question:** Which task benefits most from plan mode?

- Fixing a typo in a README
- Renaming one local variable
- Changing how three modules share a data format
- Adding a single log line

**Answer:** Changing how three modules share a data format. A wrong first choice spreads across modules. The plan lets you correct the approach before any code exists.


> **Compare the cost**
Take a change you would normally just ask for, and run it through `/plan` once. Note whether the plan told you anything you did not already know. If not, you have your own threshold.