Kimi K3 vs Claude pricing: the real cost

The list price for Claude Opus 5 is $5.00 per million input tokens. Across 5,848 requests we ran through it on client and internal repositories, we paid an effective $0.67. That is not a discount and not a negotiated rate. It is what happens when 97% of the input tokens in a request are a prefix the provider has already processed.

This is why comparing Kimi K3 against Claude by reading two pricing tables produces the wrong answer. The published rate is one input into the bill. Cache-hit rate, output length, how many attempts a task takes, and whether your tool can route cheap work to a cheap model all move the number more than the sticker does. The unit that matters is cost per accepted task, not cost per token.

Token price is not task price

A single request can contain several differently priced components:

• uncached input tokens
• cache-write tokens, where the provider charges separately for creating the cache entry
• cache-read tokens
• output tokens, including billable reasoning tokens
• tool calls, search, storage and other platform charges

request_cost =
    uncached_input × uncached_rate
  + cached_input   × cache_read_rate
  + cache_writes   × cache_write_rate
  + output         × output_rate
  + tool_costs

Even that is not the metric you buy. A model that needs three attempts to land a change is not comparable to one that lands it on the first, however cheap its tokens are:

cost_per_accepted_task = total_model_and_tool_cost / accepted_tasks

For a business, the honest version also carries the expensive part:

true_task_cost = model_cost + tool_cost + reviewer_time + correction_time

At Greek and EU rates, an hour of senior review costs more than most teams spend on model tokens in a week. Any optimisation that trades review time for token savings is going the wrong way.

A cache hit is a prefix match, not a memory

Context caching does not mean the provider remembers your topic. It means a previously processed prompt prefix can be reused. Consider the shape of an agent request:

flowchart TB
    subgraph P["Stable prefix · cached"]
      direction TB
      A["System instructions"]:::b
      B["Tool definitions"]:::b
      C["Project rules · repo context"]:::b
      D["Earlier conversation"]:::b
    end
    P --> E["New instruction<br/><i>changes every turn</i>"]:::out
    E --> R["Billed: cache-read rate for the prefix<br/>full input rate for the tail"]:::res
    classDef b fill:#494fdf,stroke:#376cd5,color:#ffffff,stroke-width:2px
    classDef out fill:#1e293b,stroke:#64748b,color:#f1f5f9,stroke-width:1.5px
    classDef res fill:#0f172a,stroke:#94a3b8,color:#f1f5f9,stroke-width:1.5px

The load-bearing word is prefix. A new question appended at the end does not destroy the cache. A single changed byte near the beginning invalidates everything after it, which is why a timestamp in a system prompt is one of the most expensive characters you can type.

Both providers reward the same request architecture, with different mechanics. Kimi caches automatically and asks only that the long prefix stays unchanged; its documentation states that a previous request must exceed 256 tokens before a later request can hit the prefix cache. Anthropic supports automatic caching for growing conversations plus explicit cache breakpoints, with five-minute and one-hour options, and a minimum cacheable prefix of 512 tokens on Opus 5, down from 1,024 on Opus 4.8.

Neither rewards sending similar information in a different order. Stable and large first, changing and small last.

What a 97% cache-hit rate looks like on a real bill

Here is our own usage, read out of the local agent transcripts rather than estimated. It covers 5,848 model requests across seven repositories between 30 July and 4 August 2026, almost entirely Claude Opus 5, during ordinary development and content work.

Out of 811.7 million input tokens, we paid the headline $5.00 rate on 64,000 of them. Output over the same period was 4.7 million tokens.

Priced at published rates with the five-minute cache-write rate, that comes to roughly $659: about $394 in cache reads, $146 in cache writes, $118 in output, and 32 cents of uncached input. The same token volumes with no caching at all would have cost about $4,177. The effective input rate works out at $0.67 per million against a $5.00 list price.

Two things in that breakdown are worth more than the saving itself.

Output is not discounted, and it dominates faster than you expect. Output was 0.58% of our token volume and 18% of the bill. Push the cache-hit rate to 99% and output becomes the majority of what you pay. Any comparison that stops at input rates is measuring the part that caching has already made cheap.

Session length decides the hit rate. Our long-running sessions in a single repository sat at 98–99% cache reads. The shortest project in the set, 21 requests against this website, sat at 78%, because the cache write is amortised over far fewer turns. The first request in any session is the expensive one. A workload of many short sessions and a workload of few long ones have different economics on identical prices.

These are our own development sessions, not a benchmark, and the mix is one flagship model. Read them as the shape of the effect, not as a forecast of your bill.

The published prices, as of 4 August 2026

Rates per one million tokens, excluding taxes and platform charges.

Three observations follow immediately.

Kimi K3 and standard-priced Claude Sonnet 5 carry identical input, cache-read and output rates. Caching alone does not separate them.

Both platforms price a cache hit at roughly one tenth of normal input. The mechanism is worth the same on either side.

Comparing Kimi K3 only against Claude Opus 5 is a mismatched comparison. Kimi ships K2.7 Code and K2.6 below K3; Anthropic ships Haiku, Sonnet and Opus, with Fable 5 above Opus at $10 / $50. Both families have cheap options. The real question is whether your tool exposes them.

What a cache-hit rate is worth

Ignoring the initial write, the effective input rate is:

effective_rate = hit_ratio × cached_rate + (1 - hit_ratio) × uncached_rate

For Kimi K3:

At 90% hits, Kimi K3 input costs $0.57 instead of $3.00. Standard-priced Sonnet 5 follows exactly the same curve, because its rates are the same. This is why a large input-token count does not imply a large bill. The bill depends on how much of that input is new.

