Kimi K3 explained: Moonshot's 2.8T open model, and how to test it on real hardware

What Kimi K3 actually is

Kimi K3 is Moonshot AI's new flagship model: a sparse Mixture-of-Experts system built on Kimi Delta Attention (KDA), a hybrid linear-attention mechanism, plus Attention Residuals and a routing scheme Moonshot calls Stable LatentMoE. Only 16 of its 896 experts fire per token, which is the detail that matters for planning: the model is sparse and routable, not a 2.8-trillion-parameter monolith you evaluate as one dense block.

The training stack behind those numbers ships four smaller innovations worth knowing if you read the technical report later: Quantile Balancing for expert-load allocation instead of a heuristic auxiliary loss, Per-Head Muon for per-head optimizer updates at scale, and a Sigmoid Tanh Unit (SiTU) paired with Gated MLA for activation and attention control. None of that changes how you call the API — it explains why Moonshot could train a stable model at this size at all.

The catch: "open" does not mean downloadable yet

Moonshot is explicit that Kimi K3 is an open-weight release, and just as explicit that the checkpoint was not on Hugging Face at launch. The company has committed to publishing the full weights by July 27, 2026, alongside a technical report and a Kimi Delta Attention implementation for vLLM. Until that date, the API and the hosted apps (Kimi.com, Kimi Work, Kimi Code) are the only practical way to use K3.

How K3 stacks up against the field

Treat any cross-lab benchmark comparison published in the first week after a launch as provisional — labs run their own evaluation harnesses, and third-party numbers get revised. What is verifiable today is the structural comparison: context length, license posture and pricing.

Test Kimi K3 in six steps on a clean box

The fastest way to form your own opinion is to call the API from an environment you fully control — no leftover Python versions, no conflicting SDK installs from a previous experiment. Here is the six-step path from zero to a working tool-calling test.

1. Get an API key: sign up on the Kimi API Platform and generate a key scoped to the kimi-k3 model.
2. Provision a clean machine: SSH into a freshly provisioned macOS box (a rented Mac mini M4 works well here — root access, nothing pre-installed to conflict with) and set up a Python virtual environment.

python3 -m venv ~/kimi-lab && source ~/kimi-lab/bin/activate
pip install --upgrade openai

3. Point an OpenAI-compatible client at Moonshot's endpoint: Kimi K3 speaks the OpenAI Chat Completions schema, so existing SDKs work with a base URL change.

import os
from openai import OpenAI

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

4. Send a first call with max reasoning effort: K3 always reasons; at launch, max is the only supported value.

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Summarize the KDA attention mechanism in 3 bullets."}],
    extra_body={"reasoning_effort": "max"},
)
print(resp.choices[0].message.content)

5. Test tool-calling: K3 supports function calling and strict JSON Schema output, which matters if you are building an agent rather than a chatbot.

tools = [{
    "type": "function",
    "function": {
        "name": "get_rental_quote",
        "parameters": {"type": "object", "properties": {"sku": {"type": "string"}}},
    },
}]
resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Quote me the daily rate for m4-16-256."}],
    tools=tools,
    extra_body={"reasoning_effort": "max"},
)

6. Try the native long-running clients: if the goal is an unattended agent rather than one-off calls, install Kimi Code (terminal CLI, select the model with /model) or run the Kimi Work desktop app — Moonshot ships an Apple-silicon build, so it runs natively on the same rented Mac you used for steps 1–5, with no Rosetta translation layer in the way.

Keeping a Kimi Code session alive as a background service is the same problem as keeping a CI runner alive: you want key-only SSH, a process that survives logout, and a machine you are not afraid to wipe and re-provision. We covered that exact launchd-based setup in our Xcode CI runner guide — the SSH hardening and service-registration steps apply directly to a long-running Kimi Code agent, not just to Xcode builds.

Numbers worth citing

• 2.8 trillion total parameters, with only 16 of 896 experts active per token — the sparsity ratio that keeps inference cost bounded.
• 1,048,576-token context window, input plus output combined, with flat pricing across the full window (no length-based tiering).
• Global API pricing: $3.00 per million cache-miss input tokens, $0.30 per million cache-hit tokens, $15.00 per million output tokens.
• Full weight release date: July 27, 2026, alongside a technical report and a vLLM implementation of Kimi Delta Attention.

Launch-window details like this move fast — pricing tiers, rate limits and the exact weight-release date can shift before or after the fact. Treat the links below as the source of truth over this article.

Moonshot AI — Kimi K3 launch post

Kimi API Platform — K3 quickstart docs

Northflank — Kimi K3 benchmarks, pricing and self-hosting analysis

IoT Digital Twin PLM — Kimi K3 architecture and benchmark breakdown

FAQ

None of the six steps above need anything exotic — an SSH session and a Python virtual environment are enough to start. What they do need is a machine you are not worried about polluting with test dependencies, half-finished agent scripts and a Kimi Code process you forgot was still running. A shared laptop accumulates that mess fast; a disposable, real Apple Silicon box that you can wipe and re-rent by the day does not. That is the whole pitch for testing new model releases on a short-term rented Mac instead of your primary machine.