Kimi vs Claude: Open Weights, Real Costs, Current Models

Model versions and prices verified August 28, 2026 against vendor documentation.

Key takeaways - Kimi is open weight and cheap per token. Claude is closed and steadier across long multi-step tasks. - Every article ranking for this comparison benchmarks models that are a generation or two old. - Cheaper per token is not the same measurement as cheaper per task. Token efficiency can erase the gap. - Cache reads dominate real agentic bills, and almost nobody prices them. - Self-hosting 1T open weights is real, and it needs a GPU cluster plus vLLM or SGLang.

The short answer

Kimi wins on price and on control. Claude wins on consistency when a task runs for twenty minutes across a dozen tool calls. If you are paying a coding subscription and watching the meter, Kimi will genuinely take a large share of that workload off your bill, and it will occasionally cost you an afternoon on the tasks where reliability matters most.

The evidence supports using both, chosen per task. The practical question is: if the right model changes per task and the prices move every few weeks, what should your system actually be built around?

Not the model. We will come back to that.

What Kimi actually is

Kimi is Moonshot AI's model family. The current lineup in Moonshot's own pricing documentation is kimi-k3, kimi-k2.7-code, kimi-k2.7-code-highspeed, kimi-k2.6, kimi-k2.5, and the older moonshot-v1 line. K3 is the flagship at a 1,048,576-token context window; the K2.7 Code models are the coding-tuned tier.

Kimi is open weight, which is a narrower claim than open source. You can download the checkpoint, run it on your own hardware, and inspect what you are serving. You cannot inspect the training data or the pipeline that produced it. Moonshot's own K2.6 model card carries a Modified MIT License and describes a Mixture-of-Experts architecture at roughly 1 trillion total parameters, about 32 billion active per token across 384 experts, deployed via vLLM, SGLang, or KTransformers.

That architecture is why the pricing works. Only a small slice of the network runs per token, so serving cost stays far below what a trillion-parameter label suggests.

What Claude actually is

Claude is Anthropic's closed frontier family, tiered by capability. The current lineup is Claude Fable 5 at the top, Claude Opus 5 for complex agentic coding, Claude Sonnet 5 for the speed and intelligence balance, and Claude Haiku 4.5 as the fast tier. Fable 5, Opus 5, and Sonnet 5 all carry a 1M-token context window with 128K max output; Haiku 4.5 sits at 200K.

You cannot download any of them. What you get instead is a specific kind of reliability: the model that finishes a long agentic run in roughly the same shape every time, and a tooling surface built around that assumption. Closed does not mean worse value. Sonnet 5 at $2 per million input tokens is not priced like a luxury good.

The differences that matter

| Dimension | Kimi | Claude | |---|---|---| | Current flagship | kimi-k3 (Moonshot docs) | Claude Opus 5, with Claude Fable 5 above it (Anthropic docs) | | Input, per 1M tokens | $3.00 (K3); $0.95 (K2.6 and K2.7 Code) | $5.00 (Opus 5); $2.00 (Sonnet 5) (pricing) | | Cached input, per 1M tokens | $0.30 (K3); $0.16 (K2.6); $0.19 (K2.7 Code) | $0.50 (Opus 5); $0.20 (Sonnet 5) | | Cache write, per 1M tokens | Not separately priced | $6.25 5-minute, $10.00 1-hour (Opus 5) | | Output, per 1M tokens | $15.00 (K3); $4.00 (K2.6 and K2.7 Code) | $25.00 (Opus 5); $10.00 (Sonnet 5) | | Context window | 1,048,576 tokens (K3); 262,144 (K2.6, K2.7 Code) | 1M tokens (Fable 5, Opus 5, Sonnet 5); 200K (Haiku 4.5) | | Open weights | Yes. Modified MIT License per Moonshot's model card | No | | Self-hostable | Yes, via vLLM, SGLang, or KTransformers | No | | Agentic posture | Coding-tuned variants; strong on self-contained scope | Adaptive thinking on by default; built for sustained tool-use loops | | Notable limitation | Token efficiency per task is worse, which narrows the per-token discount | No weight access, so no air-gap and no on-prem option |

Three rows change decisions. The cached-input row, because that is where agentic money actually goes. The open-weights row, because it is binary and it decides the question for anyone with a residency requirement. And the last row, because a per-token discount that gets spent on extra tokens is not a discount.

Notice also that Moonshot's own documentation describes K2.6 as a "256k" model while the pricing table gives 262,144 tokens. Both refer to the same window. If a comparison article quotes you three different context figures for one model, that is a signal about the rest of its numbers.

What the comparisons get wrong

Three things, none of them subtle.

They benchmark stale models. The pages ranking for this query test K2.6 against Claude Opus 4.6 and 4.7 and Sonnet 4.6. Moonshot now ships K3 and K2.7 Code. Anthropic now ships Opus 5, Sonnet 5, and Fable 5, with Opus 4.6 through 4.8 marked legacy. Those articles were accurate in the spring. They describe a matchup that no longer exists.

They cite benchmarks that trace to one source. Two of the ranking pages report identical SWE-Bench Pro figures, 58.6 for Kimi against 53.4 for Claude, neither with a citation. Identical numbers on two pages read as corroboration. They are one vendor launch card restated twice. A third page leans its whole recommendation on a 0.6-point SWE-Bench Verified gap, which sits inside the noise of any harness and should not move anyone's decision. Every benchmark number needs a name, a link, and a note about the scaffold that produced it. None of these have all three.

