The Kimi K3 API arrived with an unusual combination behind it: frontier-adjacent benchmark results, aggressive pricing, and downloadable weights. Moonshot AI published those weights on 27 July 2026, which makes K3 the largest openly available model released so far and the first time a model at this scale has been something you could, in principle, run yourself.

For anyone already paying a frontier provider, that raises a practical question rather than a philosophical one. Does it belong in your stack, and what does moving traffic to it actually change? This guide covers the pricing arithmetic, the integration work, and the places where the headline numbers do not translate into production behaviour.

In short: Kimi K3 charges roughly $3 per million cache-miss input tokens, $0.30 per million cached input tokens and $15 per million output tokens, with a 1,048,576-token context window. It exposes an OpenAI and Anthropic-compatible interface, so switching a workload is largely a base URL and model name change. The catch is that thinking is always on and defaults to maximum effort, which makes output tokens the dominant line on your invoice unless you set it deliberately.

What Kimi K3 Actually Is

The architecture matters here because it explains both the pricing and the deployment constraints.

K3 is a sparse mixture-of-experts model with 2.8 trillion total parameters, of which roughly 104 billion are activated per token. It carries 896 experts and routes each token to 16 of them. That ratio is the reason a model of this size can be served at all: you pay the memory cost of the full parameter count but the compute cost of a much smaller one.

The attention design is the genuinely novel part. Moonshot built K3 on what it calls Kimi Delta Attention, a linear attention mechanism interleaved with periodic full-attention layers at roughly a three-to-one ratio, supported by a technique it terms Attention Residuals. The linear layers handle local sequence structure cheaply while the full-attention layers preserve global information flow. That combination is what makes a million-token context economically plausible rather than merely advertised.

Two operational details follow from the model card. Weights ship in MXFP4 with MXFP8 activations, and thinking is always enabled, meaning the model returns a reasoning_content field alongside its answer on every request. You cannot switch reasoning off. You can only choose how much of it to buy.

What the Kimi K3 API Costs

The published rates are straightforward, and the gap between them is where the interesting decisions live.

Cache-miss input runs at about $3 per million tokens. Cached input runs at about $0.30, a tenfold reduction. Output runs at about $15 per million. Unlike some providers, that pricing is flat across the entire context window rather than stepping up once you pass a threshold, which makes long-context work considerably easier to forecast.

Work through a realistic case. Suppose an agent handles a support workflow with a 40,000-token system prompt and knowledge preamble, adds 2,000 tokens of conversation, and produces 1,500 tokens of answer plus reasoning. Cold, that request costs roughly twelve and a half cents in input and just over two cents in output. Warm, with the 40,000-token prefix cached, the input cost collapses to under a penny and a half while the output cost is unchanged. At ten thousand requests a day, that difference is the entire economics of the feature.

Two lessons follow. First, structure prompts so that the stable material sits at the front and never changes, because caching only helps a prefix that stays identical. Second, watch the output side carefully, since reasoning tokens are billed as output and the effort setting defaults to maximum. Our guide to reducing LLM latency with caching covers the prefix discipline in more detail, and it applies here almost unchanged.

Integration Is Mostly a Base URL Change

Moonshot exposes K3 through an interface compatible with both the OpenAI and Anthropic conventions, which means the migration for most applications is genuinely small. Point your existing client at the Moonshot endpoint, set the model identifier to kimi-k3, and supply the new credentials. Code that already speaks either protocol will usually work unmodified.

Three differences are worth handling explicitly before you ship.

The first is reasoning_effort. K3 accepts a top-level field with values of low, high or max, and it defaults to max. Leaving the default in place on a classification or extraction task means paying for extended deliberation on work that needed none. Set it low for routine calls and reserve high or max for the requests that genuinely benefit.

The second is reasoning_content. Because thinking is always on, responses carry a reasoning field in addition to the answer. Your parsing code needs to know that field exists, your logging needs to decide whether to retain it, and your interface certainly should not display it by accident.

The third is the usual discipline that applies to any provider. Keep the credentials server-side, put the call behind your own proxy so you retain per-user metering and the ability to switch providers, and pin the model identifier rather than tracking a moving alias. The architecture we recommend for that layer is set out in our guide to OpenAI API integration , and it is deliberately provider-agnostic for exactly this reason.

The Million-Token Context, and When to Ignore It

A 1,048,576-token window is a genuine capability, and it is also the feature most likely to be misused.

