OpenCode Go in 2026: three sources, three different limits

Quick answer

OpenCode Go publishes its usage limits as requests per five hours, per model, and the two most-cited third-party pages describe the same plan as a dollar budget instead. Both descriptions are live right now, in 2026, and they are not the same accounting. The vendor's own page, read on 4 September 2026, lists fourteen models with a per-model request allowance running from 110 to 45,300 requests per five hours, a 412x spread, and the two models with the biggest reputations sit at the very bottom of it. So the practical answer to "what do I get for OpenCode Go" is not a number you can carry over from a review. It depends almost entirely on which model you route to, and you have to read it off the vendor's current chart, because the unit and the lineup have both moved underneath the secondary sources.

I went to price a month of OpenCode Go for a side project and ended up with three different answers from three pages that all looked authoritative. That is the whole field log. Not a benchmark, not a verdict on model quality, just the boring discovery that the documentation for this plan has quietly forked, and that the piece of it most people are quoting is the older fork.

What the vendor publishes today

Here is the OpenCode Go page as it stood on 4 September 2026. The complete visible body of that page is about 2,000 characters, so this is a short document and it is easy to be exhaustive about what is and is not on it.

The price is stated five times as $10/month, with "Use with any agent", "Top up credit if needed" and "Cancel any time". The limits are presented as a single chart, labelled Usage limits, with the axis label Requests / 5 hours. I parsed the chart out of the page markup rather than reading it off the rendered bars, because each entry carries its model id, its value and its name as separate attributes, and reading the numbers in visual order gets you an off-by-one. (My first pass did exactly that and attributed every figure to the wrong model. More on that below.)

Two footnotes the chart carries in its own markup: GLM-5.3-Flash is flagged "2x usage" as a limited-time promotion, drawn as an extension on top of the 1,580 base rather than as a new number, so the vendor does not actually publish what the promoted allowance is. And Muse Spark 1.3 Contributor, the most generous row on the board by a distance, is marked "limited regions", which means the top of the table may simply not exist for you.

The shape here is the interesting part and it is durable regardless of what the numbers do next. This is not one allowance you spend however you like. It is fourteen separate allowances, and the ratio between the smallest and the largest is 412 to 1. Kimi K3 and Grok 4.6, the two names most likely to have sold you on the plan, are the two most rationed things on it at 110 and 169 requests per five hours. Round that out over a working day and Kimi K3 is a few hundred requests, which an agent loop will eat without noticing.

What the two most-cited pages say instead

Now the same plan, described by the two third-party pages that rank for it.

Docker's provider documentation, read the same day, describes OpenCode Go as "a low-cost subscription service ($5 first month, then $10/month)" and states three limits, none of them in requests:

• 5-hour rolling limit, $12 of usage
• Weekly limit, $30 of usage
• Monthly limit, $60 of usage

The page-1 editorial review, Thomas Wiegold's OpenCode Go review published 15 April 2026, uses the identical three-tier dollar structure, describes the plan as "$60 worth of API usage", and derives a per-model request table from it running roughly 4,300 to 50,500 requests per month, which he correctly summarises as "23x fewer requests depending on which model you pick". It is a careful piece and its arithmetic is internally consistent. Its lineup is GLM-5.1, Qwen3.5 Plus and MiniMax M2.5.

Hold those two lineups next to each other. Not one of the three models the April review builds its recommendation around appears on the vendor's chart today. The names have gone to GLM-5.3, Qwen3.7 and 3.8, MiniMax M3. The spread has gone from 23x to 412x.

Why I think the sources diverged, and what I cannot prove

The honest version is that I do not know whether the dollar caps still apply. Here is what I can and cannot say from public pages.

I can say the strings are not there. The words "first month", "weekly", "monthly" and "rolling" occur zero times on the vendor's Go page as of 4 September 2026, and since the whole visible body is about 2,000 characters that is a real absence rather than a failure to find something buried. The vendor publishes requests, and only requests.

I cannot say the dollar caps were removed. They may still be enforced underneath a request-count presentation, in which case both pages are true and are simply measuring at different layers. A $12 five-hour budget and a 110 request allowance on an expensive model are not necessarily in conflict. What I would not do is plan a month around either number without checking, because the two are not convertible without knowing per-request cost, which nobody publishes.

There is one piece of independent corroboration for the churn itself, and it is in a fourth set of docs. OpenClaw's provider page for opencode-go declines to publish a model list at all, tells you to run openclaw models list --provider opencode-go for the current one, and explains why in a single sentence: "new upstream models appear without an OpenClaw update". That is a downstream integrator saying out loud that this lineup moves faster than documentation does. Which is exactly the failure mode you are looking at when three pages disagree.

The "total lie" thread is about something else entirely

If you search this term you will hit a Reddit thread at position two titled "OpenCode Go is a total lie (IMO)", 181 comments, and you will reasonably assume it is about limits or billing. It is not, and I think it is worth saying so plainly, because the title is doing a lot of work its contents do not support.

The thread, posted 11 June 2026, alleges that OpenCode Go serves degraded or quantized models, argued from a subjective quality comparison after the author moved to direct plans from MiniMax and Moonshot. The author retracts the headline inside his own post, twice: "I don't have proof that OpenCode Go uses quantized models", and "I'm not making a definitive claim here." He also corrects himself on having used the wrong word, distilled where he meant quantized.

The top-voted substantive replies reject the premise as a category error rather than a factual dispute: "they dont host their own models... opencode is just a routing layer", and "opencode go just use the original providers for almost all the models". Another reader gets straight to it: "So you added 'total lie' in the title as a click bait." The two highest-scored comments in the entire thread are not about OpenCode at all, they are readers noting that the post's text is duplicated and looks machine-written.

I am not dismissing the underlying question, which is a real one and unresolved. I am saying that if you clicked that result hoping to find out what you actually get for your money, it does not contain that, and the vendor's own chart does.

The scoreboard

What I actually did with this

I subscribed, and I set the default route to a mid-table model rather than the headline one, which is the opposite of what I was going to do before I read the chart. The reasoning is not about price. It is that a 412x spread means model selection, not plan selection, is the decision that determines whether the thing is usable, and the two models I had assumed I would live on are the two the plan rations hardest.

The second thing I did was stop treating any secondary page as current for this product. That is a small, boring, portable habit and it is the one thing here I would carry to any fast-moving vendor: when a plan's own page and its integrator docs describe limits in different units, the integrator docs are the ones that went stale, because they are downstream of a lineup that, on the integrators' own admission, changes without telling them.

If you want the comparison rather than the accounting, I wrote up OpenCode against Claude Code building the same feature twice a month ago, and the agent-behaviour differences in that piece have held up better than any of the numbers in this one will.

One methodology note, because it nearly caught me

The vendor's chart renders each model as a bar with the number to one side. Read as flat text, the sequence goes number, name, number, name, and it is genuinely ambiguous which name each number belongs to. My first read attributed every figure to the following model and produced a table that was wrong in all fourteen rows while looking entirely plausible, because the values are monotonic either way. What settled it was the markup: each entry is one container carrying data-model, then the value, then the display name, so the number belongs to the model it precedes. If you are pulling numbers off a chart on any vendor page, check which element they are actually attached to before you publish them. Plausible and monotonic is not the same as correct.