Activity

1. github-actions

   assigned

   fwang

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

   

   github-actionsBot

   on Aug 28, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue doesn't fully meet our contributing guidelines.

   What needs to be fixed:

   • Required fields are empty: OpenCode version, Steps to reproduce, Operating System, and Terminal are all left as "No response" / blank.
   • This appears to be an account/billing support request (quota restoration, missing referral credit) rather than a reproducible software bug. Billing and account issues should be handled via help@anoma.ly (which you mentioned you already contacted) — GitHub issues are for software bugs and feature requests.

   Please edit this issue to address the above within 2 hours, or it will be automatically closed.

   ---

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

   • OpenCode Go quota usage inconsistency: Monthly usage percentage exceeds Weekly usage percentage with mismatched cost statistics #43023: OpenCode Go quota usage inconsistency — monthly usage percentage doesn't match actual spend
   • Go plan monthly usage percentage doesn't reconcile with actual spend or weekly percentage #43032: Go plan monthly usage percentage doesn't reconcile with actual spend or weekly percentage
   • Mismatch between USD consumption and usage percentages (OpenCode Go / DeepSeek-V4-Pro #43149: Mismatch between USD consumption and usage percentages (OpenCode Go / DeepSeek-V4-Pro)
   • Usage percentage appears to be significantly higher than actual model cost #43609: Usage percentage appears to be significantly higher than actual model cost
   • OpenCode Go 5-hour limit shows ~50% consumed after only ~$1.80 of usage (DeepSeek V4 Pro, 13.9M cache reads) #43387: OpenCode Go 5-hour limit shows ~50% consumed after only ~$1.80 of usage

   If you believe this was flagged incorrectly, please let a maintainer know.
3. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   and removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Aug 28, 2026
4. github-actions commented on Aug 28, 2026

   

   github-actionsBot

   on Aug 28, 2026 – with GitHub Actions

   Contributor

   More actions

   Thank you for updating your issue! It now includes clear steps to reproduce, specific details about the percentage discrepancy, and system information. We appreciate the effort to provide such a thorough report.
5. pengzh1 commented on Aug 28, 2026

   

   pengzh1

   on Aug 28, 2026

   More actions

   Read the code — this is the contribution column doing its (poorly-labeled) job, not a math bug.

   In packages/console/app/src/routes/workspace/[id]/go/lite-section.tsx the percentage column renders row.contributionPercent from buildLiteUsageBreakdown (packages/console/app/src/lib/lite-usage.ts): each row's share of the total window usage, allocated by quota-weighted largest-remainder so the column sums to the window's overall usage percent. It is not usage / per-model quota — the quota column is display-only context, which is exactly the misreading this table invites.

   Two ways to fix the confusion, happy to send either:

   1. Change the percentage to usage / quota per row (what every reader expects next to those two columns). Sum will no longer be 100%.
   2. Keep the contribution math, fix the label — e.g. rename the column to "share of window usage" in the i18n strings so it can't be read as per-model utilization.

   Preference? Option 1 is a small change in the same files.
6. lvchuanya commented on Aug 28, 2026

   

   lvchuanya

   on Aug 28, 2026

   Author

   More actions

   Thanks for explaining the per-row percentage column — the "contribution-to-window share" logic is now clear, and I agree the per-row label is the main misreading trap.

   But there is a more serious, separate problem this causes, and it is not just cosmetic: the monthly usage aggregate is being shown as 100%, which wrongly blocks the account with "Insufficient balance", even though the itemized breakdown only sums to $25.47.

   From my billing page (Go plan, $60/month limit):

   • 5-hour window: 0%
   • Weekly: 76.9% (~$23.07 / $30)
   • Monthly: 100% ($60 / $60) ← this is wrong

   Itemized monthly breakdown total:
   $17.8717 + $6.9153 + $0.3338 + $0.2009 + $0.1392 + $0.0093 + $0.0003 = $25.4705

   So the monthly bar claims $60 used, but actual itemized spend is $25.47 (~42.5%). The monthly limit is overstated by ~$34.5, and because the limit check reads this wrong value, the account is locked with "Insufficient balance" even though ~$34.5 of monthly quota remains.

   This matches several existing reports about usage percentages not reconciling with actual spend (#43023, #43149, #43387, #43609, #43387).

   Could you please check the monthly aggregate computation, not only the per-row label? The per-row contribution math may be "by design", but reporting the monthly total as 100% while itemized is $25.47 is a real defect that wrongly denies service. (Account/billing restoration — quota reset, missing $5 referral credit — is being handled via help@anoma.ly; this comment is to flag the underlying computation bug.)

   Workspace ID: wrk_01KZEJWH6X18Q2PGGMW3MH31W9
7. pengzh1 commented on Aug 28, 2026

   

   pengzh1

   on Aug 28, 2026

   More actions

   Confirmed — the monthly bar and the itemized table read two different aggregates, and they genuinely disagree.

   • The monthly bar and the Go quota check read a maintained counter (LiteTable.monthlyUsage vs the plan limit in Subscription.analyzeMonthlyUsage, packages/console/core/src/subscription.ts). Once it crosses the limit, status flips to rate-limited and the percent is forced to 100. The bar shows that raw counter, so "$60 used" is the counter's value, not a recomputed total.
   • The itemized table doesn't use the counter — it re-aggregates UsageTable events over the subscription-anchored month (queryLiteUsageDetails in packages/console/app/src/routes/workspace/[id]/go/lite-section.tsx, window from getMonthlyBounds).
   • The only counter writes in this repo are refund decrements (packages/console/core/src/billing.ts); usage ingestion and the month-boundary reset live server-side. So counter $60 vs events $25.47 points at the monthly counter not being reset (or accumulating beyond lite events) — a server-side data issue, not console math.

   Your weekly numbers reconciling ($23.07/$30 ≈ 76.9%) supports that: per-event accounting is fine, only the monthly counter drifts — same pattern as #43023 / #43149 / #43387 / #43609.

   Not fixable from this repo — maintainers will need to check the monthly reset for lite counters. Two side notes: "Insufficient balance" in the client maps to the balance check (billing.balance <= 0 in the zen handler), separate from the Go monthly rate-limit, so support can tell which one is actually blocking you. And I'm still happy to send the column-label fix (option 2 above) as a standalone PR if maintainers want it.
8. lvchuanya commented on Aug 28, 2026

   

   lvchuanya

   on Aug 28, 2026

   Author

   More actions

   @pengzh1 非常感谢你这么细致地读代码并定位到根因！你的分析把问题说清楚了：月度进度条读的是 LiteTable.monthlyUsage 这个服务端计数器、被强制成 100%，而明细表是实时重算原始事件得到 $25.47——两套数据源对不上，且 weekly 能对上说明只有月度计数器漂移。这下确认是服务端重置逻辑的 bug，而不是我乱用超额。

   我已经把这份诊断转给 help@anoma.ly 要求手动重置计数器并恢复权限（账户/账务问题走邮件）。再次感谢，也欢迎你发那个列名标签的 PR（option 2），至少能减少后来人误读。🙏
9. Tarquinen commented on Oct 20, 2026

   

   Tarquinen

   on Oct 20, 2026

   Member

   More actions

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

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

    closed this as a duplicateof OpenCode Go quota usage appears ~4x higher than displayed DeepSeek V4 Flash cost #42985 on Oct 20, 2026