Plan Mode vs. Build Mode

So far, we’ve used OpenCode reactively. We ask questions, inspect files, undo changes, and apply edits as they come up. That workflow is useful, but it still matches how we use traditional AI tools. We send a prompt, get a response, and then react to the result.

The “Plan” mode changes that dynamic by introducing a deliberate pause between intention and execution. Instead of immediately writing code, OpenCode is forced to think, explain, and sequence its work before touching any files. This single feature dramatically improves reliability, especially when tackling multi-step features or complex architectural changes.

Why does planning matter?

One of the most common failure modes in AI coding tools is premature execution. We describe a feature, the AI immediately starts writing code, and only halfway through do we realize it misunderstood the core requirements. By that point, we are stuck either undoing complex changes or patching over avoidable mistakes.

In practice, most teams don’t work this way. When you hand off a task to someone on your team, you usually start by aligning on the approach. You talk through edge cases and constraints. Once the plan is clear, implementation starts.

The “Plan” mode exists to enforce that same discipline. OpenCode operates in two primary modes: “Build” and “Plan”. The “Build” mode is the default and allows OpenCode to read and modify files. The “Plan” mode disables all code changes.

To switch into the “Plan” mode, we press the “Tab” key.

When the “Plan” mode is active, OpenCode will explicitly avoid editing files. Instead, it will respond by describing what it would do, step by step. This makes it safe to explore ideas, clarify requirements, and reason about changes without worrying about unintended modifications.

Switching modes is fast and reversible, which encourages us to use the “Plan” mode frequently rather than treating it as a special case. ... ...