Moonshot AI Kimi K3

Kimi K3 — Moonshot AI’s 2.8-trillion-parameter flagship, on a 1,048,576-token window, with thinking that cannot be switched off, cache writes billed in two tiers, and a limitations section the vendor wrote about itself

Start with what this page is measuring. Kimi K3 is the model Moonshot AI publishes as its flagship, documented on two platforms in two currencies, with a technical report, a released weight set, a forty-row benchmark table and a separate limitations section. Everything below is read from those pages, and three kinds of statement are kept apart throughout. What the official documentation writes down as specification is one set. What this workspace has actually switched on in the chat box above is a second set, and it is narrower. What the first-party client applications do with the model is a third, and it contains an entry for K3 that the API pages never mention. Where the vendor’s own pages disagree with each other, both readings are given rather than merged.

Explore the model guide
Kimi K3

What is Kimi K3?

Kimi K3 is a 2.8-trillion-parameter model built on Kimi Delta Attention and Attention Residuals, with native vision and a context window the vendor writes as one million tokens. Moonshot AI describes it as the first open model to reach that scale, which is a statement about the open-weight field rather than about benchmark placement. The mixture-of-experts configuration activates 16 of 896 experts, and the vendor puts the overall gain in scaling efficiency at roughly 2.5 times the previous generation, Kimi K2. Those architectural claims and the benchmark table on this page come from the same artefact, the technical blog published with the launch. Two relationships are worth fixing before anything else. First, the weight release is a completed event rather than a promise: the blog wrote that the full weights would be released by 27 July 2026, the vendor’s own news index carries an entry dated 27 July 2026 announcing an open day for the weights, the technical report and the infrastructure work, and the repository holding those weights is live and ungated, laid out across 96 shards under a licence named after the model. Second, the context window and the billing unit are not the same number. The pricing table lists the billing unit as 1M tokens and its footnote defines that 1M as 1,000,000, while the context column beside it reads 1,048,576. They are close and they are not equal, and treating one as the other understates the window by about five per cent.

What Kimi K3 is worth using for

A window four times the K2 family’s

The context window is 1,048,576 tokens, which the vendor’s prose rounds to one million and the pricing table prints in full. The two Kimi K2 pages on this site both carry 262,144, so the flagship multiplies the reach by four rather than adding to it. The pricing page also keeps its billing unit separate, printing 1M tokens in one column and defining that 1M as 1,000,000 in a footnote underneath, so the two figures should not be read as one. What the workspace above does with the number is narrower still. It shows no context figure at all, because the catalogue this site reads carries no context field for this model, which makes the window a documented ceiling rather than a gauge you can watch during a session.

Suggested prompt
I am going to paste a large set of files and then ask questions across all of them. Read everything before answering anything. For each answer, tell me which file you relied on, which part of my question the material did not settle, and where you would have needed a file I did not provide.

Reasoning that cannot be turned off, and a dial that can

There is no non-thinking mode here. The documentation states that K3 always reasons, and the FAQ answers the question about switching the chain of thought off with a refusal and then points at a different control. That control is reasoning_effort, which accepts low, high or max and sits at the top level of the request rather than inside a thinking block. The two official surfaces disagree about where it starts: the API documentation says max is the default, and the first-party client’s model list says high. Reasoning is also preserved across turns, so the trace from earlier messages has to be sent back intact on every follow-up and is billed as input, which turns a long session into a running cost. The workspace above displays the thinking switch and greys it out, and it exposes no effort dial, so none of the three settings is reachable from this page.

Suggested prompt
Keep a running decision log as we work. After every step, restate the constraints you are still honouring, the assumptions you have added since my last message, and anything earlier in this conversation you are no longer certain about. Stop and ask me when the next step would depend on something the earlier turns did not establish.

A billing dimension the K2 table does not have

Context caching is automatic on ordinary requests, and it is billed in three parts rather than two. Input that hits the cache is charged at the lower rate, input that misses it is charged at the full rate, and writing a prefix into the cache is a separate charge with two tiers of its own, one for a five-minute lifetime and one for an hour. No lifetime is specified by default, which means the shorter tier applies, and each hit renews the entry without another write charge. Caching works in blocks, so a prefix that does not fill a whole block cannot be stored and counts as a miss. The comparison table further down this page shows the same dimension from the other side: the K2-series rows printed directly beneath the K3 row have no cache-write column at all, because before this generation the charge did not exist.

