VibeThinker-3B: A 3 Billion Parameter Model That Outscores Opus 4.5 on Reasoning

TL;DR
VibeThinker-3B is a 3B parameter reasoning model reporting 94.3% on AIME 2026. What the paper claims, how to run it locally, and what it trades away.
A paper titled "VibeThinker: Spectrum-to-Signal Reasoning in Compact Language Models" is circulating on Hacker News with a headline claim: a 3 billion parameter model achieves 94.3% on AIME 2026 (97.1% with test-time scaling), 80.2% Pass@1 on LiveCodeBench v6, and a 96.1% acceptance rate on unseen LeetCode contests.
Those numbers match or exceed flagship models that are 100x larger. The arXiv paper explains how - and the tradeoffs involved.
Last updated: June 23, 2026
What the Paper Claims#
VibeThinker-3B is a "compact dense model" designed specifically for verifiable reasoning tasks. The authors use what they call the "Spectrum-to-Signal post-training paradigm" with three components:
- Curriculum-based supervised fine-tuning - training on progressively harder reasoning problems
- Multi-domain reinforcement learning - using verifiable rewards from math and code execution
- Offline self-distillation - the model teaching itself from its own successful reasoning traces
The key theoretical contribution is the "Parametric Compression-Coverage Hypothesis": verifiable reasoning can be compressed into compact models, while open-domain knowledge and general-purpose competence require broad parameter coverage.
Translation: you can make a small model very good at math and code if you are willing to sacrifice its ability to answer general knowledge questions.
That is the same tradeoff behind local Qwen as a different tool, not a worse Opus and GLM 5.2 local deployment. Small models get interesting when you give them narrow jobs, controlled inputs, and a harness that catches the failure modes.
What HN Is Actually Saying#
The discussion has 99 comments and the community is split on what this result means.
The clarifiers: One highly-upvoted comment cuts through the confusion: "Lots of confusion about what this model is actually focused on. It is a cheap specialist for closed-world, verifiable reasoning tasks like math, self-contained coding problems, and similar. 'Closed-world' means the needed information is already in the context. It is not a tool-using agent that can discover missing context."
The skeptics: Several commenters tried standard LLM tests and found the model lacking. One attempted the "pelican on a bicycle SVG" test and got "a rectangle and a black circle." Others pointed out this is expected - the model was not trained on SVG generation or visual reasoning.
The practical testers: One commenter reported success using VibeThinker-3B as a replacement for GPT-5 nano in source code security review, running on an RTX 3090 via vLLM. "It's not great on structured output but I'm working around that in my harness."
The math crowd: Someone tested it on a nasty ODE problem from the Mathematica 15 release notes and "surprisingly it found a valid solution." Running at 25 tok/s on an RTX 2070 Super. Another commenter reproduced the result with the Q4_K_M quantized version at 110 tok/s.
The tool calling concern: Multiple comments noted the model does not support tool calling. "Was not part of its training. It's focused on Python and I think C++ competitive programming and mathematics tasks." This limits its usefulness as an autonomous agent.
Running It Locally#
VibeThinker-3B is small enough to run on consumer hardware. The quantized versions are available on Hugging Face.
Hardware reports from the thread:
- RTX 2070 Super: 110 tok/s generation, 1800 tok/s prefill with Q4_K_M
- RTX 3090: Full speed via vLLM for batch security review work
- CPU only: Viable but slower - it is a 3B model after all
The model uses extended thinking by default. One test took 3 minutes 22 seconds to answer a math problem, spending 22k tokens on reasoning before producing the final answer.
The Architecture Question#
A recurring theme in the comments: is this a reasoning module or a standalone model?
One commenter frames it well: "These kinds of models might be more useful as tools to be used by larger orchestrator models, than being the orchestrators themselves."
The lack of tool calling support reinforces this. VibeThinker-3B cannot search the web, cannot look up documentation, cannot call external APIs. It can only reason over what is already in its context window.
For a multi-agent architecture, that might be exactly what you want - a cheap, fast reasoning specialist that handles the math and code verification while a larger model handles orchestration, context gathering, and general knowledge tasks.
That is also the practical version of model routing to cut AI spend: route the closed-world reasoning slice to a cheap specialist, and keep broad repo context, tool use, and product judgment on a stronger agent.
When to Use This#
Based on the paper and HN discussion, VibeThinker-3B makes sense for:
Competitive programming problems - The 96.1% LeetCode acceptance rate is real, and the model runs fast enough for interactive use.
Math verification - AIME-level competition math, equation solving, and formal verification tasks where the problem is self-contained.
Code security review - As one commenter demonstrated, it works for single-file security analysis where you do not need external context.
Local inference budgets - At 3B parameters, it runs on laptop GPUs. You can have a capable reasoning model without API costs.
This belongs in the same budget conversation as DeepSeek V4 for budget coding agents and AI affordability pressure for agent costs. The question is not whether a tiny model replaces a frontier model. The question is which slices no longer need one.
It does not make sense for:
General assistant tasks - It traded general knowledge for reasoning capability. Do not ask it about history, current events, or "what is a pelican."
Agentic workflows - No tool calling means no web search, no file system access, no API calls from the model itself.
Multi-file code understanding - It is optimized for self-contained problems. Repository-scale reasoning is not its strength.
The Bigger Question#
VibeThinker-3B is evidence that the "parameter count equals capability" assumption has caveats. A 3B model can outperform 300B+ models on specific benchmarks - if you accept dramatic tradeoffs in generality.
The Parametric Compression-Coverage Hypothesis suggests this is not a fluke. Verifiable reasoning - tasks where you can check the answer programmatically - may compress better than open-ended knowledge. If true, we should expect more specialized small models that excel in narrow domains while failing badly outside them.
The practical implication for developers: model selection is becoming task-specific. The best model for coding might be different from the best model for research might be different from the best model for writing. VibeThinker-3B is a data point in that direction.
For a broader local-model shortlist, keep best local coding LLMs in 2026 nearby. VibeThinker is not the general winner. It is a reminder that specialist local models are becoming real routing options.
Frequently Asked Questions#
Does VibeThinker-3B really beat Claude Opus 4.5?#
On AIME 2026 math competition problems, yes - 94.3% vs lower reported scores for much larger models. On general tasks, no. It traded general knowledge for specialized reasoning capability.
Can I use it for coding assistance?#
For self-contained coding problems (competitive programming, algorithm implementation, code review), yes. For repository-scale development with tool calling and context management, no - it lacks tool calling support.
How does it compare to other small models?#
At 3B parameters, it competes with Phi-3, Qwen2 3B, and similar. On reasoning benchmarks it dramatically outperforms them. On general knowledge and instruction following, expect comparable or worse performance.
Is the quantized version good enough?#
The Q4_K_M version runs at 110 tok/s on an RTX 2070 Super and produces equivalent results on math problems. For reasoning tasks, the quantization appears to preserve capability well.
Should I use this instead of API models?#
For batch processing of self-contained math or code problems where you want to avoid API costs, potentially yes. For general development work with tool calling and broad context needs, API models remain more capable.
Continue Reading#
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next
The Best Local Coding LLMs in 2026: Run Enterprise-Grade AI Without the Cloud
Best local coding LLMs in 2026: which models to run on what hardware, how they benchmark, owned hardware versus cloud API costs, and setups by team size.
8 min readModel Routing Recipes: Practical Config Patterns to Cut AI Spend
Model routing recipes with paste-ready OpenRouter and LiteLLM configs for task tiers, fallback chains, cost ceilings and cache-aware routing that cut AI spend.
11 min readLLM Architectures Got Complicated Fast
LLM architectures got complicated: MoE routing, mixed attention variants and integrated vision encoders replaced the simple transformer. What changed and why.
6 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








