OpenCode Go quota exhausted in ~20 minutes after DeepSeek V4 Flash cache reads suddenly dropped to 0

Description

I experienced what appears to be a severe caching/billing issue with OpenCode Go + deepseek-v4-flash on August 16, 2026.

My Go usage was around 11% used, and within approximately 20 minutes or less it reached 100%.

When I checked Usage History, I found a very clear change in billing behavior while my session context remained almost the same size.

Before the issue:

~529K–531K input tokens/request
Cost: approximately $0.0040–$0.0044 per request

Examples from my usage history:

Aug 16, 9:59 PM
Input: 528,969
Output: 230
Cost: $0.0041

Aug 16, 10:00 PM
Input: 529,263
Output: 390
Cost: $0.0043

Aug 16, 10:00 PM
Input: 529,716
Output: 144
Cost: $0.0040

Aug 16, 10:01 PM
Input: 530,924
Output: 168
Cost: $0.0041

Aug 16, 10:02 PM
Input: 531,431
Output: 622
Cost: $0.0044

Then suddenly:

Aug 16, 10:03 PM
Input: 532,116
Output: 144
Cost: $0.1172

Aug 16, 10:04 PM
Input: 532,507
Output: 294
Cost: $0.1173
Cache Read: 0

So essentially the same ~530K-token context went from costing around:

$0.004 per request

to:

$0.117 per request

That is approximately a 27x increase per request, without a meaningful increase in context size.

The Usage History tooltip explicitly shows:

Input: 532507
Cache Read: 0

After this happened, my OpenCode Go allowance was consumed extremely quickly.

Expected behavior

Repeated long-session context should continue receiving the expected DeepSeek cache treatment when the prefix/context has not materially changed.

If caching becomes unavailable, there should at minimum be protection against unexpectedly consuming nearly an entire Go allowance in minutes.

Actual behavior

Cache reads appear to have suddenly dropped to zero during an existing long-running DeepSeek V4 Flash session.

The same ~530K-token context then began being charged as fresh input repeatedly, increasing individual request cost by roughly 27x.

This caused my Go usage to go from approximately 11% used to 100% used in around 20 minutes or less.

Impact

This effectively consumed almost my entire available Go quota during one short period of normal usage.

I did not intentionally create a workload that was approximately 27x more expensive. The cost increase corresponds directly with the apparent loss of cache reads.

I have attached a screenshot of the Usage History showing the transition.

There are also other reports today involving unusually rapid Go quota consumption, including:

My case specifically appears related to DeepSeek V4 Flash caching / cache accounting, rather than simply normal heavy usage.

Request

Could the OpenCode team please investigate:

Why did DeepSeek V4 Flash cache reads suddenly drop to 0?
Why did essentially identical ~530K-token requests jump from ~$0.004 to ~$0.117 each?
Was there a DeepSeek/OpenCode Go backend, routing, caching, or pricing change around this time?
Were these requests incorrectly billed as uncached input?
Can the Go quota consumed by this apparent cache failure be reviewed and restored?

Given that the usage increase occurred directly after the cache behavior changed, I would appreciate restoration of the Go quota consumed by the abnormal uncached requests if the investigation confirms this was a service-side caching/accounting problem.

Screenshot

I will attach the Usage History screenshot showing:

~531K input → ~$0.004/request
↓
cache behavior changes
↓
~532K input → ~$0.117/request
Cache Read: 0

Environment

Plan: OpenCode Go
Model: deepseek-v4-flash
Date: August 16, 2026
OS: Windows
Issue duration: approximately 20 minutes or less
Usage impact: approximately 11% used → 100% used

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

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

