Repository navigation
GLM-5.1 prompt cache randomly drops to 0 on opencode-go, while DeepSeek V4 Flash works reliably #31348
Description
Description
I use opencode-go in a long-running coding agent workflow. With the same workflow, DeepSeek V4 Flash keeps stable and high cache reads across many turns. But after switching to GLM-5.1, cache reads randomly drop to 0, causing large unexpected cost spikes.
Observed behavior
In one session, DeepSeek V4 Flash ran from turn 1 to turn 116 without abnormal cacheRead=0 events after the initial request.
After switching to GLM-5.1, I saw two complete cache read failures within only 15 turns:
turn 123:
model: GLM-5.1
cacheRead: 0
input: 45918
turn 127:
model: GLM-5.1
cacheRead: 0
input: 63535
The surrounding turns had normal cache reads:
turn 122: cacheRead: 22272
turn 123: cacheRead: 0
turn 124: cacheRead: 35456
turn 126: cacheRead: 45888
turn 127: cacheRead: 0
turn 128: cacheRead: 57408
So GLM-5.1 does support cache sometimes, but cache reads randomly collapse to 0.
Prefix stability evidence
I added debug logging before the model call. Around both abnormal GLM-5.1 turns, the request prefix did not change:
sys_hash: 5d3ec78c
tools_hash: 6244fe09
prefix_4k_hash: 26ac1f5d
prefix_16k_hash: 30e260ca
prefix_64k_hash: d65f320d
The diff against the previous request also showed that only new items were appended:
turn 123:
previous input_items_count: 42
first_changed_input_index: 42
turn 127:
previous input_items_count: 57
first_changed_input_index: 57
This means the existing request prefix was unchanged. There was no mutation to the system prompt, tools, or earlier input items. From the client side, the prompt should have been cache-readable.
Request
Please investigate whether GLM-5.1 on opencode-go has unstable prompt cache routing or cache key/session handling.
Specifically:
- Are GLM-5.1 requests using sticky routing / session affinity for prompt cache?
- Is a stable cache key or session key passed to the upstream GLM API?
- Is GLM-5.1 routed differently from DeepSeek V4 Flash?
- Is
cacheRead: 0expected even when the request prefix is unchanged? - If opencode-go only forwards to the official GLM API, could this be escalated upstream with the evidence above?
This behavior makes GLM-5.1 unreliable for long-running coding agent workloads, because cache reads can randomly drop from tens of thousands of tokens to zero even when the request prefix is stable.
Plugins
None
OpenCode version
latest
Steps to reproduce
Use opencode-go with a long-running coding agent workflow through the OpenAI-compatible /v1/chat/completions API.
Screenshot and/or share link
Operating System
Windows 11
Terminal
Windows terminal
Activity
mrrusty-87 commentedon Jun 8, 2026
same issue here today. no prompt caching. output from opencode usage history:
Date | Model | Input | Output | Cost | Session
Jun 8, 9:12 PM | glm-5.1 | 109900 | 180 | Go ($0.1537) | U4P6qlck
Jun 8, 9:10 PM | glm-5.1 | 109769 | 112 | Go ($0.0290) | U4P6qlck
Jun 8, 9:10 PM | glm-5.1 | 108190 | 1570 | Go ($0.0365) | U4P6qlck
Jun 8, 9:10 PM | glm-5.1 | 107155 | 34 | Go ($0.0350) | U4P6qlck
Jun 8, 9:10 PM | glm-5.1 | 106845 | 60 | Go ($0.0281) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 106582 | 254 | Go ($0.0290) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 106372 | 83 | Go ($0.0281) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 106156 | 207 | Go ($0.0286) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 105474 | 602 | Go ($0.0309) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 104688 | 31 | Go ($0.0282) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 103848 | 68 | Go ($0.0314) | U4P6qlck
Jun 8, 9:09 PM | glm-5.1 | 100988 | 64 | Go ($0.0269) | U4P6qlck
Jun 8, 9:08 PM | glm-5.1 | 100769 | 194 | Go ($0.0276) | U4P6qlck
Jun 8, 9:04 PM | glm-5.1 | 100646 | 1628 | Go ($0.0344) | U4P6qlck
Jun 8, 8:59 PM | glm-5.1 | 100535 | 72 | Go ($0.0271) | U4P6qlck
Jun 8, 8:58 PM | glm-5.1 | 100318 | 968 | Go ($0.0314) | U4P6qlck
Jun 8, 8:55 PM | glm-5.1 | 100068 | 123 | Go ($0.1406) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 99678 | 30 | Go ($0.0261) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 99421 | 249 | Go ($0.0275) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 99486 | 18 | Go ($0.0260) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 99409 | 68 | Go ($0.0263) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 99220 | 97 | Go ($0.0264) | U4P6qlck
Jun 8, 8:54 PM | glm-5.1 | 98987 | 143 | Go ($0.0407) | U4P6qlck
michaelBelsanti commentedon Jun 25, 2026
Seeing the same issue with GLM-5.2. It makes the models pretty much unusable with how fast it goes through your usage.
mgadda commentedon Jun 27, 2026
Same experience for me with GLM-5.2 (Opencode Go). Definitely seems broken (hopefully not by design!). The net effect is that it's wildly more expensive than closed frontier models like GPT-5.5. I spent 67% of the 5-hour quota on a single prompt (and, egregiously also 26% of weekly, and 13% of monthly!). Usage showed cache misses on almost every other request. This behavior was reproducible in Conductor, opencode desktop and opencode CLI.
mgadda commentedon Jun 27, 2026
This appears to be duplicate of #33998.
MiunaQwQ commentedon Jun 29, 2026
Looks like the same issue is also happening on
glm-5.2Observed logs:
Cost impact:
$0.6599$0.1408$0.51914.69xExcluding the initial cold request:
$0.7338$0.21473.42xMarvinthebored commentedon Jul 5, 2026
This looks like the same mechanism root-caused in #35402: GLM models on Zen are multi-sourced with no
stickyProviderconfigured, so requests intermittently re-resolve to a different upstream with a cold prompt cache (byte-identical-request repro in that issue). DeepSeek working reliably for you is consistent — models with a single upstream (or sticky enabled) don't flap. Consolidating discussion in #35402 may help.github-actions commentedon Sep 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.