KAT-Coder-Pro V2.5 Guide: Kwaipilot's Closed Agentic Coder

A coding model that scores within four points of the frontier on SWE-Bench Pro, at a fraction of the price, sounds like an easy decision. It rarely is. The score tells you how the model behaved inside one harness on one task distribution, and the price tells you what a token costs, not what a finished task costs.

KAT-Coder-Pro V2.5 is a useful case study in reading both numbers properly. It comes from Kwaipilot, the KwaiKAT team at Kuaishou, and OpenRouter listed it from 10 July 2026. The pitch is end-to-end agentic coding: hand the model a whole issue, or a whole business workflow, and let it locate the code, make the change and verify it.

What Kwaipilot is claiming

Kwaipilot's KAT-Coder-V2.5 technical report frames the release as a systems problem rather than a scale problem: reproducible environments, verifiable rewards and stable reinforcement learning. The report names the model KAT-Coder-V2.5 rather than Pro, so confirm with Kwaipilot which API tier its figures describe. The headline numbers were:

• SWE-Bench Pro — 65.2, against 69.2 for Claude Opus 4.8
• PinchBench — 94.9, the top score in the report's table, against 93.5 for Opus 4.8
• KAT Claw Bench — 85.5, against 90.7 for Opus 4.8
• KAT Code Bench — 53.1, against 57.3 for Opus 4.8

Two of those four are Kwaipilot's own benchmarks, which makes them useful for tracking the KAT line over time and much less useful for comparing it with anyone else. SWE-Bench Pro is the one external, widely reported number, and it is the one to weigh.

Reading 65.2 honestly

65.2 on SWE-Bench Pro is a strong result. For context, it sits above the 62.1 that Z.ai reported for GLM-5.2 and below the 69.2 Kwaipilot quotes for Opus 4.8. But every one of these is a vendor-reported figure on a vendor-chosen scaffold, and scaffolds routinely move scores by several points. Our explainer on what a SWE-bench percentage actually measures covers why a gap of three points between two vendors' numbers is close to noise.

The more useful signal is the shape of the profile. Kwaipilot leads only on PinchBench, an agentic tool-calling evaluation, and trails on the harder repository-repair tasks. That is consistent with a model that is very good at operating tools reliably and somewhat behind the frontier on the deepest debugging.

How it was trained, and why that matters to you

The technical report describes two ideas worth knowing about. The first is an environment builder that reconstructs repositories into sandboxes from pull requests and commits, across 12 languages and more than 100,000 verifiable environments, accepting one only when its tests run reproducibly. That gives reinforcement learning real repositories with real test suites. The second is multi-teacher distillation: specialist experts (agentic software engineering, general agentic reasoning, terminal use, web coding and general knowledge) are fused into a single student, with the stated aim of avoiding the trade-offs of weight merging.

The practical implication is that the model was trained against executable verification. It should be most comfortable in a loop where it can run tests and read their output. If your harness gives it no way to execute anything, you are using it outside the conditions it was optimised for, and benchmark transfer will be worse.

Pro or the open Dev model

Kwaipilot also published KAT-Coder-V2.5-Dev on Hugging Face under Apache 2.0: a 35B mixture-of-experts model with 3B active parameters, built on Qwen3.6-35B-A3B, with a native 262,144-token context. Its card reports 45.96 on SWE-bench Pro and 69.40 on SWE-bench Verified, so it sits well below the flagship on the harder benchmark.

That leaves a sensible split. Use Dev, self-hosted, for high-frequency, low-stakes work: lint fixes, small test additions, tool-heavy automations where each step is simple, or anything that cannot leave your network. Use Pro for tasks that span files and require a plan to survive many turns. If you cannot tell which bucket a task falls in, run it on the cheaper model first and escalate on failure, which is the pattern described in model routing and fallbacks.

The cost of a closed coder

Our catalogue sync recorded Pro on OpenRouter at $0.74 per million input tokens and $2.96 per million output, with cached input reads at $0.15, and a 262,144-token context window. Caching matters more than the headline rate here. An agent loop resends the same repository context on every turn, so a high cache hit rate cuts the effective input price by roughly four fifths.

The weights are not published; the model is API-only. That rules it out for anyone who needs to self-host for data-residency reasons, and it means you are exposed to the vendor's deprecation schedule. Kwaipilot has already moved from KAT-Coder-V2 to V2.5, and the Pro model no longer appeared in OpenRouter's public model list at the time of writing, so plan for the identifier you depend on to change. If you need open weights beyond the Dev model, the field is covered in agentic coding models compared.

Running a fair trial

1. Pick ten closed issues from your own tracker that required changes in more than one file, with tests that prove the fix.
2. Run each through your normal agent harness with Pro, Dev and your current model, three times each.
3. Record pass rate, turns to completion and total tokens billed, including cached tokens.
4. Compute cost per solved issue, not cost per token. A cheaper model that needs twice the turns is not cheaper.
5. Read the failed transcripts. Note whether failures are bad plans, bad tool calls or giving up early.

If Pro solves what your current model solves at a lower cost per issue, the switch is justified on your data rather than on a launch chart. If Dev solves most of it, you have found a cheaper default you can host yourself.