OpenCode let me switch models, but I wanted more control

OpenCode let me plan a feature with a hosted model, switch to a local model for implementation, and return the next morning to a pull request ready for human review.

I used MiniMax-M2.7 for the design, specification, and plan. I then switched the same OpenCode session to Qwen3.5-27B, running through llama.cpp on a Mac Studio M3 Ultra with 96 GB of unified memory, and left it working overnight. By morning, OpenCode had committed the changes, pushed them, and opened the pull request.

The initial implementation covered the main feature behaviour. During manual review, I found missed edge cases and made minor edits before accepting the pull request.

OpenCode had let me change both model and execution location without leaving the coding-agent session. That was the clearest form of model choice I had experienced, but it was only one part of the control I wanted.

Provider choice was the reason to try OpenCode

In my comparison of Codex CLI, GitHub Copilot agent mode, and Claude Code, I kept all three because different work exposed different strengths. None had settled the runtime question. I wanted one coding-agent surface that could use models from different providers without replacing the workflow around them.

OpenCode offered that separation. Its provider documentation described direct APIs, hosted catalogues, subscription authentication, gateways, and local OpenAI-compatible endpoints behind one terminal interface.

My two paths were materially different. MiniMax-M2.7 ran through MiniMax’s direct API using the Coding Plan subscription key available to me at the time. Qwen3.5-27B ran on my own machine through llama.cpp.

That distinction matters. OpenCode put both models behind one interface, but using MiniMax still meant prompts and selected context travelled to a remote provider. Qwen inference ran locally, but local inference alone did not make the whole workflow end-to-end private. The model, provider, endpoint, hardware, and configuration all remained part of the result.

The hosted model planned, and the local model built

MiniMax-M2.7 produced the feature design, specification, and implementation plan. Its displayed throughput was roughly 50 tokens per second, and the output was good enough to hand to the implementation model.

For implementation, I switched OpenCode to the local Qwen3.5-27B endpoint. Its displayed throughput was roughly 20 tokens per second, and the output was good enough to cover the main feature behaviour.

These were interface counters, not benchmark results. The models did different work under different configurations: MiniMax planned; Qwen implemented. The figures describe those sessions, not relative model performance.

Human review remained the acceptance boundary

The overnight run was substantial delegation. OpenCode and the local model carried the implementation through Git and into a pull request without continuous supervision.

That did not make the pull request accepted work. I still reviewed it and checked the feature behaviour. I found missed edge cases, then made minor edits before accepting it.

The useful outcome was not that a local model had replaced the developer. It was that a locally running 27B model could complete enough of an undisclosed feature implementation to make overnight delegation practical on my hardware, while leaving acceptance with me.

The feature, repository, stack, client, and pull request remain confidential, so readers cannot inspect the result independently. My claim is limited: the implementation covered the main behaviour and was accepted after I corrected the edge cases found during review.

OpenCode was changing throughout the trial

I used OpenCode throughout May 2026 while the project’s official releases moved from v1.14.31 on 1 May to v1.15.13 on 30 May.

The release notes described changes to permission inheritance, background-agent behaviour, diff review, MCP configuration, and workspace handling, including a fix for a Plan-mode permission bypass. They establish a changing product context, not my installed build or configuration on a particular day. I therefore did not treat one documented capability as the cause of my experience or one product limitation as the reason to move on.

Model choice did not settle runtime fit

OpenCode was good enough to keep using throughout the month. It showed me that provider choice could work on real work: one session, one hosted planning model, one local implementation model, and a pull request accepted after review.

The remaining difference was personal workflow fit. I wanted reusable engineering disciplines to live as skills and instructions that I could route into the work. During my late-May pi trial, those were easier for me to encode. OpenCode documented plugins, permissions, MCP, skills, and layered configuration, but the existence of those extension points does not prove that I evaluated or exhausted them.

OpenCode was not a failure, and pi was not yet my settled runtime. The comparison made one requirement clearer: model choice mattered, but so did how easily I could encode reusable rules and tell when they affected the work.

The criteria I carried forward were simple:

• Can I switch models without discarding useful session context?
• Can I encode reusable skills and instructions, then see when they shape the work?
• Can I inspect and bound tools, permissions, network paths, and context use?
• Does human review reveal what the agent missed before acceptance?

The pull request also left a harder question. An agent had planned a feature, implemented it overnight, and produced work that mostly survived review, but it missed edge cases. Which part of that result belonged to model fluency, and which engineering judgement remained mine to apply during review?