They price the headline rate and ignore the cache. This is the expensive one.

The real cost comparison

Composio's head-to-head build is the only first-hand measurement on the page-one results, and its most useful number is one it does not dwell on. Building the same app twice, it logged 2.8 million cache-read tokens on the first task and 22.3 million on the second. Those are single tasks.

Run those volumes against each vendor's published cached-input rate:

| Cache reads on one task | Claude Opus 5 at $0.50/1M | Claude Sonnet 5 at $0.20/1M | Kimi K2.6 at $0.16/1M | Kimi K3 at $0.30/1M | |---|---|---|---|---| | 2.8M tokens | $1.40 | $0.56 | $0.45 | $0.84 | | 22.3M tokens | $11.15 | $4.46 | $3.57 | $6.69 |

At full input price rather than cached, that 22.3M read would cost $111.50 on Opus 5. The cache is doing an order of magnitude of work, and it decides whether an agentic session costs three dollars or thirty. A comparison quoting only headline per-token rates describes a small fraction of the bill.

Then the other direction. One r/kimi thread reports a $100 plan exhausted in roughly two days, the poster attributing it to the model spending more tokens per task. Composio's data points the same way: on the first task Kimi wrote 4,671 lines to Claude's 1,688 for the same brief, and needed debugging afterward. Cheaper per token, more tokens per job. The discount is real and smaller than the sticker suggests.

We will not publish a total-cost figure for a representative workload, because we cannot derive one honestly from these inputs. Composio's numbers are n=2, one author, one harness, no repeats. Measure your own.

What self-hosting open weights actually costs

Open weights are genuinely downloadable, and downloading them is the easy part. A checkpoint with roughly a trillion total parameters does not fit on one accelerator. You are provisioning a multi-GPU node, standing up vLLM or SGLang, and then owning the parts nobody advertises: batching, KV cache management, upgrades, and someone on call when a node drops mid-inference. Moonshot's own SGLang deployment example simply claims every GPU on the host. A defensible dollar-per-hour figure depends on GPU type, utilization, region, and serving configuration, so this article does not assign one.

Self-hosting makes sense in two cases. Data residency or air-gap requirements leave no other path, and cost stops being the deciding variable. Genuinely high, steady volume amortizes the fixed cost. For everyone else, Moonshot's hosted API is the same weights without the pager.

When you want each

| Scenario | Lean toward | Why | |---|---|---| | High-volume bulk classification | Kimi K2.6 or K2.7 Code | The task is short, the output is small, and the per-token gap compounds across millions of calls without much room for token-efficiency drift | | Long multi-step agentic coding task | Claude Opus 5 | Composio's measured failure was a third-party API integration across many steps, which is exactly the shape where consistency beats price | | Data residency or air-gap requirement | Kimi, self-hosted | Open weights are the only option that satisfies it. Nothing in Claude's lineup can be run on your own metal | | Latency-sensitive interactive feature | Claude Haiku 4.5 or Kimi K2.7 Code Highspeed | Both vendors have an explicit speed tier. Test both against your p95, because published rates say nothing about tail latency |

If you land on both, which most teams will, the practical requirement is that routing between models sits behind one interface. The coding agents compared question and another frontier model comparison both resolve the same way.

The Major take

The "use both" answer creates a constraint. If the right model changes per step, per task, and per month as prices and versions move, every one of those changes is a migration whenever model-specific behavior is spread through prompts and application logic. The deeper problem sits underneath the routing decision: the reasoning is re-run on every request either way. A cheaper token only slows the bleeding.

Major resolves this in two moves. First, the deterministic app layer makes the model an input rather than a dependency. When an agent on Major works out how to handle a repeatable piece of work, it builds an app for that part, with real code, a managed database, storage, and audit logs, and calls a model only for the judgment that needs judgment. Moving a step from Claude to Kimi then changes one input behind a boundary. The workflow, its data, and its history are untouched.

Second, less of the work runs through a model at all. Because the repeatable portion executes as code instead of a fresh round of reasoning, the token bill stops scaling with usage. Front-loaded, then flat. That is a structural argument rather than a per-token one, and it survives the next repricing on either side.

When the models are this close and this cheap to swap, the durable advantage is in what does not have to be re-reasoned. Reason once, run forever. It is also why building an agent that survives a model swap turns into a question of coordinating models and the app layer rather than picking a winner today.

If you are already routing bulk classification to Kimi and hard reasoning to Claude, the next thing worth building is the layer underneath that routing: the app that holds the workflow, its state, and its audit trail while the model behind any given step changes. Major gives an agent the ability to build that app itself, governed and production-ready from the first deploy. Build your model-routing workflow on Major and let the agent turn the repeatable half into code.

Related articles

• LLM Router: Routing Strategies and Their Real Limits
• Grok vs ChatGPT: Key Differences and a Reversible Choice
• AI Orchestration: Coordinating Models, Agents, and the App Layer

Related articles

• AI Coding Agent: What Happens After the Code Is Written
• Grok vs Gemini: Pricing, Context, and Which One to Wire In
• Grok vs Claude: How to Choose (and Why You Shouldn't Commit)