In this article
Compare long Kimi sessions through preserved requirements and accepted repository states, with harness differences kept visible.
A long coding session tests whether a model maintains the goal across intermediate observations. Kimi K3 and K2 Thinking should be compared on that continuity, not simply on how much code either can generate.
Recognize different generations and artifacts
The K3 card describes its newer architecture and long-horizon coding scope. The K2 Thinking card describes reasoning with tools and a native INT4 checkpoint. These are different generations with different model artifacts.
The K3 technical blog includes explicit qualifications about evaluation harnesses. A published comparison can combine model capability with scaffold and environment differences. Preserve those caveats instead of turning a vendor table into a measurement of a private coding session.
Give the session a durable requirement
Use a fictional library migration where one public operation changes internally while backward-compatible input remains required. Include a small interface document, implementation, callers and tests.
The session should encounter an informative setback, such as a test showing that a legacy caller still depends on the old behavior. The model must incorporate this observation without abandoning the compatibility requirement or repeatedly rewriting already-correct components.
Evaluate continuity across stages
| Stage | Observable requirement |
|---|---|
| Initial analysis | Identify the protected public behavior |
| First patch | Implement the requested internal change |
| Failure feedback | Explain the actual legacy-call mismatch |
| Recovery | Repair the dependency without weakening tests |
| Final delivery | Present a consistent patch and accurate explanation |
The goal is not to make every intermediate step correct. It is to determine whether the session recovers while preserving the original objective and ends in an acceptable state.
Separate context handling from capability
Keep the available files and actual tool observations the same. If one scaffold summarizes history or truncates old requirements, that transformation belongs in the record. It cannot be silently attributed to the model.
Count a claimed test success only when the corresponding observation exists. If the model stops after a plan or a partial patch, record incomplete delivery. A convincing summary of unfinished work should not become accepted completion.
Compare bounded sessions rather than anecdotes
Preserve task state, checkpoint revisions, prompt histories and final diffs. Include the permitted retry and output conditions. Repeat a small set of dependency patterns instead of relying on one spectacular demonstration.
A result may support one checkpoint for the tested long-session workflow or show that the harness needs improvement before the model difference is interpretable. It does not guarantee autonomous completion of arbitrary projects, transfer every published benchmark score or establish that one successful session removes the need for independent final checks.