Kimi K2.7 vs Opus 4.8: Coding Duel & Cost

I sent the same coding tasks to Kimi K2.7 Code and Claude Opus 4.8 through one API and measured what came back. On correctness they tied: both nailed a SemVer precedence trap and a hidden interval-merge bug. But Opus answered 3–9× faster with a quarter of the output tokens, while Kimi cost about 46% less per task at list price. So the choice isn't about which model is "smarter." If you're running cost-sensitive or batch coding work, Kimi K2.7 wins on price. If you need low latency, a 1M-token context, or a final-review model you trust, Opus 4.8 is worth the premium, and many teams end up routing between the two.

Hands-on: I ran the same coding tasks through both

How I tested: model IDs kimi-k2.7-code and claude-opus-4-8, called through one OpenAI-compatible gateway endpoint on 2026-07-13, single-shot per task at default parameters with no prompt caching. Latency is wall-clock measured client-side, so it includes network and queue time, not just generation. Before scoring I asked each model to identify itself as a sanity check (Kimi returned "made by Moonshot AI," Opus returned Anthropic); that's a routing check, not proof of version. This is a two-task sample, not a benchmark. It shows behavior you can feel; it can't measure multi-turn agentic performance.

Task 1 asked each model to implement a compare_semver() function following the SemVer 2.0.0 spec, including the part most implementations get wrong: pre-release precedence, where 1.0.0-alpha.1 < 1.0.0-alpha.beta, numeric identifiers rank below alphanumeric ones, and beta.11 > beta.2 numerically rather than by string order. I graded each answer against a 72-comparison matrix built from the spec's canonical ordering. Task 2 handed over a buggy merge_intervals() function whose real defect was last[1] = cur[1] instead of max(...), a line that silently swallows a fully contained interval like [1,10],[2,3]; I graded against 5 cases including that contained interval.

Cost is computed from the token counts above at native list prices (Kimi $0.95/$4 per million in/out, Opus $5/$25): Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143. The input-token counts differ (172 vs 774) because each model's tokenizer and the gateway's accounting count the same prompt differently, not because the tasks differed. Both models produced fully correct code on both tasks. The gap was in how they got there. Opus was terse and fast, returning 418 tokens in 5.3 seconds on Task 1. Kimi took 49.1 seconds and emitted 1,907 tokens, much of it a step-by-step reasoning trace it returned alongside the code. Yet because Kimi's tokens are roughly 6× cheaper, the verbose run still cost less.

What the duel does and doesn't prove

It proves that on bounded, well-specified coding problems, Kimi K2.7 Code reaches the same correct answer as a frontier model. It does not prove Kimi matches Opus on long, multi-step agentic sessions, which two single-shot tasks can't exercise. Kimi's own strongest claim is precisely in that agentic territory, which the benchmarks below address directly.

Benchmarks: what's third-party vs Moonshot's own table

Here's the breakdown, with each number labeled by source. Moonshot's self-reported table is where Kimi looks strongest; independent evaluation is thinner because the model is recent, and where no third-party K2.7 number exists yet, the closest published figure is for K2.6 (marked below).

The one figure the comparison hangs on, MCPMark Verified 81.1 vs 76.4, comes from Moonshot's own table, not an independent lab. That's not a reason to dismiss it, since MCP-style tool use is exactly where Kimi was tuned. But read the "Kimi beats Opus" headline as a vendor claim on a vendor-optimized benchmark. On the one head-to-head measured by an outside party, Artificial Analysis puts Opus 4.8 well ahead on its Intelligence Index (56 vs 35), though that row uses K2.6 as a proxy because K2.7 hadn't been independently scored at the time of writing.

The context-window gap benchmarks hide

Opus 4.8 carries a 1M-token context window; Kimi K2.7 tops out at 256K. Benchmark scores rarely surface this, but it decides real work. A 256K window comfortably holds a mid-size repo and a long agent trace, and it's fine for the majority of coding sessions. You hit the ceiling when you're feeding an entire large monorepo, long document sets, or multi-hour agent transcripts into one prompt. There, Opus's 4× larger window is the practical difference, not a point on a chart.

Pricing: the 5–6× gap and the cache lever

At native API list prices, Kimi K2.7 Code runs $0.95 per million input tokens and $4.00 per million output; Claude Opus 4.8 runs $5 and $25. That's a 5–6× spread on output, and it's the headline reason teams evaluate Kimi at all.

