Kimi K2.7 Code (2026): Does a 30% Token Cut Lower Your Bill?

The decision turns on one variable: the share of your output tokens that go to reasoning. Everything else — price parity, worse cache, unverified benchmarks — is secondary to that ratio.

Here's the short version, by workload. Match your traffic to the closest row.

If you do nothing else, take the "measure first" row seriously — every dollar figure depends on the share of output tokens that go to reasoning, specific to your traffic. Vendor benchmarks won't tell you; your own logs will.

Same per-token price, same context window, slightly worse cache reads, text-only. That leaves exactly one lever that can lower your bill: the thinking-token reduction.

Three facts fall out of this table. Per-token price is identical, so swapping models doesn't change your rate card. Cache reads are worse on K2.7, so cached input costs more. And K2.7 Code is text-only — it does not take images, K2.6 does. Price parity plus worse cache means exactly one lever can lower your bill: the thinking-token reduction.

Moonshot reports three coding benchmarks with double-digit gains. All three are proprietary, none have independent reproduction, and no public SWE-bench Verified, LiveCodeBench, or GPQA results shipped at launch.

The structural reason to discount: a vendor benchmark with a narrow score spread can show a big percentage gain off a small absolute move, and a proprietary harness can be tuned to the model that ships with it. VentureBeat covered the launch under the line that practitioners say the benchmarks don't check out. Researcher Elliot Arledge ran K2.7 Code vs K2.6 on KernelBench-Hard, a public GPU-kernel bench, and the MoE-kernel score regressed to 0.157 from K2.6's 0.222 on worse tuning.

The benchmark that would settle this for a routing decision has a wide spread across models and a public methodology. K2.7 wasn't submitted to that at launch. So treat K2.7 Code as roughly K2.6-class on quality until your own evals say otherwise, and justify the switch on token math, not benchmark deltas.

Roughly K2.6-class on quality, until your own evals say otherwise.

The 30% reduction is on thinking (reasoning) tokens, which bill as output (completion) tokens. Input doesn't move. So the cut only touches the reasoning slice of your output spend.

The clean saving formula is: reduction ≈ 0.30 × (thinking spend / total spend). If thinking is your whole bill, you get close to 30%. If it's a sliver, you save a sliver. The variable is the share of spend on reasoning, which ranges from near-total (agentic multi-step coding) to near-zero (long input, one-line answer).

Moonshot's own example is a 12-hour run dropping from ~2M reasoning tokens to ~1.4M — the 30%. That's a vendor example, not your measured result, but it shows the shape: on a long agentic run, reasoning dominates and the cut compounds. Don't generalize that 12-hour agent run to every job.

A summarization call that reads 200K tokens and writes 200 is the opposite profile — output is a sliver, the cut saves almost nothing, and the switch is pointless for cost. You don't have to guess: every response carries usage with prompt_tokens and completion_tokens, and thinking is folded into completion. The share you care about is completion_tokens × $4.00/M divided by the whole bill. Log it across a representative week before you change a model string.

Your measured thinking-to-output ratio decides, not the brochure.

Same price per token on both models, so the only moving part is the thinking-token cut. These three examples bracket the real world: reasoning-heavy, input-heavy, and a 12-hour agentic run.

All three assume the $0.95/M input and $4.00/M output rate card and no cache hits, so the thinking-token cut is the only lever. Monthly figures scale the per-job total by the job counts noted in each example.

The three examples bracket the real world: ~1% to ~26% depending on reasoning share; a typical mixed coding workload sits around 13% in the middle. The closer output is to all-thinking, the closer you get to the headline; the more bill is input, the less you save.

K2.7's cached input is $0.19/M vs K2.6's $0.16/M — a 19% premium on every cached token. On a cache-heavy job, that premium has to be overcome by the thinking-token cut, and on light-reasoning work it isn't.

On a 300K-input job at 80% cache hit, K2.7 costs $0.0072 more per job on input alone. At 1,000 cache-heavy jobs a day over a 30-day month that's about $216/mo extra the thinking savings must overcome. On a cache-heavy, light-reasoning job, K2.7 can end up the more expensive model.

