要查看键盘快捷键,按下问号 查看键盘快捷键 Kimi K3: The Full Developer Guide Guillermo Flor @guilleflorvs · 7月21日 · 关注 1 4 8 4,738 Kimi K3: The Full Developer Guide Written by Guillermo Flor · fact-checked against Kimi’s official documentation and current community reports on X · July 21, 2026 Kimi K3 is Moonshot AI’s flagship model for long-horizon coding, agentic knowledge work, reasoning, and multimodal tasks. Its API is OpenAI Chat Completions-compatible, it accepts text, images, and video, and it offers a 1,048,576-token context window. The model always reasons, and its preserved thinking must stay intact across multi-turn and tool-calling workflows. Official K3 quickstart The short verdict: K3 looks unusually capable when a task is large, visual, tool-heavy, or allowed to run for a while. It is less compelling when response latency is the main requirement. Early independent and community evidence also suggests that strong task completion does not automatically mean strong steerability or shell-error recovery. Give it explicit authority boundaries, acceptance tests, checkpoints, and a bounded agent loop. Contents K3 at a glance What K3 is—and is not Account setup and first API call Parameters and reasoning Preserved thinking and multi-turn state Streaming Images, video, and document files Structured output and Partial Mode Tool calling and agent loops The 1M context window and automatic caching Prompting K3 well Pricing, rate limits, and cost control Coding-agent integrations What the community on X is seeing Production checklist Troubleshooting Documentation inconsistencies to watch Compact cheat sheet
K3 at a glance Kimi K3 at a Glance Sources: K3 quickstart, model parameters, Chat API, and K3 pricing.
What K3 is—and is not K3 is a 2.8-trillion-parameter Mixture-of-Experts model. Moonshot says it activates 16 of 896 experts and combines Kimi Delta Attention, Attention Residuals, and Stable LatentMoE. The company positions it for extended work: large repositories, terminal orchestration, knowledge work, visual coding loops, CAD, and video understanding. These architecture and efficiency statements are provider claims; the practical performance of your application still needs its own evaluation. Kimi K3 technical blog Good candidates include: Large-repository investigation, refactoring, and implementation. Research that combines long documents, retrieval, analysis, and report writing. Agents that need many tools or long histories. Visual software work driven by scre enshots, rendered UI, CAD, or game output. Image and video understanding. Structured extraction from long or multimodal sources. Kimi also publishes limitations worth designing around: Dropping prior thinking history can destabilize later generations. Switching an existing conversation from another model into K3 is discouraged. K3 can be overly proactive when authority or scope is ambiguous. Explicit behavioral boundaries in the system prompt or AGENTS.md are recommended. Official limitations Our recommendation: choose K3 when long context, native vision, or extended agency materially changes the outcome. For simple rewriting, extraction, autocomplete, or latency-sensitive chat, benchmark a smaller and faster model too.
Account setup and first API call
Create an API key on the Kimi API Platform and keep it server-side:
export MOONSHOT_API_KEY="your-key"
Keys from Kimi’s regional platforms are isolated. A key created for a different Kimi platform can return 401 against the Global endpoint. K3 access currently requires a successful cash top-up of at least $1. Error reference · Recharge and limits
You can verify model access with:
curl https://api.moonshot.ai/v1/models
-H "Authorization: Bearer $MOONSHOT_API_KEY"
Python
The K3 guide uses Python 3.9+ and openai>=1.0:
python3 -m pip install --upgrade "openai>=1.0"
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "user", "content": "Explain context caching in three bullets."}
],
max_completion_tokens=2048,
)
print(response.choices[0].message.content)
Node.js
npm install openai
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.MOONSHOT_API_KEY,
baseURL: "https://api.moonshot.ai/v1",
});
const response = await client.chat.completions.create({
model: "kimi-k3",
messages: [
{ role: "user", content: "Explain context caching in three bullets." },
],
max_completion_tokens: 2048,
});
console.log(response.choices[0].message.content);
cURL
curl https://api.moonshot.ai/v1/chat/completions
-H "Authorization: Bearer $MOONSHOT_API_KEY"
-H "Content-Type: application/json"
-d '{
"model": "kimi-k3",
"messages": [
{"role": "user", "content": "Explain context caching in three bullets."}
],
"max_completion_tokens": 2048
}'
Kimi targets Chat Completions,
not OpenAI’s Responses API. A framework that only speaks Responses cannot be assumed to work directly. API overview
Parameters and reasoning K3 is not a drop-in model-name replacement for every K2.x configuration. ParameterK3 behaviorreasoning_effortSchema and K3 guides list low, high, and max; default maxthinkingK2.x field; remove it for K3temperatureFixed at 1.0; omittop_pFixed at 0.95; omitnFixed at 1; omitpresence_penaltyFixed at 0; omitfrequency_penaltyFixed at 0; omitmax_completion_tokensDefault 131,072; maximum 1,048,576 within total contextmax_tokensDeprecated alias; prefer max_completion_tokenstool_choiceauto, none, or required for practical K3 usestopUp to five strings, each at most 32 bytes Passing non-fixed sampling values can produce HTTP 400, so omit those fields. A large max_completion_tokens value is only a ceiling, but it can affect rate-limit admission; set a realistic cap and state the desired answer length in the prompt. Parameter reference The reasoning-effort rollout caveat Several K3-specific sources and the request schema list low, high, and max. However, a narrative sentence on the live Chat API page says only max is currently available, and the launch blog described lower levels as a later update. The documentation is internally inconsistent. For production today: Treat max as the universally safe value—or omit the field and accept its default. Feature-probe low and high in the exact account, endpoint, and client you deploy. Handle a 400 cleanly and fall back to max. Choose the effort level once per session; changing it breaks prefix-cache reuse. An explicit, safest-setting call looks like this: response = client.chat.completions.create( model="kimi-k3", reasoning_effort="max", messages=[ { "role": "user", "content": "Compare three zero-downtime migration approaches.", } ], max_completion_tokens=8192, ) If lower levels are enabled for your account, a useful evaluation policy is to test low for routine transformations, high for ordinary coding/analysis, and max for difficult debugging and long autonomous work. That is workload advice, not a platform guarantee.
Preserved thinking and multi-turn state The API is stateless: your application owns the history and resends it on each turn. A K3 response can contain both reasoning_content and final content. For every multi-turn or tool-calling workflow, append the complete assistant message, including its thinking and any to ol calls. messages = [ {"role": "system", "content": "You are a precise engineering assistant."}, {"role": "user", "content": "Review this migration plan."}, ] response = client.chat.completions.create( model="kimi-k3", messages=messages, max_completion_tokens=8192, ) assistant_message = response.choices[0].message.model_dump(exclude_none=True) messages.append(assistant_message) messages.append( {"role": "user", "content": "Now turn the risks into acceptance tests."} ) follow_up = client.chat.completions.create( model="kimi-k3", messages=messages, max_completion_tokens=8192, ) Do not rebuild the prior assistant turn as only: {"role": "assistant", "content": response.choices[0].message.content} That loses reasoning_content and possibly tool_calls. Kimi explicitly warns that incomplete history can make subsequent reasoning unstable. Also avoid switching an active conversation from another model into K3. Thinking-effort guide · Multi-turn guide Generated reasoning contributes to completion usage. When you send preserved reasoning back on later turns, it also occupies context and becomes input. Apply your normal privacy and retention rules before logging it.
Streaming Streaming is the best default for long K3 work. It provides progress, reduces the risk of a quiet connection being killed by a proxy, and exposes reasoning and final-answer deltas separately. stream = client.chat.completions.create( model="kimi-k3", reasoning_effort="max", messages=[{"role": "user", "content": "Audit this migration strategy."}], max_completion_tokens=8192, stream=True, ) reasoning_parts = [] answer_parts = [] for chunk in stream: delta = chunk.choices[0].delta reasoning = getattr(delta, "reasoning_content", None) if reasoning: reasoning_parts.append(reasoning) if delta.content: answer_parts.append(delta.content) print(delta.content, end="", flush=True) At raw HTTP level, the transport is Server-Sent Events and the complete stream ends with: data: [DONE] Do not treat finish_reason="stop" alone as proof that the network transmission finished; wait for [DONE]. If a stream disconnects before its final event, mark the result incomplete. For streamed tool calls, concatenate function.arguments by tool-call index before parsing their JSON. Streaming guide Our recommendation: never blindly replay a side-effecting tool after a stream reconnect. Use idempotency keys and check whether the previ ous operation committed.
Images, video, and document files Image input Multimodal content must be an actual array of parts, not a string containing serialized JSON. Public HTTP image URLs are not currently supported; use a base64 data URI or upload the image and reference ms://<file-id>. import base64 from pathlib import Path image_data = base64.b64encode(Path("diagram.png").read_bytes()).decode() response = client.chat.completions.create( model="kimi-k3", messages=[ { "role": "user", "content": [ { "type": "image_url", "image_url": { "url": f"data:image/png;base64,{image_data}" }, }, { "type": "text", "text": "Explain this architecture and identify its risks.", }, ], } ], max_completion_tokens=8192, ) Video input with open("demo.mp4", "rb") as file_handle: video = client.files.create(file=file_handle, purpose="video") try: response = client.chat.completions.create( model="kimi-k3", messages=[ { "role": "user", "content": [ { "type": "video_url", "video_url": {"url": f"ms://{video.id}"}, }, { "type": "text", "text": "Summarize the workflow and list visible errors.", }, ], } ], max_completion_tokens=8192, ) finally: client.files.delete(video.id) Formats and limits AreaDocumented behaviorImagesPNG, JPEG, WebP, GIFVideoMP4, MPEG, MOV, AVI, X-FLV, MPG, WebM, WMV, 3GPPRecommended image resolutionAt most 4096×2160Recommended video resolutionAt most 1920×1080Uploaded file sizeAt most 100 MB per fileUploaded filesAt most 1,000 per userTotal uploaded storageAt most 10 GBNumber of imagesNo fixed count stated; request-size and token limits still apply Higher resolution increases token use and processing time without necessarily improving understanding. Estimate a large multimodal request through POST /v1/tokenizers/estimate-token-count before sending it. Vision guide · Estimator Document extraction is a different flow For PDFs, Office documents, source files, and similar formats: Upload with purpose="file-extract". Retriev e the extracted text. Put that text—not the file ID—into messages. Ask K3 about it. with open("report.pdf", "rb") as file_handle: uploaded = client.files.create( file=file_handle, purpose="file-extract", ) file_text = client.files.content(file_id=uploaded.id).text response = client.chat.completions.create( model="kimi-k3", messages=[ {"role": "system", "content": file_text}, { "role": "user", "content": "Summarize the findings and cite the relevant section titles.", }, ], max_completion_tokens=8192, ) File upload/extraction and native image/video reference are separate concepts. A plain document file_id does not become context automatically. File-based Q&A
Structured output and Partial Mode Kimi provides: ModeWhat it guarantees{"type":"json_object"}Valid JSON object, but not a fixed contract{"type":"json_schema"}Output constrained to the supplied schema Use strict JSON Schema for production contracts: import json response = client.chat.completions.create( model="kimi-k3", messages=[ {"role": "user", "content": "Lin is 28 years old. Extract the person."} ], response_format={ "type": "json_schema", "json_schema": { "name": "person", "strict": True, "schema": { "type": "object", "properties": { "name": {"type": "string"}, "age": {"type": ["integer", "null"]}, }, "required": ["name", "age"], "additionalProperties": False, }, }, }, max_completion_tokens=4096, ) choice = response.choices[0] if choice.finish_reason == "length": raise RuntimeError("Structured output was truncated") person = json.loads(choice.message.content) Parse only message.content, not reasoning_content or the whole response. Validate the parsed value in application code as well. Kimi documents nested objects, arrays, and anyOf for K3, using its Moonshot Flavored JSON Schema rules. Structured-output guide Partial Mode Partial Mode continues from a supplied assistant prefix: prefix = "Conclusion: " response = client.chat.completions.create( model="kimi-k3", messages=[ { "role": "user", "content": "Explain in one sentence why API compatibility matters.", }, { "role": "assistant", "content": prefix,
"partial": True,
},], ) print(prefix + (response.choices[0].message.content or "")) The API does not repeat the prefix, so concatenate it yourself. The example above is sufficient for starting with a new prefix. To continue an actual K3 response truncated by finish_reason="length", the partial assistant message must also resend that response’s original reasoning_content; do not retain only the visible text. Do not combine Partial Mode with json_object; for structured data, prefer strict JSON Schema. Partial Mode guide
Tool calling and agent loops K3 can return one or more tool calls, including independent calls that can run in parallel. Your application—not the model—executes them. import json tools = [ { "type": "function", "function": { "name": "get_weather", "description": "Get current weather for a city", "parameters": { "type": "object", "properties": { "city": {"type": "string"}, }, "required": ["city"], "additionalProperties": False, }, }, } ] messages = [ {"role": "user", "content": "What is the weather in Andorra la Vella?"} ] for step in range(8): response = client.chat.completions.create( model="kimi-k3", messages=messages, tools=tools, tool_choice="required" if step == 0 else "auto", reasoning_effort="max", max_completion_tokens=8192, ) choice = response.choices[0] message = choice.message
messages.append(message.model_dump(exclude_none=True)) if choice.finish_reason == "length": raise RuntimeError("Model output was truncated") if not message.tool_calls: print(message.content) break for call in message.tool_calls: try: arguments = json.loads(call.function.arguments or "{}") if call.function.name != "get_weather": raise ValueError("Unknown or unauthorized tool") # Validate every argument and call a real, allowlisted backend here. result = { "city": arguments["city"], "condition": "sunny", "temperature_c": 24, } except Exception as exc: result = { "error": { "type": type(exc).name, "me ssage": str(exc), } } messages.append( { "role": "tool", "tool_call_id": call.id, "content": json.dumps(result), } ) else: raise RuntimeError("Tool-round limit reached") The non-negotiable rules: Append the complete assistant message before tool results. Execute—or return a structured error for—every tool call. Return exactly one role="tool" message with each matching tool_call_id. Validate both the schema and the caller’s authorization in application code. Bound total rounds, wall time, spend, and repeated no-progress calls. Make side effects idempotent and require approval for destructive or externally visible actions. K3’s practical tool_choice modes are: auto: the model decides; default. none: tool calls are forbidden. required: at least one tool call is required. The API syntax also describes forcing a named function object, but Kimi documents that path as incompatible with thinking. Because K3 always thinks, use required with a deliberately narrow tool set when you must force the first action. Tool Choice guide Tool definitions consume input tokens. The API reference documents a maximum of 128 tools, but sending dozens of overlapping schemas can hurt selection quality before you reach that limit. Tool-calling guide Dynamic tool loading K3 can receive a full tool declaration at a specific point in message history: messages.append( { "role": "system", "tools": [ { "type": "function", "function": { "name": "create_pull_request", "description": "Create a pull request in a repository", "parameters": { "type": "object", "properties": { "repository": {"type": "string"}, "title": {"type": "string"}, }, "required": ["repository", "title"], "additionalProperties": False, }, }, } ], } ) The tool becomes available from that point onward. The declaration is not stored server-side; retain it in later history if the tool should remain available. For a large catalog, initially expose a safe search_tools function, retrieve a shortlist in your own registry, inject only those full schemas, and then continue with tool_choice="auto". Dynamic tool loading · K3 tool-calling practices Kimi’s official Formula tools Kimi also exposes hosted Formula tools such as fetch, code_runner, quickjs, excel, date, and memory. The flow is: Fetch a Formula’s definitions from /v1/formulas/{formula_uri}/tools. Pass those definitions to Chat Completions. Send returned calls to /v1/formulas/{formula_uri}/fibers. Append the Fiber output as the matching tool message. Continue until K3 returns a final answer. Kimi currently says its web-search Formula is being updated and is not recommended for near-term production. Tool availability, rate limits, and charges can change, so verify them before building a hard dependency. Official tools guide
The 1M context window and automatic caching The 1,048,576-token context covers the prompt, preserved history, tool definitions/results, generated reasoning, and final answer. The theoretical maximum completion therefore applies only to an almost-empty prompt. In real work: prompt tokens + reasoning tokens + final-answer tokens <= 1,048,576 When the ceiling is too small, reasoning can consume it before final content begins, producing finish_reason="length" and possibly empty content. Automatic prefix caching Caching happens automatically: No manual cache creation. No required cache ID or TTL management. A prior prompt must exceed 256 tokens to become reusable. Keep the long leading prefix byte-for-byte stable. usage.cached_tokens reports cached input. Changing reasoning_effort invalidates reuse. Kimi documents that changing tool_choice or response_format does not. A cache-friendly order is: stable system and policy instructions stable reference documents stable tool definitions conversation history latest user turn Do not put timestamps, random IDs, or request-specific metadata near the start of an otherwise stable prefix. The optional prompt_cache_key can give a stable session/task routing hint, but ordinary automatic caching does not require it. Context-caching guide · Chat API At published rates, cached input is 90% cheaper than uncached input. Kimi also reports cache-hit rates above 90% for coding workloads on its own API; that is a provider-reported workload result, not a guarantee for your traffic. K3 technical blog Cache or RAG? Use caching when many requests share the same long, fixed corpus or system prefix. Use retrieval when the corpus is larger than context, changes frequently, or each question needs a different subset. Comb ine them by caching stable policy/reference material and retrieving only query-specific evidence. If you compact history, preserve complete message units. For a major compaction, start a fresh K3 session with a trusted summary instead of silently deleting pieces of thinking from an active tool trajectory.
Prompting K3 well Kimi’s general advice is to state the task clearly, include the relevant context, use delimiters, define steps, give examples where useful, specify desired length, and ground the answer in supplied references. Prompt best practices K3 particularly benefits from explicit authority and stopping conditions: Role You are a senior software engineer working in this repository. Outcome Implement <specific result>. Context <relevant architecture, files, constraints, and prior decisions> Scope and authority
You may read <scope>.
You may edit only <paths>.
Do not deploy, publish, delete data, rotate credentials, or contact external systems without approval.
Preserve unrelated user changes. Workflow
Inspect the relevant implementation and tests.
State material assumptions.
Make the smallest coherent change.
Run <specific checks>.
If a command fails, diagnose it before changing direction. Definition of done
<acceptance criterion 1>
<acceptance criterion 2>
All relevant checks pass. Verification and report
Do not invent command output.
Report changed files, checks run, failures, and remaining uncertainty.
Stop when the acceptance criteria pass. For research, require the model to separate confirmed facts, estimates, and inferences; cite sources next to claims; and disclose missing evidence. For visual work, supply the actual reference image or screenshot and define measurable constraints instead of asking for a vague resemblance. Our recommendation: give K3 room to reason, but not vague authority. “Build this” is weaker than a concrete outcome, a permitted scope, a definition of done, and verification evidence.
Pricing, rate limits, and cost control As of July 21, 2026: Token categoryUSD per 1M tokensInput, cache hit$0.30Input, cache miss$3.00Output, including generated reasoning$15.00 Prices exclude applicable taxes and are flat across the context window. Preserved reasoning becomes input when sent again on a later request. Image and video input is dynamically tokenized. Official K3 pricing estimated cost = cached input tokens / 1,000,000 × $0.30
uncached input tokens / 1,000,000 × $3.00
completion tokens / 1,000,000 × $15.00
any tool charges Example: 100,000 uncached input tokens cost about $0.30, and 10,000 completion tokens cost about $0.15, for roughly $0.45 before tax and tools. Repeating the same 100,000-token prefix as a cache hit would make that input about $0.03. Track cost per completed task, not merely price per token or per request. A slow agent can accumulate long reasoning, repeated history, and tool outputs even when the model’s input rate looks attractive. Published account tiers TierCumulative cash top-upConcurrencyRPMTPMTPDTier 0$113500,0001,500,000Tier 1$10502002,000,000UnlimitedTier 2$201005003,000,000UnlimitedTier 3$1002005,0003,000,000UnlimitedTier 4$1,0004005,0004,000,000UnlimitedTier 5$3,0001,00010,0005,000,000Unlimited Vouchers do not count toward the cumulative top-up tier. Published limits can be temporarily adjusted under cluster pressure, and documentation differs on whether some limits are described as user- or organization-scoped. Treat the console, response headers, and actual 429 subtype as authoritative. Recharge and rate limits Practical cost controls: Set a realistic max_completion_tokens ceiling; do not leave a huge default in every request. Estimate large text, image, and video prompts before sending them. Keep stable prefixes cacheable. Cap tool rounds, wall time, and total task spend. Log prompt, cached, completion, and total tokens. Distinguish quota exhaustion, rate-limit rejection, and engine overload. Set balance alerts and per-project budgets. Organization best practices
Coding-agent integrations ClientRouteImportant caveatKimi Code CLINative Kimi Platform loginSimplest first-party routeOpenCodeBuilt-in Moonshot AI providerEffort variants depend on rolloutClaude CodeKimi Anthropic-compatible endpointDisable unsupported Tool SearchCodex CLIThird-party CC Switch routerExtra credential and protocol trust boundaryCustom agentOpenAI SDK Chat CompletionsPreserve complete assistant messages Kimi Code CLI Kimi’s official macOS/Linux installer is: curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash Inspect remote installer scripts before piping them to a shell when your environment requires that control. Start kimi, run /login, choose Kimi Platform (API key · platform.kimi.ai), enter the key, select K3, and verify with /status. Kimi Code CLI guide OpenCode opencode auth login Choose Moonshot AI, paste the key, start OpenCode, select K3 through /models, and choose an available effort through /var iants. Feature-probe lower reasoning variants as described earlier. OpenCode guide Claude Code Kimi exposes an Anthropic-compatible endpoint and the kimi-k3[1m] alias: export ANTHROPIC_BASE_URL="https://api.moonshot.ai/anthropic" export ANTHROPIC_AUTH_TOKEN="$MOONSHOT_API_KEY" export ANTHROPIC_MODEL="kimi-k3[1m]" export ANTHROPIC_DEFAULT_OPUS_MODEL="kimi-k3[1m]" export ANTHROPIC_DEFAULT_SONNET_MODEL="kimi-k3[1m]" export ANTHROPIC_DEFAULT_HAIKU_MODEL="kimi-k3[1m]" export ANTHROPIC_DEFAULT_FABLE_MODEL="kimi-k3[1m]" export CLAUDE_CODE_SUBAGENT_MODEL="kimi-k3[1m]" export CLAUDE_CODE_AUTO_COMPACT_WINDOW="1048576" export CLAUDE_CODE_EFFORT_LEVEL="max" export ENABLE_TOOL_SEARCH="false" Configure every tier/subagent variable your installed Claude Code version may use, or background work can request an unknown Claude model. Kimi says Claude Code Tool Search and WebFetch are currently unsupported on this endpoint. Also check ~/.claude/settings.json for stale overrides and never commit credentials. Claude Code guide Codex CLI Kimi’s documented Codex route uses the third-party CC Switch local router because Codex speaks the Responses API while Kimi exposes Chat Completions. The configured Kimi base is https://api.moonshot.ai/v1, model kimi-k3, and context 1048576. CC Switch sees the API key and routed requests, so review its storage, logging, and local-network behavior before using it with sensitive repositories. Codex can route text and images this way, but not native video input. Codex CLI guide
What the community on X is seeing This section is deliberately evidence-weighted. Official launch statements describe the product; independent leaderboards describe a particular harness; individual posts are anecdotes. None should be converted into a universal claim. Strong frontend and agent-task results Arena Frontend Code: K3 debuted at #1 with a score of 1679 and led six of seven frontend domains in Arena’s human-preference evaluation. That is strong evidence for frontend generation in that harness, not proof that it is the best model for every coding task. Arena post Arena Agent: across more than 8,000 live agentic sessions, Arena reported K3 at #4 overall and #1 on confirmed task success. The same post placed it only #14 for steerability and #17 for bash recovery—an unusually useful warning that raw completion rate and operator experience can diverge. Arena Agent post Next.js evaluation: Guillermo Rauch reported K3 leading nextjs.org/evals, with 92% success and 96% when bundled help was available. He also cautioned that benchmarks do not tell the whole story and that no model reached 100%. This is Next.js-specific and sensitive to its harness and documentation. Rauch’s post Competitive task economics, but not necessarily interactive speed Artificial Analysis: its July 16 assessment gave K3 an Intelligence Index of 57, reported $0.94 per Intelligence Index task, and observed 21% fewer output tokens than K2.6. Those figures belong to its evaluation stack and date; use them as comparative evidence, not your cost forecast. Artificial Analysis post Real-repository anecdote: Paweł Huryn planted 45 bugs in a roughly 28K-line TypeScript repository. He reported that K3 spent 62 minutes and found four fixes, all of which he judged correct. It is a transparent but single-user, single-repo test: encouraging for unattended work, poor evidence for interactive latency or broad recall. Huryn’s post 3D workflow anecdote: GMI Cloud reported K3 slower but cheaper than a proprietary comparison model on two Blender/3D prompts, with mixed visual quality. Two prompts and a potentially interested provider are not a benchmark; the useful lesson is to measure time, cost, and quality together. GMI Cloud post Launch capacity is a real operational consideration Kimi said launch demand pushed capacity near its limits and temporarily paused new subscriptions while adding capacity. That post specifically concerned memberships, not a guarantee that the API will be overloaded. Still, the official API documents overload 429s, so long-running systems should checkpoint work, honor Retry-After, and retry transient failures with jitter. Kimi capacity post The synthesis The useful community signal is not simply “K3 is good.” It is more specific: Treat K3 as deliberate and agentic, not instant. Prefer asynchronous jobs, visible progress, and resumable checkpoints for difficult work. Define authority and done. Strong task success can coexist with middling steerability. Plan shell recovery. Validate commands, retain logs, distinguish transient failure from a bad plan, and provide rollback paths. Require verification. Run tests, inspect diffs, validate structured output, and review high-impact actions. Measure task economics. Track elapsed time, tokens, tool calls, retries, human review, and completed-task quality. Keep benchmarks in their lane. Frontend, Next.js, 3D, and general agent evaluations answer different questions.
Production checklist Reliabili ty Stream long generations and wait for the final [DONE] event. Set connect, read, and total deadlines appropriate to long-running work. Retry transient 429 and 5xx failures with exponential backoff, jitter, and Retry-After. Do not retry deterministic 400 or 401 responses unchanged. Cap total retries and surface the final reason. Check finish_reason on every response. Make tool side effects idempotent and resumable. Cap agent rounds and detect repeated no-progress calls. The OpenAI SDK can retry some transient errors automatically. On Tier 0, a single logical request plus two client retries can consume the published three-RPM allowance, so observe and configure retry behavior deliberately. Security and governance Keep API keys on trusted servers or approved developer machines. Rotate exposed keys immediately. Validate tool arguments and authorization; model output is untrusted input. Allowlist filesystem paths, domains, repositories, and command families. Require confirmation for destructive, irreversible, financial, or public actions. Apply retention rules to prompts, uploaded files, reasoning, and tool output. Use separate projects/keys and budgets for environments where practical. Hash any application-user identifier before sending safety_identifier. Observability Record at least: Request/trace ID, model, and reasoning effort. Total latency and time to first token. Finish reason and stream completion state. Prompt, cached, completion, and total token usage. Tool names, duration, result class, retries, and idempotency key. Agent step count, stop reason, and verification result. HTTP status and Kimi error subtype. Estimated and actual cost per completed task. Quality Maintain task-specific evaluations instead of one aggregate benchmark. Test lower reasoning effort only where the live endpoint accepts it. Validate strict JSON again in application code. Run automated checks and inspect diffs for code tasks. Evaluate error recovery, not just clean-path success. Keep human approval for high-impact actions. Kimi’s current Batch API documentation names K2.5 and K2.6, not K3. Do not design a K3 bulk pipeline around Batch until official support appears or a live test confirms it. Batch API guide
Troubleshooting See common error codes and Kimi troubleshooting.
Documentation inconsistencies to watch K3 launched recently and several live pages do not fully agree. Re-check these before a production release: Reasoning effort: K3-specific docs and schema list l ow/high/max, while the Chat API narrative and launch blog imply max-only availability. Feature-probe lower levels. Open-weight status: official pages call K3 open source, but full weights and the final license were only promised for July 27 as of this audit. Sampling: the public API fixes top_p=0.95, while a launch-blog benchmark footnote mentions top-p=1.0. Follow the API reference for calls. Official web search: the Formula page describes tools as temporarily free, an older legacy page lists a per-call fee, and Kimi warns search is under update. Treat availability and price as unresolved. Streaming usage location: Kimi’s streaming guide places usage differently from standard OpenAI client expectations. Test the exact SDK/framework version you deploy. File purposes: the current Files API supports image/video purposes, while a stale error example still says only file-extract is accepted. Token estimator: K3 appears in estimator examples, but at least one rendered enum was stale. Test it in your account before depending on it. Batch: current documentation does not list K3 support. Rate-limit scope: pages vary between user- and organization-level wording. Use console values and headers. Integrations: OpenCode, Claude Code, Codex, and routers change independently. Pin and re-test client versions. The full official documentation index is available at llms.txt.
Compact cheat sheet Model kimi-k3 Global API https://api.moonshot.ai/v1 POST /chat/completions Authentication Authorization: Bearer $MOONSHOT_API_KEY Reasoning Always on Default and safest rollout setting: max Docs/schema also list low and high; feature-probe them Preserve the complete assistant message across turns Context 1,048,576 total tokens max_completion_tokens default: 131,072 max configurable: 1,048,576 minus prompt/context use Fixed parameters — omit them temperature = 1.0 top_p = 0.95 n = 1 presence_penalty = 0 frequency_penalty = 0 Streaming stream = true reasoning_content and content arrive separately raw SSE is complete only at data: [DONE] Structured output response_format.type = json_schema strict = true parse message.content only Images base64 data URI or ms://<file-id> no ordinary public HTTP image URL content must be an array of parts Video upload with purpose=video reference as ms://<file-id> Document Q&A upload with purpose=file-extract retrieve files.content(file_id).text put extracted text, not the file ID, in messages
Tools tool_choice = auto | none | required preserve complete assistant message one matching tool result per tool_call_id validate, authorize, bound, and deduplicate Caching automatic keep long prefixes stable previous prompt must exceed 256 tokens changing reasoning_effort invalidates reuse Pricing per 1M tokens cached input: $0.30 uncached input: $3.00 output: $15.00 Primary sources Official Kimi K3 quickstart Kimi K3 technical blog Chat Completions API Model parameter reference Thinking Effort Vision Tool calling Context caching K3 pricing Rate limits Errors X and independent/community reports Kimi launch Kimi capacity update Arena Frontend Code Arena Agent Artificial Analysis Guillermo Rauch’s Next.js evaluation Paweł Huryn’s repository test GMI Cloud’s 3D workflow comparison Guillermo Flor @guilleflorvs 关注 investing + distribution @ Market Fit
Kimi K3