I Compared Claude Fable 5 and Kimi K3. Kimi Costs a Third.

Switching is one line, because the API is OpenAI-compatible.

This is the detail that decides whether the price gap is even worth thinking about, and it is buried in the docs rather than the marketing. Moonshot serves an OpenAI and Anthropic compatible API. You do not rewrite anything. You point the client somewhere else:

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "..."}],
)

A base URL, a key and a model name. That is the entire migration for most code.

Which matters more than it sounds, because it changes the shape of the decision. You are not picking a model to marry. You are picking a default, and keeping the other one a config change away. Anyone telling you to commit to one is describing a problem you do not have.

Two more model names worth knowing on that endpoint: kimi-k2.7-code-highspeed if your job is mostly code generation and you want throughput over depth, and kimi-k2.6 for the older general model. Moonshot's own docs say to start with kimi-k3 unless you have a reason not to.

K3 always thinks. You control how much.

K3 has no non-thinking mode — reasoning is always on. What you get instead is a dial, set per request:

{
  "model": "kimi-k3",
  "reasoning_effort": "low",
  "messages": [...]
}

It takes low, high or max, and the default is max.

That default is worth pausing on, because thinking tokens are output tokens and output is the expensive leg at $15 per million. If you benchmark K3 against Fable 5 on defaults, you are benchmarking K3 at its most expensive and slowest setting. A lot of "K3 wasn't actually that much cheaper for me" comes from leaving this alone.

For simple, high-volume work — classification, extraction, formatting, routing — low is usually the right setting and the cost difference is large. Save max for the work that genuinely needs it.

Two newer API features on K3 are also worth a look if you are building agents: tool choice constraints (tool_choice), which force or forbid particular tool calls, and dynamically loaded tools, which let you avoid shipping every tool definition on every request. Both attack the same cost problem from the input side.

It is a big model that only runs a small part of itself.

The price is not a subsidy or a loss-leader trick. It comes out of how the model is built, and the architecture is public because the weights are.

K3 is 2.8 trillion parameters in total — but only 104 billion are used for any given token. It is a mixture-of-experts design with 896 experts, of which 16 are picked per token. You are paying for the 104 billion that ran, not the 2.8 trillion that exist.

The second saving is in the attention layers, which are what make long context expensive. K3 mixes two kinds across its 93 layers: 69 layers of Kimi Delta Attention and 24 layers of Gated MLA — roughly three cheap layers for every expensive one. The stated effect is up to a 75% cut in KV-cache memory, which is the thing that balloons when your context gets long.

That last row is easy to skim past. K3 is natively multimodal — it takes video, not just images. Limits are 4K resolution for images and 1080p for video.

They trade wins. Fable 5 trades slightly more of them.

Across the fourteen benchmarks both vendors publish head to head, Fable 5 wins eight and K3 wins six. On GDPval-AA v2 the ordering is clearer: Fable 5 first at 1760, K3 fourth at 1684.

K3's own published scores give you a sense of where it is strong:

Read the 8–6 split carefully, because it is not "Fable 5 is better." It is that they trade wins and Fable 5 takes slightly more. A near-even split across fourteen tasks, at a third of the price, is not a close race on value.

So the useful question is not which model is better. It is which of the fourteen you are actually buying — and that is a question about your work, not about the models. Take the last ten real jobs you gave an agent, not demos, and see which categories they fall into. That is a twenty-minute exercise and it beats any head-to-head video, including this one.

Kimi is slower, and on an agent loop that costs you differently.

Price is not the only running cost. Independent measurement puts Claude Opus 4.8 at 56.4 tokens per second against Kimi K3 at 44.0 on maximum effort — Claude is meaningfully faster, and K3 is at the slower end even among open-weight models of its size.

That matters in a specific place. If you are running batch work overnight, speed is close to irrelevant and the price gap wins easily. If you are sitting in an interactive agent loop waiting for each turn, a 20–25% slower model is something you feel all day, and the money you saved is not the thing you are spending.

There is a compounding version of this. K3 always reasons, and the default effort is max — so out of the box you get the slowest setting of the slower model. A lot of "I tried Kimi and it felt sluggish" is that default, not the model. Setting reasoning_effort to low on simple work changes both the speed and the bill.

One caution if you go reading reviews: some from earlier in the summer state that only max is available and that low and high are "announced for later." Moonshot's current documentation lists all three, which we read directly on 10 August 2026. Check the docs rather than the reviews on this one.

It holds up on ordinary work and falls off on the hard stuff.

The most useful thing in the independent reviews is not a score, it is the shape of the failure. The repeated finding is that K3 performs close to Opus 4.8 on straightforward coding, then drops off sharply on harder and more adversarial tasks.

That is a much more actionable description than a benchmark average, because it is not a uniform gap you can discount against — it is fine, fine, fine, then suddenly not. Which means the cost saving is real on the bulk of your work and the risk is concentrated in the small part that is genuinely difficult.

That shape argues for a specific setup rather than a choice: cheap model as the default, expensive model reserved for the things you already know are hard. Since both speak the same API, that routing is a config decision rather than a migration.

And it is worth being fair about where K3 genuinely leads. It is the largest open-weight model released, and it has taken the top spot from Fable 5 on at least one frontend coding arena since launching. "Cheaper and slightly behind" is the average; it is not true everywhere.

Fable 5 was switched off for nineteen days.

This is on Anthropic's own newsroom and it belongs in any honest version of this comparison:

Nineteen days. Not degraded service — unavailable, for reasons outside the vendor's control and nothing to do with how good the model is. No benchmark column captures that.

