OpenCode Go: no prompt caching on deepseek-v4-flash and qwen3.8-max (glm-5.2 caches fine)

Summary

The OpenCode Go endpoint (https://opencode.ai/zen/go/v1/chat/completions) does not perform prompt caching for deepseek-v4-flash or qwen3.8-max, while glm-5.2 on the same endpoint does. Every request re-processes the full prefix from scratch, so Go sessions on DeepSeek/Qwen burn the $12/$30/$60 metered limits much faster than the Go docs' request estimates assume (those assume ~50-80k cached tokens per request).

Related: #41125 (same symptom for DeepSeek, reported earlier).

Reproduction (live, 2026-09-08, Go subscription key, x-opencode-session set consistently across calls)

Test 1 - deepseek-v4-flash, 3 byte-identical requests:

prompt_cache_miss_tokens = 96 on call 1 (full prompt re-processed). Cache never engages.

Test 2 - same pattern on other Go models:

Impact

• DeepSeek/Qwen turns on Go reprocess the whole prefix (system prompt + tools + history) every tool-loop iteration: higher latency and faster limit consumption.
• The Go pricing/docs assume caching works (per-model "Cached Read" rates and request estimates with ~70k cached tokens per request).

Expected

Repeated identical prompts should return prompt_tokens_details.cached_tokens > 0 after the first call, as glm-5.2 does on the same endpoint.

Start by tracing the OpenCode Go endpoint at https://opencode.ai/zen/go/v1/chat/completions and the model/provider handling for deepseek-v4-flash, qwen3.8-max, and glm-5.2. Compare the request and response paths for the models, then reproduce the three-call test with a consistent x-opencode-session. Done means repeated DeepSeek and Qwen requests report cached prompt tokens like glm-5.2.