Skip to content

[Go] Monthly usage shows 100% at ~$24.5, far below documented $60 limit #46365

Closed as duplicate

Description

@lymons

Description

Description

I am a paid OpenCode Go subscriber ($10/month).

According to the official documentation at https://opencode.ai/docs/go/#usage-limits :

Monthly limit — $60 of usage

However, my console at https://opencode.ai/workspace

Image

shows Monthly Usage: 100% while the sum of all model usages is only about $24.53.

This is less than half of the advertised quota. I am now blocked from using Go models with Resets in 1 day 22 hours remaining, which is very disappointing as a paying user who subscribed based on the documented limits.

Evidence

Screenshot from console (Monthly Usage -> Hide details):

MODEL MONTHLY USAGE MONTHLY QUOTA %
Kimi K3 $5.0435 $15.00 32.4%
DeepSeek V4 Flash $9.0902 $30.00 29.2%
DeepSeek V4 Pro $2.4758 $15.00 15.9%
GLM 5.3 Flash $2.1632 $30.00 7%
GLM 5.3 $0.7963 $15.00 5.1%
GLM 5.2 $2.7404 $60.00 4.4%
DeepSeek V4 Flash Vision Exp $0.3187 $15.00 2%
Hy4 preview $0.5634 $30.00 1.8%
Kimi K2.7 Code $1.0374 $60.00 1.7%
MiMo V2.5 $0.3025 $60.00 0.5%
Total ~$24.53 - 100%

No single model has exceeded its individual Monthly Quota (highest is 32.4%), yet the global Monthly Usage is 100%.

  • 5-hour Usage: 79.6% (Resets in 2h 58m)
  • Weekly Usage: 71.9% (Resets in 6d 16h)
  • Monthly Usage: 100% (Resets in 1d 22h) <- Incorrect

Expected vs Actual

Expected: I should be able to use up to $60 of total monthly usage, as documented. With $24.53 used, I should have ~40.8% monthly usage and ~$35 remaining.

Actual: Blocked at ~$24.53 / 100%. The effective limit is less than 50% of what is advertised.

Impact

  1. The advertised $60 value was a key reason for subscribing. The actual usable value being ~$24 makes the subscription feel misleading.
  2. As a paying user, this breaks trust. I chose Go for its "reliable access" but was rate-limited far earlier than promised.
  3. If the quota is calculated differently (e.g., weighted model multiplier), the documentation does not explain it and is therefore inaccurate.

Request

  1. Please clarify how Monthly Usage % is actually calculated. Is it a bug or is the $60 limit not a simple sum?
  2. If it is a bug, please fix the calculation and restore the correct quota.
  3. If it is by design, please update the docs at https://opencode.ai/docs/go/#usage-limits to transparently reflect the actual limits, and consider compensation/extension for affected Go subscribers.

Thank you for looking into this.