OpenCode Go endpoint: no prompt caching on DeepSeek (cache_hit always 0 even on repeated identical prompts) #41125: OpenCode Go endpoint: no prompt caching on DeepSeek (cache_hit always 0 even on repeated identical prompts) — same symptom of cache reads dropping to 0 for DeepSeek on the Go backend
Go plan: $60/month quota exhausted in 6 days while the client recorded only $14.80 of usage — cache-read billing is invisible, undocumented, and the local cost meter is misleading users #41976: Go plan quota exhausted in 6 days while local cost meter showed only $14.80 — cache-read billing invisibility causing unexpected quota consumption
GLM-5.1 prompt cache randomly drops to 0 on opencode-go, while DeepSeek V4 Flash works reliably #31348: GLM-5.1 prompt cache randomly drops to 0 on opencode-go — same pattern of cache suddenly dropping mid-session
[OpenCode Go] GLM-5.2 prompt cache randomly drops to ~500 tokens on opencode-go (opencode.ai/zen/go) #33998: [OpenCode Go] GLM-5.2 prompt cache randomly drops to ~500 tokens on opencode-go — intermittent cache drop behavior on the Go backend

Maybe I have the similar problem: #43009

I have the similar problem too #43218

The $0.004 → $0.117 jump is the published Flash off-peak table on the same ~530k tokens, not a bad meter.

https://opencode.ai/docs/go/#usage-limits

	rate	532k prompt
cache read	$0.007 / 1M	531k × $0.007 / 1M ≈ $0.0037 → the $0.004 rows
uncached input	$0.22 / 1M	532,116 × $0.22 / 1M = $0.11707 → the $0.117 rows

Usage History is reporting a real miss: that whole prefix was billed as uncached input. The prompt only grew a few hundred tokens per turn — a normal append — so a prefix-stable cache should have kept hitting.

Two misses in a row (10:03 and 10:04) also rules out a one-shot eviction. DeepSeek writes the prefix at the end of a request; the next request on the same backend should hit.

https://api-docs.deepseek.com/guides/kv_cache

Staying at cache read 0 means either the next request left that cache domain, or the hit was not the field Go reads.

1. The gateway can leave the cache domain without the client changing anything

Session is only pinned when the model has stickyProvider set. Otherwise the tracker is a no-op:

opencode/packages/console/app/src/routes/zen/util/stickyProviderTracker.ts

