Most automated code review is bad for a structural reason: it looks at the diff. The interesting bugs are not in the diff — they are in the interaction between the diff and code the diff never mentions. A 1M-token window is the first thing that makes reviewing a change against its codebase practical, and at cached-input prices it is cheap enough to do on every pull request.
This page is written for engineering teams and reviewers. If you want the model overview first, start with the complete Kimi K3 guide.
| Best effort level | max (the API default is max) |
| Context available | 1M tokens — enough for real working material, not just snippets |
| Cost | $3.00 per million input tokens, $15.00 per million output, $0.30 cached input |
Why Kimi K3 suits code review
- 1M tokens of context fits the change plus the modules it touches plus the tests — the material a human reviewer would actually want.
- Caching makes per-PR review economically trivial: the codebase prefix costs $0.30 per million on repeat reads.
- Always-on reasoning suits the task, which is inference about consequences rather than pattern-matching on style.
- 88.3 on Terminal-Bench 2.1 suggests real competence at reading and operating inside existing systems rather than writing greenfield code.
- Native vision lets you include architecture diagrams or screenshots of UI changes in the review context.
A workflow that works
- Establish the codebase as a cached prefix. Conventions, relevant modules, schema, test suite. This is the part that makes the review good and it should not be re-billed on every PR.
- Send the diff last. Stable material first for cache hits, the changing part at the end.
- Ask a specific question. "Review this" produces style comments. "What breaks if this runs concurrently with the batch job in
jobs/nightly.py?" produces findings. - Request severity ranking with a reason. An unranked list of twenty observations gets ignored; three ranked findings with a failure scenario each get read.
- Have it flag missing tests explicitly. It is a category of finding that reliably matters and reliably gets skipped.
Settings to start from
Set reasoning_effort to max. Review is a find-the-subtle-problem task, which is precisely what reasoning depth buys. Missing a real bug costs far more than the tokens. max is the default and here it is also correct — the only reason to lower it is if you are running review on every commit rather than every PR.
Remember that reasoning cannot be turned off on this model, and that the API default is max — the most expensive of the three levels. Setting it explicitly is the single highest-value line of configuration you will write. See reasoning effort explained if you want to tune it properly.
What to watch out for
- It will find things that are not problems. False positives are the failure mode of automated review, and they train reviewers to ignore output. Ask for a concrete failure scenario per finding so you can dismiss the noise quickly.
- It is not a security audit. Useful for spotting classes of issue; not a substitute for a dedicated review or a scanner.
- Repository context is a real token cost. Even cached, a large codebase in every review adds up. Scope the context to the modules the change touches.
- Do not gate merges on it. Advisory review that reviewers value beats a blocking check they learn to override.
The verdict
One of the highest-value, lowest-risk ways to use K3: nobody minds an extra reviewer, and whole-codebase context makes the findings meaningfully better than diff-only tools. Cache the codebase, ask pointed questions, keep it advisory.
If cost is the constraint, read how to cut Kimi K3 costs before downgrading — caching and effort levels usually beat switching models.
More on Kimi K3
Start with the complete Kimi K3 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Kimi K3 guideFrequently Asked Questions
Can Kimi K3 review a pull request against the whole codebase?
Yes — that is the main advantage here. Its 1M-token window fits the change alongside the modules it touches and the test suite, so it can reason about consequences outside the diff. Cache the codebase as a stable prefix so repeat reviews cost $0.30 per million input tokens.
How much does automated code review with Kimi K3 cost?
Less than you would expect. The dominant cost is the codebase context, and cached reads are $0.30 per million input tokens against a $3.00 standard rate. The review output itself is short, so output tokens barely register.
Should Kimi K3 replace human code review?
No. Use it as an additional reviewer that never gets bored of reading the whole repository. It produces false positives, and it is not a security audit. Keep it advisory rather than merge-blocking.