Suggested prompt
I will send the same long reference document together with a series of short questions. Tell me which parts of the document are worth keeping at the very front of the conversation so the repeated context stays reusable, and flag anything in my question set that would force the whole prefix to be rebuilt from scratch.

The limits the vendor publishes about itself

The technical blog carries a limitations section, and it is specific in a way that launch material usually is not. Three statements matter more than the benchmark rows. The first is that K3 was trained on preserved thinking history, so if a harness fails to return all of that history, or if a session already under way is switched to K3 partway through, output quality can become highly unstable, and the vendor recommends harnesses whose compatibility has been verified. The second is that the training emphasis on long and difficult tasks makes the model prone to deciding on the user’s behalf when a request is ambiguous, with the published remedy being explicit behavioural constraints in the system prompt or in AGENTS.md. The third is the vendor’s own assessment that the model, competitive as it is overall, shows a noticeable gap in user experience against two named rivals. A page that repeated only the wins would be dropping the parts the vendor chose to write down.

Suggested prompt
Before you start, write the operating rules you will hold yourself to for this task: what you may decide on your own, what you must ask me about first, and what counts as outside the scope. Then do the task, and at the end list every point where you came close to overstepping.

Official Kimi K3 specifications

Identifier
kimi-k3
Parameters
2.8 trillion, mixture of experts activating 16 of 896 experts
Architecture
Kimi Delta Attention (KDA) and Attention Residuals (AttnRes)
Context window
1,048,576 tokens, written as 1M in the vendor’s prose; the billing unit is a separate 1,000,000
Output ceiling
max_completion_tokens defaults to 131,072 and can be raised to 1,048,576
Thinking
Always on; reasoning_effort accepts low, high or max — API default max, first-party client default high
Sampling parameters
temperature 1.0, top_p 0.95, n 1, both penalties 0.0 — fixed, and the vendor advises not sending them
Context cache
Automatic, with write pricing in two tiers, a five-minute lifetime and one hour
Input modalities
Text, images and video; no public image URLs, so base64 or an uploaded file id
Licence
Weights and code under the Kimi K3 License
Kimi Platform · Kimi K3 quickstart ↗

Kimi K3 and GPT 5.6 Sol on the vendor’s own benchmark table

Every value below is read from a single page — the full benchmark table in the Kimi K3 technical blog, which prints Kimi K3 in one column and five comparison models in the others, all under the same effort setting. The table runs to forty rows across coding, agentic work, reasoning and vision. Eight of those rows are reproduced here, and they were chosen on one criterion only, that neither column carries a footnote. The comparison model is GPT 5.6 Sol, which this site also covers, so the two columns can be checked against their own pages afterwards. Read the rows and the shape is honest rather than flattering: Kimi K3 takes two of the eight and loses six. The two it takes are the long-horizon coding marathon and the browsing benchmark. The six it loses cover single-shot software engineering, terminal work, a general-agent rating, tool use through the model context protocol, graduate-level science questions and a multimodal reasoning set. The rows that go against the model are kept rather than filtered out, because a table that showed only the wins would no longer be a reading of the vendor’s page.

Official benchmarkKimi K3GPT 5.6 Sol
DeepSWE · Coding67.573.0
Terminal Bench 2.1 · Coding88.388.8
SWE Marathon · Coding42.039.0
GDPval-AA v2 · Elo-score · Agentic1,6681,748
BrowseComp · Agentic91.290.4
MCP Atlas · Agentic84.283.6
GPQA-Diamond · Reasoning & Knowledge93.594.1
MMMU-Pro · Vision81.683.0
Kimi Platform · Model inference pricing ↗

