I have been running Kimi K3 in two setups: Moonshot's own Kimi Code CLI and K3 wired into Claude Code. Same model, noticeably different experience. In my hands, the Claude Code side feels smoother—even though the compatibility setup is degraded and some tools are unavailable.
That is a personal observation, not a controlled benchmark. The more interesting evidence comes from Moonshot itself.
In the official K3 model card, Kimi Code Bench 2.0 scores 72.9 when K3 runs under Kimi Code. A footnote reports 73.7 under Claude Code. Two coding benchmarks and two agentic benchmarks in the same results also run K3 under Claude Code.
The 0.8-point difference does not prove one harness is better. It proves something more consequential: Moonshot treats the harness as an evaluation condition worth disclosing.
The model and the harness are separable layers—and the harness is part of the result.
This is officially supported, not a hack. Moonshot publishes a Claude Code integration guide: set a handful of environment variables and K3 runs inside a competitor's shell. A third-party integration guide captures the switching cost neatly: “Switching the model is an environment variable. Switching the harness is a weekend.”
Configuration migrates quickly. Your hooks, MCP servers, repository instructions, safety habits, and accumulated sense of when a toolchain fails do not.
I now picture an agent as two pillars supporting the same load.
The first pillar is the model. It sets the ceiling of judgment. If the model is not capable enough, no amount of orchestration can rescue it. More tools simply let weak judgment fail faster.
The second pillar is the harness: the system around the model that selects context, exposes tools, enforces permissions, carries memory, coordinates work, and verifies outcomes.
The task is the load stacked on top.
For a light load—answering a question or translating a paragraph—even a thin harness pillar holds. That is why the chat era rarely talked about harnesses. Put a repository, a long research job, or a production release on the slab, and the thinner pillar gives way first. How high you can stack does not depend on the thicker pillar. It depends on the thinner one.
Vendors keep thickening the model pillar for us. The dangerous part is that we immediately place heavier work on top while the harness pillar is still catching up.
The position paper Stop Comparing LLM Agents Without Disclosing the Harness makes the measurement problem explicit. On long-horizon coding tasks, public monitoring shows that holding the model fixed and swapping the harness moves SWE-bench Verified performance by as much as 15 percentage points. On the Verified Mini subset, a single-model swing approaches 48 points.
The same paper notes that research papers commonly present 2–4 percentage points as a meaningful model advance.
This comparison has a scope: the evidence comes from coding agents and comparable frontier models. It should not be transplanted blindly into every domain. Within that scope, however, the implication is hard to ignore: the realization gap caused by the harness can exceed the model gap we spend launch week debating.
Component lists are useful, but they do not tell you where to invest first. I divide a harness by function:
Today's coding agents have different strengths across the first five jobs. The shared weakness is the sixth.
A model says “done,” and the default delivery path often has no independent referee reading the actual workspace, rerunning the real checks, and blocking release when the evidence disagrees. Usage dashboards measure activity. They do not answer whether the outcome was correct.
In my own multi-agent system, the coordinator does not treat the executor's report as delivery. At task intake, we write a Definition of Done. After delivery, the coordinator independently reruns tests, checks the result against that definition, reviews the size of the change and sensitive-operation signals, and decides whether human review is required.
This is not a perfect system. If the tests are weakened or the Definition of Done is wrong, the gate can still wave bad work through. But “fake done” has become materially harder to pass.
The mechanical half—rerunning tests and comparing fixed criteria—does not care which model you use. The judgment half—interpreting failures and escalating risk—depends on the model seated as reviewer. Separating those halves is the point.
The next article in this series follows that acceptance problem all the way down: forged confirmations, falsely green tests, defenses that were deployed but never powered on, and the gate I built afterward.
The model sets the ceiling. The harness governs realization.
Model progress is given to you by someone else. Harness reliability is earned.
Originally published at OctoBlog. Part 1 of the Into the Harness series.
Question for you: Which of the six harness jobs is the thinnest pillar in the agent you use?