Lines 4 to 10 in 9e22c40

    
           export function createStickyTracker( 
        
             modelId: string, 
        
             stickyProvider: "strict" | "prefer" | undefined, 
        
             stickyId: string, 
        
           ) { 
        
             if (!stickyProvider) return 
        
             if (!stickyId) return

Provider selection then hashes the last four characters of the session id over the current provider pool. The pool is filtered live by TPM, TPS, and budget — and a 530k miss itself pushes TPM, which can shrink the pool on the very next turn:

opencode/packages/console/app/src/routes/zen/util/handler.ts

Lines 643 to 653 in 9e22c40

    
           // Use the last 4 characters of session ID to select a provider 
        
           let h = 0 
        
           const l = stickyId.length 
        
           for (let i = l - 4; i < l; i++) { 
        
             h = (h * 31 + stickyId.charCodeAt(i)) | 0 // 32-bit int 
        
           } 
        
           const index = (h >>> 0) % providers.length // make unsigned + range 0..length-1 
        
           const provider = providers[index || 0] ?? fallbackProvider 
        
           // sticky provider does not exist => use selected provider 
        
           if (!stickyProviderId) return provider

#35402 already showed this on GLM-5.2 with byte-identical requests: warm, then a full miss, then warm again, with the usage JSON shape flipping between two upstreams. Flash was the stable control in #31348. This report is the same cliff on Flash.

2. Or the hit is in a field Go does not read

Go’s OpenAI-compatible mapper only accepts cached_tokens / prompt_tokens_details.cached_tokens. It never reads DeepSeek’s prompt_cache_hit_tokens. An upstream that only emits the native field would look like cache read 0 and bill as input even if the prefix hit:

opencode/packages/console/app/src/routes/zen/util/provider/openai-compatible.ts

Lines 61 to 70 in 9e22c40

    
           normalizeUsage: (usage: Usage) => { 
        
             let inputTokens = usage.prompt_tokens ?? 0 
        
             const outputTokens = usage.completion_tokens ?? 0 
        
             const reasoningTokens = usage.completion_tokens_details?.reasoning_tokens ?? undefined 
        
             let cacheReadTokens = usage.cached_tokens ?? usage.prompt_tokens_details?.cached_tokens ?? undefined 
        
             const cacheWriteTokens = usage.prompt_tokens_details?.cache_creation_input_tokens ?? undefined 
        
             if (adjustCacheUsage && !cacheReadTokens) { 
        
               cacheReadTokens = Math.floor(inputTokens * 0.9) 
        
             }

That is a different bug from a hop, and it is easy to tell apart from the same two usage rows.

How to tell them apart

Look at provider (or x-opencode-endpoint-id) on the 10:02 vs 10:03 rows:

It changes → real hop. Enable stickyProvider: "prefer" for deepseek-v4-flash, the same fix Zen: byte-identical requests to glm-5.2 intermittently reroute to a cold-cache provider — please enable stickyProvider for multi-sourced models #35402 asked for on GLM.
It stays put, and the raw upstream usage has prompt_cache_hit_tokens > 0 → read that field in normalizeUsage.
It stays put and the upstream also reports 0 → a real prefix miss on one backend (tools/system first-byte change, or DeepSeek best-effort). That needs a prefix hash, as in GLM-5.1 prompt cache randomly drops to 0 on opencode-go, while DeepSeek V4 Flash works reliably #31348.

The $0.117 is the correct uncached list price. The product bug is either losing the warm cache domain or dropping the hit field. Quota from those miss rows is a support restore once one of the first two checks lands.

Same cache-drop pattern on Aug 19 (OpenCode Go + deepseek-v4-flash)

I'm seeing the exact same behavior described here. Same ~290-314K input context, same session (q5Pd5DYc), but a subset of requests jumped ~20x in cost while the rest stayed at ~$0.0025-0.004.

Usage history (Aug 19, 2026):

Time	Model	Input	Output	Cost	Cache status
8:31 AM	deepseek-v4-flash	314,141	1,578	$0.0702	miss (0)
8:12 AM	deepseek-v4-flash	312,510	1,538	$0.0037	hit
8:11 AM	deepseek-v4-flash	310,479	534	$0.0026	hit
8:11 AM	deepseek-v4-flash	310,038	404	$0.0026	hit
8:11 AM	deepseek-v4-flash	309,647	359	$0.0025	hit
8:11 AM	deepseek-v4-flash	309,252	324	$0.0026	hit
8:11 AM	deepseek-v4-flash	308,435	290	$0.0026	hit
8:10 AM	deepseek-v4-flash	307,269	456	$0.0027	hit
8:10 AM	deepseek-v4-flash	306,412	805	$0.0032	hit
8:03 AM	deepseek-v4-flash	305,376	1,019	$0.0030	hit
8:02 AM	deepseek-v4-flash	304,612	684	$0.0675	miss (0)
7:54 AM	deepseek-v4-flash	303,739	606	$0.0029	hit
7:54 AM	deepseek-v4-flash	301,992	1,733	$0.0034	hit
7:54 AM	deepseek-v4-flash	301,494	245	$0.0024	hit
7:53 AM	deepseek-v4-flash	301,190	288	$0.0025	hit
7:53 AM	deepseek-v4-flash	300,162	246	$0.0023	hit
7:53 AM	deepseek-v4-flash	299,888	108	$0.0027	hit
7:53 AM	deepseek-v4-flash	297,634	2,239	$0.0039	hit
7:52 AM	deepseek-v4-flash	296,203	647	$0.0028	hit
7:52 AM	deepseek-v4-flash	294,935	339	$0.0651	miss (0)
7:51 AM	deepseek-v4-flash	294,717	106	$0.0023	hit
7:51 AM	deepseek-v4-flash	294,320	383	$0.0026	hit
7:51 AM	deepseek-v4-flash	293,189	1,117	$0.0031	hit
7:51 AM	deepseek-v4-flash	291,982	1,193	$0.0031	hit
7:50 AM	deepseek-v4-flash	290,954	438	$0.0024	hit
7:50 AM	deepseek-v4-flash	290,761	109	$0.0029	hit
7:50 AM	deepseek-v4-flash	287,444	3,302	$0.0043	hit
7:48 AM	deepseek-v4-flash	286,803	99	$0.0023	hit
7:48 AM	deepseek-v4-flash	285,925	863	$0.0028	hit
7:47 AM	deepseek-v4-flash	285,035	503	$0.0630	miss (0)

Key observations:

The 4 expensive requests (285K/294K/304K/314K input) match exactly the cost of billing the ENTIRE input as fresh (uncached) at Go's internal rate (~$0.22/M input + $0.66/M output): e.g. 314,141×0.22 + 1,578×0.66 ≈ $0.0702. So Cache Read = 0 on those.
The ~26 requests in between, with nearly identical input sizes, were ~$0.0023-0.0043 → cache hits (only ~6-8K new tokens charged).
Same session, same ~300K context → cost fluctuates 20x depending on cache. This is the same pattern as OpenCode Go quota exhausted in ~20 minutes after DeepSeek V4 Flash cache reads suddenly dropped to 0 #42935.
No session/login change involved.

Impact: ~25% of my Go usage was consumed by these 4 cache-miss requests alone during ~45 minutes of normal use.

Requests: Could the billing/backend investigation also cover whether these intermittent cache drops (and resulting 20x charges) should be restored to the Go quota?

Follow-up: still happening — now at ~370K context, 1 in 10 requests is a full cache miss

Update from the same session (q5Pd5DYc), Aug 19, ~9:06–9:08 AM. Context has grown to ~370K and the cache-drop pattern continues — in this batch, 1 of 10 requests was a full cache miss costing ~25–30x the cached ones:

Time	Model	Input	Output	Cost	Cache status
9:08 AM	deepseek-v4-flash	370,981	98	$0.0028	hit
9:08 AM	deepseek-v4-flash	370,670	296	$0.0029	hit
9:08 AM	deepseek-v4-flash	370,272	333	$0.0817	miss (0)
9:07 AM	deepseek-v4-flash	369,484	710	$0.0031	hit
9:07 AM	deepseek-v4-flash	369,162	98	$0.0029	hit
9:07 AM	deepseek-v4-flash	368,177	970	$0.0033	hit
9:06 AM	deepseek-v4-flash	367,982	98	$0.0028	hit
9:06 AM	deepseek-v4-flash	367,123	844	$0.0032	hit
9:06 AM	deepseek-v4-flash	366,899	110	$0.0029	hit
9:06 AM	deepseek-v4-flash	366,049	835	$0.0032	hit

Verification of the miss: 370,272 × $0.22/M + 333 × $0.66/M = $0.0817 — the entire input was billed as fresh (uncached). The 9 hit rows only charged ~7–8K new tokens each.

Why this is now unmanageable:

The miss cost scales linearly with session size: ~$0.065 at 285K context → ~$0.082 at 370K. Every cache expiry (~pause/5-min TTL) produces a full-priced request.
Long coding sessions keep growing, so each cache miss keeps getting more expensive, and there's nothing I can do client-side to prevent it.
It's draining my Go quota without completing my tasks — I keep paying full input price for context that should have been cached.

Escalation: If this continues I will have to switch to another provider and cancel OpenCode Go until it's fixed. Please treat both the quota restoration and the cache-stability fix as urgent.

Stopping Go usage until this is fixed — cache miss at ~390K context, Aug 19, 9:20 AM

Same session (q5Pd5DYc), ~40 min after my last update. Context now ~390K and the pattern persists: 1 of 12 requests was a full cache miss, this time $0.0868 vs ~$0.003 for the rest.

Time	Model	Input	Output	Cost	Cache status
9:21 AM	deepseek-v4-flash	390,904	191	$0.0029	hit
9:21 AM	deepseek-v4-flash	390,750	96	$0.0029	hit
9:21 AM	deepseek-v4-flash	390,277	458	$0.0035	hit
9:20 AM	deepseek-v4-flash	388,200	2,063	$0.0868	miss (0)
9:19 AM	deepseek-v4-flash	387,435	557	$0.0032	hit
9:18 AM	deepseek-v4-flash	386,965	125	$0.0029	hit
9:18 AM	deepseek-v4-flash	386,566	249	$0.0033	hit
9:18 AM	deepseek-v4-flash	384,705	1,846	$0.0040	hit
9:14 AM	deepseek-v4-flash	384,363	280	$0.0030	hit
9:14 AM	deepseek-v4-flash	383,790	420	$0.0032	hit
9:14 AM	deepseek-v4-flash	382,529	219	$0.0029	hit
9:14 AM	deepseek-v4-flash	382,307	121	$0.0034	hit

Verification: 388,200 × $0.22/M + 2,063 × $0.66/M = $0.0868 — entire input billed as fresh again.

Escalation — I'm stopping Go usage until there's a fix. The miss cost keeps climbing with session size (~$0.063 at 285K → $0.082 at 370K → $0.087 at 390K) and it happens every few minutes of normal work, draining my quota mid-task. I can't mitigate this client-side. I'll pause using OpenCode Go (and pending a resolution, cancel the subscription) until the cache-drop issue and quota restoration are addressed.

Additional report: DeepSeek V4 Flash via Codex CLI → local OpenCode Go proxy (Responses API)

Same family of symptoms as this issue / #41125 / #32911, with a control that makes the cache miss look model-specific on the Go path.

Setup

Client: Codex CLI (wire_api = responses) pointed at a local opencode-go-proxy on http://127.0.0.1:8787/v1
Provider config: model_provider = "opencode-go", default model in go.config.toml was deepseek-v4-flash with model_reasoning_effort = high
Workload: multi-agent coding (Symphony), several concurrent sessions

Local metering (proxy usage-events.jsonl)

Window	Model	OK (200)	Non-OK (mostly 429)	Sum input tokens (OK)	Avg input / OK	Cached fields in meter
All logged	`deepseek-v4-flash`	4,726	~15,924	~825M	~175k	none / 0
2026-09-06 only	`deepseek-v4-flash`	1,628	~12,191	~294M	~181k	none / 0
Peak minute 2026-09-06T18:15Z	flash	64 req/min	—	—	—	—

Input size distribution on 2026-09-06 OK calls: p50 ~181k, p95 ~236k, almost every call >100k. After weekly quota tripped, we saw a long 429 retry storm (no token fields on those rows).

Dashboard at time of report: DeepSeek V4 Flash ~US$15.64 / US$30 monthly (~52%), weekly Go usage ~100%.

Control on the same proxy / same Codex path

muse-spark-1.3-contributor through the same opencode-go provider shows Codex token_count with ~98% cached_input_tokens (hundreds of millions cached vs input).
Early proxy structured logs for DeepSeek show shapes like "cache": {"hit": 0, "miss": 99, "ratio": 0.0} and input_tokens_details.cached_tokens: 0.
Same proxy has logged Muse/other models with high cache.hit / cached_tokens on later turns.

So this does not look like “Codex never caches anything” — Muse on the same wire caches hard; Flash metering stays at full uncached input.

Why this burns Go so fast

~180k uncached input per agent turn × many concurrent Symphony agents × tool-loop turns.
Possible Go-side cache domain hop / missing sticky provider / usage-field mapping issues already discussed in this thread (DeepSeek prompt_cache_hit_tokens vs OpenAI-shaped cached_tokens).
Client multiplies the miss: each new Codex exec session re-sends a large system/tools prefix; if the gateway does not keep a warm prefix cache, every turn pays list input.

Asks

Can you confirm whether deepseek-v4-flash on Go currently has stickyProvider (or equivalent) so concurrent agent sessions do not hop cold backends?
Does Go’s usage normalizer map DeepSeek native prompt_cache_hit_tokens when the Responses/OpenAI-compatible path is used by third-party clients (Codex), not only the OpenCode TUI?
If our Sep 6 burn was mostly cache-miss billing on Flash, please advise on quota restoration for the Go plan.

Happy to share redacted proxy log slices / request_ids if useful. Account email on Go: contact via GitHub leandrojo.

Related: #41125, #32911, #33473, #31348 / sticky discussion in #35402.

Reproduced again on 09-25/26 — same signature as your 08-16 episode, ~590k context, same session, prefix growing monotonically:

gap since previous request	cache_read	billed
43 s (previous request had ~100% hit)	256	$0.0889
18 s	589,312	$0.0028
7.4 h idle (cold start)	384	$0.0892
31.5 min (previous request had ~100% hit)	256	$0.0899

Token hit rate on my traffic: 99.07% on 09-21 (274 requests) -> ~50% on 09-25/26.

A miss on a 590k prompt costs ~45x a hit ($0.089 vs $0.002), billed at exactly the full input rate while the catalog still lists cache read at $0.003/M — this is exactly what your usage history showed: cache_read collapsing to ~0 while quota burns at full-context speed.

Consolidated evidence (this table, the byte-identical raw-HTTP flap, source analysis of the affinity headers, and the billing math) is in #50258 — worth treating these as one gateway-side issue rather than separate reports.

Happened to me today as well. Seems like opencode constantly switching between deepseek-flash and deepseek-v4.1-flash, whenever it routes to deepseek-v4.1-flash, the cache hit is 0

detail page：

Additional report for deepseek-v4.1-flash via OpenCode Go, observed on October 7-8, 2026.

Client: OmO Native (Senpi-based), Linux, provider opencode-go. These are client-recorded usage values, not independently verified dashboard charges. Times below are KST (UTC+9).

A long-running session initially had nearly full cache hits, then repeatedly alternated between warm requests and very expensive misses:

Time (Oct 7 KST)	Uncached input	Cache read	Total tokens reported
14:19:47	1,750	705,536	713,498
14:20:08	588,535	53,120	642,271
14:20:22	884	641,536	644,149
14:48:22	707,182	0	708,049
14:48:35	879	707,712	709,592
14:49:07	658,838	49,792	710,125
15:02:54	658,923	49,792	709,158
15:03:01	693	708,736	709,833

No client model switch was recorded during this interval. Some misses followed warm requests by only seconds. The initial token-count drop is unexplained; I have not captured request-body prefix hashes, so I cannot exclude client-side prompt changes or claim byte-identical requests.

Token-weighted cache-read ratios across local OmO + OpenCode records were approximately 96% on Oct 6, 73% on Oct 7, and 55% on Oct 8 through 11:37 KST. On Oct 8, 09:00-10:00 KST (00:00-01:00 UTC), the affected OmO session made 52 calls: 15,403,362 uncached input tokens and 22,420,352 cache-read tokens. The client's catalog-based cost estimate was $2.41 for that hour. I observed approximately $10 of Go usage being consumed around 09:00-10:00 KST and exhausted my weekly allowance, but I have not yet reconciled workspace-wide traffic, model-specific weighting, or dashboard rates against those local estimates. Other clients also use this workspace, so this is not proof of a metering bug.

Could the team please clarify:

Is cache-domain/provider affinity enabled for deepseek-v4.1-flash, including third-party clients? Which session headers or cache keys should those clients send?
Could upstream routing/model changes or cache-usage normalization explain this warm/miss alternation? In particular, is DeepSeek's native prompt_cache_hit_tokens accounted for on every upstream?
What current Go prices, quota weighting, and workspace-wide usage view should I use to reconcile local token estimates with quota consumption?
How can I privately submit request/account details for investigation, and can abnormal quota consumption be reviewed for restoration if a service-side fault is confirmed?

I have lowered the client's compaction threshold as a mitigation, but that does not establish the root cause. Related: #42985 and #50258.

Thanks for the detailed request history. The sudden full-price re-reads came from upstream routing at the time: requests landing on a deployment without your cached prefix are billed as uncached input. Go routing and prompt caching have changed a lot since August, so this is most likely resolved. Closing because there's been no activity for a while. If you still see cache reads dropping to 0 mid-session, comment here with the time, session ID and request IDs from the console logs and we'll reopen it. If it used up your allowance, email [email protected] with your workspace ID.

Navigation Menu

Repository navigation

OpenCode Go quota exhausted in ~20 minutes after DeepSeek V4 Flash cache reads suddenly dropped to 0 #42935

Description

Expected behavior

Actual behavior

Impact

Request

Screenshot

Environment

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

1. The gateway can leave the cache domain without the client changing anything

2. Or the hit is in a field Go does not read

How to tell them apart

Same cache-drop pattern on Aug 19 (OpenCode Go + deepseek-v4-flash)

Follow-up: still happening — now at ~370K context, 1 in 10 requests is a full cache miss

Stopping Go usage until this is fixed — cache miss at ~390K context, Aug 19, 9:20 AM

Additional report: DeepSeek V4 Flash via Codex CLI → local OpenCode Go proxy (Responses API)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	export function createStickyTracker(
	modelId: string,
	stickyProvider: "strict" \| "prefer" \| undefined,
	stickyId: string,
	) {
	if (!stickyProvider) return
	if (!stickyId) return

	// Use the last 4 characters of session ID to select a provider
	let h = 0
	const l = stickyId.length
	for (let i = l - 4; i < l; i++) {
	h = (h * 31 + stickyId.charCodeAt(i)) \| 0 // 32-bit int
	}
	const index = (h >>> 0) % providers.length // make unsigned + range 0..length-1
	const provider = providers[index \|\| 0] ?? fallbackProvider

	// sticky provider does not exist => use selected provider
	if (!stickyProviderId) return provider

	normalizeUsage: (usage: Usage) => {
	let inputTokens = usage.prompt_tokens ?? 0
	const outputTokens = usage.completion_tokens ?? 0
	const reasoningTokens = usage.completion_tokens_details?.reasoning_tokens ?? undefined
	let cacheReadTokens = usage.cached_tokens ?? usage.prompt_tokens_details?.cached_tokens ?? undefined
	const cacheWriteTokens = usage.prompt_tokens_details?.cache_creation_input_tokens ?? undefined

	if (adjustCacheUsage && !cacheReadTokens) {
	cacheReadTokens = Math.floor(inputTokens * 0.9)
	}

OpenCode Go quota exhausted in ~20 minutes after DeepSeek V4 Flash cache reads suddenly dropped to 0 #42935

Description

Description

Expected behavior

Actual behavior

Impact

Request

Screenshot

Environment

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Aug 16, 2026

sunxfancy commented on Aug 17, 2026

ZH1K1NG commented on Aug 18, 2026

Zaczero commented on Aug 18, 2026

1. The gateway can leave the cache domain without the client changing anything

2. Or the hit is in a field Go does not read

How to tell them apart

japr26 commented on Aug 19, 2026

Same cache-drop pattern on Aug 19 (OpenCode Go + deepseek-v4-flash)

japr26 commented on Aug 19, 2026

Follow-up: still happening — now at ~370K context, 1 in 10 requests is a full cache miss

japr26 commented on Aug 19, 2026

Stopping Go usage until this is fixed — cache miss at ~390K context, Aug 19, 9:20 AM

leandrojo commented on Sep 7, 2026

Additional report: DeepSeek V4 Flash via Codex CLI → local OpenCode Go proxy (Responses API)

zhengkaics commented on Sep 26, 2026

kevineh commented on Oct 1, 2026

jaehyun-ko commented on Oct 8, 2026

neriousy commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions