Moonshot’s most useful uncovered announcements are changes to the economics of context: how much repeated input costs, and how much retrieved material needs to enter a model request. Both influence the design of a research or coding agent before a new checkpoint is involved.
This opens the Moonshot / Kimi research series. Existing articles use Kimi in FrontierHarness evaluation and inference-system analysis; those are not dedicated assessments of these platform releases. The announcements below are dated September 16 and 28, not new October model launches.
Two announcements, two different optimization targets
On September 28, Moonshot announced separately billed cache writes and two prefix-cache lifetimes, five minutes and one hour. It describes K3 cache hits as one-tenth the cache-miss input price. The published behavior is prefix matching, organization-level isolation, renewed lifetime on reuse, and automatic expiry after inactivity; manual clearing is not supported. These are provider statements, not isolation or deletion tests performed here. Cache announcement.
On September 16, Moonshot announced standalone Web Search Basic, Web Search Pro, and URL Fetch APIs. Pro returns ranked passages with source metadata and an authority field, while Fetch retrieves a known page’s Markdown body. The announcement describes per-call billing. Search announcement.
Caching addresses repeated computation and input charging. Passage extraction addresses selection. Combining them can lower an agent’s cost, but neither establishes that its evidence is complete or its conclusion correct. Those are separate properties to measure.
Cache economics depend on the reuse distribution
The current caching guide lists K3 cache misses at $3 per million tokens, hits at $0.30, five-minute writes at $3, and one-hour writes at $6. It states that a written portion is charged at the write rate rather than being charged again as ordinary input. Caching guide and billing rules.
Consider a hypothetical fixed million-token prefix used repeatedly before expiry. Exclude changing suffixes, output, tools, and any non-cache fees. Without reuse, each request costs $3 for that prefix. A five-minute write followed by one hit costs $3.30, versus $6 for two uncached requests. A one-hour write followed by one hit costs $6.30, so two uses alone do not beat the $6 baseline. A third use brings that cached total to $6.60 versus $9 uncached.
These are arithmetic examples under the documented rates, not observed savings. The meaningful variable is how many requests reuse the unchanged prefix during its active lifetime. A long lifetime is valuable when reuse arrives too late for the short option; it need not be valuable when almost every reuse arrives promptly anyway.
| Workload pattern | Experiment to run |
|---|---|
| Rapid editing session | Compare short and long TTL with the same request sequence |
| Intermittent analytical work | Replay the observed gaps between turns |
| Large, frequently changing repository | Measure the stable prefix remaining after edits |
| One-off document processing | Count writes that never receive a later hit |
| Scheduled reports | Include schedule jitter, missed runs, and source revisions |
Avoid selecting a TTL from the average inter-request interval alone. A workload can have many near-instant repeats and a smaller cluster of long gaps; an average hides both. Use the distribution, include new-write charges after expiry, and reconcile against billed usage rather than a client estimate of reusable text.
Prefix optimization can become an evidence mistake
Moving stable material to the start of a request makes sense mechanically. Freezing a document because it is cheap to reuse is a different decision. A repository checkout, policy version, or research paper can remain byte-identical while becoming inappropriate for the next task.
Treat document identity, version, and eligibility as inputs to context selection. When a source changes, preserve the version used for each conclusion and build a new eligible request. Do not maintain a high hit rate by quietly keeping obsolete instructions. A cache can faithfully accelerate the wrong input.
The organization-level sharing description also needs a deployment-specific interpretation. An organization may contain several projects and customers; its identifier is not evidence that all those users should receive the same material. The application still needs to select the appropriate context before sending it. Likewise, inactivity-based cache expiry is not proof of deletion from every provider log or derivative store. Obtain the relevant data-handling terms for the actual deployment rather than inferring them from a TTL.
Search Pro makes selection more important
Returning a small relevant passage can improve the signal-to-noise ratio of a prompt. It can also remove a qualification that sits elsewhere on the page. A launch paragraph may describe availability while a later section restricts geography; a benchmark summary may omit a fallback condition found in the methodology.
An authority label is a retrieval feature, not independent proof that a particular sentence is accurate or current. A useful agent should preserve the passage, original URL, access time, and claim it supports. For consequential or disputed claims, fetch the original page and inspect the surrounding context. This is our proposed research method, not a statement that the API performs those checks automatically.
The search comparison should therefore hold the underlying questions fixed and vary the evidence path: basic results with application extraction, Pro passages, and a full-page reference set prepared for evaluation. Let reviewers inspect both answer quality and omitted evidence. A shorter answer produced from fewer tokens is not an improvement if it loses the condition that changes the conclusion.
A paired experiment for the combined system
Test cache configuration and retrieval strategy as separate factors. Otherwise, a lower bill cannot be attributed to prefix reuse versus a smaller evidence set. Keep the model, reasoning effort, task rubric, and tool budget fixed while varying each factor.
Record billed cache writes, hits and misses, search/fetch calls, answer tokens, latency, citation support, and task acceptance. Add cases with a changed source, a contradictory second page, a long idle gap, and an organization containing multiple application tenants. Run privacy checks using controlled fixtures, not live customer data.
My assessment is that these releases make Kimi a more interesting platform for context-heavy applications. The important adoption question is whether reuse and extraction reduce cost while preserving the evidence needed to resolve the task. That is a sharper claim than either a high cache-hit percentage or a large advertised context window.
Sources and dates
- Standalone search APIs — September 16, 2026, official announcement category.
- Cache-write and TTL announcement — September 28, 2026, official announcement category.
- Caching guide — living documentation accessed October 19, 2026; billing and cache behavior. No provider experiment was run.