Kimi Pricing: Tiers, Cache and Honest Routing
Moonshot prices Kimi tiers with unusual honesty: each step costs visibly more and delivers visibly more, from K2.5 volume workhorse through K2.6 agentic core to K3 flagship reasoning. No hidden multipliers, no confusing bundles — just a ladder where routing accuracy translates directly into value. This guide explains each tier's rates, where cache behavior affects real costs, and the routing discipline that keeps every ticket on its best-value rung permanently.
Rates across the ladder
K2.5 prices for volume: bulk edits, scaffolding and routine generation at rates that make per-ticket costs negligible. K2.6 and the coding-tuned K2.7-Code price the agentic core fairly — sustained tool loops and multi-file work at sustainable rates. K3 charges flagship prices for flagship judgment on architecture and the hardest debugging. Each step is proportionate, which is rarer than it sounds.
Because steps are honest, routing errors cost exactly their size — no hidden multipliers ambush careless defaults beyond the visible gap. Still, gaps compound across agent loops that repeat prices dozens of times per ticket. Default cheapest adequate, escalate deliberately, and the ladder delivers its designed value. Improvise, and even honest pricing bleeds steadily.
- K2.5 volume economics
- K2.6/K2.7-Code agentic core
- K3 flagship reasoning
- Honest steps reward routing
Cache behavior and real costs
Agentic loops resend context constantly, so cache behavior shapes real Kimi costs beyond sticker rates. Repeated system prompts, stable tool schemas and long conversations with shared prefixes all discount heavily where caching applies. Measure hit rates on your actual workloads before assuming list prices — many agent shops pay far below sticker without realizing why.
Design prompts for cacheability deliberately: stable prefixes first, volatile content last, frozen schemas across calls. These habits cost nothing and compound on every request of every ticket. Cache optimization routinely beats tier juggling on savings while preserving quality completely. The teams with the lowest bills invariably have the best cache discipline, not the cleverest tier picks.
- Repeated prompts discount
- Stable schemas compound
- Measure hit rates first
- Design for cacheability
Routing that follows rates
Default routine tickets to K2.5 and standard agent sessions to K2.6, reserving K3 for architecture decisions and debugging where judgment errors cost hours. Escalate on stall signals and known-hard categories, never by prestige or anxiety. Write triggers down where the team finds them; unwritten routing decays to top-tier defaults within weeks under deadline pressure.
Maintain triggers from telemetry: categories succeeding on lower tiers retire escalation permanently, new struggles earn it. Review monthly at first, quarterly once stable. The discipline feels bureaucratic for one week; then invoices arrive and it looks like obvious professionalism. Tiered families reward routers and punish improvisers without exception.
- K2.5 default for routine
- K2.6 for agent sessions
- K3 for architecture
- Triggers written and maintained
Trial tiers with data
Trial each tier on identical real tickets — toy tasks flatter every tier equally. Score merged results per dollar with review time included. Require two consecutive winning weeks before standardizing assignments per category; single weeks can be luck. Keep all tiers configured as mutual fallbacks regardless of outcome; providers have outage days and the fallback costs nothing idle.
Publish results internally with methodology so decisions stick beyond the trial. Future generations slot into the same framework instead of restarting debates. Trials output infrastructure — configs, triggers, baseline data — alongside verdicts. That infrastructure outlives every individual tier choice and compounds across all future decisions.
- Identical tickets per tier
- Merged results per dollar
- Two winning weeks
- Mutual fallbacks permanently
Keep rates working for you
Review tiers quarterly as Moonshot ships fast enough to obsolete careful mappings; each generation moves the adequate boundary. Keep escalation triggers hygienic from telemetry data. Test fallback coverage occasionally rather than assuming it — theoretical redundancy fails theoretically until proven with real traffic.
Maintain routing as a living document with reasons attached. New teammates inherit economics on day one instead of improvising for months. The maintenance burden is an hour per quarter guarding economics that compound every ticket. Boring rate governance beats exciting rate surprises on every metric that matters to budgets.
- Quarterly generation reviews
- Trigger hygiene from data
- Fallbacks tested routinely
- Living routing document
Frequently asked questions
Which Kimi tier for which ticket?
K2.5 for volume, K2.6/K2.7-Code for agentic core work, K3 for flagship reasoning. Price steps match capability steps unusually well — route by ticket difficulty and the economics follow.
How do I split tickets across tiers?
Route bulk and routine to K2.5, standard agent sessions to K2.6, architecture and hard debugging to K3. Escalate on stall signals; document triggers so routing survives personnel changes.
Can I use Kimi outside Moonshot tooling?
Yes. Standard compatible endpoints serve all tiers in capable clients with minutes-long setup. Trial tiers on identical tickets before standardizing any assignment.
How do I trial Kimi tiers fairly?
Mirror production weeks per tier on identical tickets, score merged results per dollar, require two winning weeks. Keep all tiers warm as mutual fallbacks permanently.
How do teams keep routing optimal?
Review quarterly as Moonshot ships fast; maintain triggers from telemetry; test fallbacks. Each generation moves the adequate boundary and the mapping must follow.
Related guides
Keep your coding workflow moving
Kintio provides an Anthropic-compatible API for Claude Code and other developer tools. Review the fit for your workload before switching.
Explore Kintio →Last updated: