KwaiKAT Team Releases KAT-Coder-V2.5: An Agentic Coding Model Trained on 100,000+ Verifiable Repository Environments

The KwaiKAT Team at Kuaishou has introduced the KAT-Coder-V2.5. It is a coding model trained to operate inside real, executable repositories rather than emit single-turn code. The served model is available through StreamLake. An open-weight variant, KAT-Coder-V2.5-Dev, was released separately on Hugging Face under Apache-2.0. AutoBuilder: environments that actually run the intended tests The research frames a verifiable task as a triplet. It needs a precise task description, an executable repository environment, and a set of validation tests. A patch is correct only if it passes all of them. Tasks are mined from real pull requests and commits, following the SWE-bench lineage. The merged code change supplies a golden patch and the accompanying test change supplies a test patch. Raw issue text is discarded as a specification. Instead, descriptions are regenerated into three parts: a problem statement grounded in the golden patch, requirements derived from the test patch, and interface constraints inferred from both. A clarity check then drops anything ambiguous, incomplete, underspecified, or internally inconsistent. AutoBuilder handles the environment side. A build agent analyzes the repository and writes a configuration script that installs dependencies and runs tests from a clean checkout. A verification agent executes that script in an isolated sandbox. The acceptance rule is the interesting part. Verification does not read exit codes or grep log patterns. It parses structured test-framework output, and accepts an environment only when more than 90% of expected tests are collected and pass/fail outcomes reproduce across runs. Failures are fed back as structured information for iterative repair. Combining a preconfigured base environment, build-system templates, and a retrievable library of distilled build recipes raised the construction success rate from 16.5% to 57.2%. The result is over 100,000 verifiable environments spanning 12 languages. Git history, commit metadata, and other exploitable traces are stripped so agents cannot read the reference solution out of the repo. Data Scaling Flywheel: filtering on process Filtering trajectories by final test success is misleading. Some passing runs rely on hard-coding, mechanism bypassing, or test-oriented shortcuts. Some failing runs contain valuable search, localization, and repair behavior. KwaiKAT addresses both directions. For near misses, targeted process-level hints indicate what to inspect or verify without revealing the solution. That alone raises the pass rate of previously zero-pass tasks to roughly 20%. Because hinted trajectories contain information unavailable at inference, the verified patch is then fixed and a hint-free trajectory is regenerated from the original task context. Only samples that pass verification, show no hint leakage, and stay consistent with the patch are retained. For passing runs, rule-based gates remove invalid, unstable, or exploitative trajectories. A scoring stage then rates exploration, localization, pre-edit reasoning, specification fidelity, repository conventions, patch minimality, verification quality, recovery behavior, and honesty. A third mechanism targets harness overfitting. Tool names, argument conventions, output formats, and prompt templates are randomized while functionality is preserved. Because verification is anchored to test outcomes rather than harness traces, one task can be re-served under many harness configurations. Realistic perturbations are injected too: missing dependencies, transient command failures, truncated outputs, and noisy logs. Explore the pipeline and the numbers (function(){ window.addEventListener("message", function(e){ if(!e.data || typeof e.data.katHeight !== "number") return; var f = document.getElementById("mtp-kat-frame"); if(f) f.style.height = e.data.katHeight + "px"; }); })(); Infrastructure failures capped rewards before algorithm