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:

• #42871
• #42884

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:

1. Why did DeepSeek V4 Flash cache reads suddenly drop to 0?
2. Why did essentially identical ~530K-token requests jump from ~$0.004 to ~$0.117 each?
3. Was there a DeepSeek/OpenCode Go backend, routing, caching, or pricing change around this time?
4. Were these requests incorrectly billed as uncached input?
5. 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