Repository navigation
Muse Spark 1.2 intermittent prompt cache miss on Zen Go #45867
Description
Description
We observed an unexpected prompt cache miss on the Zen Go Responses API.
Model:
muse-spark-1.2-contributor
Timestamp:
2026-08-28 06:47:05.310 GMT
2026-08-28 14:47:05.310 Asia/Shanghai
x-opencode-session / prompt_cache_key:
137:web_chat:f745dfe9-23f6-4ab9-bb2c-eb95e49d8de7
Upstream response ID:
resp_6a912ee9cd9eadb49d7543a0
Client request ID:
07bdc822-35df-4eb2-bab9-e19497ee96a1
Cache sequence:
- Previous request: 22,756 prompt tokens, 22,193 cached tokens
- Affected request: 23,167 prompt tokens, 0 cached tokens
- Next request: 30,682 prompt tokens, 23,153 cached tokens
The affected request preserved the previous request byte-identically
and only appended two input items. Tool definitions and model parameters
were unchanged.
Another independent session using the same model also changed from
26,161 cached tokens to 0 at 2026-08-28 06:47:13 GMT.
Could you check:
- Which upstream provider and route handled these requests?
- Whether the provider changed between the previous, affected, and next requests?
- Whether stickyProvider is enabled for muse-spark-1.2-contributor?
- Whether x-opencode-session was received and used as the sticky routing key?
- Whether the miss was caused by cache eviction, provider failover, or routing pool changes?
Plugins
requests were sent through the Zen HTTP API via LiteLLM
OpenCode version
not using the OpenCode client
Steps to reproduce
Send consecutive Responses API requests with the same x-opencode-session and an unchanged prefix, then inspect usage.prompt_tokens_details.cached_tokens. The failure is intermittent.
Screenshot and/or share link
No response
Operating System
server-side Zen API issue
Terminal
server-side Zen API issue
Activity
github-actions commentedon Aug 28, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
_No response_). Please provide the version you are using.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
~500tokens / 0 on opencode-go (zen/go) — same symptom of intermittent cache misses on Zen GoIf you believe this was flagged incorrectly, please let a maintainer know.
ricklee0411 commentedon Aug 28, 2026
Possibly related to #35402, which reports intermittent cold-cache rerouting for another Zen model despite stable request prefixes.
github-actions commentedon Aug 28, 2026
Thanks for updating the issue! The report now includes all the necessary details and looks good. We appreciate you providing the session IDs, token counts, and reproduction steps.
ricklee0411 commentedon Aug 28, 2026
Session:
137:web_chat:ddaa1f1b-3f93-4ad3-b109-be80b152e4ee
The same LiteLLM deployment was used for all 16 requests:
d8354a69-2986-4f0a-9885-9fb09bf6257f
Three unexpected cache misses occurred:
For every miss:
The misses occurred 63.5s, 64.0s and 64.8s after the previous
response completed. Other requests with similar gaps still hit the cache,
so this does not appear to be a simple fixed cache TTL.
ricklee0411 commentedon Aug 28, 2026
Added a second session with three confirmed full-billing cache misses; prefixes, tools, deployment, session metadata, and request parameters remained unchanged.
rhaenni commentedon Sep 3, 2026
Same symptom, observed from the OpenCode client (not LiteLLM) — so this also affects the vanilla client path.
Client: OpenCode TUI v1.18.27
Model:
muse-spark-1.3-contributorviaopencode-go(Zen Go)Session:
ses_f98bb8516ffeLqZ6LUmJQ0elIg9 full/partial cache misses in ~11 minutes (13:19:27–13:30:41 GMT) during a single
agent session, all mid tool-loop while only appending tool results (psql/grep/read — no
user message, no todo update, no parameter change). 4 of them were billed at full uncached
input price ($0.0104–$0.0132/request vs $0.0003–$0.0005 baseline, ~110–150k input tokens each).
Evidence the client is not changing the prefix:
requests (e.g. 130,545 → 131,761 → 132,593 → 133,809 → 135,025 → 135,729 → 136,113 →
… → 144,241), i.e. the serialized conversation is byte-identical and append-only.
todowritemid-streak was followed by an immediate full cache hit (rules out todoinjection as the cause). Tool-output pruning occurred exactly once in the whole session.
requests with 54–61s gaps still hit.
13:20:45 → 104,113 cached 5s later) — consistent with a routing hop to a differently-warmed
upstream, re-writing the cache there, then sticking again.
Most telling detail:
cached_tokenson the miss requests snaps to a small set of exactrecurring values — {177, 241, 1393, 2353, 6193, 7857} — with the same values repeating
exactly across 20 minutes (7857 ×5). These look like fixed structural boundaries of the
prompt (tool definitions / system prompt) that are warm on the upstream, while the
per-session conversation tail is not. That points at cache partitioning across upstream
replicas/tiers rather than eviction or client-side prefix changes.
Same questions as the OP, plus:
x-opencode-sessionenabled formuse-spark-1.3-contributor?prefix tiers shared across sessions?
neriousy commentedon Oct 21, 2026
Thanks for the detailed request IDs and timestamps. Muse Spark prompt caching on Go has been fixed since this was reported, so these intermittent full-price misses shouldn't happen anymore. Closing because there's been no activity for a while. If you still see cache misses on Muse Spark with an unchanged prefix, comment here with the time, session ID and request IDs from the console logs and we'll reopen it.