You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OpenCode Go endpoint: no prompt caching on DeepSeek (cache_hit always 0 even on repeated identical prompts) #41125
The OpenCode Go subscription endpoint (https://opencode.ai/zen/go/v1/chat/completions) does not perform prompt caching on DeepSeek models. Every request returns prompt_cache_hit_tokens: 0, even when the exact same prompt is sent repeatedly, so the full prompt is re-processed from scratch on each call. This adds significant per-turn latency on real coding sessions, where large instruction files (AGENTS.md/CLAUDE.md/CONVENTIONS.md + memory) are re-sent on every tool loop.
The OpenAI-compatible /v1 API exposes prompt_cache_hit_tokens / prompt_cache_miss_tokens and prompt_tokens_details.cached_tokens in the usage object, but cache is never hit.
Plugins
None (default). Custom provider block in opencode.json pointing at the Go subscription:
Send POST https://opencode.ai/zen/go/v1/chat/completions with model deepseek-v4-flash and a fixed prompt (e.g. "Explain in 2 lines what a PHP email-validation function does").
Repeat the exact same request 3 times (a few seconds apart).
Expected: on call #2 and #3 the prefix should be cache-hit (DeepSeek's API does support automatic prompt caching, with hits reported via prompt_tokens_details.cached_tokens). Instead cache is never engaged.
Impact: full prompt re-processing on every turn → higher latency and token cost on long coding sessions, and no benefit from DeepSeek's automatic prefix caching.
These issues describe related or overlapping problems with prompt cache tokens not being correctly reported/utilized on DeepSeek and OpenAI-compatible providers. Please review them and consider whether your issue is already tracked there.
Reproduced live today (2026-09-08) against https://opencode.ai/zen/go/v1/chat/completions with a Go subscription key, x-opencode-session set consistently across calls.
Test 1 - deepseek-v4-flash, 3 byte-identical requests (same session header):
call
prompt_cache_hit_tokens
prompt_tokens_details.cached_tokens
latency
1
0
0
2.4s
2
(absent)
0
1.1s
3
(absent)
0
2.1s
prompt_cache_miss_tokens = 96 on call 1 (full prompt re-processed). Cache never engages.
Test 2 - same pattern on other Go models:
model
call 1 cached
call 2 cached
deepseek-v4-flash
0
0
qwen3.8-max
0
0
glm-5.2
10
25
So the Go endpoint does cache for some models (glm-5.2) but not for deepseek-v4-flash or qwen3.8-max. This is server-side on the Go gateway - nothing client-side (session header, model id, repeated identical prompts) changes the outcome. Practical impact: DeepSeek turns on Go reprocess the full prefix (system + tools + history) every turn, so latency stays high and the $12/$30/$60 metered limits burn much faster than the "cached" request estimates in the Go docs assume.
Timeline data point on this exact endpoint (/zen/go/v1), measured from my account:
09-21: healthy — 99.07% token hit rate over 274 DeepSeek requests (so the "always 0" state from August did get fixed at some point)
09-25/26: broken again, intermittently — 49.9%, including full ~590k re-reads 43 s and 31.5 min after requests that had just returned ~100% hits on the same session with a strictly growing prefix
So this endpoint has gone (at least) disabled -> working -> flapping. That fits replica pools with independent or rapidly-evicting caches better than a deterministic "caching not implemented" bug — byte-identical requests also flap per the raw-HTTP repro in #50258.
Per-request table and the billing impact (each 590k miss billed $0.089 vs $0.002 cached) are in #50258 — suggest consolidating there.
Activity
github-actions commentedon Aug 7, 2026
This issue might be a duplicate of existing issues. Please check:
These issues describe related or overlapping problems with prompt cache tokens not being correctly reported/utilized on DeepSeek and OpenAI-compatible providers. Please review them and consider whether your issue is already tracked there.
csalvarado commentedon Sep 9, 2026
Reproduced live today (2026-09-08) against
https://opencode.ai/zen/go/v1/chat/completionswith a Go subscription key,x-opencode-sessionset consistently across calls.Test 1 - deepseek-v4-flash, 3 byte-identical requests (same session header):
prompt_cache_miss_tokens= 96 on call 1 (full prompt re-processed). Cache never engages.Test 2 - same pattern on other Go models:
So the Go endpoint does cache for some models (glm-5.2) but not for deepseek-v4-flash or qwen3.8-max. This is server-side on the Go gateway - nothing client-side (session header, model id, repeated identical prompts) changes the outcome. Practical impact: DeepSeek turns on Go reprocess the full prefix (system + tools + history) every turn, so latency stays high and the $12/$30/$60 metered limits burn much faster than the "cached" request estimates in the Go docs assume.
lerothias commentedon Sep 11, 2026
Have the same issue 👍
zhengkaics commentedon Sep 26, 2026
Timeline data point on this exact endpoint (
/zen/go/v1), measured from my account:So this endpoint has gone (at least) disabled -> working -> flapping. That fits replica pools with independent or rapidly-evicting caches better than a deterministic "caching not implemented" bug — byte-identical requests also flap per the raw-HTTP repro in #50258.
Per-request table and the billing impact (each 590k miss billed $0.089 vs $0.002 cached) are in #50258 — suggest consolidating there.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