Skip to content

OpenCode Go endpoint: no prompt caching on DeepSeek (cache_hit always 0 even on repeated identical prompts) #41125

Closed as not planned

Description

@hirjoabaioan

Description

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:

"opencode-go": {
  "npm": "@ai-sdk/openai-compatible",
  "options": {
    "baseURL": "https://opencode.ai/zen/go/v1",
    "apiKey": "..."
  },
  "models": {
    "deepseek-v4-flash": {},
    "deepseek-v4-pro": {}
  }
}

OpenCode version

1.18.15

Steps to reproduce

  1. 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").
  2. Repeat the exact same request 3 times (a few seconds apart).
  3. Inspect usage in each response.

Result (all 3 identical calls):

"usage":{"prompt_tokens":101,"completion_tokens":100,"total_tokens":201,"prompt_cache_hit_tokens":0,"prompt_cache_miss_tokens":101,"prompt_tokens_details":{"cached_tokens":0}}

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.

OS / Terminal

Linux (Kubuntu) / bash + curl

Activity

  1. github-actions commented on Aug 7, 2026

    @github-actions
    Contributor

    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.

  2. csalvarado commented on Sep 9, 2026

    @csalvarado

    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.

  3. lerothias commented on Sep 11, 2026

    @lerothias

    Have the same issue 👍

  4. zhengkaics commented on Sep 26, 2026

    @zhengkaics

    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.

  5. thdxr commented on Oct 11, 2026

    @thdxr
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

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