Skip to content

OpenCode client appears to consume Go quota abnormally fast compared with third-party clients using the same API key/model #46374

Closed as duplicate

Description

@wyhkey

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.04
  • glm-5.3-flash (go): $2.17
  • qwen3.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:

  1. Number of model requests generated by the OpenCode client
  2. Input/output token counts per request
  3. Prompt cache hit/miss tokens
  4. Whether full conversation context was repeatedly resent
  5. Automatic retry count
  6. Subagent/tool-generated model calls
  7. 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

Image Image

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:

    Please review these issues and add any additional details that differentiate your report.

  2. MonetteDev commented on Aug 31, 2026

    @MonetteDev

    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.

    Image
  3. zhengkaics commented on Sep 26, 2026

    @zhengkaics

    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_read collapses 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.

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