Bug Report: 5‑hour rolling quota incorrectly hits 100% while actual USD spend is far below limit

Description

（

I’m experiencing abnormal quota‑counting behavior with the OpenCode‑Go subscription plan.

According to my usage chart, my total real‑world spending for the day was under 5 USD. My weekly quota sits at 45% and monthly quota at 22%, both well below their hard limits. However, the 5‑hour rolling quota hit 100% and blocked further API calls. The dashboard showed a full reset would take another 1 hour and 14 minutes.

Per official documentation, OpenCode‑Go applies these limits measured in USD value within sliding time windows:

• 5‑hour rolling limit: 12 USD
• Weekly limit: 30 USD
• Monthly limit: 60 USD

There are two clear contradictions between documented rules and observed behaviour:

1. Broken 5‑hour rolling‑window calculation
   Total daily spend was less than 5 USD, far under the 12 USD 5‑hour cap, yet the rolling‑usage counter maxed out at 100% and triggered rate‑limiting.
   The counter also did not behave as a sliding window: old usage was not gradually released as time passed. Instead the quota stayed fully locked until the full waiting period completed.
2. Mismatched quota metrics across different time ranges

• Weekly usage: 45% (not exhausted)
• Monthly usage: 22% (not exhausted)
• 5‑hour rolling usage: 100% (hard‑blocked)

Weekly and monthly percentage values align reasonably with real dollar spend. Only the 5‑hour rolling counter hits the ceiling prematurely.
This strongly suggests the 5‑hour rolling counter is tracking raw token / request throughput internally, not USD‑denominated consumption as stated in the documentation.

To Reproduce

1. Activate an OpenCode‑Go subscription
2. Run long‑running Agent / MCP workflows with heavy tool calls and large output token volume; mix multiple backend models (deepseek‑v4‑flash(go), deepseek‑v4‑pro(go), kimi‑k3(go) etc.)
3. Keep actual total daily monetary consumption below 5 USD

Expected behavior

1. The 5‑hour rolling quota should calculate real USD‑equivalent consumption within the sliding 5‑hour time window.
2. Rate‑limiting should not trigger at 100% when spend remains well under the 12 USD threshold.
3. The rolling window should operate in true sliding fashion: old usage decays over time and frees up quota incrementally, instead of locking completely until full reset.

Actual behavior

• Total real‑world daily spend <5 USD, but 5‑hour rolling usage hits 100% and blocks API requests.
• Weekly and monthly quota percentages remain normal and unexhausted.
• The rolling‑usage progress bar stays locked; quota only becomes available again after waiting for the full remaining reset time, without gradual decay.

Additional context

• Subscription type: OpenCode‑Go paid subscription
• Models involved: deepseek‑v4‑flash(go), deepseek‑v4‑pro(go), kimi‑k2.6(go), kimi‑k3(go), minimax‑m3(go), qwen3.7‑plus(go)
• Screenshots attached: daily cost bar chart, 5‑hour rolling‑usage full‑cap screen, weekly/monthly usage panel
• Documentation reference: [https://opencode.ai/docs/zh](https://link.wtturl.cn/?target=https%3A%2F%2Fopencode.ai%2Fdocs%2Fzh&scene=im&aid=582478&lang=zh)‑cn/go/

This issue heavily breaks MCP / long‑agent use‑cases. Workflows with low real monetary cost get unexpectedly terminated by the 5‑hour rolling limiter, which conflicts with the advertised quota‑billing logic.

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

No repository files, tests, version, or concrete diagnostic data are named. Start by tracing the OpenCode-Go quota dashboard and 5-hour rolling rate-limit path, then compare its calculation with the documented USD threshold and sliding-window behavior. Done means usage is measured consistently and quota becomes available as older usage expires.