I moved from Cursor to OpenCode: what actually changed

Table of Contents

For two years my coding agent was whatever Cursor shipped. Then I moved my daily work — a large legacy PHP 8.x codebase — onto OpenCode, the open-source, model-agnostic coding agent that crossed 160K GitHub stars and 7.5M monthly active users by mid-2026. This is the honest account of what changed, what didn’t, and what I had to set up before I trusted an open-source agent with my repo.

If you already juggle Claude, Codex, and a local model or two, the headline matters more than any feature list: OpenCode is not wired to one vendor.

Model-agnostic is the whole point

Cursor is excellent, but it is fundamentally Cursor’s pipeline with a model behind it. OpenCode flips that — it speaks to 75+ providers (Claude, GPT, Gemini, DeepSeek, and local models via Ollama) and lets you switch the backing model mid-task.

That sounds like a checkbox feature until you actually use it. In a single afternoon I:

  • Started a refactor on Claude, hit a rate limit, and switched to GPT without losing the conversation or the plan.
  • Dropped to a cheaper model for mechanical edits (renaming, moving methods) where frontier reasoning is wasted money.
  • Pointed a privacy-sensitive change at a local Qwen model through Ollama so the code never left my machine — the same setup I covered in running Llama locally with Ollama.
# Switch the active model inside a session — no restart, no lost context
/model anthropic/claude-sonnet-4-6
/model ollama/qwen2.5-coder:14b

The cost lever alone changed how I work. Not every task deserves the most expensive model, and OpenCode is the first agent that let me make that call per-task instead of per-subscription.

LSP integration means it fixes, not guesses

The feature that quietly made the biggest difference is the Language Server Protocol integration. OpenCode runs your project’s LSP and feeds real diagnostics back to the model — actual compiler and type-checker output, not the model’s best guess about what the error might be.

On PHP this is the difference between an agent that says “this should work” and one that sees the Intelephense error, reads the actual type mismatch, and fixes it. Set up your language servers before you start:

// opencode.json — wire the PHP language server in
{
  "lsp": {
    "php": { "command": ["intelephense", "--stdio"] }
  }
}

When the agent makes an edit, it gets the diagnostics back on the next turn and self-corrects. With Cursor I’d watch it confidently introduce a type error and only catch it when I ran the code. OpenCode catches a large share of those before handing the change back.

It sits beside your editor, not on top of it

OpenCode is a terminal-first agent. That felt like a downgrade for about a day, then it didn’t. It does not try to replace your editor — it runs in a pane next to it, and your editor stays whatever you already trust.

For a legacy codebase this is the right shape. I keep the agent scoped with an AGENTS.md at the repo root — the same scoped-instruction approach I described in the Cursor rules file setup guide, just in a vendor-neutral file:

# AGENTS.md
- PHP 8.2, PSR-12. Never touch files under legacy/vendor-shim/.
- Run `composer test -- --filter` for the touched module before finishing.
- Prefer small diffs. Ask before changing public method signatures.

Keeping that file lean matters — every line is context the model reads on each run, so vague rules cost tokens and dilute the important ones.

Head-to-head on the legacy PHP repo

I ran the same three tasks through OpenCode and Cursor 3’s Agents Window (which I broke down in Cursor’s parallel coding teams):

  • Add validation to a controller — both nailed it. Cursor was slightly faster to first edit; OpenCode’s LSP loop produced a cleaner final diff with no type warnings.
  • Trace a bug across four files — OpenCode won. Switching to a frontier model just for the investigation, then a cheaper one for the fix, was something Cursor couldn’t do in one session.
  • Rename a widely-used service — Cursor’s tighter editor integration made the multi-file rename smoother. OpenCode needed clearer guardrails in AGENTS.md to avoid touching generated files.

Where OpenCode needed the most hand-holding was breadth-of-change tasks on unfamiliar code. Give it a tight scope and it’s excellent; turn it loose on “clean up this module” and it over-reaches without explicit do-not rules. That’s not unique to OpenCode — it’s the same discipline I use with Copilot’s agent on legacy PHP.

The honest verdict

  • Switch if you already use more than one model provider, care about per-task cost, or need some changes to stay on a local model. The flexibility is real and you feel it daily.
  • Don’t switch if you want a polished, all-in-one IDE experience and only ever use one model — Cursor’s integration is still smoother for pure editor-bound work.
  • Before you trust it: wire up your LSP, write a lean AGENTS.md with explicit do-not rules, and confirm your local model setup works. An open-source agent rewards the setup you put in.

For me, the model-agnostic core won. Being able to match the model to the task — and keep sensitive code on my own hardware — is worth the rougher edges.