Reported in recent model launches
These model reports include this benchmark. Their harnesses, task subsets, scoring policies, and resource budgets can differ; follow each report’s evaluation notes before joining the numbers.
What it measures
Kimi’s internal coding evaluation tests workflows selected by the model developer.
How to read the result
Treat the result as a targeted development signal and ask which types of engineering work the task selection emphasizes.
Limits and comparison traps
The reviewed launch does not publish a complete independent replication contract. Provider fallback behavior can also affect comparisons.
Published evaluation
Developer-reported Kimi Code Bench 2.0 scores. This version is separate from Code Bench 3.0 Long-horizon in the K3.1 report. Maximum effort, fallback settings and model versions remain visible in the source model labels.
Where this fits in an evaluation suite
The agent wrapper is part of the system. Pin tools, dependencies, timeouts, tests, and the repository revision. Compare contest coding separately from repository maintenance.
Start with a capability hypothesis, then choose a second test with a different failure mode. Keep the checkpoint, reasoning effort, agent tools, sampling policy, and scoring procedure fixed when measuring a training intervention. Record failures and missing outputs in the denominator.
A reproducible comparison
Developer-reported Kimi Code Bench 2.0 scores. This version is separate from Code Bench 3.0 Long-horizon in the K3.1 report. Maximum effort, fallback settings and model versions remain visible in the source model labels.
Publish the exact run configuration, item coverage, score units, and available uncertainty. If a source supplies only an aggregate or a single run, preserve that limit. A new model name or a rounded score alone does not establish a capability improvement.
PRIMARY EVIDENCE & FURTHER READING
Reviewed 2026-10-27. Explanation and interpretation by RLTasks. Benchmark ownership remains with its original authors.