What you will be able to do
- Explain what plan mode allows and what it blocks until you approve a plan
- Spot the signs that a task needs plan mode: large-scale, multi-file, architectural, or with several valid approaches
- Pick direct execution for well-scoped changes, such as a single-file fix with a clear stack trace
- Plan a large change such as a library migration in plan mode, then execute the approved plan
- Explain why exploring and designing in plan mode before committing to changes prevents costly rework
- Delegate a verbose discovery phase to the Explore subagent so only a summary returns to the main conversation and the context window survives a multi-phase task
Key concept
Plan mode — Plan mode is a permission mode. In it, Claude reads the codebase and proposes an approach, but it cannot edit files until you approve the plan. The costly decisions get made before any code changes.
1.What plan mode actually does
Every Claude Code session runs in a permission mode. The mode decides what Claude can do without stopping to ask you. Most modes differ only in how many edits and commands run without a prompt. Plan mode works differently: it keeps Claude out of your source files entirely until you have agreed on a direction.
| Mode | What runs without asking | Best for |
|---|---|---|
| default | Reads only | Reviewing every action yourself, sensitive work |
| acceptEdits | Reads, file edits, and common filesystem commands (mkdir, touch, mv, cp, etc.) | Iterating on code you’re reviewing |
| plan | Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it |
| auto | Everything, with background safety checks | Long tasks, reducing prompt fatigue |
In plan mode, Claude reads, searches and reasons, then presents a proposal. It writes nothing to your source files until you accept that proposal. To start a session in plan mode, run claude --permission-mode plan. To switch during a session, press Shift+Tab until you reach plan mode.
The exam compares plan mode with *direct execution*. The documentation has no mode by that name. In exam scenarios it means letting Claude start editing right away, in whatever editing mode the session already uses (manual, accept edits or auto). So this subdomain is not really about permission settings. It is about the order of work: decide first, or act first.
One more thing plan mode does not do: it does not shrink what the exploration puts into your context window. Every file Claude reads in plan mode lands in the main conversation. For a multi-phase task with a verbose discovery phase, that is where the Explore subagent comes in, covered at the end of this lesson.
2.Signals that a task needs a plan
Plan mode is worth using because the costs are lopsided. Anthropic's usage guidance gives the numbers: a plan costs a few hundred tokens, while a wrong diff costs you twice. You pay once to generate it and again to revert and regenerate it, plus the turns spent explaining what went wrong. Claude explores first and waits for your approval, so a wrong direction is caught while it is still only a proposal.
That is the safety property the exam guide describes: plan mode enables safe codebase exploration and design before committing to changes. Claude can read every file, trace every call path and draft the whole design, and none of it can touch your source files. The permission-modes docs put it as "explore before changing anything". You review the design while it is still a proposal, so a mistake in it costs a re-read, not a revert. Committing to changes only after the design is agreed is what prevents the costly rework.
The tasks where this matters all have the same shape: the first decision constrains every edit that follows. The exam guide lists four signals:
- Large-scale changes, such as a library migration affecting 45+ files. One wrong call about the replacement API is repeated in every file. - Multiple valid approaches, such as choosing between integration approaches with different infrastructure requirements. Once code is written against one option, switching to another is expensive. - Architectural decisions, such as restructuring a monolith into microservices. This moves boundaries that many later edits depend on. - Multi-file modifications. Even without an architectural change, edits that must stay consistent across files need an agreed file list before any one file is touched.
The same guidance gives a concrete threshold. If a change touches more than two or three files, switch to plan mode. At minimum, ask Claude to list the files it will touch, and what it will do in each, before it changes anything.
A platform team is restructuring a monolith into three microservices, touching shared data models, service boundaries, and deployment topology, with several viable ways to split the code. Before any files are changed, which approach should the architect direct Claude Code to take?
Correct answer: B — Enter plan mode so Claude explores the codebase, evaluates the competing service boundaries, and proposes a design before any edit is approved
- A. Accept-edits mode lets Claude write files immediately, so boundary mistakes get baked into multiple files before anyone reviews the overall design.
- B. Correct. Plan mode restricts Claude to read-only exploration and requires an approved plan before edits happen, which is exactly what a multi-file architectural decision with several valid approaches needs to avoid costly rework.
- C. Picking a split without investigation discards the architectural analysis the task needs and pushes discovery of structural errors to test time, after the damage is already spread across files.
- D. bypassPermissions removes prompts and safety checks entirely, which is the opposite of the deliberate, reviewable investigation an architectural restructuring calls for.
3.When to skip the plan
The same cost comparison works in the other direction. If the scope is already known (one file, one function, a clear symptom), planning produces a plan that just restates your request. The exam guide's examples of well-scoped work are adding a single validation check to one function, adding a date validation conditional, and fixing a single-file bug where the stack trace already points to the line.
Direct execution still includes verification. Anthropic's best-practice guidance for a failing build is to give Claude the evidence and the check in one message: paste the error, ask for the fix, and ask it to confirm the build succeeds. That is the right shape for a stack-trace bug fix. The diagnosis is already in the prompt, so a planning phase has nothing left to find.
| Task | What is still undecided | Choice |
|---|---|---|
| Add a date validation conditional to one function | Nothing: location and change are known | Direct execution |
| Single-file bug fix with a clear stack trace | Nothing: the trace names the fault | Direct execution |
| Library migration affecting 45+ files | Replacement API usage across every call site | Plan mode, then execute |
| Choosing between integration approaches with different infrastructure requirements | Which approach to build on | Plan mode |
Automated runs follow the same rule. Suppose a pipeline gives Claude a pre-approved change with the exact value already decided. There is no approach to choose and no codebase to map, so a plan-approval gate would only add a step for a decision that has already been made.
A stack trace points to a null check missing in a single function inside one file, and the fix is a one-line conditional. Which workflow best matches the scope of this change?
Correct answer: C — Direct execution, since the change is a well-scoped, single-file fix with a clear cause already identified from the trace
- A. Plan mode is for tasks with multiple valid approaches or architectural implications; forcing every bug fix through it adds friction without benefit when the fix and cause are already clear.
- B. The Explore subagent isolates verbose discovery output for large investigations; there is no substantial discovery phase here since the cause is already known from the trace.
- C. Correct. A single-file fix with a clear, already-identified cause is a well-understood, well-scoped change, which is exactly what direct execution is suited for.
- D. Breaking a one-line, already-diagnosed fix into multiple phases adds unnecessary process overhead for a change this small.
Sources6
4.Plan the investigation, execute the implementation
You don't have to pick one approach for the whole task. For large work, the strongest pattern uses both in sequence: plan mode for the investigation, then direct execution to carry out the plan you approved. Anthropic's best-practices page shows the sequence:
Explore
read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.
Plan
I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.
Implement
implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.Here is how that applies to a library migration. In plan mode, Claude finds every call site and proposes an approach. You read the file list and correct it in plain English, for example "skip legacy/, and don't touch the tests yet". Then you approve it and let execution run.
Once the plan exists, most of the execution is mechanical. That is why the guidance suggests planning with a stronger model and executing with a cheaper one. Claude Code builds this split into /model opusplan, which uses Opus for planning and Sonnet for execution. Switching models doesn't clear the conversation, so Sonnet still sees the whole plan.
Notice that the Explore step is the verbose one. Reading all of /src/auth and the secrets handling produces a lot of file content, and in a 45-file migration the discovery phase is larger still. If all of it lands in the main conversation, the plan and implement phases that follow have less context window to work with. The next section shows how the Explore subagent isolates that discovery output and returns only a summary, so the later phases keep their room.
5.The Explore subagent: keep discovery output out of the main conversation
A subagent is a delegated worker inside your session. It does a side task in its own context window and returns a summary. The docs name the trigger exactly: use one when a side task would flood your main conversation with search results, logs or file contents you won't reference again. A discovery phase is that side task. Claude needs to read dozens of files to find every call site, but you and Claude only need the findings, not the file contents.
Claude Code ships a built-in Explore subagent for this. Its purpose is file discovery, code search and codebase exploration. Its tools are read-only: Write and Edit are denied, so it can never change your source. It inherits the main conversation's model, capped at Opus on the Claude API, so it never runs on a more expensive model than the session already uses.
| Agent | Tools | Purpose |
|---|---|---|
| Explore | read-only tools; Write and Edit are denied | file discovery, code search, codebase exploration |
| Plan | read-only tools; Write and Edit are denied | codebase research for planning |
| General-purpose | every tool available to subagents | complex research, multi-step operations, code modifications |
The reason this matters is context window exhaustion. Every file Claude reads in the main conversation stays there for the rest of the session. In a multi-phase task, the explore phase is the most verbose and comes first, so it can crowd out the plan and implement phases before they even start. When the Explore subagent handles the research instead, the large file reads stay in its separate context window. Only the summary and a small metadata trailer come back to the main conversation.
This is the exam skill: for a multi-phase task, delegate the verbose discovery phase to the Explore subagent. Claude does this on its own when the task calls for it, and you can ask for it directly: "use a subagent to find every call site of the old library and report the list back". The main conversation then holds a short list of files, not the contents of 45 of them, and there is room left to plan and to execute.
How this fits with plan mode: they solve different problems. Plan mode controls *when Claude may edit*. The Explore subagent controls *where the discovery output goes*. A large migration typically uses both: plan mode so nothing changes until the approach is approved, and the Explore subagent so the exploration that feeds the plan does not exhaust the context window.
An architect is migrating a project from one ORM library to another across 60 files, where call sites use inconsistent query patterns and the correct replacement idiom differs by pattern. The architect wants Claude to first survey how the old library is used before writing any replacement code. What is the most effective way to structure this work?
Correct answer: A — Use plan mode to survey the inconsistent call site patterns and draft a migration approach, then exit plan mode and execute the approved plan directly
- A. Correct. Plan mode fits the investigation phase across many files with varying patterns, and once the migration approach is approved, switching to direct execution carries it out efficiently, matching the combined plan-then-execute pattern for library migrations.
- B. Starting in acceptEdits lets edits happen before the varying call-site patterns across 60 files are fully understood, risking inconsistent replacements that need rework.
- C. Skipping the survey step for a migration with inconsistent patterns across many files is likely to produce mismatched replacements that require costly correction later.
- D. Assuming one idiom applies everywhere ignores the stated inconsistency in call site patterns and will misapply the wrong replacement to many files.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Plan mode is the safer default, so it is also the right choice for a single-file fix with a clear stack trace.Why is that wrong?
Plan mode pays off when a wrong first direction multiplies rework. The documented threshold is work that touches more than two or three files. A well-scoped fix is better handled with direct execution plus a verification step.
Covered in When to skip the plan
2.Once you choose plan mode, the whole task has to stay in plan mode. Planning and then executing directly is inconsistent.Why is that wrong?
The recommended workflow plans first and then executes the approved plan. Claude Code even builds that handoff into model selection.
Covered in Plan the investigation, execute the implementation
3.Switching to plan mode keeps the exploration's file reads out of the main conversation, so a large discovery phase is safe in plan mode alone.Why is that wrong?
Plan mode only blocks edits. Files Claude reads still land in the main context window. Keeping them out requires delegating the research to a subagent, such as the built-in Explore subagent, whose reads stay in its own context window and only a summary returns.
Covered in The Explore subagent: keep discovery output out of the main conversation
4.The Explore subagent can apply the fixes it finds while it searches, saving a round trip.Why is that wrong?
Explore is read-only. Its purpose is file discovery, code search and codebase exploration, and Write and Edit are denied to it. Modifications belong to the main conversation or a general-purpose subagent.
Covered in The Explore subagent: keep discovery output out of the main conversation
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/permission-modesOfficial docs
“Exploring a codebase before changing it”
↩︎ What plan mode actually does“Explore before changing anything | claude --permission-mode plan | None | Claude Code blocks edits until you approve a plan”
↩︎ Signals that a task needs a plan“Claude Code blocks edits until you approve a plan”
↩︎ Key concept - 2.
“Plan: Claude explores and proposes a plan without editing your source files”
↩︎ What plan mode actually does - 3.https://code.claude.com/docs/en/costsOfficial docs
“Use plan mode for complex tasks: Press Shift+Tab to cycle to plan mode before implementation.”
↩︎ What plan mode actually does“Claude explores the codebase and proposes an approach for your approval, preventing expensive re-work when the initial direction is wrong.”
↩︎ Signals that a task needs a plan - 4.https://code.claude.com/docs/en/context-windowOfficial docs
“As Claude works: each file read adds to context”
↩︎ What plan mode actually does“a subagent handles the research in its own separate context window, so the large file reads stay out of yours”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Only the summary and a small metadata trailer come back.”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Delegate large reads: send research to a subagent so the file contents stay in its context window, not yours.”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Delegate large reads: send research to a subagent so the file contents stay in its context window, not yours.”
↩︎ Exam trap 3 - 5.
“A plan costs a few hundred tokens. A wrong 400-line diff that you revert and regenerate costs thousands, twice”
↩︎ Signals that a task needs a plan“for anything touching more than two or three files, switch to Plan Mode”
↩︎ Signals that a task needs a plan“Once a good plan exists, execution is mostly mechanical and Sonnet handles it at a fraction of the cost.”
↩︎ Plan the investigation, execute the implementation“Read the list, correct it in plain English”
↩︎ Plan the investigation, execute the implementation“for anything touching more than two or three files, switch to Plan Mode”
↩︎ Exam trap 1“This pattern is built in as /model opusplan, which uses Opus while planning and Sonnet for execution.”
↩︎ Exam trap 2 - 6.https://code.claude.com/docs/en/best-practicesOfficial docs
“the build fails with this error: [paste error]. fix it and verify the build succeeds.”
↩︎ When to skip the plan“implement the OAuth flow from your plan.”
↩︎ Plan the investigation, execute the implementation - 7.https://code.claude.com/docs/en/sub-agentsOfficial docs
“Preserve context by keeping exploration and implementation out of your main conversation”
↩︎ Plan the investigation, execute the implementation“Purpose: file discovery, code search, codebase exploration”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Tools: read-only tools; Write and Edit are denied”
↩︎ The Explore subagent: keep discovery output out of the main conversation“so Explore never runs on a more expensive model than the one you already chose for the session”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Tools: read-only tools; Write and Edit are denied”
↩︎ Exam trap 4 - 8.https://code.claude.com/docs/en/agentsOfficial docs
“A side task would flood your main conversation with search results, logs, or file contents you won’t reference again”
↩︎ The Explore subagent: keep discovery output out of the main conversation“Delegated workers inside one session that do a side task in their own context and return a summary”
↩︎ The Explore subagent: keep discovery output out of the main conversation