Kimi K2.5: The cost and latency worksheet

Moonshot's docs list exactly one current multimodal release: kimi-k2.5, no K2.7 page or endpoint yet. Anything quoting K2.7 numbers is testing a rumor: check the live docs before shipping. Skip the leaderboard instinct. Wrong direction. Start from your requests and what a wrong answer costs, then ask whether K2.5 earns a new route.

decide what counts as a win first

Before the first prompt, decide what an accepted result looks like. 'Sounds right' isn't a criterion anyone can check.

• extraction: a schema-valid record whose fields trace to the source
• coding: a patch that clears tests and review, not just compiles
• research: a claim list where every claim traces to a real source

None of that credits fluency. Log cached versus uncached input, reasoning versus output tokens, tool charges, retries, latency, and repair time per workload. Keep the full request too, reasoning-effort knobs included, closer to a reasoning dial in Codex than a switch.

model id + api version, prompt/tool-schema version
cached/uncached input, reasoning, output tokens
pass/retry/abstain/repair, provider error, fallback route

where the bill actually hides

The expensive mistake: pricing by input tokens while output, cache writes, tool calls, and retries run the bill up. Frontier output reads plausible almost every time, so verify with code, have reviewers tag defects, and keep the failures: they teach the router more than clean runs do.

Long context earns extra suspicion: a bigger window doesn't remove prefill time, retrieval noise, or the line between trusted instructions and an untrusted document. Cache the stable prompt prefix and send a checkpoint instead of full history. A tight decision plus evidence beats an unrequested tutorial.

Tool use changes the risk. A model picking functions better doesn't excuse your code from validating arguments, authorizing callers, and capping side effects. A web page or tool result is data the model read, not an instruction to obey. The harness matters: native tool calls and pasted terminal text aren't the same test.

config decides, not fashion

The rule that survives production: optimize verified work per dollar and second, never the cheapest token, in configuration, not whatever model somebody read about last week. Log model identity, timings, tokens, and eval results, skipping sensitive prompt content by default.

Keep a cheap, fast lane for routine work and a written escalation condition for the rest. Send the expensive model only what benefits; a cheap tier isn't cheap once retries and review eat the savings.

Treat every model swap as maintenance: pin dated versions, watch deprecation notices, canary new aliases before full rollout, and keep a fallback ready. The same discipline keeps any model migration from becoming an incident; re-run your eval set when the model or tool contract changes.

The one rule I'd keep, flat: a model earns its route with verified work per dollar-second, nothing else counts.