Repository navigation
Go quota accounting does not match Usage History or documented limits #41391
Description
Description
OpenCode Go quota percentages do not appear to match the dollar amounts shown in Usage History. This makes it difficult to understand how much of the shared Go allowance a request consumes.
The OpenCode Go usage limits documentation states:
- 5-hour limit: $12 of usage
- Weekly limit: $30 of usage
- Monthly limit: $60 of usage
The documentation also provides estimated request counts by model, but it does not clearly explain how the model Usage values map to these shared limits.
Evidence
Issue #41146 reports approximately $7.52 of visible qwen3.8-max usage, while the dashboard showed:
- Weekly quota: 100% of the $30 limit
- Monthly quota: 50% of the $60 limit
This is consistent with the visible amount being converted to approximately $30 of quota usage, suggesting an effective multiplier close to 4x.
Issue #41206 reports approximately $11.09 of visible Go usage, while the dashboard showed:
- Weekly usage: 100%
- Monthly usage: 52%
The monthly percentage corresponds to approximately $31.20 of internal quota usage, rather than the visible $11.09.
Issue #40031 reports approximately $3 of visible Grok usage, while the session usage showed 100% of the $12 rolling limit.
These examples suggest that the visible Usage History amount may be multiplied before it is applied to the Go quota.
Main question
Could the team please confirm or correct the following interpretation?
For some models, does OpenCode Go effectively apply a 4x multiplier to the visible Usage History amount? In other words, is the model table effectively normalizing the shared monthly $60 limit to approximately $15 of visible usage for those models?
For example, if the visible Usage History for Grok 4.5 reaches $15, does that mean:
- approximately
$15is deducted from the shared$60monthly quota, leaving approximately$45for other models; or - approximately
$60is deducted from the shared quota because of a 4x model multiplier, leaving no monthly quota for other models?
The same question applies to any other model whose table value is $15.
Please provide a simple worked example or formula showing the relationship between:
- the dollar amount displayed in Usage History;
- the model's
Usagevalue in the documentation table; and - the amount deducted from the shared 5-hour, weekly, and monthly quotas.
If the 4x interpretation is intentional, the documentation should state this explicitly so users do not assume that $15 of visible usage leaves $45 of the shared $60 allowance. If it is not intentional, these reports may indicate a quota-accounting bug.
Plugins
None.
OpenCode version
OpenCode Go web dashboard/account quota; this concerns server-side accounting.
Steps to reproduce
- Subscribe to OpenCode Go and use one or more Go models.
- Open the Usage dashboard and record the dollar amount shown in Usage History.
- Compare it with the rolling, weekly, and monthly quota percentages.
- Compare the result with the published limits and model table in the Go documentation.
Screenshot and/or share link
See the account-level data and screenshots in issue #41206 and issue #41146.
Operating System
Not applicable to server-side quota calculation.
Terminal
Not applicable to server-side quota calculation.
Activity
github-actions commentedon Aug 9, 2026
Thanks for updating the issue! It now includes a clear summary, supporting evidence with references to related issues, and a well-structured set of direct questions. The issue looks good — appreciate the detailed write-up.
[-]OpenCode Go quota accounting does not match Usage History or model usage table[/-][+]Go quota accounting does not match Usage History or documented limits[/+]Zaczero commentedon Aug 18, 2026
Yes — the bars are not reading the Usage History dollars.
They read that amount multiplied by
60 / Usage, then compared to the shared $12 / $30 / $60 windows.Usageis the last column in the table at https://opencode.ai/docs/go/#usage-limits. So $15 is a 4× factor, $30 is 2×, and $60 is 1×.That answers the Grok question directly. $15 of visible Grok (or Pro, or any other $15 model) deducts the whole $60 monthly cap. It does not deduct $15 and leave $45 for everything else.
The other open reports close the same way:
One Luna-only window produced a full set of three bars from a single number: $6.38 of visible Go usage, then 100% / 42% / 21%. That is exactly 2× against $12 / $30 / $60. Worth a look only because Luna’s table value is $15, which would have been 4× — either billing treats it as $30, or the table and the meter disagree.
A sentence in the usage-limits section would settle this:
cvasani commentedon Aug 29, 2026
What is the solution or workaround for this issue ?
jhste102lab commentedon Sep 22, 2026
I have another data point that looks inconsistent with the documented quota calculation, specifically for Muse Spark 1.3 Contributor.
The current Go documentation lists Muse Spark 1.3 Contributor with:
My dashboard currently shows approximately:
The quota bars show:
The weekly and monthly percentages both imply about $10.20 of quota usage:
However, the visible Muse Spark usage is only about $6.70. That means the quota appears to be consuming roughly 1.52× the visible cost.
This seems especially unexpected given the formula discussed above in this issue: quota usage is normalized by
60 / model monthly limit. Since Muse Spark 1.3 Contributor has a documented monthly limit of $60, its expected normalization factor should be 1×, not ~1.52×.Using the documented token prices, the visible cost shown by the dashboard is also broadly consistent with the displayed token totals, so the discrepancy seems more likely to be in quota accounting than in the displayed token pricing.
For reference, my raw usage counters are:
input_tokens: 25,327,277output_tokens: 9,230,068reasoning_tokens: 7,558,769cache_read_tokens: 1,088,053,366Could the team check whether Muse Spark 1.3 Contributor currently has an incorrect internal
costMultiplier, monthly-limit value, or another quota-accounting adjustment that is not reflected in the documentation/UI?If the extra quota consumption is intentional, it would be very helpful for the dashboard to expose the effective quota cost or multiplier so users can reconcile the visible dollar usage with the rolling/weekly/monthly percentages.
Dante-dan commentedon Sep 30, 2026
I traced the current dashboard paths. Usage History sums the selected calendar month using the browser timezone, while the Go quota bars use subscription-anchored monthly bounds. The backend records each request's multiplier and adds
round(cost × multiplier)to quota usage (usage chart, Go quota window, recorded multiplier and quota update).So the $6.70 and 17%/34% figures alone do not establish a 1.52× discrepancy unless they cover the same window and model rows. Could you share the Usage History date range and browser timezone, plus the Go monthly reset date and per-model cost breakdown for that same window? A maintainer can then compare the matching raw costs with the historical recorded multipliers and quota contributions. No account identifiers or raw token data are needed.
Tarquinen commentedon Oct 20, 2026
We're tracking this in #42985, so I'm closing this as a duplicate. Please follow that issue for updates.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