Kimi-K3
Kimi K3 is the first open model in the three-trillion-parameter class — 2.8 trillion total, 104 billion active, a million tokens of context, and native vision. Two architectural bets carry it: Kimi Delta Attention paired with Attention Residuals, and a sparsity framework that selects sixteen experts from eight hundred and ninety-six, together delivering roughly two and a half times the scaling efficiency of the previous generation. Thinking is permanently on with three effort levels, and the model was trained in preserved-thinking-history mode — meaning your client must send its reasoning back on every turn, not as an optimisation but as a requirement.

Kimi K3
2.8 trillion parameters. 104 billion active. A million tokens of context. The world's first open model in the 3T class.
Announced 16 July 2026; weights released 27 July under the Kimi K3 License.
⚠️ You Must Send the Reasoning Back
The integration requirement, and the thing that breaks silently if you get it wrong.
Kimi K3 was trained in preserved thinking history mode. Not offered as an option — trained in it.
NVIDIA's model card states the consequence as an instruction: for multi-turn conversations and tool
calls, clients must pass back the complete assistant message, including reasoning_content and
tool_calls.
# Correct — the whole object goes back
conversation.append(message)
# Broken — reasoning_content is discarded, and nothing errors
conversation.append({"role": "assistant", "content": message.content})The failure mode is the dangerous kind. Turn one works. Turn two works, badly. Nothing raises, nothing logs, and the degradation looks like the model being worse than advertised rather than like a bug in your loop.
Three things follow.
Replayed reasoning is billed as input tokens. The consistency this buys has a measured cost on
every subsequent turn, and it compounds across a long agent session. Watch prompt_tokens growth on
your first real run rather than estimating it.
Some harnesses drop reasoning_content. It has been reported as a real failure across serving
stacks. On a model that requires the field, dropping it is not a cosmetic bug.
Verify before you build. Send two turns, print prompt_tokens on the second, and confirm it
includes more than the visible text. That measurement takes a minute and settles whether your path
handles this model correctly.
Thinking Is Always On
No off switch. No instant mode. Every request reasons and returns reasoning_content.
Effort is set with a top-level reasoning_effort field — not a template argument, not a system
prompt string:
| Level | |
|---|---|
low | |
high | |
max | Default |
The default is the deepest setting. A request that omits the field runs at maximum deliberation, which is the most expensive configuration available.
That inverts the usual expectation and it is worth acting on: set the level explicitly on every path,
and treat max as a choice rather than a fallback.
Contrast with the previous generation, which shipped a separate Instant mode for latency-bound work. That option is gone here. If your application has a fast path, it needs a different model — this one has a single gear, and the gear is deep.
Architecture
| Total parameters | 2.8T |
| Activated per token | 104B |
| Layers | 93 — 69 KDA, 24 Gated MLA |
| Experts | 896 routed, 16 selected, 2 shared |
| Attention | Kimi Delta Attention with Attention Residuals |
| Sparsity framework | Stable LatentMoE |
| Vision encoder | MoonViT-V2, ~401M parameters |
| Vocabulary | 160K |
| Quantisation | MXFP4 weights, MXFP8 activations |
| Context | 1,048,576 tokens |
Sixteen of 896 experts — under two percent of the routed pool. That sparsity is what makes a 2.8-trillion-parameter model deployable at all.
Sixty-nine KDA layers to twenty-four Gated MLA. Roughly three to one: linear attention carries most of the depth at constant state cost, with full latent attention placed where exact retrieval matters. A million-token window is affordable because most of the stack never builds a growing cache.
Attention Residuals is the second architectural bet, named alongside KDA as the reason for the jump.
Moonshot credits the combination with approximately 2.5× better scaling efficiency than the previous generation — not a bigger model doing the same thing, but a different curve.
Quantisation Applied From SFT Onward
A detail worth pausing on.
Quantisation-aware training is applied from the supervised fine-tuning stage onward, using MXFP4 weights with MXFP8 activations, chosen for broad hardware compatibility.
Most models are trained at full precision and quantised afterwards, leaving the conversion cost undocumented — you get benchmark numbers from one configuration and weights from another. Here the model learned at the precision it ships in, so the evaluated model and the downloaded model are the same thing.
Specifications
| Model ID | moonshotai/Kimi-K3 |
| Context length | 1,048,576 tokens |
| Input | Text, image |
| Output | Text |
| Reasoning | Always on |
| Effort levels | low, high, max — default max |
| Thinking history | Preserved — required |
| Tool calling | Native, with dynamic tool loading |
| Licence | Kimi K3 License |
| Weights released | 27 July 2026 |
Capabilities
| Capability | Value |
|---|---|
input_types | text, image |
output_types | text |
context_window | 1048576 |
reasoning | Always enabled |
effort_levels | low, high, max |
reasoning_field | reasoning_content — must be replayed |
thinking_disable | Not supported |
streaming | Supported |
tool_calling | Native, dynamic tool loading |
structured_output | Supported |
partial_mode | Supported |
context_caching | Supported |
requires_prompt | Yes — text prompt required, image optional |
⚠️ The Licence Has Commercial Thresholds
Not MIT, not Apache, and the differences are quantified rather than vague.
The Kimi K3 License carries three clauses worth reading before you deploy commercially:
A Model-as-a-Service revenue clause tied to a twenty-million-dollar threshold.
An attribution clause triggered at one hundred million monthly active users or twenty million dollars in monthly revenue.
An internal-use exemption, which is the clause that matters most for the majority of deployments.
For most companies none of these bind. The thresholds are large. But they exist, they are specific, and a licence with numbered conditions is a different object from a permissive one — read it against your actual deployment rather than assuming it behaves like Apache 2.0.
Benchmark Conditions
Moonshot publishes their evaluation methodology, and the details change how the numbers read.
| Multimodal scores | Averaged over three runs |
| ZeroBench | Five runs, per the official setting |
| MMMU-Pro | Official protocol — original input order preserved, images prepended to text |
| PerceptionBench | In-house benchmark — atomic visual perception |
Averaging over three runs is more honest than a single figure, and it is not universal practice.
The MMMU-Pro detail is a prompting instruction in disguise. Images prepended to the text input, original order preserved — that is the arrangement the reported score was produced under. If your integration appends images after the question instead, you are not running the configuration that was measured.
PerceptionBench is in-house and unreleased. Treat its result as a claim rather than a verifiable measurement, the way you would any vendor benchmark without a public test set.
Reported Results
| Benchmark | Score |
|---|---|
| FrontierSWE | 81.2 |
| Terminal-Bench 2.1 | 88.3 |
Independent evaluation places the model at 44 on the Artificial Analysis Intelligence Index v4.3, narrowly behind the leading open model on that index at the time of measurement.
Across the thirty-three public rows in Moonshot's launch table, one analysis found the model first or tied-first on eight, ahead of every other open model on essentially all of them, and generally within a few points of the closed frontier.
That is the honest summary: leading the open field, close to but not at the closed frontier.
Using Kimi K3 on DEVUP AI
Base URL: https://api.devupai.com/v1 · Model ID: moonshotai/Kimi-K3
A single request — Python
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
response = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=[
{"role": "user", "content": "Hello world!"}
],
max_tokens=16384,
extra_body={"reasoning_effort": "high"},
)
message = response.choices[0].message
trace = getattr(message, "reasoning_content", None)
if trace:
logger.debug("reasoning: %d characters", len(trace))
print(message.content)reasoning_effort is set explicitly rather than left to default — the default is max, and on a
single-turn question that is rarely what you want.
A multi-turn conversation, done correctly — Python
The pattern this model requires.
conversation = [
{"role": "user", "content": "Outline three approaches to sharding this order table."}
]
for follow_up in [
None,
"Take the second approach and describe the migration path.",
"What breaks if we run both schemes during the transition?",
]:
if follow_up:
conversation.append({"role": "user", "content": follow_up})
response = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=conversation,
max_tokens=32768,
extra_body={"reasoning_effort": "high"},
)
# The whole message object, reasoning included. Rebuilding it breaks the model.
conversation.append(response.choices[0].message)
usage = response.usage
print(f"in {usage.prompt_tokens:>8,} · out {usage.completion_tokens:>7,}")Watch the input column. It grows faster than the visible conversation does — that difference is the replayed reasoning, and it is billed as prompt tokens. Seeing the actual shape on your own prompts is the difference between budgeting for a long session and discovering its cost at the end of one.
An agent loop — Python
import json
TOOLS = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file relative to the repository root.",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_tests",
"description": "Run the test suite and return pass/fail counts with failure output.",
"parameters": {"type": "object", "properties": {}},
},
},
]
def read_file(path: str) -> dict:
"""Replace with your real, sandboxed file access."""
raise NotImplementedError
def run_tests() -> dict:
"""Replace with your real, sandboxed test runner."""
raise NotImplementedError
HANDLERS = {"read_file": read_file, "run_tests": run_tests}
session = [
{"role": "user", "content": "The DZD invoice test fails on totals ending in .005. Find the cause and fix it."}
]
CEILING = 50
for step in range(CEILING):
response = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=session,
tools=TOOLS,
max_tokens=32768,
extra_body={"reasoning_effort": "high"},
)
message = response.choices[0].message
session.append(message) # complete object — reasoning_content and tool_calls both required
if not message.tool_calls:
print(message.content)
break
for call in message.tool_calls:
handler = HANDLERS.get(call.function.name)
if handler is None:
outcome = {"error": "unknown tool", "name": call.function.name}
else:
try:
outcome = handler(**json.loads(call.function.arguments or "{}"))
except Exception as exc:
# Failures go back as data. The model reasons around them.
outcome = {"error": type(exc).__name__, "detail": str(exc)}
session.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(outcome)})
else:
print(f"Stopped at the {CEILING}-step ceiling.")high rather than max on a fifty-step loop. Every step reasons — that is not optional here —
and the default would run all fifty at maximum depth. Reserve max for the single hardest question
rather than for a sustained session.
Verifying your path handles the model correctly — Python
Worth running once before you build anything on it.
def check_reasoning_replay() -> None:
"""Confirm reasoning_content is returned and travels back into the next request."""
conversation = [{"role": "user", "content": "Think about why 2+2=4, then answer."}]
first = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=conversation,
max_tokens=4096,
extra_body={"reasoning_effort": "low"},
)
message = first.choices[0].message
trace = getattr(message, "reasoning_content", None)
if not trace:
raise RuntimeError("no reasoning_content returned — this model always produces it")
conversation.append(message)
conversation.append({"role": "user", "content": "Now explain it differently."})
second = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=conversation,
max_tokens=4096,
extra_body={"reasoning_effort": "low"},
)
print(f"turn 1 input: {first.usage.prompt_tokens:,}")
print(f"turn 2 input: {second.usage.prompt_tokens:,}")
print(f"trace length: {len(trace):,} characters")Two failure signals. No reasoning_content on turn one means something in the path is stripping
it — a known issue across serving stacks, and fatal for a model that requires the field. Turn-two
input barely above turn one means the reasoning is not making it back, even though the field
arrived.
Node.js
import DevupAI from "devupai";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
async function main() {
const response = await client.chat.completions.create({
model: "moonshotai/Kimi-K3",
messages: [{ role: "user", content: "Hello world!" }],
max_tokens: 16384,
reasoning_effort: "high",
});
console.log(response.choices[0].message.content);
}
main();cURL
curl -X POST "https://api.devupai.com/v1/chat/completions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "moonshotai/Kimi-K3",
"messages": [
{ "role": "user", "content": "Hello world!" }
],
"max_tokens": 16384,
"reasoning_effort": "high"
}'Working With Images
Moonshot's own evaluation protocol is a prompting hint.
Prepend images to the text input, preserving the original order. That is how MMMU-Pro was measured, and it is the arrangement the published multimodal scores describe.
An integration that appends images after the question is running a different configuration from the one that was benchmarked — which may be fine for your case, and is worth knowing when a result disappoints.
Where It Fits
Long-horizon coding, which Moonshot names as the design target: sustained engineering sessions with minimal oversight, large repositories, and terminal orchestration.
Knowledge work across a million tokens, where preserved reasoning keeps a long analysis coherent rather than letting it drift.
Multi-step agentic execution, with native tool calling and dynamic tool loading.
Visual understanding alongside text, through a native vision encoder rather than an adapter.
Self-hosted frontier-scale deployment, where open weights make something possible that no closed model of comparable capability allows.
Not for latency-bound paths. There is no fast mode. Every request reasons, and the default is the deepest level available.
Not for high-volume classification. Same reason — the floor is a reasoning pass.
Practical Notes
Set reasoning_effort on every request. The default is max.
Append the complete assistant message, never a rebuilt one.
Verify reasoning_content survives your path before building on it.
Budget input tokens for replayed reasoning across a long session.
Prepend images to text, matching the evaluated protocol.
Use high for sustained agent loops; save max for the single hardest question.
Read the licence thresholds against your deployment.
Return tool errors as data rather than raising.
Limitations
Preserved thinking is mandatory. Rebuilding an assistant message from content degrades
multi-turn behaviour with no error raised.
Replayed reasoning is billed as input. That is the cost of the consistency, on every turn.
No fast path. Thinking cannot be disabled and the default effort is maximum.
Some serving stacks drop reasoning_content. Verify rather than assume.
Text output only. It reads images; it does not generate them.
The licence carries numbered commercial thresholds — a Model-as-a-Service revenue clause and an attribution clause — plus an internal-use exemption.
PerceptionBench is an unreleased in-house benchmark. Treat that score as a claim.
Benchmark conditions matter. Multimodal figures are three-run averages under a specific image ordering; reproducing them means reproducing the setup.
Reasoning traces are working notes. Unpolished, sometimes exploring abandoned branches, and occasionally contradicting the answer that follows.