Superpowers vs Opusplan

Superpowers and opusplan are two answers to the same frustration: a coding agent that plans sloppily and then confidently builds the wrong thing. They fix it from opposite ends. Opusplan changes the model doing the thinking: it puts Anthropic's strongest model on the plan and a faster one on the execution. Superpowers changes the process around the model, forcing a disciplined sequence of brainstorm, plan, test, and verify no matter which model is running.

The reason people compare them is that both are pitched as the way to get Claude Code to produce better work. The more useful framing is that they operate on different axes. One is a model-routing decision. The other is a workflow discipline. Understanding that difference is most of the answer, and it also explains why the honest recommendation is usually to run both.

The short answer

Reach for opusplan when the quality of the plan is your bottleneck and you want the strongest available reasoning applied to it without paying for that reasoning through the whole build. Reach for superpowers when the problem is not raw intelligence but discipline: when the agent skips straight to code, does not write a test first, or declares victory without checking. They are not mutually exclusive. Opusplan raises the ceiling on the planning step; superpowers makes sure the steps happen in the right order and get verified.

Opusplan: a smarter model where it counts

Opusplan is a model setting in Claude Code, selected with /model opusplan, the --model opusplan flag, or a config entry. Under the hood it is a routing rule rather than a single model: while Claude Code is in plan mode it uses Opus, and once you approve the plan and it starts making changes, it switches to Sonnet for the execution.

The logic is a cost-and-capability trade. Planning is where deeper reasoning pays off most. It is the step that decides what gets built, where the edge cases are, and which approach avoids a dead end. Execution, once the plan is sound, is comparatively mechanical: apply the edits, run the commands, follow the plan. Opus is the stronger reasoner; Sonnet is faster and cheaper. Opusplan spends the expensive model on the decision that carries the most weight and the cheaper model on the volume of work that follows.

Plan mode itself is worth understanding, because opusplan only matters in relation to it. Plan mode is a read-only posture: Claude Code can explore the codebase and propose an approach, but it cannot edit files or change state until you approve. You cycle into it with Shift+Tab, review the plan it produces, and then decide how execution proceeds. Opusplan changes who writes that plan, seating Opus there instead of the default model, without changing the mechanics of the mode.

What opusplan does not do is change the shape of the work. It will happily produce an excellent plan for a task that never should have skipped a brainstorming step, and it will switch to Sonnet and execute whether or not there is a test proving the change is correct. It improves the raw material. It does not impose a method.

Superpowers: a method the model has to follow

Superpowers takes the other position: the limiting factor is usually not how smart the model is, but whether it follows a sound process. It is an open-source collection of skills for Claude Code, created by Jesse Vincent, installed through the plugin marketplace. Rather than a single behavior, it is a set of interlocking workflows that the agent is required to invoke before it acts.

The skills map to the stages of disciplined engineering:

• Brainstorming forces requirements and intent to be pinned down before any code is written.
• Writing plans turns that intent into an explicit, reviewable specification.
• Executing plans carries the plan out, often dispatching isolated subagents to work on independent pieces.
• Test-driven development requires a failing test first, then the code that makes it pass.
• Systematic debugging demands a root cause before a fix, rather than guessing.
• Verification before completion insists on running the commands and showing the output before anything is called done.

The through-line is that these are treated as mandatory workflows, not gentle suggestions. The framework checks for a relevant skill before a task and expects it to be used. That is the whole point: it removes the agent's ability to shortcut straight to a plausible-looking answer and makes the discipline structural instead of optional.

Because superpowers is a process layer, it is model-agnostic. It works with Opus, Sonnet, Haiku, or Fable, and it composes with whatever model routing you have configured, opusplan included. It does not make the model reason better in a single step. It makes the whole run more reliable by controlling the order of operations and forcing verification.

A side-by-side reading

As with any such table, these are tendencies rather than hard limits. The row that matters most is the second one: opusplan improves the input to your process, and superpowers improves the process itself. They are not competing for the same job.

Using them together

The framing as a versus is where the comparison misleads. Nothing stops you from setting opusplan and running the superpowers workflow at the same time, and in practice that combination is close to ideal. Opus writes the plan during the brainstorming and planning skills, where its reasoning is most valuable; superpowers ensures those steps happen at all, that a test exists before the code, and that the result is verified before it is accepted; and Sonnet handles the execution the plan describes, at lower cost.

If you have to choose one, choose by your actual failure mode. If your agent produces shallow or wrong plans and the work suffers from bad direction, opusplan addresses the direct cause. If your agent plans reasonably but then skips tests, patches symptoms instead of root causes, or claims success it has not earned, superpowers addresses that, and no amount of model upgrade will, because the failure is procedural, not intellectual. As covered in the broader idea of human-in-the-loop AI, the reliability of an AI system usually comes from the structure around the model as much as from the model itself.

How XY Space thinks about it

XY Space treats this the way it treats most tooling questions: as a fit decision, not a loyalty one. The two are not rivals, and picking a side is the wrong instinct. The pattern that holds up in the systems we build is that model quality and process discipline are separate dials, and the good outcomes come from turning both: a capable model aimed at the decisions that carry the most weight, wrapped in a workflow that enforces planning, testing, and verification so the capability is not wasted.

That is exactly the shape of the agentic workflows we deploy for clients: strong judgment at the steps that need it, explicit structure and checks everywhere else, and a person in the loop where a mistake is expensive. Opusplan and superpowers are two instances of that same principle, applied to a coding agent. Used together, they are a small, concrete example of how to make an AI system both smart and dependable. If you want help building systems that are both, talk to us.

Sources

• Claude Code model configuration
• Claude Code permission modes (plan mode)
• Superpowers on GitHub (obra/superpowers)