K2.7 Code earns its keep on a narrow profile: text-only work where long thinking traces dominate output spend. Outside that profile the headline 30% rarely arrives.

• Text-only — no image or screenshot input in the prompt.
• Reasoning-heavy: long thinking traces vs a short visible answer (agentic coding, multi-step debugging, planning-heavy work).
• Not leaning hard on cache reuse — repeated context that hits the cache a lot pays the $0.19/M premium on K2.7.

If you need more throughput at the same price, kimi-k2.7-code-highspeed keeps the token math identical — the swap doesn't change the bill, just the speed.

K2.6 is the safer default for anything K2.7 Code can't do well or where the thinking cut doesn't reach the bill.

• You need image input — K2.7 Code is text-only and an image_url block fails on it.
• Input-heavy, short-output jobs (RAG, summarize, classify) — savings round to nothing, and K2.6's cheaper cache makes it cheaper outright.
• You rely on non-thinking mode for fast direct answers — there's nothing for the 30% to cut.
• You've validated K2.6 in production and have no measured reason K2.7 does the work better; the benchmarks are unverified.

If K2.6 is validated in your production and you have no measured reason K2.7 does the same work better, the unverified benchmarks aren't a reason to switch.

K2.7 Code is a narrow efficiency gain on reasoning-heavy text. If that isn't your bottleneck, optimize routing, not this swap.

The point of K2.7 Code is a narrow efficiency gain on reasoning-heavy text; if that's not your bottleneck, optimize routing not this swap. Match model tier to job first; optimize within a tier second.

Match the model tier to the job first; optimize within a tier second.

Both Kimi variants share one OpenAI-compatible endpoint, so A/B is a loop over two model strings. Run your real prompt through both, log the token counts the API returns, and compute the bill on your own traffic.

Python — A/B both models in one loop

from openai import OpenAI

client = OpenAI(
    base_url="https://api.moonshot.ai/v1",   # Moonshot's API, or any OpenAI-compatible gateway carrying both Kimi variants
    api_key=os.environ["MOONSHOT_API_KEY"],   # swap is one model string, nothing else changes
)

models = ["kimi-k2.6", "kimi-k2.7-code"]
for m in models:
    r = client.chat.completions.create(
        model=m,
        messages=[{"role": "user", "content": PROMPT}],
    )
    u = r.usage
    bill = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.00e-6
    print(m, u.prompt_tokens, u.completion_tokens, f"${bill:.4f}")

Node — same shape

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.moonshot.ai/v1",   // Moonshot's API, or any OpenAI-compatible gateway carrying both Kimi variants
  apiKey: process.env.MOONSHOT_API_KEY,   // swap is one model string, nothing else changes
});

const models = ["kimi-k2.6", "kimi-k2.7-code"];
for (const m of models) {
  const r = await client.chat.completions.create({
    model: m,
    messages: [{ role: "user", content: PROMPT }],
  });
  const u = r.usage;
  const bill = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.00e-6;
  console.log(m, u.prompt_tokens, u.completion_tokens, `$${bill.toFixed(4)}`);
}

Swap is one string. Run the loop over your top 20 real prompts, sum the bills, and the cheaper model on your traffic is right there in the totals. The bill formula is prompt_tokens × $0.95e-6 + completion_tokens × $4.00e-6 — the same on both models, so the only difference is how many completion tokens each emits.

r = client.chat.completions.create(
    model="kimi-k2.6",   # swap to kimi-k2.7-code -> error
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Describe this screenshot."},
            {"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}},
        ],
    }],
)

• Moonshot AI, Kimi K2.7 Code overview (kimi.com/resources/kimi-k2-7-code)
• Hugging Face, moonshotai/Kimi-K2.7-Code model card
• VentureBeat, coverage of the Kimi K2.7 Code launch
• Elliot Arledge, Kimi K2.7 Code vs K2.6 on KernelBench-Hard
• Moonshot AI, Kimi K2.6 release and model card