Why I switched from Claude Code, Cursor, and OpenCode to OMP

I did not switch tools because one model won a benchmark. I switched because the harness around the model changed how much control I had over daily engineering work.

For a while, my work moved between Claude Code, Cursor, and OpenCode. Each one solved a real part of the problem. Cursor was strong when the editor was the center of gravity. Claude Code was a capable terminal agent with a mature workflow around instructions, skills, hooks, MCP, and multiple surfaces. OpenCode gave me an open-source, provider-flexible terminal and IDE experience.

Then I started using Oh My Pi, usually called OMP. The reason I stayed was not a single feature. It was the combination: a terminal-first agent with the IDE wired into the harness, model and provider freedom, first-class language servers and debuggers, persistent evaluation kernels, structured subagents, stream-time rules, and a plugin system that could hold my entire setup.

OMP is a harness, not another model

OMP is a coding agent built on top of Pi, with a terminal interface and a broad tool surface. It does not need to own the model. The model is one replaceable part of the system; the harness owns the loop around it.

That loop includes:

• reading and searching code;
• edits with structured validation;
• LSP operations for definitions, references, renames, and diagnostics;
• DAP access to real debuggers;
• persistent Python and Bun evaluation kernels;
• MCP servers and external tools;
• model roles, fallbacks, sessions, memory, and plugins;
• subagents that can return structured results instead of prose handoffs.

This distinction matters because many AI tools are presented as model products with an agent mode attached. OMP feels closer to an operating layer for coding agents. I can change the model, provider, prompt layer, extension set, and tool policy without replacing the environment where the work happens.

What Cursor optimizes for

Cursor is an editor-first product. That is a strength, not a criticism. Its workflow is built around an IDE where code navigation, inline changes, review, context mentions, rules, MCP, and agent work are available without leaving the editor. The official documentation describes it as a coding agent for understanding a codebase, planning and building features, fixing bugs, and reviewing changes.

I still prefer Cursor when the main question is visual: which lines changed, how does this component render, or how do I move quickly through a familiar codebase from an editor surface?

OMP optimizes for a different center:

• terminal sessions are first-class;
• tools are inspectable and scriptable;
• the same agent can drive LSP and a live debugger;
• model roles can be selected independently for default, plan, vision, fast, slow, task, and review work;
• the environment can be configured as a plugin and installed on another machine.

Cursor lets the editor be the harness. OMP lets the harness drive the editor’s capabilities. That difference became important when I wanted one workflow to cover web debugging, backend work, mobile projects, database inspection, and terminal automation without making the IDE the boundary of the system.

What Claude Code gets right

Claude Code has a clear terminal identity and a broad workflow surface. It can edit files, run commands, work with MCP, use CLAUDE.md, load skills, run hooks, spawn subagents, and operate across terminal, IDE, desktop, and web surfaces. Its documentation is explicit about that breadth.

I did not leave it because it was incapable. I left because I wanted the same kind of workflow with a different control plane.

The differences that mattered to me were:

1. Provider choice as a normal configuration decision. I wanted to route different roles to different models and gateways without treating the provider as the product.
2. IDE capabilities inside the agent loop. LSP and debugging should be tools the agent can invoke, not only features I use manually in an editor.
3. A more inspectable runtime. Persistent evaluation, tool metadata, extension APIs, and local resources make it easier to understand what the agent is doing.
4. A plugin ecosystem around the harness. I wanted to package skills, extensions, MCP definitions, themes, and shared configuration as one installable unit.

Claude Code can be customized extensively, including with skills, hooks, MCP, and subagents. The claim is not that it cannot do these things. The claim is that OMP made this particular combination feel like the core product rather than a collection of add-ons around a provider experience.

What OpenCode gave me first

OpenCode was the closest predecessor to my current workflow. It is open source, runs in the terminal, desktop app, and IDE extension, and supports multiple model providers. Its setup centers on configuring a provider, initializing a project, and using plan/build modes with project instructions.

That foundation made the migration to OMP easier. I already valued:

• an agent that could run locally from a repository;
• provider configuration outside a single model vendor;
• project instructions in AGENTS.md;
• a terminal workflow that did not require a specific editor.