An API processing unrelated invoices, contracts or CVs sits at the top of that table rather than the bottom. Instructions and schemas still cache; the document does not. Cache savings shrink as the share of unique input grows, and a shared API key changes nothing either way. Request structure decides the hit rate, not key hygiene.

A six-turn session, priced six ways

Assume a stable 100,000-token project prefix, 5,000 new input tokens per turn, 2,000 output tokens per turn, six turns, prefix cached after the first request, Anthropic priced at the five-minute write rate. This is a cost model, not a benchmark.

Kimi K3 is cheaper than Opus 5 for identical token volumes, which is unsurprising given the published rates. But an Anthropic workflow can still be cheaper than a Kimi K3 workflow, because a task that does not need Opus can run on Haiku at $0.27. And Kimi K2.7 Code lands at $0.27 too, so “Anthropic supports cost optimisation and Kimi does not” would be false. The defensible claim is narrower: a tool that exposes routing gives you more cost control than a tool that pins every task to one flagship model.

Intelligence shows up in the bill as retries

Take our measured volumes and price them on Kimi K3 instead: roughly $378 against $659, a 43% saving. That number is precisely the one you cannot act on, because it assumes the identical number of attempts, the identical amount of output, and the identical amount of our time. Change any of the three and it inverts.

The arithmetic is unforgiving. A model at $0.12 per attempt that averages 1.8 attempts costs $0.216 per accepted task. A model at $0.20 that lands on the first attempt costs $0.20. More expensive per run, cheaper per result, and that is before anyone’s review time enters the calculation.

Public benchmarks capture this badly, because the difficulty in real work is not in the algorithm. It is in understanding an existing architecture, following local conventions, touching only the files that need touching, recognising that an attempted fix did not work, responding usefully to a failing test, and producing a change a human is willing to merge.

If you want a defensible comparison, log these:

attempts_per_task
accepted_without_correction
accepted_after_correction
abandoned_or_escalated
human_minutes_per_task

Routing is where the savings actually are

Not every step needs the strongest model. A document pipeline can extract fields with a small model, validate deterministically for type, format and plausibility, and escalate to a stronger model only when validation fails. A coding workflow can search files and summarise logs cheaply, implement routine changes in the middle tier, and reserve the flagship for architecture, hard debugging and final review.

routed_cost = cheap_model_work + escalation_rate × strong_model_work + validation_cost

At a 10% escalation rate, the flagship price applies to 10% of the workload. This turns pricing into an orchestration question, and it is worth separating three layers that pricing arguments routinely collapse:

• Model family: cheaper and stronger models exist. True on both sides.
• Product: your agent, CLI or subscription actually lets you select them.
• Workflow: you validate, escalate and measure, so routing decisions are informed.

Deterministic validation deserves special mention. Replacing a second model call with a type check is the only cost optimisation on this page that also increases reliability.

Subscriptions and APIs are different products

A subscription does not convert cleanly into a token rate. It bundles usage behind message quotas, rolling windows, model allowances and provider-side context management, and the provider is free to cache, compact and route internally without exposing the accounting.

API pricing is measurable because you can log token categories and request outcomes. A subscription is better judged at the outcome level:

monthly_price / accepted_tasks_or_productive_hours

The two can be compared, but only there. Pretending a subscription contains a known number of ordinary API tokens produces a confident number with nothing behind it.

What to measure before you switch

Run a representative workload and collect four things.

Workload shape: average stable-prefix tokens, average changing input, average output and reasoning tokens, how context grows across a session, and what share of requests process unrelated content.

Cache behaviour: cache-read, uncached and cache-write tokens with their TTL, hit share by task type, and which prefix changes are causing misses. If your provider reports these fields, this is a one-hour job. Ours took a single pass over the local transcripts.

Quality: attempts per accepted task, first-run acceptance, escalation rate, human correction minutes, regressions and abandoned tasks.

Routing and operations: which tasks can drop a tier, which genuinely need the flagship, whether validation can replace a model call, whether batch latency is acceptable, and whether your tool exposes model selection at all.

Then compare on the metrics you actually buy: cost per accepted task, per productive session, per merged change, per verified document. None of these fit in a pricing table, which is exactly why pricing tables keep producing the wrong answer.

The cheapest model is the one that finishes the task

Kimi K3’s list price does not tell you whether Kimi K3 is expensive, and Claude Opus 5’s list price does not tell you whether an Anthropic workflow is expensive. The shape of the work decides.

A stable coding session reuses a large cached prefix and gets dramatically cheaper after the first request, as our 97% hit rate and $0.67 effective input rate show. A document API with mostly unique input sees little of that benefit. A stronger model earns its rate by avoiding retries. A routed system sends extraction and search to cheap models and keeps flagship intelligence for the difficult tail.

So the questions worth asking are: how stable is your context, what share of input actually hits cache, how many attempts does an accepted result take, how much output and hidden reasoning does the task generate, can the work be routed, and how much human correction does each model create.

If you want that instrumentation on your own workloads rather than an estimate, tell us what you are running and we will measure it with you.

Sources

• Kimi K3 pricing
• Kimi K2.7 Code pricing
• Kimi context caching guide
• Claude API pricing
• Claude prompt caching
• Claude Code cost management

Prices and product capabilities change often. Verify against provider documentation before acting on any figure here. Our measured numbers come from our own agent transcripts for 30 July to 4 August 2026 and are directional, not a benchmark.