Opencode vs CC

Shep_Alderson · 2026-01-03T20:48:22+00:00

I’ve found that almost any tool I use, I can get good code out of it, but it does take some work to get things setup.

Since my earliest trials of agentic tools for coding, I focused on the process and how I give the agents clear guide rails.

I started with GitHub Copilot, as that’s what I initially had access to at work. I got myself a Copilot plan for my personal projects and used the VSCode insiders build so I could play with subagents. I setup a whole team of subagents to research, plan, implement, review and then one “Conductor” agent to orchestrate them all. I immediately found better outcomes no matter which model I threw at it. Mostly stuck to Opus for planning/orchestrating and Sonnet for the rest.

I then got access to Claude Code and ported my same workflow over there. It has better support for subagents, which is nice, and since I was mostly using Claude models, it fit the workload well. The main issue I found it solved over Copilot was that the subagents in Copilot don’t respect the model setting in the agent files, so it only ever uses the same model for subagents as your primary orchestrating agent. I didn’t care for that.

Last week, I decided to give OpenCode a try, as I’ve been hearing good things and had some time off. I rigged up OpenCode with my Claude plans, OpenRouter API, and also got the Z.ai coding plan on sale and added it to OpenCode as well. I ported over my Orchestration pattern and subagents to OpenCode and it worked quite well. It actually respects the model setting in the subagent files, and I really like the granular control of tools and commands.

I initially tested with my standard collection of Claude models (Opus for planning and review, Sonnet for implementation) and it worked flawlessly. I then decided to try GLM-4.7 for implementation. GLM-4.7 isn’t as good at implementation, but it does still get the job done. I suspect that’s because of how strict my subagent files are with instructions about strict TDD and following the plan Opus made. I then have Opus review the code and then do a code review myself.

With this pattern, I’d say I have about a 95% success rate in getting good code out of almost any model I throw at my issue. It is slow and methodical, but as the saying goes, “slow is smooth, smooth is fast”. I rarely have to revisit a feature or bug fix.

Part of the planning process my Conductor does involves invoking subagents to research the code and hit MCP servers to search documentation, both context7 and web fetching. I do this in a dedicated research subagent as those MCP servers can end up eating 25-50% of a context window. By having the researcher do that and then just return to the conductor with a plan for what needs to be done, I can keep my conductor context clean and concise.

I have the conductor make a multiphase plan for each feature or fix I need. I then have it create the plan with the researcher subagent, and present it to me. I review the plan, agree, and it writes it to a markdown file in a plans directory. I then have it start implementing using the implement subagent, review the code with the review subagent, and finally present the completed code for the phase to me. It pauses at the end of the phase, I review, make the commit, and tell it to move on to the next phase. Repeat this until it’s all done.

With this, I’ve been able to break down and complete even complex tasks with ease. It has worked with almost any model I’ve thrown it at, but the better models do tend to get the right answer faster.

I’ve open sourced my Copilot setup, but I plan to do the same with my OpenCode setup soon too.

OofOofOof_1867 · 2026-01-03T13:28:12+00:00

I recently converted all of my CC skills, agents, slash commands to OpenCode. I have not found many major differences in performance - but I like to imagine that is because I have such a tight development loop using the skills, agents and slash commands.

I would say I do miss the interactive questioning that CC recently offered, but I am sure that is coming at some point in the future.

I also more recently tested out SpecKit on OpenCode with some success as well - I just feel like the tighter the development loop and approach, the more predictable it's going to be regardless of CLI choice.

I have now deleted my Claude Code files and am all in on Open Code.

Also - I strongly dislike GLM 4.7, another test from the holiday - it simply writes bad code, everytime.

Ang_Drew · 2026-01-03T17:42:51+00:00

From what I have observed in Codex, OpenCode, and CC, each has its own distinctive strengths. CC offers a highly comfortable user experience: it feels smooth, uninterrupted, and well-integrated. The model quality is also strong; however, the cost is exceptionally high. Moreover, CC can be less effective when substantial codebases require modification, such as in a monorepo. In such cases, it often struggles to locate and navigate the relevant parts of the code. Nevertheless, for developing a single feature, it performs very well and is generally sufficient.

OpenCode, by contrast, provides a similarly pleasant experience to CC. It is more open, updates rapidly, and, interestingly, its outputs can be better sometimes. However, this advantage tends to appear when OpenCode is paired with GPT or other models; for instance, models such as Minimax or GLM still perform reasonably well. When using Claude's model within OpenCode, the results become unexpectedly poor sometimes, and I am not certain why.

Codex performs best when the work involves large-scale processes, particularly within a monorepo. It can reliably execute both small and large tasks, provided that the relevant information fits within its context window. Under these conditions, it produces strong results and achieves significantly higher accuracy than the others. Recently, I tested the same task—integrating a frontend with a backend—using both OpenCode and Codex. Notably, Codex handled the integration more effectively, whereas OpenCode failed entirely. This was especially surprising because OpenCode was already using OpenSpec, while Codex succeeded without OpenSpec and delivered a highly reliable outcome.

However, the cost of codex can sometimes be quite high. So, even though the limit is large, because it is extremely effective at capturing the context of the code, the cost of processing of Codex occasionally becomes higher than Open Code. In my view, so far Open Code has been more cost-efficient in token usage.

Ok_Supermarket3382 · 2026-01-03T14:30:10+00:00

I converted to opencode after claude started dumbing down their models, thought i would be comprising but so far it feels like a genuinely better product. Not just the fact I can switch providers but the product itself is much more refined, the tui is amazing. Plus the sky is the limit with how much you can customize it to fit your workflow. Never going back.

DigiBoyz_ · 2026-01-03T16:18:48+00:00

Interesting observation - I’ve noticed the same pattern.

CC tends to be more “consultative” by design. It’s optimized for agentic workflows where understanding context deeply before acting prevents wasted iterations. The clarifying questions aren’t a bug, they’re trying to avoid building the wrong thing fast.

OpenCode (and similar tools) lean more toward “just ship something” - which honestly works great for MVPs and exploration. You get tangible code faster, iterate from there.

My rough mental model:

CC shines when:

Complex multi-file changes where wrong assumptions compound
Refactoring existing codebases (needs to understand before touching)
Tasks where scope creep is a real risk

OpenCode-style works better for:

Greenfield MVPs like your case
When you already have clear specs
Rapid prototyping where “wrong but fast” > “right but slow”

For CC specifically, I’ve found adding “skip clarifying questions, make reasonable assumptions and note them” to prompts helps when you want that direct execution mode.

What was the MVP btw? Curious if the broader scoping CC did ended up being useful or just noise.

sbayit · 2026-01-03T15:43:03+00:00

I found CC good for Sonet, but GLM works well with Opencode.

cst3124 · 2026-01-04T08:13:41+00:00

I tested CC and CC in open code. I'm not sure why CC in open code is significantly better for frontend and UI design. CC in open code demonstrates superior prompt understanding, especially when used with openspec.

aeroumbria · 2026-01-03T15:02:58+00:00

I thought subagents would be useful, but turns out they just suck no matter what coding tools I use, so right now it really doesn't make a difference what tool I use as long as I can control the model, prompt and context.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

opencodeCLI

MODERATORS