Environment:

  • Plan: OpenCode Go ($10/month)

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Activity

  1. github-actions commented on Aug 31, 2026

    @github-actions
    Contributor

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

    If your issue is the same as one of these, please add a reaction or comment there instead so the team can track it in one place.

  2. fdl-dev12 commented on Sep 3, 2026

    @fdl-dev12

    I have the same issue. Opencode’s misleading advertising is really frustrating, and there’s no customer support channel either. It’s pretty disappointing. I’ve already switched to Cline.

  3. ggt625 commented on Sep 3, 2026

    @ggt625

    Same issue here. My monthly usage bar shows 100.1% while the sum of all model usages is only ~$27.82 — about 46% of the documented $60 monthly limit. No single model is anywhere near its own per-model quota.

    Per-model breakdown from the console (2026-09-03):

    Model Monthly usage Monthly quota Console % Actual usage÷quota
    DeepSeek V4 Flash $15.5853 $30.00 55.9% 52.0%
    GPT 5.6 Luna $1.5127 $15.00 10.9% 10.1%
    Kimi K3 $1.4075 $15.00 10.1% 9.4%
    GLM 5.2 $5.3235 $60.00 9.6% 8.9%
    GLM 5.3 Flash $2.1924 $30.00 7.9% 7.3%
    DeepSeek V4 Pro $0.2702 $15.00 2% 1.8%
    GLM 5.3 $0.2113 $15.00 1.5% 1.4%
    Hy3 $0.5679 $60.00 1% 0.9%
    MiMo V2.5 $0.4607 $60.00 0.8% 0.8%
    others ≤$0.13 each — ≤0.2% —

    Two observations:

    1. The global monthly bar appears to be the sum of the per-model percentage column: 55.9 + 10.9 + 10.1 + 9.6 + 7.9 + 2 + 1.5 + 1 + 0.8 + 0.2 + 0.2 = exactly 100.1. Those percentages have different denominators ($15 / $30 / $60 quotas), so they cannot be added together — the correct monthly figure should be $27.82 / $60 ≈ 46%.
    2. Each per-model percentage is also consistently ~8% higher than usage ÷ displayed quota (e.g. 15.5853 ÷ 30 = 52.0%, shown as 55.9%). The ~1.08x inflation applies to all of the larger rows, so something is being counted into the percentage that is not shown in the usage column.

    The 5-hour (71.5%) and weekly (65%) bars are consistent with the documented dollar limits ($8.58/$12 and ~$19.5/$30) — only the monthly bar is off.

  4. lymons commented on Sep 5, 2026

    @lymons
    Author

    Thanks for the detailed analysis

    Same issue here. My monthly usage bar shows 100.1% while the sum of all model usages is only ~$27.82 — about 46% of the documented $60 monthly limit. No single model is anywhere near its own per-model quota.

    Per-model breakdown from the console (2026-09-03):

    Model Monthly usage Monthly quota Console % Actual usage÷quota
    DeepSeek V4 Flash $15.5853 $30.00 55.9% 52.0%
    GPT 5.6 Luna $1.5127 $15.00 10.9% 10.1%
    Kimi K3 $1.4075 $15.00 10.1% 9.4%
    GLM 5.2 $5.3235 $60.00 9.6% 8.9%
    GLM 5.3 Flash $2.1924 $30.00 7.9% 7.3%
    DeepSeek V4 Pro $0.2702 $15.00 2% 1.8%
    GLM 5.3 $0.2113 $15.00 1.5% 1.4%
    Hy3 $0.5679 $60.00 1% 0.9%
    MiMo V2.5 $0.4607 $60.00 0.8% 0.8%
    others ≤$0.13 each — ≤0.2% —
    Two observations:

    1. The global monthly bar appears to be the sum of the per-model percentage column: 55.9 + 10.9 + 10.1 + 9.6 + 7.9 + 2 + 1.5 + 1 + 0.8 + 0.2 + 0.2 = exactly 100.1. Those percentages have different denominators ($15 / $30 / $60 quotas), so they cannot be added together — the correct monthly figure should be $27.82 / $60 ≈ 46%.
    2. Each per-model percentage is also consistently ~8% higher than usage ÷ displayed quota (e.g. 15.5853 ÷ 30 = 52.0%, shown as 55.9%). The ~1.08x inflation applies to all of the larger rows, so something is being counted into the percentage that is not shown in the usage column.

    The 5-hour (71.5%) and weekly (65%) bars are consistent with the documented dollar limits ($8.58/$12 and ~$19.5/$30) — only the monthly bar is off.

    Thanks for the detailed analysis !
    So I can confirm your finding #1: the global monthly bar is incorrectly calculated as the sum of per-model percentages with different denominators. It should be total $ usage / $60.
    Hope the team can fix the calculation and restore the correct quota. Thanks again for digging into this!

  5. shyrnr commented on Oct 5, 2026

    @shyrnr

    I believe the Monthly Usage % is computed as the sum of each model's usage divided by its own per-model limit, rather than total_dollars / $60.

    Data from my console (Go plan, $10/month):

    MODEL                        USAGE      QUOTA      %
    glm-5.3-flash              $15.00      $60      25.00%
    mimo-v2.6-flash             $5.57      $60       9.28%
    mimo-v2.6-pro               $4.32      $15      28.80%
    kimi-k3                     $1.42      $15       9.47%
    deepseek-v4.1-flash         $3.26      $60       5.43%
    qwen3.8-max                 $0.72      $15       4.80%
    muse-spark-1.3-contributor  $2.36      $60       3.93%
    deepseek-v4-pro             $0.26      $15       1.73%
    deepseek-v4-flash           $0.40      $30       1.33%
    gpt-5.6-luna                $0.09      $15       0.60%
                                                  --------
                                                   SUM  90.38%
    

    The dashboard shows Monthly: 91% with a total cost of $33.40.

    • 33.40 / 60 = 55.7% — what a shared pool would give
    • Sum-of-fractions = 90.38%, which matches the displayed 91% within rounding

    I also applied the same formula to the breakdown already in this thread (@lymons):

    33.62 + 30.30 + 16.51 + 7.21 + 5.31 + 4.57 + 2.12 + 1.88 + 1.73 + 0.50 = 103.75%
    

    which is consistent with the 100% displayed there (clamped at 100%). Two independent datasets fitting the same formula seems more than coincidental.

    Two questions:

    1. Is the sum-of-fractions calculation intended? If it is, then the docs are misleading — "Monthly limit — $60 of usage" at https://opencode.ai/docs/go/#usage-limits reads as a shared pool, but the effective limit is much lower.

    2. This formula means per-model limits dominate the meter disproportionately. $1 on a $15-limit model advances the monthly meter by 6.67%, while $1 on a $60-limit model advances it by 1.67% — a 4x difference for identical work. If that is by design, it is a significant cost difference that isn't documented anywhere.

    On the documentation mismatch specifically: I subscribed because of the advertised $60. As a paying customer I ended up blocked at $33.40 (91%), and I had no way to know in advance that the effective budget was roughly $35, not $60. If this is by design, I'd ask that the docs be updated to state the actual accounting, and that affected subscribers be granted a quota extension or credits for the current cycle.

    Separate issue — per-request cost is not predictable from the displayed Tokens column:

    A qwen3.8-max request showing 92 tokens was billed $0.0786. At the documented Qwen3.8 Max output rate of $6.00/1M, that implies ~13.1k output tokens not reflected in the token count shown in the logs UI. Related data points from #41206 show the same session with near-identical input sizes producing very different costs:

    474,625 input / 6,072 output -> $1.2228
    480,782 input / 2,237 output -> $0.1481
    482,809 input /   169 output -> $1.2079
    

    Because of this, there's currently no reliable way for a user to estimate quota consumption before hitting a limit. It would help if the logs UI exposed the billing breakdown (including reasoning/output tokens) used for the cost calculation.

  6. ifelse-codes commented on Oct 9, 2026

    @ifelse-codes

    I am experiencing the same issue with my paid OpenCode Go subscription.

    My dashboard evidence (October 9, 2026):

    • Plan: OpenCode Go
    • Reporting period: Last 30 days
    • Reported cost: $32.63
    • Requests: 23,654
    • Tokens: 3.692 billion
    • Monthly usage indicator: 100%
    • Weekly usage indicator: 73%
    • Credits balance: $0.00
    • Paid Go usage blocked until the monthly reset

    The official documentation lists model-specific monthly usage allowances, including $60 for several models, and specifies that weekly and monthly limits are calculated from those allowances.

    My dashboard shows $32.63 in aggregate cost, yet the monthly usage indicator is already at 100%.

    I found this issue while investigating the existing reports of incorrect global monthly quota aggregation. Could the team please investigate whether the same calculation or enforcement bug is affecting my account?

    In particular, I would appreciate confirmation of:

    1. My actual quota consumption broken down by model.
    2. Whether the global monthly limit is incorrectly calculated by summing percentages with different model-specific denominators.
    3. Whether the backend is blocking requests based on that same incorrect calculation.
    4. Whether my Go access can be restored if the limit was enforced incorrectly.

    I have attached my console screenshot showing the 30-day reporting period and the quota indicators. I can also provide a usage export with timestamps and model-level costs.

    Thank you for investigating this.

    Image
  7. Tarquinen commented on Oct 20, 2026

    @Tarquinen
    Member

    We're tracking this in #42985, so I'm closing this as a duplicate. Please follow that issue for updates.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions