Go: 5-hour usage limit blocks all models after one model hits its own limit

Description

Summary

After grok-4.6 hit its own 5-hour usage limit, every other OpenCode Go model
with zero usage started returning the same "5-hour usage limit reached" error,
with the same rolling reset window. Switching models does not help.

Environment

opencode 1.18.30
OS: Windows (win32)
Provider: opencode-go
Workspace: wrk_01M253ZBQ65WYRCXEEQE0SVV17

Expected

Per docs (https://opencode.ai/docs/go/), usage limits are per-model
(5h = 20% of that model's monthly limit). GLM-5.3, DeepSeek, Kimi etc. had
zero usage, so they should remain usable.

Actual

grok-4.6 is the only model with spend ($3.17, its 5h cap is $3.00) — legitimately
blocked. But all other models return the identical error with the same countdown,
across separate sessions and even for tiny title-generation requests.

Console usage page shows grok-4.6 only; every other model = $0.

Steps to reproduce

Use grok-4.6 until its 5h limit is reached.
Switch to glm-5.3 / deepseek-v4.1-flash / kimi-k3 (all $0 usage).
Send any request (new session, minimal prompt).
Same error: "5-hour usage limit reached. Resets in X".

Log evidence (opencode.log, 2026-09-14)

Different models, same error and same rolling reset window:

15:49 grok-4.6 (subagent)
16:16 muse-spark-1.2-contributor
16:17 / 16:25 glm-5.3
16:21 deepseek-v4.1-flash
16:31 kimi-k3 (new session) + title generation

Attached: log excerpts + console screenshot.

Impact

Paid models unusable for the remainder of the window, despite per-model
allowances by design.

Plugins

No response

OpenCode version

1.18.30

Steps to reproduce

No response

Screenshot and/or share link

<img width="1192" height="722" alt="

go_limit_evidence.txt

Image" src="https://github.com/user-attachments/assets/1a4ea3fb-58d8-42ec-81b8-e1bce89b52f1" />

Operating System

Windows 11

Terminal

OpenCode

I’m experiencing what appears to be the same or a closely related issue as #49014.

Kimi K3 reached 94.3% of its 5-hour usage limit while showing only 20.4% monthly usage. After some additional usage on other Go models, I became unable to use any Go model, even though none of the individual models had reached 100% of their own displayed 5-hour quota.

Details:

Plan: OpenCode Go
Main model involved: Kimi K3
Kimi K3 5-hour usage shown: 94.3%
Kimi K3 monthly usage shown: 20.4%
Other affected models: All other Go models I tried
Remaining quota shown for those models: They still showed remaining 5-hour quota and had not individually reached their limits
Error message: [429: {"message":"5-hour usage limit reached. Resets in 40min. To continue using this model now, enable usage from your available balance: https://.ai///","type":"GoUsageLimitError","param":"","code":null}]
Approximate time this happened: [Approximate time this happened: 2026-09-15 17:07 UTC

]

After the usage window reset: [did access return to normal?]

This looks like usage from multiple models is being combined into a shared 5-hour limit. Once the combined usage reaches that limit, all Go models become unavailable, even though no individual model has actually exhausted its own displayed 5-hour quota.

I’m also concerned that the same behavior may affect the weekly and monthly limits. If usage across models is aggregated in the same way for those limits, users could potentially lose access to all models even when individual models still show substantial remaining weekly or monthly quota.

I can provide screenshots, timestamps, and additional non-sensitive diagnostic information if needed.

I can confirm what appears to be the same issue on OpenCode Go.

My 5-hour usage breakdown was:

Kimi K3: 97.9%
GLM 5.3 Flash: 2.5%
Muse Spark 1.3: 1.2%
Total displayed: 101.6%

Muse still had almost its entire individual 5-hour allowance remaining, but I could no longer use it. Switching models did not bypass the 5-hour limit.

After the 5-hour window reset, access returned normally.

This strongly looks like the service is summing each model's normalized percentage (97.9 + 2.5 + 1.2 = 101.6) and enforcing that aggregate as a shared 100% limit, instead of enforcing the displayed per-model limits independently.

I can also reproduce the same arithmetic on my weekly/monthly dashboard:
the displayed total is exactly the sum of the individual model percentages.

I have screenshots if useful.

I have the same problem.
I was using Opencode Go's GLM-5.2. I haven't been able to resolve the issue by switching to another model, such as MiniMax-M3 or Kimi K3.
I tried using the Zed editor and encountered the same issue, so the problem lies with the service itself, not the tool.

I can reproduce this on OpenCode 1.18.31 on Windows, and my case suggests the issue is broader than a single model hitting its own limit.

It looks like OpenCode Go is aggregating the percentage usage of different models into one shared 5-hour / weekly / monthly limit.

For example, my current 5-hour usage is:

GLM-5.3: $2.5057 / $3.00 = 83.5%
Muse Spark 1.3 Contributor: $0.8109 / $12.00 = 6.7%
MiniMax M3: $0.7908 / $12.00 = 6.6%
GLM-5.3 Flash: $0.56 / $12.00 = 4.7%

Total shown by the dashboard:

83.5 + 6.7 + 6.6 + 4.7 = 101.5%

At this point the 5-hour limit is reached globally.

So in my case, no $60-limit model individually reached anything close to its own 5-hour allowance. Instead, usage percentages from several different models appear to be summed into one global percentage.

The same thing is happening with the monthly limit.

My monthly usage currently shows:

GLM-5.3: $2.5057 / $15 = 16.7%
GLM-5.3 Flash: $6.4745 / $60 = 10.8%
Muse Spark 1.3 Contributor: $3.6967 / $60 = 6.2%
MiniMax M3: $0.7908 / $60 = 1.3%
Grok 4.6: $0.02 / $15 = 0.1%

And the dashboard reports:

16.7 + 10.8 + 6.2 + 1.3 + 0.1 = 35.1% monthly usage.

Weekly usage is already 70.2% as well.

This seems inconsistent with the current Go documentation, which says:

"Each model has the following usage limits: 5-hour — 20% of the monthly limit; weekly — 50%; and monthly — 100%."

That wording strongly suggests per-model limits.

If the intended behavior is actually a single shared normalized quota across all models, then the documentation and model-specific dollar limits are very misleading.

If the intended behavior is truly per-model allowances, then this looks like a quota aggregation bug.

This is particularly problematic when mixing models with different monthly limits. For example, $1 of GLM-5.3 consumes about 6.67 percentage points of the global monthly meter ($15 limit), while $1 of GLM-5.3 Flash consumes only about 1.67 points ($60 limit).

So using even a small amount of an expensive / low-cap model can consume a very large part of the apparent global allowance and then block otherwise mostly-unused models.

Environment:

OpenCode Desktop 1.18.31
Windows
Provider: opencode-go

I have the same problem, and im blocked in all models :

I bought a subscription 6 hours ago and I'm stuck—I'm shocked.

I have this same problem. I think it's really unfair considering that it's a paid subscription

Same here with latest cli on mac. Is this not the intended behaviour?

Same here with latest cli on mac. Is this not the intended behaviour?

The docs say each model has its own 5-hour, weekly, and monthly limits, which sounds like separate quotas. But we're seeing that after hitting the 5-hour limit on one model, switching to another Go model with no usage gives the same limit/reset time.

Is Go actually using one shared quota with different model multipliers, rather than independent quotas per model? If so, the docs could probably make that clearer.

Same behavior here, with timestamps (opencode CLI on macOS, provider opencode-go, 2026-09-25 UTC):

The 5-hour window opened with the first Go request, a Muse Spark 1.3 Contributor call completing at 09:02:25Z.
Between 10:57 and 11:04Z, five different Go models (grok-4.6, muse-spark-1.3-contributor, glm-5.3, deepseek-v4-pro, kimi-k2.7-code) returned "Go limit reached" / "5 hour usage limit reached", all with the same reset time to the second: 14:02:25Z, exactly 5 hours after that first request.
No single model was near its own documented 5-hour share (20 % of its monthly limit): the highest was grok-4.6 at about 69 % of its share, kimi about 26 %, muse about 6 %.
Summing each model's spend as a fraction of its own 5-hour share gives 100.9 %, and that sum crossed 100 % at 10:57:07Z, about 30 s before the first limit error.

So the limit behaves like one shared account meter with per-model cost weights, not independent per-model limits as the docs describe. Could a maintainer confirm which is intended? If the shared meter is intended, the docs should say so explicitly; if per-model limits are intended, this looks like a bug.

Same here, i subscribed 2 days ago and i m using only free model : Space Bunny Free, its not fair

This is not just confusing. This is misleading.
I paid for OpenCode Go because the documentation explicitly says that “each model” has its own usage limits.
In reality, that is not what happens.
I exhausted GLM-5.3, then immediately switched to Grok 4.7, which I had not used. Grok was instantly rejected with HTTP 429 without even starting.
My dashboard showed:

Rolling usage: 0% left
Weekly usage: 20% left
Monthly usage: 60% left
So in practice, the product behaves like a shared normalized quota across all models, not independent per-model quotas.
Other users in this issue have reproduced the same behavior and even shown that the percentages of different models are being summed into one global meter.
Yet the documentation still says:
“Each model has the following usage limits.”
That wording is not a minor documentation mistake. It materially affects a purchasing decision.
I specifically bought this subscription believing that when one frontier model hit its limit, I could switch to another model with its own remaining quota.
That was false in practice.
Selling a paid subscription while presenting the limits this way is, in my view, deceptive and unacceptable.
If the quota is intentionally shared across all models, the documentation needs to say that clearly and prominently on the pricing page before payment.
If this is a bug, it has been publicly reported for weeks and is still affecting paying customers.
Either way, customers should not be discovering the real quota structure only after paying and getting locked out.
I am requesting:

A clear public explanation of how Go limits actually work.
Immediate correction of the pricing/documentation.
A refund for customers who purchased based on the current per-model wording.
Screenshots of my dashboard and rejected GLM/Grok requests are attached.

@Xemnai

Still reproducible on v2.0.21 (latest) as of 2026-10-03, so this survives the version bump from the 1.18.x reports above.
Plan: Go ($10/mo), Linux, opencode v2.0.21.

Windowed (rolling 5h) at the moment of the block, from opencode's own recorded cost figures:

kimi-k3              $2.98 / $3.00   (20% of its $15 monthly limit)  =  99.4%
deepseek-v4.1-flash  $0.10 / $12.00  (20% of its $60 monthly limit)  =   0.8%
                                                                global = 100.2%

Crossed 100% at 2026-10-03 10:36:25 UTC, the exact timestamp the last kimi-k3 call completed. kimi-k3 alone was at 99.4% of its own share, i.e. one model consumed essentially the entire shared meter by itself, with DeepSeek's 0.8% providing the last push.

Six paid models tested directly afterwards — kimi-k3, deepseek-v4.1-flash, grok-4.7, glm-5.3, qwen3.8-max, gpt-6-luna — all returned an identical Go usage limit exceeded. grok-4.7, glm-5.3, qwen3.8-max and gpt-6-luna had never been called on this account at all, so 0% usage cannot have exhausted their own allowances. Both unlimited free models (space-bunny-free, longcat-2.5-preview-free) were unaffected.

This confirms the normalized-sum mechanism @Xemnai and @AndreyBoyarshinov described. The practical consequence worth stating explicitly: because the meter normalizes per model, the real 5-hour ceiling is $3.00 for any $15-cap model and $12.00 for any $60-cap model. $1 of a $15-cap model consumes ~4x the shared meter that $1 of a $60-cap model does, so routing work through an expensive model cannibalizes allowance belonging to models the user has barely touched.

@alexandre500's request stands: either the per-model table or the enforcement is wrong. That table sums to well over $1,000/month of implied included usage across the listed models, which cannot be true under a single normalized meter.

I am experiencing this exact issue. I have the Go plan ($10/month) with 43% of the monthly limit remaining, and my 5-hour and weekly limits are at $0 (completely unused), yet I get "Go usage limit exceeded" on all models — including free models like mimo-v2.6-flash-free, ling-3.1-flash-free, and big-pickle.

The logs show mixed errors: "Go usage limit exceeded", "ECONNRESET", "Endpoint is unavailable", and "Rate limit exceeded", all in bursts of ~13 minutes.

My config uses opencode-go/mimo-v2.5 for build/plan/general and opencode-go/deepseek-v4.1-flash for explore. If one model's 5-hour limit blocks all others, this makes the plan unusable for real work.

Please prioritize the fix — the docs promise per-model limits but the implementation blocks the entire account. Thanks.

@smogunovandrey66

Hello @smogunovandrey66 and others in this thread

Unfortunately, due to poor wording or intentionally OpenCode misleading comments, the usage limits from all models are sharing one allowance. Meaning if you exhausted your whole limit for the 5-hours, week or month, you are no longer able to use opencode.

This confirmation has been said by the OpenCode support team themselves (see the image below).

An example would be:
Mixing two GLM models

$30 of GLM-5.3-Flash usage consumes 50% of your allowance.
$7.50 of GLM-5.3 usage consumes the other 50%.
You have now exhausted the monthly allowance, so switching to another paid model does not help.

@chrisssp

I assume others who reported this issue in this thread should know

@chrisssp @sebinbenjamin @niliadu @mustafa-colakoglu

@chrisssp

I assume others who reported this issue in this thread should know

@chrisssp @sebinbenjamin @niliadu @mustafa-colakoglu

thank you, i canceled my subscribtion one week ago, documents is wrong as i understand

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

@thdxr

24. Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

the issue is still pending on both v1 and v2, opencode devs needs to either clarify how the usage limit works or don't (intentionally or unintentionally) lie to people about each model having separate usage
@thdxr

I initially understood from the documentation that each model has its own independent monthly limit. However, based on my experience, it seems that hitting the limit on one model (e.g., Gemini 4 Argon) blocks access to all other models in the Go subscription.

I used only Argon, but after hitting the 5-hour limit, all other models became unavailable. From what I understand from the community discussions (e.g., issues #52962 and #50457), there is actually a single shared pool, and each model consumes it at a different rate (multiplier) based on its documented monthly limit.

If this is the intended design, it would be really helpful to explicitly state this "shared pool" and "multiplier" mechanism in the subscription documentation. Right now, the current wording makes it look like the limits are completely independent, which is misleading for users.

This really is quite confusing and the documentation does not make it clear in the slightest.

Asking multiple language models such as chatgpt/gemini etc to peruse the documentation and their interpretation was that each model had an independent limit as well.

Maybe opencode should use opencode to review their own documentation prior to publishing it.

The cynic in me thinks that it's a deliberate choice to not be transparent so as to sucker people in to thinking they're getting more than they actually are...

Navigation Menu

Repository navigation

Go: 5-hour usage limit blocks all models after one model hits its own limit #49014

Description

Summary

Environment

Expected

Actual

Steps to reproduce

Log evidence (opencode.log, 2026-09-14)

Impact

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go: 5-hour usage limit blocks all models after one model hits its own limit #49014

Description

Description

Summary

Environment

Expected

Actual

Steps to reproduce

Log evidence (opencode.log, 2026-09-14)

Impact

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

almooms commented on Sep 15, 2026

Xemnai commented on Sep 16, 2026

Garkatron commented on Sep 18, 2026

AndreyBoyarshinov commented on Sep 18, 2026

mjhazbri commented on Sep 19, 2026

alvarocanosoto commented on Sep 20, 2026

DaveValor commented on Sep 22, 2026

sebinbenjamin commented on Sep 23, 2026

lukemaj commented on Sep 25, 2026

mustafa-colakoglu commented on Sep 28, 2026

alexandre500 commented on Oct 2, 2026

niliadu commented on Oct 3, 2026

chrisssp commented on Oct 6, 2026

redcasinotimonneo commented on Oct 8, 2026

redcasinotimonneo commented on Oct 8, 2026

mustafa-colakoglu commented on Oct 8, 2026

thdxr commented on Oct 11, 2026

redcasinotimonneo commented on Oct 11, 2026

Surdagon commented on Oct 31, 2026

Orteko commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions