{"slug": "kimi-k3-the-complete-developer-guide", "title": "Kimi K3: The Complete Developer Guide", "summary": "Moonshot AI released Kimi K3, a 2.8-trillion-parameter open-weights model, the largest open-weight model ever released and the first open-source model in the 3-trillion-parameter class, designed for long-horizon coding and deep reasoning. Together AI is serving Kimi K3 with an OpenAI-compatible API, supporting reasoning effort levels (low, high, max), streaming, vision input, structured output, and tool use. The model introduces architectural innovations including Kimi Delta Attention (KDA), Attention Residuals, and the Stable LatentMoE framework, activating 16 of 896 experts per token.", "body_md": "- What is Kimi K3, and what makes it different?\n- What is under the hood: KDA, Attention Residuals, and the Stable LatentMoE architecture\n- How do you use reasoning effort, streaming, tools, vision, and 1M context?\n- How do you take it from a first API call to production?\n- How does Kimi K3 compare to the frontier on coding and agentic benchmarks?\n- How much does Kimi K3 cost on Together AI?\n\nKimi K3 is Moonshot AI's most capable model to date: a 2.8-trillion-parameter model and the world's first open-source model in the 3-trillion-parameter class. It is designed for frontier intelligence work like long-horizon coding, end-to-end knowledge work, and deep reasoning. It is also the first open-weights model competing at the GPT 5.6 Sol and Claude Fable 5 tier, and Together AI is working directly with the Moonshot team to serve it.\n\n## The largest open-weight model released\n\nThe Kimi team is deeply committed to scaling, and it shows: in nine of the twelve months from July 2025 to July 2026, Kimi models set the upper bound of open-model scale. At 2.8 trillion parameters, K3 is now the largest open-weight model ever released.\n\n## What is under the hood\n\nTwo architectural updates form K3's backbone, both designed to help information flow more easily through longer sequences and deeper into the network:\n\n**Kimi Delta Attention (KDA):** a hybrid linear attention mechanism that provides an efficient foundation for scaling attention across very long contexts. This is the first Kimi model to support a 1M context length.**Attention Residuals (AttnRes):** selectively retrieves representations across model depth rather than accumulating them uniformly.\n\nOn top of that, Moonshot pushed Mixture-of-Experts sparsity further with the Stable LatentMoE framework, efficiently activating 16 of 896 experts. At this level of sparsity, roughly 2% of experts activated per token, routing and optimization become first-order challenges, so several supporting techniques enable stable training at 2.8T scale:\n\n**Quantile Balancing:** derives expert allocation directly from router-score quantiles, eliminating heuristic updates and a sensitive balancing hyperparameter.**Per-Head Muon:** extends the Muon optimizer to optimize attention heads independently for more adaptive learning at scale.**Sigmoid Tanh Unit (SiTU):** improves activation control.**Gated MLA:** improves attention selectivity.\n\n## How to use Kimi K3 on Together AI\n\nThe API is OpenAI-compatible. The snippets below target Together AI and use the official Together Python SDK.\n\n### Thinking effort\n\nK3 can be configured with the top-level reasoning_effort field. Three levels are supported: low, high, and max, with max as the default. On Together, thinking can also be switched off via the standard reasoning={\"enabled\": False} toggle.\n\n### Streaming\n\nStreaming responses deliver separate reasoning_content (the thinking trace) and final-answer content deltas.\n\n### Vision input\n\nMultiple images can be provided as input. Moonshot has also released a visual reasoning benchmark, [Perception Bench](https://www.kimi.com/blog/perception-bench).\n\n**Vision limits:**\n\n- No limit on the number of images, but the whole request body must stay under 100 MB.\n- Recommended maxima: 4K (4096x2160) for images. Higher resolutions cost processing time and tokens without improving understanding.\n- Token cost scales with resolution.\n\n### Structured output\n\nUse response_format with json_schema and strict: true to constrain the final message.content.\n\nThe looser {\"type\": \"json_object\"} mode also works on Together when you only need syntactically valid JSON. Either way, keep max_tokens generous: the whole thinking trace is spent before the first schema-constrained token is emitted, so a tight cap truncates the JSON rather than the reasoning.\n\n### Tools and tool_choice\n\nK3 keeps the standard tool-choice constraints. The standard loop: declare functions in tools; when the model returns tool_calls, append the complete assistant message to history, then append one tool message with the matching tool_call_id for each call, then call again. Use tool_choice=\"required\" on a first turn to force at least one tool call, and switch back to \"auto\" afterward. Changing tool_choice does not invalidate the prefix cache.\n\n### Dynamic tool loading\n\nYou can place a complete tool definition (full name, description, and parameters) inside a system message that carries a tools field and no content. The tool becomes available from that message's position onward.\n\nKey rules:\n\n- Dynamic declarations use exactly the same format as the top-level tools field.\n- They apply per request and are not retained by the server, so keep the message in later request history yourself. Keeping it preserves both the tool's availability and the cached prefix; dropping it means the model can no longer call that tool and the changed prefix may miss the cache.\n- Appending a dynamic declaration to the end of messages does not affect the cached prefix; removing or modifying an earlier declaration may hurt cache hits after the point of change.\n\nRecommended pattern for large tool catalogs:\n\n**Conversation start:** declare only a single search_tools function (implemented by your backend) plus a few core tools, and advertise searchable domain tags in the system prompt.**First turn:** set tool_choice: \"required\" to force retrieval before answering.**Inject on demand:** insert the full definitions of matching tools via a system message based on retrieval results.**Call directly:** the model uses the loaded tools in subsequent generations.**Cost trade-off:** decide reasoning_effort before the conversation starts.\n\nCode Example:\n\n### 1M context and automatic caching\n\nTogether supports the full 1M context length, and context caching is automatic. Keep your long prefix (system prompt, knowledge base, repo dump) byte-stable across requests so later calls can hit the cache. Moonshot recommends placing fixed bulk context (knowledge documents) at the very beginning of the messages array, ahead of the system message, then appending questions and replies after it.\n\n### Sampling parameters\n\nThe sampling parameters are fixed and you should omit them from requests. The model was trained using these params and does not support setting alternatives:\n\n- temperature = 1.0\n- top_p = 0.95\n- n = 1\n- presence_penalty = 0\n- frequency_penalty = 0\n\n### Preserved thinking\n\nK3 was trained in preserved thinking history mode, so the trace is the state the next turn depends on. Use the following to preserve thinking tokens from the previous turn and forward them to future turns.\n\nDrop the reasoning_content line and the same call answers with a different freshly-invented number every time. In real code you never hand-write the trace; you replay what the model produced, which is the one-liner from the tool loop:\n\n## Kimi K3 pricing\n\nKimi K3 is priced per token, with a cache-hit input tier that rewards stable prefixes:\n\nTwo cost aspects to internalize:\n\n**The cache is your lever.** With a >90% hit rate in coding workloads, effective input cost trends toward the \\$0.30 floor, but only if you keep prefixes stable. Restructuring earlier messages or tool declarations will break it.**Reasoning is billed as output and can be dialed in.** Thinking tokens are output tokens at \\$15/M and thinking cannot be fully disabled, but reasoning_effort now has three levels. max remains the default, so a pipeline that never sets the field is paying the maximum reasoning bill on every call, including the trivial ones.\n\n## Kimi K3 benchmarks\n\nAcross the evaluation suite, Kimi K3 posts frontier-level numbers. It leads the field on several coding and agentic benchmarks (SWE Marathon, BrowseComp, DeepSearchQA, AutomationBench, OmniDocBench) and stays competitive with the strongest proprietary models on others, while clearly outperforming the other open model tested, GLM-5.2. On a handful of benchmarks it trails Claude Fable 5 and GPT 5.6 Sol, which is consistent with Moonshot's own positioning of the model.\n\nAll Kimi K3 results below use reasoning effort set to max.\n\n## How Kimi K3 compares to the frontier\n\nAggregate benchmark tables only go so far. For a head-to-head read on cost, coding quality, and routing behavior, we ran Kimi K3 against the leading proprietary models on DeepSWE:\n\n[Kimi K3 vs GPT 5.6 Sol on DeepSWE: cost, coding, and routing](https://www.together.ai/blog/kimi-k3-vs-gpt-5-6-sol-on-deepswe-cost-coding-and-routing)[Kimi K3 vs Claude Fable 5 on DeepSWE: cost and coding](https://www.together.ai/blog/kimi-k3-vs-claude-fable-5-on-deepswe-cost-and-coding)\n\n## Frequently asked questions\n\n**What is Kimi K3?** Kimi K3 is Moonshot AI's flagship 2.8-trillion-parameter model and the first open-source model in the 3-trillion-parameter class, built for long-horizon coding, knowledge work, and reasoning.\n\n**Is Kimi K3 open source?**\n\nYes. It is released as an open-weights model, and Together AI works directly with the Moonshot team to serve it.\n\n**What is Kimi K3's context window?**\n\n1M tokens (1,048,576), supported in full on Together AI with automatic context caching.\n\n**How much does Kimi K3 cost on Together AI?**\n\n\\$0.30 per 1M cache-hit input tokens, \\$3.00 per 1M cache-miss input tokens, and \\$15.00 per 1M output tokens.\n\n**Can you turn off thinking on Kimi K3?**\n\nOn Together AI you can disable thinking with reasoning={\"enabled\": False}, or dial reasoning depth with reasoning_effort set to low, high, or max.\n\n**Does Kimi K3 support vision?**\n\nYes. It has native vision and accepts multiple images per request, as long as the total request body stays under 100 MB.\n\n## Kimi K3 is on Together AI. Run it and ship it to production.\n\nMaking K3 yours starts with a single API call.\n\n- Run Kimi K3 inference:\n[Kimi K3 API on Together AI](https://www.together.ai/models/kimi-k3) - Start building with the API:\n[read the docs](https://docs.together.ai/docs/quickstart)", "url": "https://wpnews.pro/news/kimi-k3-the-complete-developer-guide", "canonical_source": "https://www.together.ai/blog/kimi-k3-guide", "published_at": "2026-08-01 00:00:00+00:00", "updated_at": "2026-08-02 00:11:54.555825+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-research", "ai-products", "ai-infrastructure"], "entities": ["Moonshot AI", "Kimi K3", "Together AI", "Kimi Delta Attention", "Attention Residuals", "Stable LatentMoE", "Perception Bench"], "alternates": {"html": "https://wpnews.pro/news/kimi-k3-the-complete-developer-guide", "markdown": "https://wpnews.pro/news/kimi-k3-the-complete-developer-guide.md", "text": "https://wpnews.pro/news/kimi-k3-the-complete-developer-guide.txt", "jsonld": "https://wpnews.pro/news/kimi-k3-the-complete-developer-guide.jsonld"}}