Muse Spark 1.2 intermittent prompt cache miss on Zen Go

Description

We observed an unexpected prompt cache miss on the Zen Go Responses API.

Endpoint:
https://opencode.ai/zen/go/v1/responses

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:

1. Which upstream provider and route handled these requests?
2. Whether the provider changed between the previous, affected, and next requests?
3. Whether stickyProvider is enabled for muse-spark-1.2-contributor?
4. Whether x-opencode-session was received and used as the sticky routing key?
5. 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

Start with the Zen HTTP API request path and its LiteLLM integration, using the supplied timestamps, session key, upstream response ID, and client request ID. Compare routing, provider, stickyProvider, and cached-token results across the previous, affected, and next requests; done means identifying whether the miss came from eviction, failover, or routing changes.