Table of Contents
Kimi K3 review: pricing, coding benchmarks, and when to switch your agent's model
Moonshot AI shipped Kimi K3 on July 16, and for the first time an open-weight model tops the benchmark that tracks real agentic coding: SWE Marathon, where K3 posts 42.0 against Claude Fable 5's 35.0 and GPT-5.6 Sol's 39.0 on Moonshot's own suite (MarkTechPost, July 16). The API is live now, the weights go public by July 27 (Simon Willison, July 16), and the pricing has one number that changes the math for coding agents: cache-hit input at $0.30 per million tokens. If your agent reloads the same repo context on every step, that is where the switch pays for itself. The short version, and the rest of this review defends it: for a coding-agent operator running long, tool-heavy sessions, K3 is the pick today. For a developer firing short one-shot prompts, it is not, and the reason is buried in the output pricing.
Kimi K3 is a sparse mixture-of-experts model with 2.8 trillion total parameters, but it activates only 16 of its 896 experts per token, so the per-token compute sits closer to a 16-billion-parameter model than a 2.8-trillion one (MarkTechPost). Two changes matter for coding. Kimi Delta Attention gives up to 6.3x faster decoding at million-token contexts, and the model ships a 1M-token window with native vision. Access runs through the OpenAI SDK against a Moonshot base URL, which is the detail that makes it a drop-in swap for most agent stacks. Moonshot is candid that overall it still trails Fable 5 and Sol; the interesting part is the specific tasks where it does not.
Pricing: what a coding loop actually costs
K3 uses flat pricing with no tiering by context length. Cache-hit input is $0.30 per million tokens, cache-miss input is $3.00, and output is $15.00 (MarkTechPost). The cache-hit rate is the whole game, and Moonshot reports above 90% cache hits in coding workloads, where the agent resends the same file map and system prompt on every call.
| Model | Input, cache miss | Input, cache hit | Output | Source |
|---|---|---|---|---|
| Kimi K3 | $3.00 | $0.30 | $15.00 | MarkTechPost |
| Claude Fable 5 | $10.00 | caching available, rate not published | $50.00 | Anthropic docs |
| GPT-5.6 Sol | $5.00 | ~$0.50 (90% off cached reads) | $30.00 | Crypto Briefing |
All figures per million tokens, pulled 2026-07-17. Sol's cache-hit figure is derived from its published 90% cached-read discount; Fable 5 supports prompt caching but Anthropic has not published a Fable-specific cached rate.
Now the number the pricing page will not give you. Take a team running 500 agentic coding sessions a day. Assume each session loads 100,000 tokens of repo context with 90% served from cache, and produces around 12,000 output tokens. Those token counts are an illustrative workload, not a measurement; the per-token rates come from the sourced table above. The math is worth showing rather than asserting:
Example: cost per coding session at the table's per-token rates
Kimi K3 90,000 cache-hit @ $0.30/M = $0.027
+ 10,000 cache-miss @ $3.00/M = $0.030
+ 12,000 output @ $15.00/M = $0.180
= $0.237 / session -> ~$3,555 / month at 500 sessions/day over 30 days
GPT-5.6 Sol with the 90% cached-read discount applied
= ~$0.455 / session -> ~$6,825 / month
Claude Fable 5 at sticker input (no published cache rate)
= ~$1.60 / session -> ~$24,000 / month
Monthly gap, K3 vs Sol: ~$3,270 (about $39,000 / year)Even after you hand Sol its cache discount, K3 comes in at about half the monthly cost, and the reason is the output rate: K3 bills output at the lowest rate of the three in the table above. Once your context is cached, output is where the money goes, and K3 starts from the lowest base. The yearly gap versus Sol is enough to cover a contractor invoice or a small team's whole tooling budget.
Here is the candid con, and it is a real one. K3 has a single reasoning effort, max, and it is heavy. Willison watched it spend 13,241 reasoning tokens to produce 3,417 tokens of visible output on a trivial prompt, and even a bare hi billed 86 input tokens, pointing to an 85-token hidden system prompt (Simon Willison). For short prompts with no long cached context, that reasoning overhead is pure output cost, and it erases the advantage. The savings above are real only when the context is long and the cache is warm.
Where Kimi K3 leads, and where it does not
The benchmark scores below are Moonshot's self-reported suite with reasoning effort set to max, so read them as vendor numbers (MarkTechPost). Two independent signals back the direction: Artificial Analysis put K3 behind only Fable 5 on its long-horizon knowledge-work evaluation, and Arena's Frontend Code arena had it leading, ahead of Fable 5 (Simon Willison). The split is clean enough to draw a line down the middle: agentic loops on one side, hard single-shot problems on the other.
Where K3 leads: the long-session agent operator
On the agentic tasks, K3 is out front. SWE Marathon rewards a model that browses a real repo, writes a patch, and runs tests across many steps, and K3's 42.0 beats Fable 5's 35.0 and Sol's 39.0. BrowseComp, the web-browsing agent test, has K3 at 91.2 against Fable 5's 88.0, though that run used context compaction at 300K tokens; without it K3 scores 90.4. Program Bench (77.8) and Automation Bench (30.8) both edge out the two frontier models by a hair. The pattern is consistent: multi-step work that fits inside the 1M window, with tool calls and browsing, is K3's home turf.
The persona this fits: you run a coding agent that opens a repo, holds the module graph and test suite in context, and grinds through a refactor over twenty minutes with minimal supervision. That is the workload where the SWE Marathon lead and the cache-hit pricing compound in your favor.
Where Fable 5 and Sol still lead: the hard single-shot problem
Flip to single-shot difficulty and the ranking flips too. On FrontierSWE, hard software-engineering problems, Fable 5 takes 86.6 to K3's 81.2. DeepSWE goes to Sol at 73.0 against K3's 67.5. And on HLE-Full, the hardest reasoning set, Fable 5's 53.3 clears K3's 43.5 by ten points. One caveat cuts against Fable here: its scores use a fallback that routes refused requests to Opus 4.8, so part of that number is a second model covering for the first.
The persona this fits: you throw one genuinely hard algorithmic problem at the model and want one strong answer on the first try, not a long agent loop. For that, Fable 5 is still the pick on the FrontierSWE and HLE numbers above, and Sol edges it on the pure DeepSWE-style tasks.
How to use K3 right now
You have three ways in, and none of them require waiting for the weights.
The lowest-friction path is OpenRouter, which proxies the model without a Moonshot account. Willison used exactly this route with the llm CLI:
llm -m openrouter/moonshotai/kimi-k3 'Generate an SVG of a pelican riding a bicycle'The native Kimi API is an OpenAI-SDK call with the base URL swapped. Note the constraints: reasoning_effort accepts only max, the thinking parameter from the K2 line must not be used, and temperature, top_p, and n are fixed, so omit them (MarkTechPost).
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
completion = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="max",
messages=[{"role": "user", "content": "Refactor this module for testability."}],
)
print(completion.choices[0].message.content)Because K3 speaks the OpenAI protocol, any IDE agent that accepts a custom endpoint runs it with one config change. In Cline, add an OpenAI-compatible provider, set the base URL to https://api.moonshot.ai/v1, paste your Moonshot key, and set the model to kimi-k3. That is the entire integration.
{
"provider": "openai-compatible",
"baseUrl": "https://api.moonshot.ai/v1",
"apiKey": "<YOUR_MOONSHOT_API_KEY>",
"model": "kimi-k3"
}Send a first request and confirm the shape before you wire it into a real loop. On a small prompt you should see a completion plus a reasoning-token count in the usage block that dwarfs the visible output; that is expected on max effort, and it is your early signal that short prompts will cost more than the sticker input rate suggests.
The July 27 self-hosting question
When the weights drop by July 27, the pitch is that you can run K3 yourself and drop the API bill. Run the math honestly and that pitch only holds at high volume.
Start with memory, because sparse activation does not help you here. Activating 16 of 896 experts cuts the compute per token, not the storage: you still hold all 896 experts in memory. At the MXFP4 quantization Moonshot trains for, 2.8 trillion parameters is roughly 1.4TB of weights before you add the KV cache for a 1M-token context. This is why Moonshot recommends supernode configurations of 64 or more accelerators, not a single card (MarkTechPost). One saving grace: Kimi Delta Attention makes the long-context decode fast enough to be practical, and Moonshot contributed a prefix-caching implementation to vLLM, so the serving stack exists.
On a cloud GPU host the smallest node that fits is an 8-GPU box with enough pooled VRAM for that 1.4TB. DigitalOcean's 8x AMD Instinct MI300X droplet gives 1,536GB of GPU memory at $1.88 per GPU per hour, and the newer 8x MI350X pushes that to 2,304GB, which leaves real headroom for the KV cache (DigitalOcean GPU pricing, pulled 2026-07-17). Run the MI300X node around the clock and it costs about $11,000 a month.
Put that next to the API. At our 500-sessions-a-day example workload, the always-on MI300X node runs roughly three times the K3 API bill from the pricing section above, before you account for whether one node can even serve 500 long-context sessions with acceptable latency. Break-even against a single always-on node lands near 1,500 sessions a day, and at real concurrency you would need more than one node, which pushes it higher still. Self-hosting K3 is a control-and-data-residency decision, not a cost decision, until your volume is well past that line. For teams that do clear it, or that need the weights on their own hardware for compliance reasons, DigitalOcean's H100 and MI300X droplets are the entry point to price the GPU compute against the API estimate above.
One footnote for the self-host shortlist: Thinking Machines Lab released Inkling on July 15, an open-weight MoE with 975 billion total parameters and about 41 billion active (TechCrunch, July 15). K3 has the higher benchmark ceiling, but Inkling's roughly 490GB of 4-bit weights fit a single 8x H100 node with room to spare, so if single-node self-hosting is the goal, it belongs on the same evaluation list.
Which teams should switch
Sort yourself by workload, not by the top-line benchmark.
If you run a coding agent with long-context loops, 100,000-plus tokens of context reloaded on every call, switch to K3 now. The cache-hit pricing and the SWE Marathon lead both point the same way, and the savings versus Sol run to a few thousand dollars a month at 500 sessions a day.
If you write short, rapid-fire prompts under about 8,000 tokens, stay on Sol or Fable 5. K3's cache savings are small on short context, and the 13,000-plus reasoning tokens it burns per call add both cost and latency you will feel.
If you throw hard single-shot algorithmic problems at the model and want one strong answer on the first try, Fable 5 is still the pick on FrontierSWE and HLE, with Sol close behind on DeepSWE.
If you are on Cline or Continue and already point at an OpenAI-compatible endpoint, try K3 through OpenRouter this week. The migration cost is one config line, and you will know inside an afternoon whether your workload is the long-context kind that benefits.
If open-source control is the reason you are here, wait for the July 27 weights, price a multi-node GPU cluster honestly, and only pull the trigger if your session volume is past roughly 1,500 a day; otherwise the API is cheaper and simpler.
The one thing worth doing before July 27, whatever you decide: point Cline at the Kimi API through OpenRouter and run one real agent session on your own repo, so your switch call rests on your cache-hit rate and your output-token count, not on Moonshot's benchmark table.