Go plan monthly usage percentage doesn't reconcile with actual spend or weekly percentage #43032

Activity

1. github-actions

   assigned

   MrMushrooooom

   on Aug 17, 2026
2. github-actions commented on Aug 17, 2026

   

   github-actionsBot

   on Aug 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • OpenCode Go weekly/monthly quota does not match usage history #41206: OpenCode Go weekly/monthly quota does not match usage history — reports the same mismatch between displayed quota percentages and actual tracked spend
   • Go plan: $60/month quota exhausted in 6 days while the client recorded only $14.80 of usage — cache-read billing is invisible, undocumented, and the local cost meter is misleading users #41976: Go plan quota exhausted far faster than usage history indicates — related discrepancy between dashboard figures and actual billed amounts
   • Bug Report: 5‑hour rolling quota incorrectly hits 100% while actual USD spend is far below limit #42549: 5-hour rolling quota incorrectly hits 100% while actual USD spend is far below limit — similar dashboard/quota accounting inconsistency

   If your issue is distinct from the above, please add clarifying details so maintainers can differentiate it.
3. AakashKay commented on Aug 17, 2026

   

   AakashKay

   on Aug 17, 2026

   Author

   More actions

   I do not believe this is a duplicate of the cited reports, and I would prefer to keep it open for investigation.

   The distinguishing observation is that my weekly meter reconciles exactly with the same visible spend, while the monthly meter does not:

   • Subscription age: less than 24 hours
   • Actual/visible spend: $5.70
   • Weekly: 19% of $30 = $5.70 — exact match
   • Monthly: 40% of $60 = $24.00 — does not match

   So this is not a case where all quota windows disagree with usage history. It is a first-day, window-specific inconsistency: the weekly calculation is internally consistent, while the monthly calculation is approximately 4.2× higher.

   #42549 concerns the 5-hour rolling window, which is not the behavior reported here. #41206 and #41976 may be related, but neither presents this exact weekly-correct/monthly-incorrect first-day comparison.

   Please investigate whether the monthly Go-plan meter is using a different accounting source, billing-cycle boundary, or display calculation than the weekly meter, and confirm whether the displayed 40% represents actual quota consumption. I need an accurate reading of the $60 monthly cap to plan usage without unexpected loss of inference access.
4. n-osennij commented on Aug 17, 2026

   

   n-osennij

   on Aug 17, 2026

   More actions

   +1
5. AakashKay commented on Aug 17, 2026

   

   AakashKay

   on Aug 17, 2026

   Author

   More actions

   New observed quota event

   I have now hit the 5-hour rolling usage limit (100%) even though the visible usage history is below the published $12 rolling cap.

   Current dashboard state:

   • Rolling usage: 100%, resetting in approximately 2 hours 16 minutes
   • Weekly usage: 59% of $30 = approximately $17.70
   • Monthly usage: 60% of $60 = approximately $36.00

   Visible Go usage history so far:

   • Aug 16: DeepSeek V4 Flash (Go): $1.60
   • Aug 17: DeepSeek V4 Flash (Go): $7.93
   • GPT-5.6 Luna (Go): $0.01
   • Visible total: approximately $9.54

   The 5-hour rolling bar has reached 100% even though the visible usage for today is $7.93, below the documented $12 rolling cap. Separately, the weekly and monthly percentages imply approximately $17.70 and $36.00 of consumption, respectively, which do not reconcile with the approximately $9.54 visible total.

   This is now a live service-impact issue: I am rate-limited and cannot continue inference despite the dashboard's visible usage history remaining below the documented rolling limit.

   Please investigate the account-level Go quota calculation and clarify:

   1. What exact usage is counted toward the 5-hour, weekly, and monthly windows?
   2. Whether cache reads, hidden multipliers, or another usage source are included but omitted from the usage-history cost display.
   3. Whether the current 100% rolling / 59% weekly / 60% monthly readings represent actual remaining quota.

   I can provide the screenshots of the dashboard and usage history privately if needed.

   
6. RionizSoftware commented on Aug 17, 2026

   

   RionizSoftware

   on Aug 17, 2026

   Last edited by RionizSoftware

   More actions

   So they basically offer 1/2 price last week to gather bunch of money and suddenly 30x the price , nice ! imagine 500k people bought the subscription for 5$ that's a 2,5m$

   😕React with 😕1Reacted by Aakash Kay
