Go quota accounting does not match Usage History or documented limits #41391

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.

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. Usage is 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:

• Overcharged on Go plan — weekly limit exhausted at ~$7.50 despite $30 limit #41146 — $7.52 of qwen3.8-max (Usage $15) → weekly 100%
• Mismatch between USD consumption and usage percentages (OpenCode Go / DeepSeek-V4-Pro #43149 — $3.65 of Pro (Usage $15) → monthly 24%
• Incorrect Quota in Opencode GO consumption #40031 — about $3 of Grok → rolling 100% of $12

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:

Quota is visible cost × (60 / model Usage) on the shared $12 / $30 / $60 windows. Usage $15 means the monthly cap runs out at $15 of Usage History, not $60.

What is the solution or workaround for this issue ?

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:

• Input: $0.10 / 1M tokens
• Output: $0.20 / 1M tokens
• Cached read: $0.002 / 1M tokens
• Monthly limit: $60

My dashboard currently shows approximately:

• Requests: 8,367
• Input: 25.9M
• Cached read: 1.110B
• Output: 9.4M
• Visible cost: $6.70

The quota bars show:

• 5-hour / rolling: 22%
• Weekly: 34%
• Monthly: 17%

The weekly and monthly percentages both imply about $10.20 of quota usage:

• $30 × 34% = $10.20
• $60 × 17% = $10.20

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,277
• output_tokens: 9,230,068
• reasoning_tokens: 7,558,769
• cache_read_tokens: 1,088,053,366

Could 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.

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.