Kimi K3: the setup guide, the workflows, and whether it earns a place in your stack

Moonshot AI shipped Kimi K3 on 16 July 2026: a 2.8 trillion parameter, open weight model with a 1 million token context window that Chinese state media and Silicon Valley alike are calling the moment the gap with the leading US labs genuinely narrowed. Full open weights are due on 27 July under a Modified MIT licence. Until then, what you can actually use is a hosted API and a set of consumer apps, all live now.

This is the practical version: how to get it running in every surface that matters, the prompts and settings that make it behave, three workflows worth stealing, and an honest look at where it wins, where it fabricates, and whether it belongs anywhere near client work.

What it actually is

• 2.8 trillion total parameters, Mixture of Experts, 16 of 896 experts active per token (roughly 50 billion active)
• 1,048,576 token context window, flat pricing across the whole thing
• Native vision, always thinking by default at launch (a low/high/max effort split has since been documented)
• Built on two in-house architecture pieces: Kimi Delta Attention, a hybrid linear attention mechanism, and Attention Residuals, a drop-in replacement for standard residual connections
• Two variants at launch: K3 Max for chat and agent work, K3 Swarm Max for large scale parallel processing
• API live since 16 July at api.moonshot.ai, model ID kimi-k3, OpenAI SDK compatible

Four ways in

Browser

kimi.com, the Kimi app on iOS and Android, and the Kimi Work desktop app all offer K3 on a free tier with no developer account needed. Good for quick checks and getting a feel for the model. Launch week traffic has been heavy enough that tasks interrupt mid-run, so don't rely on the free web app for anything time sensitive yet.

API

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_MOONSHOT_API_KEY",
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Summarise the attached brief in three sentences."}],
)
print(response.choices[0].message.content)

Pricing: $3.00 per million input tokens on a cache miss, $0.30 per million on a cache hit, $15.00 per million output tokens. Flat across the full context window, no long context surcharge.

Terminal

Moonshot ships a native agent, Kimi Code CLI, written in TypeScript and distributed via npm:

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

or, with Node.js 22.19 or later already installed:

npm install -g @kimi-ai/kimi-code

First launch prompts you to authenticate, either via OAuth device flow (/login) or a Kimi API Platform key. Config lives at ~/.kimi-code/config.toml, which is also where you'd point it at Anthropic, OpenAI or Google models if you want it to run more than one provider.

Claude Code

Moonshot exposes an endpoint that mirrors Anthropic's own Messages API precisely so Claude Code can drive K3 with no code changes. Set this in ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.moonshot.ai/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_MOONSHOT_API_KEY",
    "ANTHROPIC_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3[1m]",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3[1m]",
    "ENABLE_TOOL_SEARCH": "false",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1048576",
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

Remove any existing ANTHROPIC_API_KEY first; having both set alongside ANTHROPIC_AUTH_TOKEN causes conflicts. Launch Claude Code, type /status, and confirm the base URL and model both show correctly before you trust it with anything. Two things catch people out: WebFetch does not work on this endpoint (WebSearch does), and Tool Search needs to stay off, since the endpoint doesn't support it yet.

The prompts and settings that actually change the output

Constrain it on purpose. Moonshot's own release notes admit the model can act with too much initiative: when instructions are ambiguous, it tends to make the call itself rather than ask. Put explicit boundaries in your system prompt or an AGENTS.md file: name what it must check with you before doing, what's off limits, and when to stop and report rather than push forward.

Brief it like a document, not a message. Role, goal, source material, constraints, output format, and a verification step. K3 improvises when the brief is thin, so the more of the ambiguity you remove up front, the less it fills in on its own.

Don't chunk what you don't have to. With a million tokens on tap, paste the whole repository or the whole document set and refer back to it rather than pre-summarising for it. It held accuracy across a full 1M token context in independent testing, so the width is real, not a spec sheet number.

Mind the reasoning tax. At launch only maximum reasoning effort was live, which means every call thinks at full depth whether the task needs it or not. One independent tester found a bare "hi" cost 86 tokens before the model replied a word, and a one-line request for a simple SVG drawing burned over 13,000 reasoning tokens, working out to roughly 25 cents for a single image. Standard and High effort tiers have since been documented, so check whether your integration exposes them before you route trivial calls through max effort by default.

Ask it to show its working on anything factual. Given the hallucination profile below, have it flag uncertainty and point to the specific part of the context it drew an answer from, rather than asserting facts unprompted.

Three workflows worth running

Websites. K3 posted the strongest published score among compared models on BrowseComp, a benchmark built around structured live web research. That translates well to monitoring tasks: competitor pricing pages, planning portal updates, company filings. In Claude Code, frame these as "search for X and summarise" rather than "fetch this URL", since WebSearch works on the Kimi endpoint but WebFetch doesn't.

Large codebases. This is where K3's lead is clearest. It tops SWE Marathon (long horizon, multi session engineering) and FrontierSWE by a wide margin over GPT-5.6 Sol, and it holds the top spot on LMArena's Frontend Code Arena outright. The workflow that plays to that strength: hand it the full repository, ask for a written plan before any edits, then let it iterate against your own test suite and logs rather than reviewing changes line by line. Holding the routing layer, the service layer and the tests in view at once is exactly what a wide context window is for, and it's where smaller-context models start proposing changes that look correct locally and break something two files away.

Document research. K3 leads OmniDocBench, the document understanding benchmark, and reads scanned pages, screenshots and photographed documents natively through its vision input rather than needing a separate OCR step first. For due diligence packs, contract sets or long reports, load the whole set into a single session and ask for cross-referenced findings across the set, instead of running the model document by document and stitching the answers together yourself afterward.

