Plan mode
Plan mode tells Magic Coder: don’t change anything yet. Investigate the repo, think about the request, and propose a concrete plan first. It’s the right starting point for tasks that touch multiple files, are hard to undo, or where you want to validate the approach before code starts changing.
When to use it
Section titled “When to use it”Use plan mode when:
- The change spans more than a couple of files and you want to see the shape first.
- The task is risky — refactors, migrations, schema changes, anything touching CI or config.
- You want to confirm Magic Coder understood the request before it commits.
- You’re exploring an unfamiliar codebase and want a tour with a recommendation, not changes.
Skip it for trivial edits, one-line fixes, or quick exploratory questions — the overhead of “plan, then act” isn’t worth it for those.
How to enter plan mode
Section titled “How to enter plan mode”From the command line
Section titled “From the command line”coder --planYou can combine it with a startup query:
coder --plan --query "rip out the old auth middleware and replace it with the new one"From inside the TUI
Section titled “From inside the TUI”Toggle plan mode for the next message via the keyboard shortcut shown in /help. (Plan mode is a per-thread state; once you turn it on, it stays on until you turn it off.)
What plan mode actually does
Section titled “What plan mode actually does”A plan-mode turn looks like this:
- Magic Coder reads. It uses
list_dir,read_file, andgrepto understand the repo and the affected areas. No edits, no diffs. - It produces a plan. A grounded, implementation-shaped plan that names concrete files and subsystems, outlines the sequence of changes, calls out risky parts, and reflects the existing patterns in your codebase.
- It stops. The plan is the deliverable. Magic Coder yields back to you for approval.
Plan mode plans aren’t generic “first do X, then Y” outlines — they’re tied to the actual files Magic Coder read.
Approving the plan
Section titled “Approving the plan”You have three options:
- “Looks good, go” (or anything similar) — Magic Coder treats your acceptance as authorization to execute. The next message starts implementing without asking again.
- Tweak the plan — say what to change. “Don’t touch the database migration; do the API change first.” Magic Coder revises and presents the updated plan.
- Reject — say so. Magic Coder waits for new direction.
You can also drop out of plan mode at any time and return to normal interactive editing.
Plan mode + automagic
Section titled “Plan mode + automagic”Combining --plan with --automagic is the pattern for non-interactive runs that should still investigate first. Magic Coder:
- Investigates the repo
- Produces a plan
- Implements it without further approval
- Exits
For day-to-day work, prefer just --plan so you can sign off on the plan before code changes.
Plan mode is not a separate model
Section titled “Plan mode is not a separate model”Plan mode is a behavior, not a different model. It uses the same model and the same reasoning effort you’ve configured. If you want a deeper plan, raise reasoning effort before turning plan mode on.