OMP won me over by going deeper into the harness. The tool layer is more explicit, including dedicated LSP operations, debugger operations, structured file selectors, and output-aware tooling. The runtime also exposes extension points for commands, tools, renderers, providers, resources, and session events.

OpenCode remains a good choice when its surface matches your workflow. My change was not “OpenCode is bad.” It was that OMP gave me more control over the layer I was increasingly modifying anyway.

The features that changed my daily work

LSP and debugger as agent tools

The biggest practical difference was treating IDE intelligence as part of the agent’s tool surface. A rename can use the language server instead of a text replacement. A bug in a Go, Python, or native process can lead to a debugger session instead of a new print statement.

This shortens a common loop: read code, guess, edit, discover a type or runtime fact was different, then undo the guess. The agent can ask the same questions an IDE or debugger would answer.

Structured subagents

OMP’s task surface lets a parent agent fan work out to workers and receive typed results. The important part is not parallelism alone. A subagent can have an explicit role, isolated worktree, tool policy, and output schema.

That is different from asking several agents to “look into it” and parsing a pile of prose afterward. The orchestration contract becomes part of the tool call.

Time-traveling stream rules

OMP can interrupt a generation when a rule matches, inject a correction, and retry from the same point. This is useful for rules that should act only when the model is about to make a known mistake.

A static instruction consumes context on every turn. A stream rule can stay dormant until the risky pattern appears. That is a small architectural detail with a noticeable effect in long sessions.

Persistent evaluation kernels

The Python and Bun evaluation runtimes make tool use composable. A kernel can call back into agent tools, load data, compute a result, and keep state between steps. That is useful for audits, data work, API probing, and any task where repeatedly starting one-off scripts would lose context.

Model roles instead of one default model

I stopped thinking in terms of “which model is my coding model?” and started assigning roles:

• a strong default for implementation;
• a planning model for architecture;
• a vision model for images;
• a cheap model for exploration;
• a slow model for difficult reasoning;
• a task model for subagents;
• a separate advisor for review notes.

The model catalog and fallback policy become configuration, not muscle memory. When a provider changes, the workflow stays recognizable.

Plugins and marketplaces

The final reason I switched was operational. I did not want to rebuild my setup on every computer. OMP plugins can carry skills, extensions, themes, MCP definitions, and a shared configuration profile. A private marketplace can turn that package into a repeatable installation.

That is what the companion post covers in detail: how to create a personal OMP marketplace. The key idea is simple: version the surface you want to share, keep secrets and machine state local, and upgrade the plugin instead of maintaining a symlink network.

What OMP does not replace

OMP is not automatically the best choice for everyone.

Use Cursor when editor-native interaction, inline review, and visual context are the priority. Use Claude Code when its provider, surfaces, and established workflow match your needs. Use OpenCode when you want an open-source, provider-flexible coding agent with a simpler setup. Use OMP when you want to own more of the harness and are willing to configure it.

That last part is the cost. OMP exposes more decisions: providers, roles, fallbacks, extension loading, MCP trust, LSP adapters, debuggers, output compaction, and plugin versions. More control means more responsibility. A broken MCP, stale model ID, or incompatible extension is now part of your environment to diagnose.

Why I switched

The decision was cumulative:

• I wanted terminal-first work without giving up IDE intelligence.
• I wanted LSP and real debuggers inside the agent loop.
• I wanted models and providers to be replaceable.
• I wanted subagents with contracts instead of prose-only delegation.
• I wanted rules that could activate at the risky moment.
• I wanted persistent evaluation for data and investigation work.
• I wanted one versioned setup across computers.

OMP did not eliminate configuration. It made configuration part of the product surface. That tradeoff worked for me because I was already paying the complexity cost manually across multiple tools.

Checklist before switching

• Decide whether your priority is editor-native flow or harness control.
• Test LSP and debugger availability for your languages.
• List the model roles you actually use instead of choosing one default.
• Keep provider credentials and OAuth state outside shared configuration.
• Treat MCP servers as privileged integrations, not harmless settings.
• Start with one plugin containing skills and extensions before packaging everything.
• Keep the current tool available until the new harness passes one real project workflow.

The useful comparison is not “which tool has the smartest model?” It is “which harness gives me the right control over the work I do every day?” For me, the answer became OMP.