Reaching weekly quota won't allow request to other models #52783

Activity

1. github-actions

   assigned

   vimtor

   on Oct 2, 2026
2. github-actions commented on Oct 2, 2026

   

   github-actionsBot

   on Oct 2, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • #51550: Reports that reaching one Go model’s weekly quota blocks other unused Go models.
   • #50457: Reports that reaching 100% weekly Go usage prevents switching to another Go model.
3. niklasthorild commented on Oct 2, 2026

   

   niklasthorild

   on Oct 2, 2026

   More actions

   Check the "Go" tab at the OpenCode console. The subscription has rolling, weekly and monthly usage limits.
4. mjunaid106 commented on Oct 2, 2026

   

   mjunaid106

   on Oct 2, 2026

   Author

   More actions

   Check the "Go" tab at the OpenCode console. The subscription has rolling, weekly and monthly usage limits.

   Yes, I get that but why can I not switch to a different model and my weekly quota would then update. Why does it block me from accessing any other model?

   
5. niklasthorild commented on Oct 2, 2026

   

   niklasthorild

   on Oct 2, 2026

   More actions

   No, those limits you see there are global. Those applies to ALL models. Per model quotas are within those limits.
6. mjunaid106 commented on Oct 2, 2026

   

   mjunaid106

   on Oct 2, 2026

   Author

   More actions

   No, those limits you see there are global. Those applies to ALL models. Per model quotas are within those limits.

   oh, so I have used weekly quota across all the models. Now need to wait for 2 days :|
7. niklasthorild commented on Oct 2, 2026

   

   niklasthorild

   on Oct 2, 2026

   Last edited by niklasthorild

   More actions

   Yes exactly. Opencode Go is a relatively low-cost subscription. It's GREAT for low-end models, but as soon as you start using the anything close to flagship models you will eat up your global limits extremely quickly.
8. mjunaid106 commented on Oct 2, 2026

   

   mjunaid106

   on Oct 2, 2026

   Author

   More actions

   I was using Qwen because it have you $60 worth of credit apparently somehow. I have no idea how can I use $60 worth of credits....
9. niklasthorild commented on Oct 2, 2026

   

   niklasthorild

   on Oct 2, 2026

   Last edited by niklasthorild

   More actions

   That's a $60 monthly limit in Qwen 3.7 plus, the same as your global monthly limit.
   https://dev.opencode.ai/docs/go/

   I don't know the exact reason, but I'm guessing the per-model limits is a way for Opencode to direct users to use their global limits in a way thats sustainable for their business model.
10. chrisssp commented on Oct 6, 2026

    

    chrisssp

    on Oct 6, 2026

    More actions

    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.
