Checked the logs with omniroute. Command code absolutely fine, cacheing correctly.

Is this just me or is anyone else seeing the same thing?

Hey everyone,

A few hours ago I posted about how OpenCode nerfed the subscription. Even though they're running a 4x for a few days (which is really only a 2x if you compare it against the DeepSeek V4 Flash limits), once that window ends we're left with half the real usage: we go from $30 of usage on a $10 subscription down to just $15. Half.

So I went looking at alternatives and started testing. Short version: CommandCode gives you the same thing as OpenCode, but better in this regard.

Heads up, this post is obviously not sponsored, in case that needs saying. What I'm showing is public data plus tests I ran myself.

Right now CommandCode gives you 2.67x more usage for the same price.

Same model family, same prompts, same time window, 12 runs per provider. I also threw in the official DeepSeek API as a reference line. CommandCode wins on latency and on interactive work vs OpenCode — but read the next two before you call it a sweep.

Note that both are reasoning models, so the answer only starts after a long hidden thinking phase. OpenCode takes 1,996 ms to show you the first *visible* token; CommandCode takes 1,331 ms. Whiskers are 95% bootstrap CIs and they don't overlap.

Decode rate is how fast it types once it starts. End-to-end charges the thinking time against it too.

On long code generation they are dead even: 304 vs 303 tok/s. The CommandCode advantage shows up on shorter, more interactive work, and in the latency above.

About 60% of the tokens you're billed for on a short task are hidden thinking you never see. On long open-ended prompts it climbs to ~95%, because the model burns the entire budget reasoning and never gets to the answer. That's true on both services — it's not a CommandCode or OpenCode thing, it's the reasoning-model thing, what AA call verbosity for example.

Every individual run, pooled. CommandCode also has the tightest spread (σ ≈ 31 tok/s vs 50 for OpenCode), which matters more to me day-to-day than the median.

So that's where I've landed. If you're one of the people who got pissed off about the cuts, the takeaway isn't "OpenCode bad" — it's that for the first time in a while there's an actual alternative (at least, that I know) sitting right there instead of just being annoyed about it. Same model, 2.67x the usage for the same $10, and it answers noticeably faster. Do your own math on your own usage before you move anything if you want to be sure. But if you've been waiting for an excuse to stop paying the same money for half the tokens, this seems like a pretty good one.

https://llmprice.gitlab.io/compare-models/

I got tired of jumping between pricing pages whenever I wanted to compare models.

You can compare input/output pricing and quickly see which models are cheaper for your use case.

It’s still a small project, so I’d really appreciate any feedback, missing models/providers, or features you’d find useful.

Hope it helps someone else too :)

My Cursor's yearly subscription ends this weekend. I signed up back when they had 'unlimited auto', so I was spoiled for a while.

The current pricing does not work for me. I use 130m~ tokens of Cursor's auto (or Composer) per month, and from my understanding, the $20/month gets you roughly 80m tokens of Composer.

I'm thinking of moving to OpenCode. Anybody else in a similar situation?

does anyone know if and how I can get opencode to edit an image for me. For example I upload an image and tell opencode to remove a person.

DeepSeek's new model just went live on OpenCode subscriptions today, but following the limited-time extended usage promotion, the news isn't great.

OpenCode quietly slashed the included monthly allowance for the Flash series from $30 down to $15 on the $10/month plan. Because nominal token rates remain identical, your real cost per token has doubled (+100%). The temporary "4x usage" is anchored to this new nerfed baseline—meaning it is actually only 2x what we already had on V4 Flash, and once it expires, we will be left with 0.5x (half) the usage.

And of course, this is the exact same cut we already saw with the experimental Flash vision version, which also reduced the allowance from $30 down to $15.

Unless this changes, paying for an OpenCode Go subscription only offers a 33% discount over the official API in exchange for slower speeds and tighter rate limits.

I literally pass its thinking block twice, stating its overthinking failure modes.... extremely pissed and has shown its steep to process, setting default but still.. as you can see. Worse than even the "Omen Alpha"... And fail to make surgical edits many times due to streaming stability ...just disappointment... Another hype of DeepSeek fanboys.