It earns its place when the task truly requires whole-corpus reasoning: comparing a contract against every prior version, tracing a behaviour across an entire repository, or reconciling a long agent trajectory where earlier steps matter. In those cases, retrieval actively hurts, because the relevant fragment is defined by relationships the retriever cannot see.

It is the wrong tool for question answering over a document collection. Stuffing a million tokens into every request is slower and vastly more expensive than retrieving the four passages that matter, and accuracy on precise lookups is frequently worse rather than better. The honest rule is that large context is for problems where you cannot know in advance which part is relevant. Everything else still belongs in a retrieval pipeline.

Reading the Benchmarks Honestly

K3 scores well. On aggregate intelligence indices it sits just behind the leading proprietary frontier models while comfortably ahead of the previous generation, and it performs strongly on agentic and terminal-based coding evaluations. Reported figures include results in the high eighties on Terminal-Bench 2.1 and the low eighties on FrontierSWE.

Those numbers deserve a caveat that applies to every model, not just this one. Coding benchmark results depend heavily on the harness used to run them, and comparisons that mix harnesses can swing by ten to twenty-five points on identical models. A score produced with a vendor’s own agent scaffold is not directly comparable to one produced with a generic runner. When a table shows one model ahead of another, check whether both were evaluated the same way before drawing a conclusion.

The practical implication is that public benchmarks are useful for shortlisting and useless for deciding. Build a small evaluation set from your own traffic, run the candidate models through it with your own prompts and scaffolding, and compare on the work you actually do. Thirty to a hundred representative cases will tell you more than any leaderboard.

Where It Fits in a Production Stack

The sensible pattern in 2026 is routing rather than allegiance, and K3 slots into that pattern well.

Send high-volume routine work to a small, fast, cheap model. Send long-horizon agentic work, large-repository tasks and genuine whole-corpus reasoning to K3, where the context window and agentic performance earn the cost. Keep a frontier proprietary model available for the minority of requests where you need the best available answer and price is not the deciding factor.

The prerequisite is an abstraction layer that lets you move traffic between providers without touching application code. Teams that hard-code one vendor’s client throughout their codebase discover that switching costs weeks, which means they never switch, which means they never capture the saving. Build the seam first and the model choice becomes a configuration decision rather than a project.

One further consideration favours K3 specifically. Because the weights are published, a workload you build against the API can later move onto infrastructure you control without rewriting the application. That is a real strategic option, and it is covered in our companion guide to self-hosting Kimi K3 .

Get the Integration Built Properly

Mecanik builds production language model integrations across providers as part of our AI integration services . We handle the proxy and routing layer, prompt caching structure, effort tuning, evaluation harness and the cost controls that stop a promising feature turning into an unpredictable invoice.

If you are weighing a move to Kimi K3 from an existing provider, we will run your own traffic through both and show you the quality and cost difference before you commit to anything. For the wider commercial picture, our AI integration cost guide sets out what build and running budgets realistically look like. Full model specifications are published on the Kimi K3 model card .

Related reading: AI Agency vs In-House: UK AI Adoption in 2026 , Claude API vs OpenAI API: A Developer’s Comparison 2026 , DeepSeek R1 vs. OpenAI o3-mini: Which API is Best? and Does True AI Exist? Unraveling the Myths and Reality .

Frequently Asked Questions

How much does the Kimi K3 API cost? Published pricing is approximately $3 per million cache-miss input tokens, $0.30 per million cached input tokens and $15 per million output tokens, applied flat across the full context window. Because reasoning tokens bill as output and effort defaults to maximum, output is usually the dominant cost.

Is the Kimi K3 API compatible with OpenAI client libraries? Yes. Moonshot exposes an interface compatible with both the OpenAI and Anthropic conventions, so most applications migrate by changing the base URL, model identifier and credentials. Budget a little time for the reasoning effort field and the additional reasoning content returned on every response.

Can I turn off reasoning in Kimi K3? No. Thinking is always enabled and every response includes a reasoning content field. You control depth through the reasoning effort setting, which accepts low, high or max and defaults to max, so set it explicitly on routine tasks to avoid paying for unnecessary deliberation.

Should I use the million-token context instead of retrieval? Only when the task genuinely requires reasoning across a whole corpus, such as tracing behaviour through an entire repository. For question answering over a document set, retrieval remains faster, cheaper and often more accurate than filling the context window on every request.

How reliable are Kimi K3’s published benchmark scores? The scores are real but harness-dependent. Coding evaluations can vary by ten to twenty-five points depending on the agent scaffolding used, so results produced with a vendor’s own harness are not directly comparable to generic runners. Validate against your own tasks before deciding.