Muse Spark 1.3 intermittent prompt cache miss on Opencode Go paid tier

Description

Intermittent full prompt cache misses on Zen Go for muse-spark-1.3-contributor, observed from the OpenCode client.
Prefixes are byte-identical between consecutive requests (agent tool-loop, append-only), yet requests intermittently
return near-zero cached_tokens and get billed at full uncached input price. Same family as #45867 (muse-spark-1.2)
and #31348 (GLM-5.1), reporting here for 1.3 visibility.

Endpoint: opencode-go (Zen Go) — https://opencode.ai/zen/go/v1/responses
Model: muse-spark-1.3-contributor
Timestamps: 2026-09-03, 13:19:27–13:30:41 GMT
OpenCode session: ses_f98bb8516ffeLqZ6LUmJQ0elIg (server-side request IDs correlatable via these timestamps)

9 full/partial cache misses in ~11 minutes 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 were billed at full uncached
price ($0.0104–$0.0132/request vs $0.0003–$0.0005 baseline; ~110–150k input tokens re-billed each).

Time GMT	Prompt tokens	Cached tokens	Billed uncached
13:19:27	102,542	1,393	101,149
13:20:12	103,791	7,857	95,934
13:20:45	104,150	241	103,909
13:21:10	107,934	7,857	100,077
13:22:12	110,984	7,857	103,127 ($0.0104)
13:24:49	113,298	7,857	105,441 ($0.0106)
13:26:34	125,691	177	125,514 ($0.0132)
13:27:31	130,563	1,393	129,170 ($0.0130)
13:30:41	147,947	177	147,770

Evidence the client is not changing the prefix:

• Between misses, cache reads grow in lockstep with prompt growth for 10–15 consecutive requests (130,545 → 131,761
  → … → 144,241), i.e. the serialized conversation is byte-identical and append-only.
• A todowrite mid-streak was followed by an immediate full cache hit (rules out todo injection). Tool-output
  pruning occurred exactly once in the entire session.
• Not a TTL effect: misses occurred 11–32s after the previous response completed, while other requests with 54–61s
  gaps still hit.
• After every miss, the next request returns to a full hit (e.g. miss with 241 cached at 13:20:45 → 104,113 cached
  5s later) — consistent with a routing hop to a differently-warmed upstream that re-writes the cache, then sticks
  again.

Most telling detail: cached_tokens on miss requests snaps to a small set of exact recurring values — {177,
241, 1393, 2353, 6193, 7857} — with identical values recurring across 20 minutes (7857 ×5). These look like fixed
structural boundaries of the prompt (tool definitions / system prompt) that stay warm upstream while the per-session
conversation tail does not. This points at cache partitioning across upstream replicas/tiers rather than eviction or
client-side prefix changes.

Could you check:

1. Whether sticky routing per x-opencode-session is enabled for muse-spark-1.3-contributor, and whether it was
   applied to these requests?
2. Which upstream provider/replica handled the miss requests vs the preceding/following hits?
3. Whether the recurring cached-token boundaries (177 / 1393 / 7857) correspond to shared system+tools prefix tiers?
4. Whether the miss was caused by failover, routing pool changes, or per-replica cache isolation?

Plugins

None affecting requests (stock OpenCode client, @dietrichgebert/ponytail system-prompt plugin only)

OpenCode version

1.18.27

Steps to reproduce

Run an OpenCode session on muse-spark-1.3-contributor (opencode-go) long enough to reach ~100k prompt tokens and
let the agent do a read-only tool loop (shell/psql/grep). Inspect per-request cache_read (opencode stores it per
step in ~/.local/share/opencode/opencode.db, part rows of type step-finish) or watch the billing dashboard for
full-price requests. The misses are intermittent — roughly every 5th request in the observed window.

Screenshot and/or share link

No response

Operating System

Linux (Arch, kernel 6.x) — client-side; misses are server-side routing behavior

Terminal

OpenCode TUI — not terminal-specific

Plugins

none

OpenCode version

OpenCode TUI v1.18.27

Start with the OpenCode 1.18.27 session, the opencode-go endpoint, and the per-step cache_read records in ~/.local/share/opencode/opencode.db. Correlate the listed timestamps and session ID with server-side request IDs, then compare the miss and hit requests. Done means determining whether routing, failover, or replica cache isolation explains the recurring cache boundaries.