Kimi K2.7 Code pricing: API rates, tiers, and real costs

Kimi K2.7 Code pricing at a glance

Here's the part you came for. These are the official rates from Moonshot's pricing page, per 1 million tokens:

A few details the table alone won't tell you. Moonshot bills both input and output tokens on every chat completion call, and if you upload a document and pass its extracted text into a prompt, that text counts as billed input too - the extraction step itself is temporarily free, only the completion call charges you. There's no free API tier at all; a $1 cumulative recharge is the entry ticket before the API responds to a single request. HighSpeed isn't a different model, it's the same weights tuned for throughput (roughly 180 tokens/second, up to 260 in short contexts), and Moonshot prices that speed at a flat 2x on every tier.

The catch: rate limits are gated by how much you've paid, not a flat quota

This is the structural detail that shapes how the pricing actually plays out for a real account. Moonshot's rate limits scale with cumulative recharge, not a fixed per-key ceiling:

At $1 you're on Tier0: one concurrent request, three requests a minute, a 1.5M-token daily ceiling. That's a proof-of-concept limit, not a production one - a single MCP tool-calling loop that runs 4,000+ steps (the exact long-horizon workload K2.7 Code is built for) will bump into Tier0's concurrency cap almost immediately. Moonshot does hand out a $5 voucher once you cross $5 in cumulative recharge, but that's a one-time incentive credit, not a recurring free allowance. Anything past Tier5 means emailing api-service@moonshot.ai directly for a custom arrangement.

How it stacks up against Opus 4.8, and where third parties undercut Moonshot's own price

Moonshot's own model card puts K2.7 Code's pricing next to Claude Opus 4.8, and the gap is the headline number every launch post led with:

Opus 4.8 costs more than 5x as much per token and doesn't ship open weights, though it does carry a much larger 1M-token context window and, per Moonshot's own benchmark table, still leads K2.7 Code on most of the six coding evals it published. The one place K2.7 Code actually beats Opus 4.8 outright is MCP Mark Verified (81.1 vs 76.4) - a real head-to-head win on a tool-calling benchmark, not just a cheaper consolation prize.

Moonshot's own $0.95/$4.00 rate isn't the cheapest way to run this model, either. OpenRouter's provider table lists more than a dozen third-party hosts serving the identical open weights:

DeepInfra undercuts Moonshot's own price by roughly 20-25% on input tokens while matching it closely on uptime. That's the direct upside of open weights: because anyone can host the model, the official vendor doesn't have pricing power the way a closed lab does. OpenRouter's own 30-day weighted average across every host, after accounting for cache hits, comes out to roughly $0.38/1M input and $4.13/1M output - a reminder that the sticker price on any of these tables is a ceiling, not what a well-cached workload actually pays.

Self-hosting: the real zero-dollar option

If neither Moonshot's own rate nor OpenRouter's discount is cheap enough, the weights are yours to run. Kimi K2.7 Code ships under a Modified MIT License covering both code and weights, downloadable straight from Hugging Face - 870,022 downloads last month at the time I checked, a genuinely large open-weight adoption number. Self-hosting means the only cost is your own compute, not a per-token fee to Moonshot.

The catch is size. Full BF16 precision runs to roughly 595GB on disk - a server-class deployment, not a laptop model. Community quantization narrows that gap considerably: r/unsloth published a Dynamic 2-bit quant that shrinks the model to about 325GB (a 48% reduction) while still running at over 40 tokens/second on consumer-scale RAM/VRAM rigs, using inference engines like vLLM, SGLang, or KTransformers. It's a real option, just one that trades a token bill for a hardware bill.

The gap between the "30% cheaper" claim and what real accounts are paying

This is the part that actually changes how you should read every price table above. Moonshot's headline efficiency claim is that K2.7 Code uses roughly 30% fewer reasoning tokens than K2.6 - "less overthinking," in the company's framing - which should shrink the output half of the bill, since reasoning tokens bill as output on most price cards.

Reddit tells a different story. A thread titled "Kimi 2.7 Code is good, but it thinks forever and consumes way too much limit" is the core complaint in one headline, and the top reply doesn't soften it:

"Same for me: I'm spending tokens twice as fast..."

u/Rupertonic, comment on "Kimi 2.7 Code is good, but it thinks forever and consumes way too much limit"

A separate thread, "Does the new Kimi K2.7 use up your credits twice as fast?", describes a paid plan "draining 1% per complex" task at a rate the poster didn't expect going in. Not everyone agrees on why - one thread, "Do you think the increase in consumption of Kimi 2.7 is due to...", frames it as an open question between infrastructure issues, model regressions, or, as one commenter bluntly put it, "pure greed on Moonshot's" part. What's consistent across the threads is the direction: real usage running against the official efficiency claim, not with it.

MarkTechPost's own cost-calculator example is a useful illustration of what the claimed savings should look like, even if real accounts aren't seeing it. Assume 50,000 input tokens and 8,000 output tokens per run, a 50% cache hit rate, and 1,000 runs a month, with reasoning making up 40% of output:

• Input cost: ~$28.50/month
• Output cost: ~$32.00/month
• Estimated monthly total: ~$60.50/month
• Estimated savings from the 30% reasoning-token cut: ~$3.84/month, versus running the same workload on K2.6-style reasoning

That's a real but modest saving on paper, on a moderate workload, if the efficiency claim holds. On the Reddit threads above, it isn't holding for everyone, which means the honest way to budget for K2.7 Code is to price it at K2.6-era token consumption and treat any savings as a bonus, not a baseline.

Token pricing vs paying per outcome

Here's the reframe I'd leave you with, and it's one I come back to a lot having spent years watching AI run on live queues rather than benchmarks. Kimi K2.7 Code's pricing is genuinely good if you're a developer with a coding agent and roughly predictable token volume - you can forecast a monthly bill within a reasonable range, and you have three ways to pay less (official rate, OpenRouter, or self-host). But if the reason you landed on a "coding model pricing" page is that you're actually trying to budget AI for something like customer support, per-token billing is the wrong unit entirely, and the community threads above are exactly why.

A ticket that gets resolved in three quick tool calls and a ticket that needs twelve costs wildly different amounts under token billing, and a model update - like K2.6 to K2.7 - can silently double what a "resolved" conversation costs without anyone changing a setting. That's the exact unpredictability that makes teams stall on AI support rollouts: you can't put a number in next year's budget if the number moves every time the vendor ships a model that "thinks" differently, and a model that's mandated to always reason before responding - which K2.7 Code is, thinking mode can't be turned off - is one more variable stacked on top of that.

Try eesel

If you got this far because you're weighing AI pricing for customer support rather than a coding agent, this is the part worth reading closely. eesel is an AI support teammate that runs on frontier models under the hood, but you never watch a token meter: it's priced per resolved ticket, starting at $0.40 per ticket with no seat fees and no platform minimum, so a model update on the backend doesn't quietly change what your bill looks like. It plugs into your existing helpdesk (Zendesk, Freshdesk, Front, and 100+ others), learns from your actual ticket history on day one, and you can simulate it against past tickets to see the real resolution rate, and the real cost, before it ever answers a live customer.