Overview
KAT-Coder-V2.5-Dev is a Mixture-of-Experts (MoE) coding model built by Kwaipilot for autonomous software engineering tasks within executable repositories. The model contains 35B total parameters with 3B activated per token, operating as a text-only model compatible with Hugging Face Transformers, vLLM, SGLang, and KTransformers. Built on the Qwen3.6-35B-A3B base model, it underwent supervised fine-tuning on 127K examples followed by reinforcement learning training to optimize tool use and eliminate pathological behaviors like excessive parallel tool calls and content repetition. The critical distinction from typical code generators is that this model operates as an agentic tool that can execute commands, read repository files, and iteratively solve tasks within real sandboxed environments rather than generating code in isolation. The open-weight release excludes vision and multimodal components, providing language-model weights only. Apache 2.0 license permits commercial use.
Best use cases
Software repository-level bug fixing and issue resolution. This model excels at autonomous patch generation for real software repositories, achieving 69.40% on SWE-bench Verified—the highest among open-source models at this scale. It can navigate repository structures, read code context, execute tests, and iteratively refine solutions based on test feedback. The hierarchical reward training with fine-grained execution feedback enables it to learn from partial progress, making it particularly strong when tasks require multiple tool interactions and error recovery rather than single-turn code completeness.
Multilingual software engineering tasks. Performance of 63.00% on SWE-bench Multilingual demonstrates capability across different programming languages. The model learned to work within diverse ecosystems through the training pipeline's support for reconstructing repositories across multiple languages into executable sandboxes, making it valuable for polyglot codebases or when maintainers need language-agnostic repository-level fixes.
Complex software engineering with terminal interaction. Terminal-Bench 2.1 performance of 41.02% shows competence with command-line tool orchestration and shell interactions. This model can chain multiple tools—running tests, building code, searching repositories, editing files—in sequences that require understanding execution feedback and adapting subsequent actions. The terminal-oriented training makes it suitable for infrastructure automation and deployment-related code changes.
Tool-use intensive agentic workflows. The RL training specifically targeted excessive parallel tool calling and designed Qwen3.6-specific reward penalties that suppress pathological tool behaviors. This optimization makes the model reliable for production agentic systems where tool-call discipline and avoiding hallucinated tools matter more than raw parameter count. It achieved 93.43% on PinchBench, indicating strong tool-use grounding.
Scientific code and mathematical problem-solving. Scicode benchmark performance of 44.20% indicates capability on domain-specific problem solving. The training included process-aware filtering and hindsight-augmented value estimation, enabling the model to learn from near-miss trajectories and incomplete solutions—valuable for scientific computing where correct approaches matter even if execution differs.
Limitations
Text-only model without vision capabilities. This open-weight release excludes vision and multimodal components entirely. Users requiring analysis of screenshots, diagrams, or visual documentation cannot use this model; the proprietary KAT-Coder-V2.5 includes vision components but remains closed-source.
Requires 8-GPU clusters for practical deployment. The model documentation specifies tensor parallelism across 8 GPUs with --tp-size 8 for both vLLM and SGLang examples, suggesting a single GPU cannot accommodate this model's working memory. No single-GPU quantization options or specific VRAM requirements are documented, making accessibility limited without enterprise infrastructure.
Context window and token limit constraints. While 262,144 token context length is supported, the training revealed that the base model generates trajectories exceeding 70 parallel tool calls in single turns, causing context overflow and invalid execution. The RL training added penalties to suppress this behavior, but the underlying tendency remains a limitation for especially complex tasks requiring exploration.
Low download count and limited production validation. The model has only 396 downloads as of this documentation, suggesting limited real-world deployment and production hardening. Community feedback on failure modes, latency characteristics, and edge cases remains minimal compared to models with thousands of active users.
Hallucination of unsupported tools during evaluation. Testing showed the base Qwen3.6 model frequently invokes unavailable MultiEdit tools and other hallucinated functions. While RL training improved this (abnormal tool labels dropped from 9.34% to 0.28%), the tendency toward tool hallucination persists as a weakness requiring careful prompt engineering and tool-set specification.
Model collapse risk during RL training. The initial binary 0/1 reward formulation caused model collapse as early as the second epoch when applied directly to Qwen3.6. Recovery required multiple Qwen3.6-specific penalty adaptations, indicating the model exhibits training instability without precise reward shaping—a concern for users attempting custom RL fine-tuning.
Repetitive generation behavior. Though RL training reduced single-turn continuous repetition from 0.34% to 0%, this behavior was sufficiently common to warrant specific penalty targeting, suggesting it remains a latent failure mode under certain prompting conditions.
How it compares
KAT-Dev is a general-purpose 32B open-source model achieving 62.4% on SWE-bench Verified, whereas KAT-Coder-V2.5-Dev reaches 69.40% on the same benchmark through specialized agentic training and tool-use optimization. Choose KAT-Coder-V2.5-Dev when you prioritize state-of-the-art performance on repository-level bug fixing; choose KAT-Dev for users with smaller GPU clusters or simpler code generation tasks where general-purpose capability suffices.
KAT-Dev-72B-Exp achieves 74.6% on SWE-bench Verified and represents the larger experimental RL version from the same maintainer. If you have access to sufficient GPU capacity and need maximum accuracy, KAT-Dev-72B-Exp outperforms this model; KAT-Coder-V2.5-Dev remains preferable if you need the fastest inference within the KAT family or operate under resource constraints.
deepseek-v3 is a general-purpose frontier model optimized for reasoning tasks rather than agentic coding. It delivers stronger performance on abstract problem-solving and multi-step reasoning without tool execution, making it better for code generation and algorithm design; KAT-Coder-V2.5-Dev is superior for autonomous repository navigation and iterative bug fixing within actual executables.
Qwen3.5-35B-A3B-AWQ-4bit is the base model's predecessor, offering quantized 4-bit access with smaller VRAM footprint. Choose the Qwen quantized version for inference-only scenarios with hardware constraints; KAT-Coder-V2.5-Dev when you need specialized agentic training and superior software engineering benchmarks.
Kimi-Dev-72B by Moonshot achieves 60.4% on SWE-bench Verified and emphasizes large-scale reinforcement learning optimization. Both models use similar agentic training approaches, but KAT-Coder-V2.5-Dev achieves higher accuracy at smaller activated parameter count (3B vs. implicit larger activation in 72B), making it more efficient; Kimi-Dev-72B provides an alternative from a different maintainer if you prefer different training recipes or want model diversity.
Technical specifications
Architecture and Parameters. KAT-Coder-V2.5-Dev is a Mixture-of-Experts model with 35B total parameters and 3B activated parameters per forward pass. It is built on Qwen3.6-35B-A3B as the base model.
Training Details. The model underwent two-stage post-training: supervised fine-tuning (SFT) on 127K examples followed by reinforcement learning (RL) for 10 epochs. The training pipeline incorporates four core components: Token-in-Token-out (TITO) consistency to ensure identical token sequences between rollout and training; Truncated Importance Sampling (TIS) to mitigate policy staleness in asynchronous training; reliability-hardened sandboxes with systematic validation to prevent infrastructure failures from contaminating reward signals; and hierarchical rewards constructed from fine-grained harness execution feedback. Additional Qwen3.6-specific reward penalties target excessive parallel tool calls, failed tool calls, empty tool-call blocks, and large repeated content.
Supported Frameworks. Compatible with Hugging Face Transformers, vLLM (version 0.19.0+), SGLang (version 0.5.10+), and KTransformers. The model operates in text-only mode; vision and multimodal components are excluded from this open-weight release.
Context Window. Supports maximum context length of 262,144 tokens for both SGLang and vLLM deployments.
Deployment Requirements. Documentation specifies tensor parallelism across 8 GPUs (--tp-size 8) in standard serving configurations. Memory allocation uses --mem-fraction-static 0.8 in SGLang examples. No single-GPU quantization or specific VRAM per-device numbers are documented.
Model Format. Weights and configuration provided in Hugging Face Transformers format. Both vLLM and SGLang require the --language-model-only flag during initialization because the open-weight release excludes vision encoder weights that the frameworks attempt to load by default.
Parsing Options. Inference frameworks support --reasoning-parser qwen3 for standard operation and --tool-call-parser qwen3_coder for agentic tool-use scenarios with automatic tool choice via --enable-auto-tool-choice.
Model inputs and outputs
Inputs
-
Text prompts in natural language or code description format
-
Tool specifications and available function definitions for agentic scenarios
-
Repository context and file paths when operating in software engineering tasks
-
Execution feedback from sandboxed environments or test harnesses during iterative refinement
Outputs
-
Generated text and code sequences at standard text generation granularity (per-token)
-
Structured tool calls formatted according to the Qwen3.6 tool-use convention (parseable by qwen3_coder)
-
Intermediate reasoning and planning text when engaged in multi-step agentic workflows
-
API responses in OpenAI-compatible format when served via vLLM or SGLang endpoints at
http://localhost:8000/v1
Getting started
Using vLLM with tool-use support:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="not-needed",
)
response = client.chat.completions.create(
model="Kwaipilot/KAT-Coder-V2.5-Dev",
messages=[
{
"role": "user",
"content": "Fix the failing test in the repository at /path/to/repo"
}
],
temperature=0.7,
max_tokens=2048,
)
print(response.choices[0].message.content)
Launching vLLM server with tool support:
vllm serve Kwaipilot/KAT-Coder-V2.5-Dev \
--port 8000 \
--tensor-parallel-size 8 \
--max-model-len 262144 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--language-model-only
Using SGLang for streaming inference:
python -m sglang.launch_server \
--model-path Kwaipilot/KAT-Coder-V2.5-Dev \
--port 8000 \
--tp-size 8 \
--mem-fraction-static 0.8 \
--context-length 262144 \
--reasoning-parser qwen3 \
--tool-call-parser qwen3_coder
Frequently asked questions
Q: What license does this model use and can I use it commercially?
A: KAT-Coder-V2.5-Dev is released under the Apache 2.0 license, which permits commercial use without requiring you to open-source derivative models. You may use it for commercial applications, including offering model access as a service.
Q: How much GPU memory do I need to run this model?
A: The documentation specifies deployment with tensor parallelism across 8 GPUs (--tp-size 8), but exact per-GPU VRAM requirements are not documented. Based on 35B total parameters, assume 80GB+ total GPU memory across the cluster; single-GPU inference is not supported and no quantized versions are provided.
Q: How does this model compare to Qwen3.5-35B for coding tasks?
A: KAT-Coder-V2.5-Dev achieves 69.40% on SWE-bench Verified versus Qwen3.5-35B-A3B at 58.60%, a gap of nearly 11 percentage points. This advantage comes from agentic training and RL optimization specifically for tool use within sandboxed environments, whereas the base Qwen model generates code without execution feedback.
Q: Does this model have vision or multimodal capabilities?
A: No. This open-weight release includes language-model weights only and operates as a text-only model. Vision and multimodal components are excluded and unavailable. The proprietary KAT-Coder-V2.5 includes vision capabilities but is closed-source.
Q: What are the known failure modes or limitations I should be aware of?
A: The model shows tendency toward hallucinating unsupported tool calls (reduced but not eliminated through RL), exhibits model collapse under naive reward formulations, and occasionally generates excessive parallel tool calls (70+) in single turns despite penalty training. Low production deployment volume (396 downloads) means fewer real-world edge cases have been discovered and shared.
Q: Can I fine-tune this model for custom tasks?
A: Yes. The model weights are compatible with Hugging Face Transformers, enabling standard fine-tuning and RL training approaches. However, the documentation warns that direct RL training on Qwen3.6-based models without specialized reward penalties causes rapid model collapse, requiring careful design of task-specific rewards similar to the hierarchical + penalty approach documented in the technical report.
Q: What is the input/output format and context window?
A: The model accepts text prompts in OpenAI-compatible chat format when served via vLLM or SGLang. It generates text tokens in standard streaming format. Maximum context length is 262,144 tokens, accommodating large repository contexts, though the model's baseline tendency to generate 70+ parallel tool calls can cause practical context exhaustion even within this window.
Q: How fast is inference and what batch sizes should I expect?
A: Inference speed is not documented in the README. With 3B activated parameters, inference should be faster than 35B dense models, but tensor-parallel deployment across 8 GPUs introduces communication overhead. Batch sizes depend on hardware configuration and memory allocation (--mem-fraction-static 0.8 in examples suggests reserving 20% for other operations), but specific throughput numbers are unavailable.