OpenHands LM 32B: How a 32B Model Proves Size Isn't Everything
> In March 2025, the OpenHands team released an open-source coding model based on Qwen2.5-Coder-32B. Fifteen months later, its successors—also 32B parameters—achieved a 62.2% resolve rate on SWE-Bench Verified. Meanwhile, the 671B-parameter DeepSeek V3 managed only 38.8%. This isn't magic—it's evolution on three levels: data quality, training methods, and agent framework synergy. While the industry chases parameter scale, the OpenHands ecosystem proves that software engineering capability depends more on *how you train* and *how you use* a model than on *how big it is*.
- Published: 2026-06-05
- Source: OpenHands Dev Team / All Hands AI, 2025–2026
- Core model: OpenHands LM 32B (based on Qwen2.5-Coder-32B-Instruct)
- DeepSeek V3 (671B): 38.8%
- Qwen2.5-Coder-32B-Instruct (untuned): 6.2%
- OpenHands LM 32B (fine-tuned): 37.2%
- SFT is the common base; data provenance differs (SWE-Gym, R2E-Gym, etc.)
- RL: SWE-Master went from 57.8% (SFT) to 61.4% (+RL) — +3.6 points, but with heavy compute, reward design issues (passing tests ≠ correct fix), and overfitting risk
- TTS is the biggest lever: SFT 57.8% → 70.2% (TTS@8); SFT+RL 61.4% → 70.8%. Multiple candidates are generated and a verifier (test suite) picks the best one; parallel verification makes this efficient.
- SWE-Master-32B + TTS: 70.2% (near Claude-3.7)
- SWE-Hero-32B: 62.2% (Claude-3.5 equivalent)
- The remaining gap lies mainly in general reasoning and complex multi-step tasks, not code understanding itself.
- Single RTX 3090 (24GB VRAM): runs the 32B model at 4-bit quantization
- Consumer GPUs only: no A100/H100 cluster needed
- Ollama/SGLang/vLLM: OpenAI-compatible APIs supported
- Privacy: code stays local
- Cost: near-zero marginal cost for high-frequency tasks (vs. $1–5 per API task)
- Latency: local inference is faster, especially for multi-turn interaction
- Customization: fine-tune on private codebases
- Best suited to GitHub issue resolution; weaker on other tasks
- Occasionally produces repetitive loop behavior
- Stability degrades on long sequences (>50 turns)
- OpenHands LM 32B (2025-03): 37.2% (≈ 671B DeepSeek V3's 38.8%)
- SWE-Hero-32B (2026-01): 62.2% (best on OpenHands)
- SWE-Master-32B + TTS (2026-02): 70.2% (near Claude-3.7)
- Untuned Qwen2.5-Coder-32B: 6.2% (fine-tuning delivers 6–10× gains)
- OpenHands Dev Team (2025). Introducing OpenHands LM 32B. https://www.openhands.dev/blog/introducing-openhands-lm-32b
- Wang et al. (2025). SWE-Mirror-LM: Training on Mirrored Real-World Issues. arXiv:2509.08724
- Song et al. (2026). SWE-Master: Unleashing the Potential of Software Engineering Agents via Post-Training. arXiv:2602.03411
- Luo et al. (2025). DeepSWE-32B-Preview. arXiv:2505.xxxxx
- He et al. (2025). SWE-Swiss-32B. Agentless framework with SFT+RL.
- Fu et al. (2026). OpenSWE-32B. SWE-Agent framework.
- Zeng et al. (2026). daVinci-Dev-32B. SWE-Agent with MT+SFT.
- Pan et al. (2025). SWE-Gym: Training SWE Agents with RL. arXiv:2512.21103
- Skywork AI (2025). Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs. arXiv:2506.19290
- Wang et al. (2024). OpenHands: An Open Platform for AI Software Developers as Generalist Agents. arXiv:2407.16741
1. A Counterintuitive Fact: 32B Can Beat 671B
In March 2025, OpenHands released OpenHands LM 32B, fine-tuned from Qwen2.5-Coder-32B-Instruct on successful trajectories from OpenHands agents working on real open-source repositories.
Its SWE-Bench Verified score: 37.2%.
Comparisons:
32B parameters, near-671B performance: 1/20th the parameters, 95% of the performance.
2. From 37.2% to 70.8%: A 15-Month Evolution
| Model | Time | Framework | Method | SWE-Bench Verified | Key Innovation | |---|---|---|---|---|---| | OpenHands LM 32B | 2025-03 | OpenHands | SFT (SWE-Gym) | 37.2% | First open 32B coding agent model | | SWE-agent-LM-32B | 2025-05 | SWE-Agent | SFT | 40.2% | Different agent framework | | SWE-Mirror-LM-32B | 2025-09 | MOpenHands | SFT (mirrored dataset) | 52.2% | Large-scale mirrored real issues | | Skywork-SWE-32B | 2025-06 | OpenHands | SFT + TTS | 38.0% → 47.0% | Data scaling laws | | SWE-Compressor | 2025-12 | OpenHands | SFT | 57.6% | Trajectory compression | | SWE-Swiss-32B | 2025-12 | Agentless | SFT + RL | 58.0% | RL optimization | | DeepSWE-32B | 2025-10 | OpenHands | RL | 42.2% → 59.0% (+TTS) | Pure RL training | | daVinci-Dev-32B | 2026-04 | SWE-Agent | MT + SFT | 56.1% | Multi-task training | | SWE-Zero-32B | 2026-02 | OpenHands | SFT | 57.5% | Data built from scratch | | SWE-Master-32B-SFT | 2026-02 | R2E-Gym | SFT | 57.8% → 70.2% (+TTS) | Best SFT + test-time scaling | | SWE-Master-32B-RL | 2026-02 | R2E-Gym | SFT + RL | 61.4% → 70.8% (+TTS) | RL + test-time scaling | | SWE-Hero-32B | 2026-01 | OpenHands | SFT | 62.2% | Best on OpenHands framework | | OpenSWE-32B | 2026-02 | SWE-Agent | SFT | 62.4% | Best on SWE-Agent framework |
Key observations:
1. 37.2% → 62.2%: Same 32B parameters, same OpenHands framework, different data/methods — a 67% improvement 2. Test-time scaling (TTS) is striking: SWE-Master-32B went 57.8% → 70.2% just by adding inference-time attempts 3. RL's marginal effect: SFT+RL gains ~3–5 points over pure SFT, at significantly higher cost
3. Why Does 32B Work? Three Levels
3.1 Data: Quality Matters, but So Does Quantity
OpenHands' data generation paradigm: let the agent run itself, keep only successful trajectories (SWE-Gym approach):
1. Pick a real GitHub issue 2. Let an agent (Claude/GPT) attempt a fix 3. If tests pass → keep the trajectory as training data 4. If it fails → discard
Advantages of this bootstrapped data generation: real distribution, naturally executable trajectories, and high quality (the model only learns "doing things right"). SWE-Mirror-LM scaled data volume via mirroring real issues (37.2% → 52.2%). Skywork-SWE found data scaling laws: no saturation observed as data volume grows.
3.2 Training Methods: SFT Is the Foundation, RL the Icing, TTS the Secret Weapon
3.3 Agent Framework: The Model Is the Engine, the Framework the Chassis
The same untuned Qwen2.5-Coder-32B-Instruct scores only 6.2% under OpenHands — the model is not the only variable. OpenHands' core design:
1. Event-driven architecture: every step (observe, think, act) is a recordable/replayable event 2. Sandboxed environment for all operations 3. Multi-tool support: file editing (str_replace_editor), bash execution, browser, finish 4. Persistent state for long tasks 5. 128K context window for large codebases
Per the Skywork paper, over half of adopters choose OpenHands, and the same model often performs better under it — though system prompt and pipeline version differences cause significant variance.
4. Versus Closed Models: The Gap Narrows
| Model | Framework | SWE-Bench Verified | Notes | |---|---|---|---| | Claude-4.5-Sonnet | OpenHands | 77.2% | Current SOTA | | Claude-3.7-Sonnet | OpenHands | 53–72% | Config-dependent | | GPT-4.1 | OpenHands | 54.6% | Strong multilingual | | GPT-4o | Multi | ~50% | General purpose |
5. Deployment: Runs on a Single 3090
Implications for developers:
6. Key Limitations: Benchmarks Aren't Reality
6.1 SWE-Bench's Limits
SWE-Bench only tests fixing known GitHub issues — not requirements understanding, architecture design, code review, refactoring decisions, or tech-debt management.
6.2 Data Contamination Risk
Test issues come from public GitHub and may appear in training data. The Skywork paper explicitly fixed a git-log issue to prevent leakage, reporting slightly lower scores — contamination is a real risk.
6.3 TTS Practicality
TTS@8 means 8× inference time and cost. If each attempt takes 5 minutes, a fix takes ~40 minutes — unacceptable for urgent fixes.
6.4 Model Limitations (acknowledged by OpenHands)
7. Industry Impact: An Inflection Point for Open-Source Agents
1. From API calls to local runs: lower cost, latency, privacy risk, and vendor lock-in 2. From model competition to data competition: identical 32B backbones yield vastly different results; data generation frameworks (SWE-Gym, R2E-Gym, SWE-Flow) and scaling laws matter more than architecture 3. From single model to system engineering: best results come from the triad of model + framework + verifier
8. The Questions That Really Matter
1. Where is the 32B ceiling? 62.2% ≈ Claude-3.5, but 77.2% (Claude-4.5) remains distant — data, architecture, or fundamental capability gap? 2. TTS's practical boundary: is 8× inference time for +12 points a good trade? 3. From bug fixing to full development: architecture, review, refactoring? 4. Multilingual support: SWE-Bench is mostly Python; 32B performance on other languages is limited 5. Automated data generation: can cheaper 7B/14B models replace Claude/GPT for trajectory generation? 6. RL's potential: is the 3–5 point gain a reward-design problem, or is SFT near its ceiling?
9. Summary
OpenHands LM 32B and its ecosystem prove that on software engineering tasks, model size isn't the sole determinant — data quality, training methods, and agent-framework synergy let mid-sized models approach frontier performance.
Key data recap:
Key insights: data generation strategy beats architecture; framework choice matters significantly; TTS is the highest-ROI lever; RL gains are marginal but promising; local deployment (single 3090) reshapes open-source agent economics.
Open question: when 32B models run locally at near-zero cost with Claude-3.7-level performance, what pressure does that put on closed-API pricing and business models? That inflection point may arrive faster than most expect.