Skip to content
Powered by BridgeApp

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.

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.

Terminal window
coder --plan

You can combine it with a startup query:

Terminal window
coder --plan --query "rip out the old auth middleware and replace it with the new one"

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.)

A plan-mode turn looks like this:

  1. Magic Coder reads. It uses list_dir, read_file, and grep to understand the repo and the affected areas. No edits, no diffs.
  2. 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.
  3. 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.

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.

Combining --plan with --automagic is the pattern for non-interactive runs that should still investigate first. Magic Coder:

  1. Investigates the repo
  2. Produces a plan
  3. Implements it without further approval
  4. Exits

For day-to-day work, prefer just --plan so you can sign off on the plan before code changes.

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.