7. carloslucenah commented on Aug 18, 2026

   

   carloslucenah

   on Aug 18, 2026

   More actions

   Same problem here.

   Adding the numbers from my account, since the console only shows percentages and they have to be converted against the documented limits before the inconsistency is visible.

   Console (https://opencode.ai/auth), read at 2026-08-18 10:36 UTC:

   card	shown	resets in	implied window start	dollars, at the documented limit
   Continuous (5 h)	0%	5 h 0 m	2026-08-18 08:36 UTC	$0.00 – $0.12 (of $12)
   Weekly	7%	5 d 13 h	2026-08-16 23:36 UTC	$2.10 – $2.40 (of $30)
   Monthly	17%	29 d 8 h	2026-08-16 18:36 UTC	$10.20 – $10.80 (of $60)

   Window starts are derived from the reset counters; limits from https://opencode.ai/docs/go/. Ranges assume the percentage is truncated to an integer. One corroboration that the derived anchors are real: the monthly window starts 2026-08-16 18:36 UTC, and my auth.json — the moment I subscribed and saved the API key — was written at 18:55 UTC the same day. The month is counted from the subscription.

   CLI, same account, all time (opencode stats): $2.96, 88 sessions, 402 messages, 1.5M input / 85.5K output / 5.8M cache read.

   Every costed message, by hour — the entire history of the account fits in this table:

   hour (UTC+2)	cost	running total from here to now
   08-15 17:00 → 08-16 19:00	$0.0000	$2.9606
   08-16 20:00	$0.0196	$2.9606
   08-16 21:00	$2.1072	$2.9410
   08-16 22:00	$0.0813	$0.8337
   08-17 10:00	$0.1710	$0.7525
   08-17 12:00	$0.0986	$0.5815
   08-17 13:00	$0.4829	$0.4829

   Last request 2026-08-17 11:52 UTC; nothing since, which the 0% on the 5-hour card confirms. This is the only machine I have ever run OpenCode on, and there is no activity of any kind before 2026-08-15 15:08 UTC.

   Why the monthly figure can't be right. This needs no assumption about server-side pricing, and no trust in the CLI's estimates beyond their order of magnitude:

   • The monthly window contains the weekly one — both end now, the monthly starts earlier — so monthly − weekly is exactly the usage between the two window starts.
   • The console puts that difference at ≥ $7.80 ($10.20 − $2.40, taking the most favourable rounding in both directions).
   • Everything this account has ever spent is $2.96, and $2.94 of it landed in one evening that sits inside both windows.

   So the monthly card reports, as a difference between two nested windows, roughly 2.6× more than the account has spent in total. No interval of time on this account can hold it. The weekly and 5-hour cards are in the right range.

   Possible cause. The two cards become consistent if the monthly one divides by the wrong limit. For a single underlying figure X:

   • X / $30 displaying as 7% → X ∈ [$2.10, $2.40)
   • X / $12 displaying as 17% → X ∈ [$2.04, $2.16)

   Both hold at once for X ∈ [$2.10, $2.16), and the CLI's figure for that period sits right inside it: $2.1072 for the single hour that is 71% of my lifetime spend. So if the Monthly card computed its percentage against the 5-hour limit ($12) instead of the monthly limit ($60), it would print exactly the 17% I see, from the same dollars that make the weekly card print 7%. That would make it a display bug rather than over-counted usage — but from outside, with only percentages exposed, I can't tell which.

   Anyone can check the same thing on their own account:

   opencode db "select
     round(sum(case when time_created > (strftime('%s','now')-5*3600)*1000  then json_extract(data,'\$.cost') else 0 end),4) as last_5h,
     round(sum(case when time_created > (strftime('%s','now')-7*86400)*1000 then json_extract(data,'\$.cost') else 0 end),4) as last_7d,
     round(sum(case when time_created > (strftime('%s','now')-30*86400)*1000 then json_extract(data,'\$.cost') else 0 end),4) as last_30d,
     round(sum(json_extract(data,'\$.cost')),4) as all_time
   from message where json_extract(data,'\$.cost') is not null"

   Two things that would settle it from your side: show the dollar amount next to the percentage (a percentage over an undisclosed denominator can't be verified by the user, and can't be reported precisely either — this comment is reverse-engineering three integers), and document the window definitions plus whether the free models count. On my account nemotron-3-ultra-free, deepseek-v4-flash-free and big-pickle are 58% of the token volume (4.30M of 7.40M) and are priced at $0 by the CLI, so if the server bills them differently the two sides can never be reconciled.

   Environment: opencode 1.18.18 (npm, opencode-windows-x64), Windows 11 x64, provider opencode-go with API-key auth. Happy to run any query against the local DB or share the full per-model breakdown.
8. AakashKay commented on Aug 20, 2026

   

   AakashKay

   on Aug 20, 2026

   Author

   More actions

   Follow-up — 20 August

   This remains unresolved and is affecting a paid subscription. I emailed help@anoma.ly from the subscription email address on 17 August and followed up again today, but have not received an acknowledgement or account-level explanation. Other users have now corroborated the mismatch in this issue.

   Please audit the account and confirm whether the enforced rolling, weekly and monthly quotas include usage, cache accounting or multipliers that are not visible in Usage History. If allowance was consumed incorrectly, please restore or adjust it accordingly.

   I am considering cancelling the Go subscription and moving the workflow elsewhere because I cannot safely monitor or predict usage while the published dollar limits, visible history and enforced blocks disagree. A maintainer acknowledgement and expected resolution timeline would be appreciated.
9. shivam411 commented on Sep 2, 2026

   

   shivam411

   on Sep 2, 2026

   More actions

   

   The Total 50.4% is literally the sum of the individual percentage values:

   Kimi K3: 24.0%
   Grok 4.6: 18.2%
   Qwen3.8 Flash: 4.1%
   Kimi K2.7 Code: 2.8%
   DeepSeek V4 Flash Vision: 1.3%

   24 + 18.2 + 4.1 + 2.8 + 1.3 = 50.4%

   But those percentages have different denominators because each model has a different quota ($15, $30, $60, etc.). You cannot add them together to get overall monthly usage.

   The correct calculation from the displayed dollar amounts is:

   $9.4475 / $60 = 15.7458% ≈ 15.7%

   So the dashboard should show roughly 15.7%, not 50.4%.
10. thdxr commented on Oct 11, 2026

    

    thdxr

    on Oct 11, 2026

    Member

    More actions

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
11. thdxr

    closed this as not plannedon Oct 11, 2026