Kimi Context Caching: Managed Cache vs Routed Test

Kimi context caching is a native-platform feature: Moonshot documents a managed context cache on platform.moonshot.ai, but our 2026-07-28 routed test of Kimi K2 returned 0 cached tokens and near-identical billing on both calls.

The gap between what a vendor documents and what a buyer gets on their actual path is the whole story here. Moonshot AI develops the Kimi model family, and Kimi K2 is the endpoint we measured. The caching feature belongs to the native platform, so it does not follow the model through a third-party marketplace.

Kimi context caching (verified 2026-07)

Context caching is a server-side cost optimization that stores the key-value state of a repeated prompt prefix so later requests reusing that prefix are billed at a reduced input rate instead of the full rate. It changes input cost and latency only. It has no effect on output quality, and no honest test can claim otherwise.

According to Moonshot AI platform docs, context caching is offered on Moonshot's own platform as a managed cache with its own storage pricing. That design is different in kind from a cache that simply turns itself on when you resend a prefix. A managed cache is something the caller creates, references, and pays to keep alive, which means a plain chat completion sent through an intermediary has no reason to touch it.

First-hand evidence: what the Kimi K2 usage fields returned

We sent the same ~1800-token prefix twice on 2026-07-28, two seconds apart, with a different one-line question each time, temperature 0 and max_tokens 40. Kimi K2 on the routed path reported prompt_tokens 3255 on both calls and cached_tokens 0 on both calls. Billing came back at $0.00190135 for the first call and $0.00189675 for the repeat, a gap of roughly four ten-thousandths of a cent that tracks the two fewer completion tokens on the second call (20 versus 18) rather than any input discount. Latency moved from 3.37s to 2.23s. We do not read that as cache evidence: with cached_tokens at 0 on both calls, the swing is ordinary routed-request variance.

One caveat governs every zero in this article. Our design measures implicit, automatic caching only. Any provider whose cache requires an explicit marker, a cache object, or a stored-prefix reference is expected to report 0 here, and that is a finding about default behavior on the path we used, never a claim that caching is unsupported.

The cross-endpoint result matrix

The Qwen row is not cache evidence. Call B matches Qwen's list price (about $0.00032 computed), while call A billed roughly twice list, so the delta tracks provider-price variance on the routed marketplace rather than a measured cache. We flag it because pricing noise on a marketplace looks exactly like a cache discount if you only watch the invoice.

Managed and explicit caches versus implicit ones

Three caching designs are in play across the vendors we tested, and they behave very differently when a request crosses an intermediary.

According to DeepSeek API docs, cache-hit input tokens bill at $0.014 per million against $0.14 per million for misses, and the cache is automatic. Our native measurement matched that behavior: 98% of the prompt hit on the repeat, and latency fell from 1.43s to 0.90s. Anthropic sits at the other end of the spectrum. According to Anthropic's prompt caching docs, caching activates through explicit cache_control breakpoints, with cache writes priced above normal input and cache reads far below it, so our test could not have triggered it. OpenAI documents automatic caching for prompts at or above 1024 tokens on its own API, per platform.openai.com, which we did not see through the routed path either.

Kimi's design is closer to Anthropic's than to DeepSeek's in one respect that matters for buyers: it is opt-in. The difference is that Moonshot's version is a managed object with storage economics, so the buyer is choosing to pay rent on a cached prefix in exchange for cheaper reads. We did not test that native path and do not quote a storage price, because we have not measured one.

What this means if you are buying Kimi

The blanket claim that routers destroy caching is false, and our own run disproves it. DeepSeek's cache was lost through the router on 2026-07-28 while GLM-5 kept a 75% billed discount and MiniMax-M2.5 kept 62% on the same routed path. Cache survival is a per-provider integration property, not a property of routing itself. Kimi K2 landed on the no-discount side of that split in this run.

Practically, that leaves three positions. If your workload is a long fixed system prompt or a stable document prefix hit thousands of times a day, the Kimi caching feature is a reason to hold an account on Moonshot's own platform rather than to expect savings from a marketplace key. If your traffic is spiky and prefixes rarely repeat, a managed cache with storage pricing can cost more than it saves and an automatic cache is the better fit. If you want caching without operating it, DeepSeek's automatic behavior was the strongest thing we measured, and our DeepSeek cache discount breakdown covers the pricing side.

Choose Kimi's native platform if you can pin a prefix and want deterministic control over what is cached and for how long. Avoid assuming the same discount through an aggregator key until you see cached_tokens above zero in your own usage payloads.

Methodology and disclosure

DeepSeek V4-Flash was measured natively on api.deepseek.com. Every other endpoint, Kimi K2 included, was reached through a third-party router, which we disclose because routed behavior is not native behavior. All 17 calls succeeded, routed spend totaled $0.051, and this is a single-region snapshot from 2026-07-28. Native Kimi re-verification is outstanding, so treat the Kimi row as evidence about one route on one day, not a permanent property.

FAQ

Does Kimi support context caching? Yes, on its native platform. Moonshot documents a managed context cache with storage pricing at platform.moonshot.ai. Our test used a routed path with no cache markers, so it could not exercise that feature and correctly reported 0 cached tokens.

Why did our Kimi K2 test show 0 cached tokens? The test design sends a plain repeated prefix and reads the API's own usage fields. It detects implicit caching only. A managed or explicit cache needs the caller to create or mark the cache, which our calls never did, so zero is the expected result rather than a failure.

Is Kimi caching lost because of the router? Not provably from this run. Both facts are true at once: the routed Kimi calls billed full price twice, and our design could not have triggered a managed cache on any path. GLM-5 and MiniMax-M2.5 did keep large cache discounts through the same router.

How do I tell if caching is working on my own Kimi traffic? Read the usage object your endpoint returns. Cached prefix tokens appear as a nonzero cached-token count, and the billed cost for a repeat call drops visibly. If both stay flat across two identical-prefix calls, no cache is being applied on that route.

Does caching change answer quality? No. Caching affects input cost and latency. It does not alter how a model reasons or what it returns, so any comparison that mixes cache savings with accuracy claims is measuring two unrelated things.

For the full cross-vendor picture, including which providers kept their discount through a router and which lost it, see our prompt caching benchmark hub.

Author: Kevin Fan, Customer Success Manager. Last verified: 2026-07-28.