Kimi K3 for Coding: Pricing, Benchmarks, and Tool Setup
Review Kimi K3 API pricing, coding benchmark caveats, Token usage signals, and setup paths for Claude Code, Codex CLI, and OpenCode.
Kimi K3 is worth testing for long agent-based tasks, working with a large repository, and scenarios where images are added to the code. But the model should not be chosen from one place in the table: its results depend on harness, maximum reasoning, endpoint and the task itself, and constant thinking can make a short cycle slow and expensive.
Want to test Kimi K3 on your own task? The Kimi K3 API page shows the current access method, while the BetterToken catalog lists current pricing and availability. Create your own API Key, define a short testable task, and budget for one run first. This gives you the cost of your workflow instead of a vendor headline.
What Moonshot AI released
According to the official repository, Kimi K3 is a sparse MoE model with 2.8 trillion parameters, of which 104 billion are activated on Token. Context - 1,048,576 Tokens. The model accepts text and images, and reasoning is always enabled; in the published benchmark configuration, maximum effort was used.
These numbers describe the capacity and mode of the model, but do not guarantee that a million Token code will be equally useful. The greater the context, the more important it is to test that the required files are found, that task boundaries are respected, and that the ability to complete a long tool chain is completed.
How much does one run cost?
As of August 15, 2026, on the international Moonshot platform, the official tariff for Kimi K3 is:
- Login, cache hit: $0.30 per 1 million Token.
- Login, cache miss: $3.00 for 1 million Token.
- Exit, including reasoning: $15.00 per 1 million Token.
Consider an agent run with 200,000 input Tokens and 20,000 output Tokens. Without a cache hit, it costs:
0.2 × $3 + 0.02 × $15 = $0.90.
If the entire duplicate input is cached, the same volume costs $0.36. This is not a promise of a typical price: the actual cache hit percentage depends on the stability of the system prompt, toolset and reused prefix.
To repeat the calculation for BetterToken, substitute the current input and output rates from the catalog into the same formula: 0.2 × input price + 0.02 × output price. Do not carry a cache discount from one provider to another unless it is listed separately. With both the official API and a compatible provider, input is only part of the final cost: long reasoning is billed as output and can become the largest cost component.
What coding benchmarks show
The official Moonshot table published, among other things, the following results:
- Terminal-Bench 2.1: 88.3.
- DeepSWE: 67.5.
- ProgramBench: 77.8.
- FrontierSWE: 81.2.
- SWE-Marathon: 42.0.
- Kimi Code Bench 2.0: 72.9.
These are vendor-reported results. For Kimi, the Kimi Code harness was often used, and for some competitors, their best published harness was used. The footnotes also indicate the maximum effort and fixed generation parameters. Therefore, a difference of several points does not answer the question of which model is better with your CLI, set of tools and project rules.
A useful unit of comparison looks like this:
model + harness + effort + endpoint + task.
If at least one element changes, the previous score becomes only a guide. An independent test is more useful when it captures the same repository, the same time limit, the same tools and the same acceptance criteria.
For what tasks does Kimi K3 look appropriate?
A strong candidate is a task where the model must hold the architecture for a long time, move between files and check the result itself. For example:
- parse a large repository and create a dependency map;
- fix a bug that goes through several modules;
- compare the layout or screenshot with the implementation of the interface;
- carry out a long plan with tests and re-checking;
- explore several options before changing the code.
A short interactive cycle looks weaker: rename the function, fix one check, explain a small diff. Always-on thinking adds delay and Token output even where long reasoning is not needed. For such problems, first compare K3 with an easier model using the same five examples.
Connect to Claude Code
Moonshot provides an Anthropic-compatible endpoint. The minimum configuration of the current international platform looks like this:
Once running, run /status. The response must have the same Base URL and Model ID. Checking through the /model menu is not sufficient: the interface may show Claude Code's own aliases rather than the actual model of the compatible endpoint.
Do not mix Moonshot Open Platform and Kimi Code keys with someone else's Base URL. Platforms have different domains and key types; 401 in this configuration does not indicate the quality of the model.
Connecting to Codex CLI
The official Moonshot instructions use CC Switch. The reason is technical: Codex works through the Responses API, and Kimi K3 provides Chat Completions. The local router converts one format to another.
In CC Switch you need to select the Kimi preset, specify https://api.moonshot.ai/v1, model kimi-k3, enable routing and reasoning support, then completely restart Codex. Make sure that kimi-k3 is visible in the status, then issue one safe command without changing files.
CC Switch is a separate component that accesses API Key and traffic. Before using it, check its source, updates, and how credentials are stored. For a team with strict security requirements, this may be more important than the difference in benchmark.
Connect to OpenCode
The official way is shorter:
Select Moonshot AI, insert the key via secure dialog, then use /models to select Kimi K3 and /variants to check effort. The test should force the model to read a couple of files and return their names, but not change the project. After answering, check the selected model and Token consumption in the provider’s account.
What problems have already been described by users
In issue MoonshotAI/kimi-code #1911, the user described freezing, poor response to stopping, and going beyond the task boundaries: instead of reporting, the agent started a long chain of shell commands. In #2031 the author reported a session with 18.3 million input Tokens.
These are two separate user posts and not an independent reproduction or statistics of the entire model. It's useful to turn them into checks for your own run:
- set explicit file boundaries and prohibit collateral changes;
- limit the number of iterations and subagent;
- stop the launch if several steps do not bring you closer to the readiness criterion;
- measure input, output, reasoning and time, and not just price per million;
- start from a separate branch or test repository.
How to conduct your own short test
Prepare five tasks from your work: one local bug, one change in several files, one test, one repository search and one script with an image. For each model, fix the same rules, time limit and PASS criterion.
Store four numbers: total input Token, output Token, duration and number of manual interventions. Separately note boundary violations. After five runs, you can already decide whether the Kimi K3 is suitable as a main agent, as a model for complex tasks, or only as a backup option.