The Opencode Go Experience
A short, first-hand look at using Opencode Go for a month, why model quality matters, and why a GUI layer like Openchamber makes terminal agents easier to live with.

One Month with Opencode Go
It's been a month since I went all-in on Opencode Go, the $10-a-month AI subscription almost nobody knows exists.
Week One: Shaky Start
Honestly, week one was shaky. I kept sneaking back to Antigravity, not because Antigravity is any good, but because of how it pools quota.
Inside Antigravity, you'll find:
- Sonnet 4.6
- Opus 4.6
- Gemini 3.5 Flash
- Gemini 3.1 Pro
Claude's usage draws from one small pool, while Gemini's draws from another, much bigger one. Once you learn to lean on the Gemini side, the ceiling stops feeling like a ceiling. It's not that the limit is generous; it's that you stop being able to see it, which is its own kind of relief.
Early Impressions of GLM 5.2
Then GLM 5.2 launched, and everyone panicked: "the model that beats opus!", "the BEST open-source model is better than claude!!!". So I went to give it a try... I was heavily disappointed.
Apparently, the provider Opencode had at the time was rough and slow. It thought in that unmistakable Kimi K2.6 cadence: pages of "actually," "wait," "let me reconsider," and no action to show for it. A lot of talk-no-jutsu.
Leaning on Kimi 2.7 Code
So I leaned on Kimi 2.7 Code instead. This wasn't really a switch, more an adoption, since it was benchmarking well and sat somewhere between Gemini Flash and Sonnet as a good code writer. I kept Gemini 3.1 Pro around for the actual debugging and issue-hunting; Kimi wrote, Gemini dug.
Kimi's failure mode wasn't sloppy output either; it was worse in a specific way: it would fall into a deep loop of thinking in circles. When (or if) it eventually finished, it would surface a half-solved answer that may or may not be what you even asked for. Not the kind of miss you'd forgive from a model that benchmarks that well.
Two Weeks In: GLM 5.2 Revisited
Two weeks in, I gave GLM 5.2 a second look, mostly out of boredom. I was impressed; it's like it was a whole different model. No rambling, straight to the work, results I could actually predict. Its only real tic is assuming instead of reading a file first, and that's partially my fault because I was using it in Copilot's harness (yes, it supports custom models).
The interesting part was watching it catch itself mid-trace. It would head down a wrong line of thinking and visibly correct course before acting on it.
<thinking>
***Wrong line of thinking***
</thinking>
Actually, let me check how the data is loaded first.
<tool: file_contents> data.ts </tool:file_contents>
My best guess, and it is only a guess, is that early access was either heavily quantized or quietly rerouted onto Kimi capacity for load-balancing. This would explain the Kimi-flavored rambling before later requests landed on real Z.ai-grade serving, and the finetuning underneath finally showed. I can't prove any of that. It's just the shape of what I saw.
The Real Test: Rust + React Feature Planning
The real test came while I was planning a feature for a Rust + React project. I asked Opus 4.6 what it thought and how we should tackle this feature, then asked GLM 5.2 the same question just to compare.
Both proposed the exact same set of solutions; one of them would require running a server on the client, which is not a small ask.
- Opus didn't flag the problem at all; it just suggested we do it (like we'll figure it out later).
- Sonnet 5 flagged it, explained that we'd need a server on the client (basically why this was a bad idea), and then said let's build it anyway.
- GLM 5.2 flagged it and said we probably shouldn't do that.
That's roughly where I decided that I'm renewing this subscription.
Surviving Complaint
One complaint survives, though: I hate running an agent in a terminal. I want a sidebar where I can watch code get written among other features.
The Selling Point: Flexibility
Here comes the actual selling point of Opencode Go: Its models aren't locked to Opencode's own agent! You can point them at whatever agent you already use.
- VS Code's Copilot will
- Zed will
- Kilo Code will
- And with a small proxy trick, even Claude Code will
Still, I wanted to keep Opencode's own agent, since it's plain enough to reason about and apparently good enough that Andrej Karpathy himself has said kind things about it.
Openchamber: The Visual Layer
Which is what Openchamber is for. It's a fan-built visual layer that sits on top of your local Opencode process; a screen to watch and steer the agent from, instead of living in a terminal. It runs as:
- A VS Code extension
- A desktop app
- A web page you can open when you're away from your machine
Pricing & Alternatives
Opencode Go is $5 for the first month, $10 after. It's worth the experiment.
oh forgot to mention, you get an additional $5 if you use a referral link (and I do too), here's mine: https://opencode.ai/go?ref=7M86Z4412S
If you'd rather skip Opencode entirely, Cline Pass gets you the same idea, same models, different shell.
Both of them give similar limits, one that I couldn't exhaust easily.
Enjoy. ❤️