How to use Kimi K3 online

  1. Bring the whole task, not a fragment

    Thinking is mandatory here and its reasoning is preserved across turns, which makes the model a poor fit for one-line questions that expect one-line answers and a good fit for a task with a shape. State the outcome you want, the constraints that cannot move, the evidence you want cited, and the condition under which the model should stop and ask instead of deciding for you. Because earlier reasoning stays in context and is billed like any other input, a long session is a running cost, so it is worth starting a fresh conversation when the problem changes rather than carrying an unrelated history forward. The vendor states one more precondition plainly: a harness that has not been verified to return the full thinking history can destabilise the output, and switching a live session over to this model mid-way is a specific case to avoid.

  2. Decide what the window is actually for

    The million-token ceiling is a documented property of the API and, as the specification cards above show, this interface does not display a context figure at all, so plan as if you had less room rather than more. On the official side the way to reach that window is a request body, not an upload widget: images and video go in as base64 or as a file identifier, public image URLs are refused outright, and caching stores prefixes in blocks, so a document that is slightly too short to fill a block is not cached at all. On this page the attachment control accepts JPEG, PNG, WebP and PDF at up to 24 MB, which means long documents are the practical way to use the window here and video is not.

  3. Set the boundaries before the run, not after

    The vendor’s own limitations section names over-proactiveness as a failure mode, and names its remedy as explicit constraints written into the system prompt or into AGENTS.md. That advice transfers directly to a chat box. Write the rules as the first message rather than as a correction after the model has already acted, say which decisions you want to make yourself, and say what should happen when the request is ambiguous. It costs one message and it addresses the one weakness the vendor chose to publish, which is the useful kind of instruction to take from launch material.

  4. Read the price as two meters, not one

    Kimi K3 is reachable two ways and they are measured differently. On the API it is billed per token with the cache-write tiers above, and access itself is gated: the calling guide states that the platform must be topped up before the model unlocks and that the new-user voucher does not apply to it. Inside the first-party client the same model appears under two identifiers with different context ceilings and different plan requirements, and a subscription allowance is quoted in consumption terms rather than in tokens. Nothing here converts into either currency, and this page bills in points against a catalogue reference price.

What Kimi K3 costs, and which official number belongs to which meter

Two official price tables describe this model and they are not interchangeable, so they are kept apart here. The first is the China platform in yuan per million tokens, and it is the table the comparison above is drawn from: cache writes at ¥20 for the five-minute tier and ¥40 for the hour, input at ¥2 when the cache is hit and ¥20 when it is missed, and output at ¥100, with a context window of 1,048,576 tokens. The second is the same table on the international platform in US dollars, and it repeats the shape rather than the numbers: $3, $6, $0.30, $3 and $15 across the same five columns, with the same window, and a note that those prices exclude applicable taxes. The shape is the part worth pausing on. This row has five priced columns and the K2-series rows printed beneath it have three, because the two cache-write tiers are new here, and reading the K3 line as though it were a more expensive version of the K2 line would miss the column that did not previously exist. Two further official rules attach to the rates. Entry to the model is gated on a top-up, with the calling guide naming a minimum of 10 yuan, and the sign-up voucher is explicitly excluded from this model. The rate limits that govern throughput are account-level, set by cumulative top-up rather than by model, so they belong to the account and not to this page. No official page attaches a date, a campaign window or an introductory price to any of these rates, and both tables were checked on 8 October 2026. Nothing above is this site’s checkout price. This site bills in points against a catalogue reference price of 509.6525 points per million input tokens, 2548.2626 per million output tokens and 50.9653 per million cached read tokens, and there is no conversion between points and either currency.

View points and plans ↗

Kimi K3 FAQ

Is Kimi K3 open source, and where are the weights?

Yes, and the release is a fact rather than a plan. The vendor’s model page states that the model is open source, that the full weights are available on a repository, and that the weights and the code are released under the Kimi K3 License, which permits running, deploying, fine-tuning and modifying the model subject to its terms. The launch blog wrote that the weights would be released by 27 July 2026, and the vendor’s own news index carries an entry dated 27 July 2026 announcing an open day for the weights, the technical report and the infrastructure work. The repository itself is live and ungated, and it holds 96 weight shards under a licence named after the model. A technical report on the model was submitted to arXiv on 27 July 2026 and revised on 7 August 2026.

Can I turn thinking off?

Not on this model, and not through the API either. The documentation states that K3 always reasons, and the FAQ that asks how to switch the chain of thought off answers that it cannot be switched off at present. What can be changed is the depth: reasoning_effort accepts low, high or max at the top level of the request, and the recommended workaround for output that feels too slow is to lower the effort rather than to disable reasoning. There is one further detail worth knowing, because it decides how a session has to be run: reasoning is preserved, so the full assistant message from every earlier turn has to be sent back intact, and it is billed as input.