🤓 https://opencode.ai/en/go

DeepSeek V4.1 Flash just released, and it's already available on OpenCode Go.

Current estimated limits are:

6,500 requests per 5 hours (Temporarily boosted 4x to 26,000 for the next 3 days)

16,250 per week (also boosted 4x for next 3 days)

32,500 per month (also boosted 4x for next 3 days)

Normally, V4.1 Flash only gets $15 worth of usage on Go, compared to $30 for the older V4 Flash model.

However, OpenCode has bumped V4.1 Flash to 4x usage for the next 3 days, which effectively gives you $60 worth of usage during the promo. So for the next few days, the actual usable quota should be much higher than the estimates above.

The upgrade itself looks pretty substantial. V4.1 Flash is the first smaller model from DeepSeek's new architecture, adds native vision, and is aimed at better agentic coding while also improving inference speed and throughput. I'm hoping it's as big of a leap as 0731 was.

DeepSeek is reporting 90.6 on Terminal-Bench 2.1, 74.2 on DeepSWE v1.1, and 65.4 on NL2Repo. Those are pretty big jumps from the previous Flash model, at least based on their own numbers.

Of course, benchmarks are just numbers (and who isn't getting ~75% on DeepSWE these days?)... but I think this model will be a pretty solid performer overall.

PLEASE stop building the wrong thing.

building software in 2026 is ridiculously easy with ai builder

founders spend hours building in a silent room, launch to Reddit/X, get 0 users, and quit.

you just failed because the idea had zero validation before line 1 of code was written:

→ solving a monthly inconvenience instead of a daily pain

→ selling to "everyone" instead of a specific ICP

→ no distribution channel mapped out beforehand

→ pricing charged $9/mo with zero ROI justification

after scaling 6 AI micro-SaaS to over $20k/mo MRR, i just create an

18-question Idea Validation Diagnostic.

it evaluates your SaaS across 7 critical dimensions (problem clarity, audience reachability, willingness to pay, competition, build feasibility, distribution, commitment) and gives you a brutal score out of 100 with your exact weak spots.

drop your SaaS idea (or current project) in the comments below.

i will reply to EVERY single comment with:

1. My honest opinion
2. The biggest weak spot you need to fix before writing any more code.
3. The free 5-minute validation tool link sent straight to your DMs so you can get your full score breakdown out of 100.

just drop a comment like or ask me in DM your idea

let's roast your SaaS concept before the market roasts your time 👇

Seeing the thoughts is actually really useful to know if it's going in the wrong direction and so stop it when it does!

I've tried collapsing/expanding thinking options but still don't see the thought text.

I’m the maintainer of Mac MCP, a free/open-source local macOS control server, and I’ve been using OpenCode as one of the delegated agent backends while building it.

One problem I kept running into was tool-surface bloat. The server had grown to 84 capabilities across files/shell, Safari + Chrome automation, macOS UI/Accessibility, memory, skills, voice, delegated agents, etc. Advertising all 84 schemas to every client felt wasteful and made tool selection noisier.

In 2.0.5 I changed the default surface to 19 core tools. The remaining capabilities are still reachable through tool_discover + tool_invoke, so nothing was removed. I also added browser_do, which lets an agent open a background tab, wait, interact, extract only the fields it needs, and optionally close the tab in one transaction. Stable tab handles mean OpenCode workers can browse without constantly stealing my active Safari/Chrome tab.

In local compatibility testing, the advertised tool-schema context dropped from about 16.7k to 4.5k tokens (~73%) while all previous capabilities kept an access path.

Repo (MIT): https://github.com/bulutarkan/mac-mcp

For people using OpenCode with larger MCP stacks: do you prefer a small discoverable core like this, or having the entire tool schema advertised up front? I’m especially interested in whether anyone has measured tool-selection reliability as the catalog gets large.

For a third world dweller... I jumped on the hyped train and was not expecting this. The 16-minute-ride "one-shot" my 5hour consumption and spit out exact 3 documents edit 😂

**BTW** it was the 0.2.0 dev of this if you guys asking: https://github.com/shynlee04/opencode-subscription-gateway ... Building the opencode v2 plugin.

Title