Why does my prompt cache randomly return zero on GLM-5.3-Flash?
Because that one model drops its cache intermittently. In our run it happened on 5 of 12 warm calls, while the other four models never dropped one.
What we found
Prompt caching is the largest single lever on what an agent costs, because an agent resends the same prefix on every turn. So a cache that silently stops hitting is a cost increase with no error attached to it.
We sent an identical prefix repeatedly to all five models and recorded what came back in the usage object. Four of the five cached reliably. GLM-5.3, DeepSeek-V4-Pro, DeepSeek-V4-Flash and Kimi K3 cached on every warm call we made, 12 each, with hit rates of 90 percent and above once the prefix passed about 500 tokens.
GLM-5.3-Flash is the exception. On the same prefixes, in the same run, through the same connection, 5 of its 12 warm calls reported zero cached tokens. The ones that did hit reported 99 percent. So it is not a partial hit or a degraded one. The cache is either fully there or fully absent, and which one you get varies between otherwise identical calls.
We checked the obvious explanations and neither holds. It is not prefix length: the model cached 99 percent of an 8192 token prefix in the same run where it cached nothing at 4096. It is not a short cache lifetime: a follow-up ten seconds later hit on all four other models, and GLM-5.3 in particular held its cache perfectly across every delay we tried.
We do not know the cause. It is upstream of us and it affects one model out of five. Being precise about the evidence: this is two runs about an hour apart on one day, 2026-09-21, and the second of those is the one with all five models in it. That is enough to say the behaviour is real and not a one-off call, and it is not enough to tell you the rate you should expect over a week. What we can tell you is the shape of it, so that you recognise it rather than spending an afternoon looking for it in your own prefix construction.
One consequence worth stating plainly, because it is money. We bill cached input at the cached weight and uncached input at the full one, from the number the provider reports. When a call drops its cache, the provider reports those tokens as uncached and they are billed as uncached. That is correct billing of an upstream event rather than a discount we withheld, and it is still a real cost difference you did not choose.
What to do instead
- If caching matters more to you than the speed difference, use GLM-5.3 rather than GLM-5.3-Flash. It cached on every call we made.
- Do not tune your prefix in response to a single zero. The same prefix that reports zero on one call reports 99 percent on the next, so one observation tells you nothing.
- If you track spend per call, expect variance on this row that does not correspond to anything you changed.
How this was measured
An unattributed measurement is a marketing claim, so here is the receipt.
- Probe
- probe_cache_hits.py
- Measured
- 2026-09-21
- Applies to
- glm-5.3-flash
We found this by running the probe against the models we serve, which is also why it is worth trusting: it is a reading rather than a restatement of somebody's documentation. The full catalog is on /models, and what a request costs is on /pricing.
Upstream behaviour changes without notice, and a measurement is only as good as its date. If you find this is no longer true, tell us on the support page and we will re-run the probe.