What is the cache-write charge, and why is it not on the K2 rows?

Because the charge did not exist before this generation. The K3 row of the pricing table has five priced columns, and two of them cover writing a prefix into the context cache, one priced for a five-minute lifetime and one for an hour. The K2-series rows printed directly underneath have three priced columns and no cache-write column at all. Caching itself is automatic, a hit is billed at the lower input rate, and each hit extends the entry without a further write charge. Two practical consequences follow: a prefix that does not fill a whole block cannot be cached and counts as a miss, and leaving the lifetime at its default means five minutes, which is long enough for a follow-up question and short enough that a long pause rebuilds the prefix.

How much more expensive is Kimi K3 than the K2 models?

The output rate is the clearest comparison, and it is roughly three and a half to four times the K2-series rate: 100 yuan per million tokens against 27.00 for the two K2 rows on the same page, or 15 dollars against 4.00 on the international table. Cache-hit input moves from 1.30 to 2 yuan, and cache-miss input from 6.50 to 20. Two things keep that from being the whole story. The window is four times larger, at 1,048,576 tokens against 262,144, and the cache-write tiers are an entirely new line item rather than a repricing of an existing one. So the honest reading is that the flagship costs more on every column, and also does something on one column the earlier generation never did.

How much context do I get here?

The official window is 1,048,576 tokens, which the vendor writes as one million, and the billing unit is defined separately as 1,000,000 tokens. This interface displays no context figure at all, because the catalogue it reads carries no context field for this model, so any number you see quoted for this page is the documented ceiling rather than a live reading of a session. The workspace does not display a context field for any model, so this is not a property of Kimi K3 alone but of how this site reads its catalogue.

Is Kimi K3 better than GPT 5.6 Sol?

On the vendor’s own forty-row benchmark table, over the eight rows reproduced on this page, Kimi K3 wins two and loses six. It leads on the long-horizon coding marathon and on the browsing benchmark, and it trails on single-shot software engineering, terminal work, a general-agent rating, tool use through the model context protocol, graduate-level science questions and a multimodal reasoning set. There is a further official statement worth weighing alongside the table, and it is the vendor’s own: the technical blog states that the model shows a noticeable gap in user experience against two named competitors. This page does not publish a ranking of its own, and it does not treat a benchmark row as a prediction about your own task.

Can I use Kimi K3 in the first-party client instead of the API?

Yes, and this is where the official pages disagree in an interesting way rather than contradicting each other. The client’s model list puts K3 behind a subscription across two identifiers, one with the full million-token window and one limited to 262,144 tokens, with the larger consuming about twice the quota of the smaller and video input available only on the larger. It also states that both identifiers default to the high reasoning effort, whereas the API documentation says the default is max, so the two surfaces ship with different starting points even though the parameter has the same three values. On the API side the same model is reached with a key after a top-up. Neither route is a substitute for the other, and the client is the only one that this page cannot bill through.

Do these rates have an expiration date?

None is published. The China pricing table and the international pricing table were both checked on 8 October 2026, and neither attaches a date, a campaign window or an introductory price to this model’s rates. The rate limits that govern throughput are described as subject to temporary adjustment when cluster load reaches capacity, which is a statement about availability rather than about price. Read the figures as current at the last edit rather than as guaranteed, and note that no promotional figure for this model was found on any official page, which is why none appears here.

Sources and model information

Information checked

Start a Kimi K3 conversation

The chat box above runs this model, and this page is written to be checked rather than trusted. The specifications come from the official calling guide, the comparison comes from the forty-row benchmark table in the vendor’s technical blog, the pricing comes from the two official tables that print the same row in two currencies, and the limits of this workspace come from the code that runs it. Where the two sides disagree, the page says so in the sections above instead of quietly writing the official number next to this interface. Where the vendor disagrees with itself, both readings are given. The three most useful facts on the page are also the three least repeated elsewhere: that cache writes are billed in two tiers, that thinking cannot be switched off at all, and that the vendor has published a limitations section naming what the model does badly.

Start a chat with Kimi K3 ↑