Repository navigation
Description
Description
Description
I believe there may be a serious quota / token consumption issue in the OpenCode client when using OpenCode Go.
This does NOT appear to be simply caused by the Go plan being too small or the model being expensive.
I tested the same OpenCode Go API account with a third-party coding agent and with the OpenCode client, and the difference in quota consumption is extremely large.
What I observed
Today (2026-08-31), I used the OpenCode Go API through a third-party coding agent with:
- Model:
glm-5.3-flash - Same OpenCode Go account/API key
- Similar coding workload
- Long-running coding/agent session
I was able to use it for an entire afternoon and only consumed roughly 40% of the available quota.
However, after switching back to the OpenCode client, the remaining quota was consumed extremely quickly.
The difference is large enough that normal model pricing does not seem to explain it.
Usage shown by OpenCode Go
My usage page for 2026-08-31 shows approximately:
deepseek-v4-pro (go): $3.04glm-5.3-flash (go): $2.17qwen3.8-max (go): $1.81
Total visible cost: approximately $7.02.
At one point my quota page showed:
- 5-hour usage: 101.3%
- Weekly usage: 40.5%
- Monthly usage: 70.3%
This does not seem consistent with the visible usage cost and with my experience using the exact same Go API through another client.
I will attach screenshots of both the cost page and quota page.
Important A/B comparison
This is the most important part of the report:
Third-party client
Same OpenCode Go API key
Same Go service
Model: glm-5.3-flash
Result:
Used for an entire afternoon and consumed only about 40% of quota.
OpenCode client
Same OpenCode Go account/API service.
Result:
After switching back to OpenCode, the remaining quota dropped extremely quickly and was exhausted in a very short period of time.
Because the backend account is the same, this makes me suspect the problem may be related to how the OpenCode client manages requests rather than simply model pricing.
Possible causes
I do not know the root cause, but based on the consumption pattern it may be worth investigating:
- Prompt cache unexpectedly missing / cache hit rate dropping
- Entire long conversation context being resent as uncached input
- Auto-compaction not triggering correctly
- Context size increasing on every agent step
- Excessive retries
- Tool/subagent loops causing additional hidden model requests
- Multiple requests being generated for what appears to the user as one agent step
The consumption pattern feels increasingly aggressive as the session becomes longer.
It does not look like constant linear consumption.
A long-running session appears to become progressively more expensive until the quota drops extremely quickly.
Expected behavior
Using the same OpenCode Go API/model through OpenCode and another compatible client should not produce an order-of-magnitude difference in quota consumption for comparable workloads.
If OpenCode performs additional internal model calls, retries, compaction, subagent calls, etc., these should ideally be visible in usage statistics so users can understand why quota is being consumed.
Actual behavior
Third-party client:
Several hours of use -> approximately 40% quota consumed.
OpenCode client:
Remaining quota can disappear extremely quickly after switching back to OpenCode.
Request
Could the OpenCode team please investigate the server-side request logs for my account around 2026-08-31 and check:
- Number of model requests generated by the OpenCode client
- Input/output token counts per request
- Prompt cache hit/miss tokens
- Whether full conversation context was repeatedly resent
- Automatic retry count
- Subagent/tool-generated model calls
- Whether quota accounting matches the usage history shown to the user
If abnormal consumption is confirmed, I would also appreciate restoration/reset of the quota consumed by the abnormal requests.
I am happy to provide additional logs, timestamps, session IDs, or screenshots if needed.
Environment
OS: Windows
OpenCode Go: active subscription
Model(s): primarily glm-5.3-flash, also deepseek-v4-pro and qwen3.8-max
OpenCode version: [PLEASE FILL IN]
Third-party client used for comparison: [PLEASE FILL IN]
Timezone: UTC+8
Date observed: 2026-08-31
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
github-actions commentedon Aug 31, 2026
This issue might be a duplicate of existing issues. Please check:
Please review these issues and add any additional details that differentiate your report.
MonetteDev commentedon Aug 31, 2026
There is something weird happening, while i was sleeping and no api keys were being used, there were made some petitions with kimi and other models that i don´t use, maxing out my account.
zhengkaics commentedon Sep 26, 2026
Measured data point relevant to the client-vs-third-party comparison: at least part of the quota burn is upstream cache loss, not client behavior.
From my account (same Go key/model), per-request
cache_readcollapses to ~256 tokens on a ~590k prompt 43 seconds and 31.5 minutes after requests that had just returned ~100% hits on the same session, prefix strictly growing. Those turns are billed at the full input rate: $0.089 vs $0.002 cached (~45x per affected turn). Hit rate: 99.07% on 09-21 (274 requests) -> ~50% on 09-25/26.Also relevant: the raw-HTTP repro in #50258 — byte-identical requests from a different client, different OS, no agent involved, flap between 0% and 100% hits. So the flapping cannot be attributed to the OpenCode client's request construction.
Third-party clients may still burn less on top of this (smaller contexts, fewer turns), but cache loss alone can amplify per-turn cost by an order of magnitude on large contexts, and it hits any client against this endpoint.
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