It is worth being fair about what this shows. The suspension happened because Anthropic ships a model capable enough to attract that kind of scrutiny, and the response — a classifier, a public explanation, a dated timeline anyone can read — is what you would want a vendor to do. This is not a scandal.

But if you are choosing what to build on, "can be switched off by a government directive" is a real property of the product, and it is the kind of thing that only shows up once. The model whose weights you can download has a different failure mode from the one that only exists behind someone's API.

There is a smaller everyday version of the same trait. Fable 5 routes a narrow band of sensitive requests to Claude Opus 4.8 instead of answering directly, which Anthropic says happens in under 5% of sessions. Refusals around voice cloning and likeness are the ones people hit and complain about. That is a deliberate design decision rather than a bug — but if your work sits inside that band you will meet it, and no benchmark reports it.

You can download one of them.

K3's weights are published on Hugging Face under the Kimi K3 License, covering both code and weights. Fable 5 is closed and API-only.

For most people this is an abstraction they will never use, and it is worth saying plainly why: serving a 2.8-trillion-parameter model is a serious infrastructure project, not a weekend. The recommended engines are vLLM, SGLang and TokenSpeed, with MXFP4 weights and MXFP8 activations for quantised serving. For almost everyone, the API price is the real price.

Open weights stop being abstract in exactly two situations: when availability becomes the problem, and when the data cannot leave your building. If neither applies to you, treat it as a tiebreaker rather than a feature.

A million tokens of context, and a 90% discount for repeating yourself.

The headline comparison understates the difference for the most common kind of agent work, and it is worth understanding why before you benchmark anything.

K3's context window is 1,048,576 tokens — a real megabyte-scale window, priced flat with no separate long-context tier. Whatever you put in it costs the same rate as a short prompt.

Then there is caching. Repeated input drops from $3.00 to $0.30 per million — a 90% discount on anything the model has already seen.

Those two facts together matter because of how agent work is actually shaped. A coding agent, a support bot, a document pipeline — they all send the same large block over and over: the system prompt, the tool definitions, the codebase, the policy document. Only the last bit changes.

Two practical consequences. Put the stable content first and the changing content last — caching works on a shared prefix, so a variable timestamp at the top of your prompt can quietly destroy the hit rate for everything after it. And measure your real cache-hit ratio before deciding anything; it is the number that determines whether you are paying $3.00 or $0.30, and most people have never looked at it.

Fable 5 also has prompt caching, so this is not a K3-only advantage — it is a reminder that the sticker prices at the top of this page describe the worst case for both models, and the ranking between them can widen or narrow depending on how repetitive your work is.

Pick on your constraint, not on someone's bake-off.

• Volume is what hurts — take K3, and set reasoning_effort deliberately instead of leaving it on max. At a third of the price you can afford to run a job twice and keep the better answer, and still pay less than one Fable 5 run.
• Your work is the hardest thing on the list — pay for Fable 5. A cheaper model that gets your most important task slightly wrong is not cheaper.
• You cannot tolerate an outage — keep both configured. This costs almost nothing given the shared API, and June is the argument for it.
• You are running a long, repetitive loop with a stable prefix — check K3's $0.30 cached rate against your real cache-hit ratio. This is where the gap gets much wider than 3.3×.
• Your inputs include video — K3 takes it natively.
• You do not know yet — run both on your last ten real jobs. Both are cheap enough that the test costs less than the time spent reading comparisons.

Honest limits.

• We did not run the two models against each other. The prices, architecture and dates are from primary sources. The 8–6 benchmark split is reported by the vendors. Treat the framework as a way to design your own test, not as a verdict.
• Benchmarks are vendor-chosen. Fourteen benchmarks that both vendors decided to publish is a filtered set by construction.
• Nothing here is a speed measurement. No figure above is tokens per second, and on an interactive agent loop latency often matters more than price.
• Prices exclude tax, which Moonshot's page states explicitly.
• Anthropic's prompt-caching discount is not included in the comparison. It exists, but we did not confirm the rate on a vendor page, so the cached row above only shows K3.
• Model lineups shift. Moonshot's own docs note the older Moonshot V1 series is expected to sunset on 31 August.

The price question is settled. The dependency question is the real one.

Kimi K3 is a third of the price on both legs, takes video, publishes its weights, and loses a near-even benchmark split. Fable 5 is stronger on more of the hard tasks and spent nineteen days in June switched off.

Because they share an API, you do not have to choose in the way these comparisons imply. Default to the cheap one, set the reasoning dial on purpose, and keep the expensive one one line away for the jobs that need it.

Everything above, traceable to a primary source.

• platform.kimi.ai Moonshot AI — Kimi K3 pricing table ($0.30 cached / $3.00 input / $15.00 output)
• platform.moonshot.ai Moonshot AI — Kimi K3 quickstart and model list
• huggingface.co Hugging Face — moonshotai/Kimi-K3 (open weights and model card)
• moonshot.ai Moonshot AI
• anthropic.com Anthropic — Claude Fable 5 and Claude Mythos 5 (launch, $10 / $50)
• anthropic.com Anthropic — Redeploying Fable 5 (the export-control suspension, 12–30 June 2026)
• anthropic.com Anthropic — Claude Fable
• anthropic.com Anthropic — pricing
• goldiebench.com Goldie Bench — Fable 5, one-shot scores
• claudecodexmastery.space The Kimi K3 model card, scrolled — architecture and licence in the vendor's own words
• claudecodexmastery.space Anthropic's Fable page, scrolled