The lever most pricing tables miss is caching. Kimi charges $0.19 per million tokens on a cache hit, an 80% discount on input you've already sent. In an agentic loop that re-reads the same codebase on every step, cached input dominates the bill, so the effective cost drops well below the sticker spread. Baseten's Philip Kiely reported roughly 82% savings on a sample workload after switching from Opus 4.8 to Kimi 2.7 Code, the kind of cache- and input-heavy job where Kimi's pricing compounds. Your number will move with your input-to-output ratio, but the direction is consistent: the more you re-read context relative to what you generate, the more Kimi wins on cost.

Opus earns its price back on the output side. It generated a quarter of the tokens Kimi did on my Task 1, so on generation-heavy work like writing large files or verbose refactors, the per-token gap narrows in real spend, and Opus's speed cuts wall-clock time you're paying an engineer to wait on.

The open-weights promise vs the 577GB reality

Kimi K2.7 ships as open weights under a modified MIT license, so you can self-host and fine-tune it. Opus 4.8 is API-only; your code and reasoning traces go to Anthropic. On paper that's a decisive privacy and lock-in advantage for Kimi. In practice, check the hardware bill first.

Kimi K2.7 is a 1-trillion-parameter Mixture-of-Experts model (32B active per token, 384 experts). Independent reviewers put a full INT4 deployment at roughly 577GB of VRAM once weights, KV cache, and runtime overhead are counted, which lands the minimum practical setup around 8× H100 80GB or a DGX Spark-class box. A single RTX 4090 (24GB) can't run the full model at usable settings. For all but a handful of well-funded teams, "open weights" means the freedom to route to a hosting provider or fine-tune on rented GPUs, not a model you stand up in-house. If your reason for choosing Kimi is on-prem data control, price the cluster before committing; for most teams, self-hosting stays theoretical.

Which one should you pick

Match the model to the workload rather than crowning a winner:

• Choose Kimi K2.7 Code for cost-sensitive, high-volume, or agentic coding where you re-read a codebase repeatedly, latency isn't critical, and a 256K context is enough. The caching discount compounds in your favor.

• Choose Claude Opus 4.8 when you need low latency, a 1M-token context for large repos or long sessions, terser output, or a final-review model to trust on high-stakes changes, where its lead on independent reasoning scores matters most.

The hybrid play: cheap model drafts, frontier model finishes

The most common pattern among teams running both isn't picking one, it's routing. Let Kimi K2.7 handle the bulk generation and iteration cheaply, then hand the result to Opus 4.8 for the final review or the parts that need frontier judgment. Kimi speaks the OpenAI format natively while Opus uses Anthropic's own API, so the practical way to route between them is a gateway that fronts both behind one OpenAI-compatible endpoint; on a platform like AIReiter, for example, both sit under a single key, making a Kimi-to-Opus switch a model-string change rather than a re-integration. The 82% savings above came from exactly this kind of routing, not from dropping Opus entirely.

FAQ

Is Kimi K2.7 better than Claude Opus 4.8 for coding?

On bounded, well-specified tasks they're even; in my test both returned fully correct code. Kimi's edge is agentic tool use (MCPMark 81.1 vs 76.4, Moonshot-reported); Opus leads on general reasoning, speed, and long-context work.

How much cheaper is Kimi K2.7 than Opus 4.8?

About 5–6× cheaper on list price ($0.95/$4 per million vs $5/$25). With cache hits ($0.19/M input) on repetitive workloads, real-world savings can reach 80% or more.

What is the context window of Kimi K2.7 vs Opus 4.8?

Kimi K2.7 handles 256K tokens; Opus 4.8 handles 1M, four times larger.

Can I run Kimi K2.7 locally?

Only with serious hardware. A full INT4 deployment is reported to need about 577GB of VRAM (roughly 8× H100 or a DGX Spark). A single consumer GPU like an RTX 4090 can't run the full model.

Is Kimi K2.7 open source?

It ships open weights under a modified MIT license, so you can self-host and fine-tune. Opus 4.8 is closed and API-only.

The bottom line

If your bottleneck is budget, default to Kimi K2.7 Code and let caching do the rest. If it's latency, context length, or a change you can't afford to get wrong, pay for Opus 4.8. Treat the open-weights license as a bonus you'll cash in only if you own the GPUs. And if you're not sure, wire up both and route by task instead of betting the workflow on one bet you'll have to unwind later.

Related reading

• Grok 4.5 vs Claude Opus 4.8

• Claude Sonnet 5 vs Opus 4.8

• GLM 5.2 vs Claude Opus 4.6