11. markmonkey commented on Oct 19, 2026

    

    markmonkey

    on Oct 19, 2026

    More actions

    Adding a second data point — same symptom on the 5-hour window instead of the weekly one: while the rolling window sits at 100%, every Go model is rejected, including models with essentially no usage of their own.

    Environment: opencode v2.0.32, macOS arm64 (Darwin 25.6.0), Ghostty, zsh; no plugins. Go plan ($10/mo, subscription started 2026-10-17).

    Evidence (2026-10-19, ~03:50–03:56 UTC)

    1. GET https://opencode.ai/inference/go/v1/usage returns a single workspace-level set of numbers, identical for every ?model= value (including nonexistent model names):

    {"usage":{"rolling":{"status":"rate-limited","percent":100,"resetsAt":"2026-10-19T05:39:26.000Z"},
              "weekly":{"status":"ok","percent":40,"resetsAt":"2026-10-26T00:00:00.000Z"},
              "monthly":{"status":"ok","percent":40,"resetsAt":"2026-11-17T05:39:36.000Z"}}}

    2. While rolling was at 100%, direct curl calls (outside OpenCode) to two models with negligible own usage both returned HTTP 429 with the same body:

    • deepseek-v4.1-flash (≈$1.19 lifetime usage, ≈$0.3 inside the 5-hour window)
    • glm-5.3-flash (essentially unused)

    {"type":"error","error":{"type":"GoUsageLimitError","message":"Go usage limit exceeded"},
     "metadata":{"workspace":"org_01M4FC…","limitName":"5 hour"}}

    3. Switching models mid-block does not help (all within ~5 minutes):

    • 03:34:05 qwen3.8-max → 429 "5 hour"
    • 03:37:26 glm-5.3 → 429 "5 hour"
    • 03:37:51 glm-5.3-flash → 429 "5 hour"
    • 03:39:07 deepseek-v4.1-flash → 429 "5 hour"

    4. Free models still work in this state: longcat-2.5-preview-free returned HTTP 200 while rolling was at 100% (consistent with the docs tip).

    Expected (per https://opencode.ai/v2/docs/console/go): each model has its own limits — 5-hour = 20% of its monthly limit, weekly = 50%, monthly = 100% (e.g. DeepSeek V4.1 Flash $80/mo, GLM-5.3-Flash $60/mo). Exhausting one model's window should not block unrelated models.

    Actual: the 5-hour gate behaves as one shared workspace-wide pool. It was exhausted after only ~$3–4 of local usage — the console shows ≈$4 total usage, and the endpoint reporting monthly ≈40% is consistent with ≈40% of the $10 plan price rather than the documented per-model monthly amounts. The window also behaved as a fixed window, not sliding: it stayed fully locked until resetsAt instead of releasing old usage gradually.

    Local per-model accounting for the period (list prices, from session data): qwen3.8-max 64 req ≈ $4.44; glm-5.3 6 req ≈ $1.48; deepseek-v4.1-flash 285 req ≈ $1.19.

    Practical impact: one expensive model's burst (Qwen3.8 Max — $2/$6 per 1M tokens, $2.50/M cache write) takes every Go model down for hours while weekly/monthly allowances are still at 40%, and the obvious mitigation (switching models) does not work.

    Related context: #42549 (rolling hits 100% far below documented spend), #45312 ($3 vs $12 5-hour mismatch), #50457 (weekly 100% unexpectedly / unclear shared usage calculation).
12. markmonkey commented on Oct 19, 2026

    

    markmonkey

    on Oct 19, 2026

    More actions

    Update: the mechanism is officially confirmed in #54875, I re-verified it against a second workspace, and the current docs are actively misleading — not just incomplete.

    Following up on my report above (5-hour window exhausted → every Go model 429 while weekly/monthly sat at 40%): @shayaandanishansari posted the official answer from OpenCode support in #54875, and it explains everything precisely. Quoting from there:

    All paid models in OpenCode Go draw from one shared allowance, with model-specific weighting. The allowances aren't separate for each model.

    • Your plan has one usage allowance, with three limits: 5-hour (20% of the monthly limit), weekly (50%) and monthly (100%).
    • Each request costs the model's published token prices. That cost is then weighted by the model's listed monthly limit: a $60 model counts at face value, a $30 model counts twice as much, and a $15 model counts four times as much.
    • The "Monthly limit" for each model is how much of that model alone you could use with the full allowance. It is not a separate budget for that model.

    Verification against my workspace (Go plan)

    Applying that weighting (equivalently weight = 60 / listed monthly limit, so DeepSeek V4.1 Flash at $80 counts ×0.75), everything lines up to the percent:

    Window	face value	weighted	limit	what the console/API showed
    Monthly (since subscription)	$7.10	$24.56	$60	40%
    Weekly (from Mon 00:00Z)	$3.18	$11.85	$30	40%
    The 5h window that blocked me (1st)	$3.35	$12.28	$12	rate-limited
    The 5h window that blocked me (2nd)	$3.18	$11.85	$12	rate-limited

    Qwen3.8 Max alone: $4.44 face value → $17.78 weighted (×4). So "$4 of usage" behaves like ~$18 against the $60 pool, and the $12 five-hour bucket dies after ~$3 of any $15-tier model. That is precisely what users experience as "I only used $4 and everything locked."

    Face-value budgets per window (Go plan), for planning:

    Listed monthly limit	Weight	5 hours	Weekly	Monthly
    $60 (e.g. GLM-5.3-Flash, MiniMax M3, MiMo-V2.6-Flash, LongCat-2.0)	×1	$12	$30	$60
    $80 (DeepSeek V4.1 Flash)	×0.75	$16	$40	$80
    $30 (e.g. Qwen3.8 Flash)	×2	$6	$15	$30
    $15 (e.g. Qwen3.8 Max, GLM-5.3, Kimi K3, Grok 4.7)	×4	$3	$7.50	$15

    The documentation problem

    This section of https://opencode.ai/v2/docs/console/go is misleading by construction:

    • "Each model has the following usage limits: 5-hour — 20% of the monthly limit; weekly — 50%; and monthly — 100%" reads as per-model buckets. Combined with the per-model "Monthly limit" column ($80 / $60 / $30 / $15), the natural reading is "$80 of DeepSeek V4.1 Flash plus $60 of GLM-5.3-Flash plus …". That is flat wrong: there is $60 of weighted allowance in total, and the table only tells you how much of each model would consume all of it.
    • Weighting is nowhere in the docs or console. The console shows a percentage of an unnamed pool; the CLI/API error is just Go usage limit exceeded with no scope, no model, no weight, no reset time. Reconstructing the real rule took three issues (go: exhausting one model's 5h limit locks out every Go model despite documented per-model limits #54875, Go: 5-hour usage limit blocks all models after one model hits its own limit #49014, Reaching weekly quota won't allow request to other models #52783) and support emails.
    • The weighting is counter-intuitive in direction: within the $15 tier, cheaper-per-token models (GLM-5.3, Qwen3.8 Max) burn the shared pool 4× faster per dollar than $60-tier models like GLM-5.3-Flash. The table's presentation implies the opposite.
    • Practical consequence: a single expensive burst locks the entire plan for hours even though "monthly" shows 40% left, and switching models does not help — verified live with direct curl requests to models with near-zero own usage (both returned 429 {"type":"GoUsageLimitError"} / "limitName":"5 hour").

    Suggested fixes (any subset would help)

    1. Rewrite the limits section as: one shared allowance (5h 20% / weekly 50% / monthly 100%); state the weight in the model table (×1 / ×2 / ×4 / ×0.75); rename "Monthly limit" to something like "model-alone equivalent".
    2. Surface weighted usage (pool %, and ideally per-model contribution) in the console and in /usage.
    3. Include scope, window name, weight and resetsAt in the 429 payload and in the error surfaced by the CLI (e.g. {"limitName":"5 hour","pool":"plan","resetsAt":"...","weight":4}).
    4. If the intent is genuinely per-model buckets, enforce per-model buckets instead. Either way, service and docs must agree — right now they contradict each other, which is the actual bug from a user's perspective.

    For other readers: the "free models keep working" and "Use balance" escape hatches documented on the Go page are accurate and do work while blocked.

    Related: #54875 (closed — official answer + email guidance), #49014 (closed — same pooled behavior), #43651 (docs transparency), #52894 / #53252 (show reset time).
13. Tarquinen commented on Oct 20, 2026

    

    Tarquinen

    on Oct 20, 2026

    Member

    More actions

    Thanks for the report! This is the same as #54875, so I'm closing this as a duplicate. Please see that issue for details.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
14. Tarquinen

    closed this as a duplicateof go: exhausting one model's 5h limit locks out every Go model despite documented per-model limits #54875 on Oct 20, 2026
15. starcasttech commented on Oct 27, 2026

    

    starcasttech

    on Oct 27, 2026

    More actions

    Additional weekly-limit report from a newly subscribed Go user, observed on 27 October 2026 using OpenCode 2.1.3 on Debian 13.

    At 02:47 UTC, opencode-go/qwen3.8-max stopped mid-session with HTTP 429:

    {"type":"error","error":{"type":"GoUsageLimitError","message":"Go usage limit exceeded"},"metadata":{"limitName":"weekly"}}

    Immediately afterwards opencode-go/deepseek-v4.1-flash received the same error in two separate sessions, before generating any tokens. The supplied retry time corresponds to 2 November 2026 at 00:00 UTC.

    The full recorded local CLI history shows approximately:

    Model	Recorded local cost
    DeepSeek V4.1 Flash	$1.4664
    Qwen3.8 Max	$4.0769
    Gemini 4 Argon	$2.8547
    DeepSeek V4 Pro	$0.2293
    Other paid Go models combined	$0.2560

    These are local CLI cost figures, not a verified account-wide export or confirmed opencode.allowance deductions. We are not claiming these figures prove the server meter is wrong.

    We found the support explanation reproduced in #54875: all paid models share a weighted allowance, and a listed model monthly limit is the equivalent if that model alone consumes the pool. That explains cross-model blocking in principle, but the docs still read like independent per-model budgets. The DeepSeek $80 figure caused exactly that purchasing misunderstanding here.

    Please make the shared weighting explicit before checkout, expose per-model allowance contributions and window totals, and make the CLI distinguish list-price cost from subscription-allowance consumption. We also need a concrete account-ledger reconciliation for the weekly block; the private account identifiers and timestamps have been emailed to help@anoma.ly.

    Related: #54875, #50457, #42985. No account identifiers, email addresses, credentials or raw prompts are included in this public report.