Why I dropped Claude Code for OpenCode

Update, July 2026 — I’ve since gone back to Claude Code (Anthropic Max subscription) — not for the model, for the ecosystem Anthropic built around it. The lock-in described here still holds. Sequel: Anthropic, the Apple of AI.

I started with Claude Code via the Anthropic subscription. It was the obvious choice: official tool, Sonnet model renowned for quality, zero configuration. In 10 minutes I was productive. For several months, I used it daily on a production Symfony 7 + TypeScript/React project — including via OpenCode, which allowed using the Claude Code subscription as a provider.

The migration didn’t come from disappointment with quality. It came from an Anthropic decision.

When the lock-in became concrete

Anthropic restricted the use of the Claude Code subscription in third-party tools. Overnight, my OpenCode + Claude Code subscription workflow stopped working. The choice: go back exclusively to Claude Code (with its single-provider lock-in ), or find an alternative.

That’s the structural problem with lock-in: when the vendor changes the rules, you have no options. It’s not a pricing issue — it’s a control issue over your own workflow.

The problem of non-capitalizable workflows

The second problem surfaced when we started getting the team on agents. On our project, we’d developed recurring patterns: how we create an API Platform endpoint, how we structure a Symfony service with in-house conventions, how we generate test fixtures.

These patterns lived in my head and in my manual prompts. With Claude Code, there’s no mechanism to formalize and share them via Git. Every dev starts from scratch.

With OpenCode, custom commands are versioned Markdown files. A new dev clones the repo, they have access to the workflows the team has built.

# .opencode/commands/new-service.md
Create a Symfony service for {entity} following the project conventions.
Follow the patterns in CLAUDE.md. Generate the corresponding unit tests.

That’s the difference between tribal knowledge and codified knowledge.

What I lost in the migration

Let’s be honest: there’s real friction in the first few days with OpenCode. The TUI is more complex than Claude Code’s clean interface. The initial configuration (providers, custom commands) takes 2-3 hours of investment.

And on truly complex tasks — architecture refactoring, debugging subtle behaviors — I haven’t noticed a significant difference, but I can’t claim the two tools are identical across all cases. Claude Code with Sonnet 4.5 remains a solid reference.

What tipped the balance

After the migration, the verdict is clear:

Kilo Code CLI — a fork of OpenCode — offers Kilo Gateway with free models (including MiniMax 2.5). Mechanical tasks that used to cost Sonnet tokens are now at zero cost. Same perceived quality on those tasks.

The team’s custom commands now represent ~15 formalized workflows in Git. A new dev is operational on the project’s patterns in less than an hour.

The client/server architecture (inherited from OpenCode) works perfectly with our SSH Mac→Ubuntu setup. I detach a tmux session, reattach later, the state is there.

Who should stick with Claude Code

I don’t advise everyone to migrate. If you’re starting with coding agents, Claude Code is still the best entry point: zero friction, immediate quality. If you work solo and API cost isn’t a variable, Claude Code’s simplicity is real value.

The tipping point comes when two conditions are met: you don’t want to depend on a single provider, and you want to share formalized workflows as a team. If either applies, OpenCode or Kilo Code CLI are worth the investment.

Full comparison OpenCode vs Claude Code vs Kilo Code Guide: agentic workflow in production