Using the million tokens without wasting money

Flat pricing across the full context window sounds like the cost problem is solved. It isn't, quite.

• The cache hit is the real lever. Repeated context, the same system prompt, the same repository, the same document set across a session, drops from $3 to $0.30 per million input tokens once it's cached: a 90% discount. That only holds if the prefix stays stable. Reordering tool results, branching into sub-agents, or editing the system prompt mid-session breaks the cache and you're back to full price.
• Output is never discounted, and K3 is a verbose model. Independent testing flagged it as unusually token-hungry per completed task relative to its peers, and with only max reasoning effort available at launch, every call paid for full-depth thinking regardless of how simple the task was.
• Budget per completed task, not per token or per call. A single $12 run that succeeds first time is cheaper than three $4 runs that don't. Track cache-hit input, cache-miss input, output, and failed attempts separately, then divide total spend by accepted outputs rather than by calls made.
• In practice: keep one long-lived session per repository or document set instead of starting fresh each time, and do your constraining through one stable system prompt rather than re-briefing on every turn.

Where K3 actually beats the field

• Long horizon, multi-session engineering work: clear first place on SWE Marathon, and a double-digit point lead on FrontierSWE over GPT-5.6 Sol
• Frontend code: first place on LMArena's Frontend Code Arena, ahead of Claude Fable 5, across six of seven judged domains
• General programming: first place on Program Bench, narrowly ahead of GPT-5.6 Sol
• Web research: leads BrowseComp among the models it's been compared against
• Document understanding: leads OmniDocBench
• Cost per completed task: on workloads it's strong at, real world cost per task has been reported below GPT-5.6 Sol and Claude Opus 4.8, because it needs fewer retries, even though its list price sits closer to those models than to its own predecessor
• The first open weight model to place in the top tier of the Artificial Analysis Intelligence Index, fourth overall at launch, which matters if self-hosting is on your roadmap once the weights land on 27 July

Where it still falls short

• Hallucination rose alongside accuracy. On the AA-Omniscience evaluation, K3's accuracy climbed to around 46% from its predecessor's 33%, but its hallucination rate rose too, from 39% to 51%. It gets more right and fabricates more confidently when it doesn't know. Anything factual needs a verification step, not a straight pass-through.
• Too much initiative. Moonshot's own documentation flags that K3 can make unrequested decisions on ambiguous tasks. Left unconstrained, it acts rather than asks.
• The verbosity tax. Unusually token-hungry per task, and at launch only maximum reasoning effort was available, so every call paid full price for full-depth thinking. Worth rechecking whether lighter effort tiers are exposed in your integration yet.
• Still fourth on broad intelligence. On the Artificial Analysis Intelligence Index, K3 sits behind Claude Fable 5 and two GPT-5.6 Sol configurations, just ahead of Claude Opus 4.8. It wins agentic and coding benchmarks decisively; on general reasoning it's close, not first.
• The open weights aren't out yet. The API is live; the promised weights weren't due until 27 July. At the time of writing, open weight is a promise rather than something you can self-host today, so check the date before you plan an architecture around it.
• A real data handling incident, not a theoretical one. In April 2026, Kimi disclosed one user's actual CV, name, phone number and full work history to a completely different user during an unrelated document translation task, a cross-user data isolation failure logged in the OECD's AI Incidents Monitor. Moonshot is incorporated in Singapore, but China's Cybersecurity Law and Data Security Law impose obligations on it as a company regardless of where a server physically sits, and its own privacy policy permits using conversation data to train and refine its models, with opt-out handled by email.

Is it worth adding to your stack

For anything that touches client-privileged or regulated data, the incident above and the underlying legal exposure aren't a reason to write the model off, but they are a hard line: keep it away from anything a law firm, accountancy practice or insurance brokerage couldn't explain to a regulator or an ICO investigator if asked.

Where it earns its place is internal engineering work, bulk document triage that carries no client identifiers, competitor and market research, and any high volume task where the fully loaded cost per completed task genuinely beats what you're paying today, run through a vetted pipeline rather than the consumer app. It's a strong second model, not a replacement for your primary vendor, at least until the weights are actually out, the hallucination profile has a longer track record, and the effort tiers settle down.

How to best add it

1. Keep your current model as the default for anything client-facing, anything reasoning about a named individual's data, and anything where a wrong answer has legal or financial consequences.
2. Add K3 behind a router for internal, non-privileged work only: repo-scale refactors, drafting, first-pass document triage, competitor monitoring. Wire it in through the API or OpenRouter rather than the consumer app, so there's an audit trail and access can be pulled centrally.
3. Pilot before you commit. One bug fix, one small feature, one refactor is enough to see how it behaves on your own codebase before it touches anything bigger.
4. If you're already running Claude Code day to day, the Anthropic-compatible endpoint means the whole trial is an environment variable swap and nothing else. The cost of finding out is genuinely one afternoon.
5. Re-check the weights release, the effort tier rollout and the hallucination numbers before scaling up. All three were still moving in the days after launch, and a model this new isn't somewhere to lock in architecture decisions yet.

---

Sources: Moonshot AI's official K3 technical blog and API documentation; independent benchmark reporting from Artificial Analysis, LMArena, DeepSWE and Vals AI; launch coverage from Bloomberg, VentureBeat, CNBC, Forbes and Tom's Hardware; hands-on testing from Simon Willison; and incident reporting from the OECD AI Incidents Monitor.