CCAR-F - Claude Code Configuration & Workflows (20% of the exam) - Section 3.4
Determine when to use plan mode versus direct execution.
Plan mode suits large-scale changes, several valid approaches, architectural decisions and multi-file modifications, because it allows safe exploration and design before any change and prevents costly rework. Direct execution suits a simple well-scoped change such as one validation check in one function. Candidates should also use an exploration subagent to isolate verbose discovery output, and should combine plan mode for investigation with direct execution for the implementation itself.
plan modedirect executionarchitectural implicationsExplore subagentcontext window exhaustion during discovery
Northwind's checkout service holds about 400 source files. A developer asks Claude Code, in direct execution, to find every caller of a deprecated pricing helper and update them. The session reads 38 files inline, the context window fills during discovery, and the run is restarted before a single edit lands. A colleague reruns the same task by first dispatching the Explore subagent to locate the callers, then editing in the main session, and the run completes. Which mechanism explains why the second run has room left for the edits?
AThe Explore subagent works in its own context window and returns the paths and line references it concluded with, so the bodies of the files it read stay out of the main session's window.check_circle Correct
BThe Explore subagent reads source files in a compressed representation that costs fewer tokens per file, so the same 38 files occupy a small fraction of the main session's context window.
CThe Explore subagent continues inside the main session's conversation, so its reads are deduplicated against the files that session already opened and only the new callers are added to the window.
DThe Explore subagent forces the main session to compact before it begins, so the earlier turns are summarised and the reclaimed window is what the subsequent edits are then written into.
Delegating discovery to a subagent keeps raw file contents in the subagent's context, returning only a conclusion to the main session. Context exhaustion during discovery is a placement problem. Read inline, each of the 38 files lands permanently in the main session's window and competes with the edits that follow. Dispatched to a subagent, the same reads land in a separate window that is discarded when the subagent finishes, and the coordinator receives a short report instead. The token cost of looking is paid somewhere that does not have to hold the work.
Why A is correct: Correct. A dispatched subagent holds a separate context, and only its final report crosses back, so discovery that would have cost tens of thousands of tokens inline arrives as a short answer.
Why B is wrong: Tempting because the subagent clearly handles more material than the main session could, but there is no cheaper encoding of file contents; the saving comes from where the contents are held, not from how they are represented.
Why C is wrong: Tempting because the subagent is dispatched from the session and reports back to it, but a subagent does not share the coordinator's conversation; treating it as continuing that conversation is the classic inheritance error.
Why D is wrong: Tempting because compaction is a real way to reclaim a window, but dispatching a subagent does not trigger it; the second run simply never accumulated the file contents in the first place.
Exam traps in Claude Code Configuration & Workflows
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.
Reads issued during plan mode are buffered rather than executed, so the 22 reads in the recording were carried out in a batch at the moment the engineer accepted the plan.
errorWhy it is wrong: Tempting because plan mode does defer something until approval, but what it defers is mutation; a read that returned nothing until approval could not inform the plan it was gathered for.
Plan mode caches the discovery pass for later reuse, so a saving appears once an earlier session in the same repository has already visited the files that the refactor goes on to touch.
errorWhy it is wrong: Tempting because caching is a genuine lever on token cost, but no plan is retained across sessions for reuse; the refactor's saving came from avoiding a wrong edit rather than from a warm cache.
That every file the refactor will touch is read before the steps are proposed, so the plan is known to cover all nine files in the billing module.
errorWhy it is wrong: Tempting because plan mode does front-load investigation and often reads widely, but the mode places no completeness requirement on discovery; the model can propose a plan after reading a subset and miss a caller entirely.