VibeThinker: A 1.5B and 3B Reasoning Model Family Built on the Spectrum-to-Signal Principle

The Problem VibeThinker Attacks: Reasoning Quality Per Parameter

The README frames the project around a single claim: that small dense models are assumed to lack reasoning ability, and that this assumption is a training problem rather than a capacity problem. VibeThinker-1.5B is the concrete test of that claim. The repository states it is a 1.5B-parameter dense model developed with a post-training methodology centered on the Spectrum-to-Signal Principle, and reports that it surpasses DeepSeek R1-0120 on AIME24 (80.3 against 79.8), AIME25 (74.4 against 70.0) and HMMT25 (50.4 against 41.7). The README also notes that DeepSeek R1 is over 400 times larger. That framing tells you who the intended reader is: someone who has to justify a model choice on hardware budget, not someone shopping for the strongest model available at any price. The README's own cost comparison makes the same argument in money rather than parameters, citing post-training costs of $294K for DeepSeek R1 and $535K for MiniMax-M1 against $7,800 for this approach, a reduction the README describes as a factor of 30 to 60. Treat those figures as the authors' own accounting, not an independent audit; the README does not break down what the $7,800 covers.

Spectrum-to-Signal: Two-Stage Diversity Distillation Then MaxEnt-Guided Policy Optimization

The mechanism the README describes has two phases, and the naming is literal. In the supervised fine-tuning phase, a technique called Two-Stage Diversity-Exploring Distillation is used to generate a broad spectrum of candidate solutions. In the reinforcement learning phase, MaxEnt-Guided Policy Optimization (MGPO) is used to amplify the correct signal out of that spectrum. The framing is that diversity is produced first and correctness is selected second, rather than asking a single training run to do both at once. The README does not publish the MGPO objective, the reward definition, or the filtering thresholds, so the actual selection rule has to come from the linked paper (arXiv 2511.06221 for the 1.5B model). For VibeThinker-3B the pipeline is described as an upgraded version of the same idea: curriculum-based supervised fine-tuning, multi-domain reinforcement learning, offline self-distillation, and instruction-oriented reinforcement learning, built on Qwen2.5-Coder-3B. The 3B model also introduces Claim-Level Reliability Assessment (CLR), a test-time scaling strategy for answer-verifiable reasoning, with a separate paper at arXiv 2608.11994 and a companion repository at WeiboAI/CLR. CLR is the part of the design that costs you at inference time rather than training time, and the README's own numbers show the trade: AIME26 moves from 94.3 to 97.1, HMMT25 from 89.3 to 95.4, and BruMO25 reaches 99.2 when CLR is applied.

What the Repository Actually Ships: Weights, Papers, and Not Much Else

This is the most important practical fact about the repository, and the README is quiet about it. The primary language is Python and the licence is MIT, but the README's own structure is a paper index, a news log, a feature list, a model download table, and figures. There is no installation section, no requirements file described, no inference script shown, no vLLM or Transformers command, and no configuration keys documented in the supplied material. What you get are two weight locations per model: Hugging Face (WeiboAI/VibeThinker-1.5B and WeiboAI/VibeThinker-3B) and ModelScope (modelscope.cn/models/WeiboAI/...). The README also links technical reports hosted on Hugging Face Papers and arXiv. The repository has no releases, which is consistent with a weights-and-papers distribution model rather than a versioned software package. If you adopt VibeThinker, plan on writing your own loading and serving path, because the README does not hand you one. The MIT licence on the repository is permissive, but the README does not state the licence terms attached to the model weights themselves, and those are separate artifacts hosted elsewhere; check the model cards before you assume the repository licence covers them. That is a factual gap in the material, not legal advice.

The 3B Model's Reported Benchmark Profile Is Narrower Than It Looks

VibeThinker-3B reports 94.3 on AIME26, 89.3 on HMMT25, 80.2 Pass@1 on LiveCodeBench v6, and a 96.1% acceptance rate on unseen LeetCode weekly and biweekly contests from April 25 to May 31, 2026. Read those together and a pattern appears: every headline number is a verifiable task with a checkable answer. The README says as much directly, describing the model as designed for tasks with reliable verification signals, including mathematical reasoning, competitive programming, STEM reasoning, and instruction-following with explicit constraints. That is a scope statement, and it cuts both ways. It means the training signal is trustworthy for those domains, and it means the README makes no claim about open-ended writing, summarization, multi-turn dialogue, retrieval-augmented generation, or tool use. If your workload is a chat assistant, none of the reported numbers speak to it. The LeetCode acceptance rate deserves particular care: the README does not say how many contests, how many problems, or whether the model received problem statements in the same format a human contestant would. Those details matter for whether the figure transfers to your pipeline, and they are in the paper, not here.

Where VibeThinker Is the Wrong Choice

Three cases stand out from the material. First, latency-sensitive serving. The CLR results show that the project's own best numbers come from test-time scaling, which by definition spends more compute per answer. If you need a single forward pass per query, you are looking at the non-CLR figures, and the README does not describe how much CLR costs. Second, anything outside verifiable reasoning. The README's own framing limits the design target to tasks with reliable verification signals, so adopting it as a general-purpose model means using it outside the regime it was post-trained for, with no reported evidence either way. Third, teams that need a maintained software dependency rather than a checkpoint. There are no releases, no changelog, and no documented API surface in the supplied material. Upgrades here mean pulling a new set of weights and re-running your own evaluation, not bumping a version pin. The README's news log shows the cadence: 1.5B open-sourced in November 2025, 3B released in June 2026, with the CLR paper following in August 2026. That is roughly a seven-month gap between model generations, and the 3B model is a different base (Qwen2.5-Coder-3B) with a different pipeline extension, so it is not a drop-in replacement for the 1.5B checkpoint.

Alternatives: What Changes If You Pick Something Else

The README names its own comparison set, which is useful because it tells you what the authors consider the relevant field. On the open side, GPT-OSS-20B-Medium is cited as a peer for the 1.5B model, and MiniMax-M1 as a model with comparable results. On the closed side, Magistral Medium and Claude Opus 4 are named as models the 1.5B model is claimed to outperform on reasoning. The difference in approach is not just size. A 20B open model like GPT-OSS-20B-Medium gives you more capacity per forward pass and, in most cases, a more conventional serving story, at the cost of roughly an order of magnitude more memory and compute. MiniMax-M1 sits in a different training-cost bracket entirely, per the README's own $535K figure. DeepSeek R1-0120 is the cleanest contrast: 671B parameters, over 400 times larger per the README, and the 1.5B model is reported to beat it on three mathematical benchmarks. If your constraint is a single GPU or an edge box, that comparison is the whole argument. If your constraint is answer quality on a task with no verifier, the comparison is irrelevant, and you should be looking at models whose documentation covers that task. The honest read is that VibeThinker is not competing on generality. It is competing on the ratio of reasoning accuracy to parameter count inside verifiable domains, and the README's evidence is confined to that lane.

Maintenance, Cost, and What to Verify Before You Commit

Maintenance cost here is unusual because there is no software to maintain. The repository is MIT-licensed and, based on the supplied material, contains documentation and figures rather than a package you install. Your ongoing cost is the cost of running inference on a 1.5B or 3B dense model, plus, if you enable CLR, whatever the test-time scaling procedure adds. The README does not quantify that, so measure it on your own hardware before you plan capacity. The training-side cost claim ($7,800) is about reproducing the post-training, not about running the released weights, and it is the authors' figure. On licensing, the repository is MIT, but the weights live on Hugging Face and ModelScope under model cards the README does not summarize. Verify the model card licence separately before commercial deployment. The practical next step is narrow: pull WeiboAI/VibeThinker-1.5B or WeiboAI/VibeThinker-3B, run it against your own held-out set of verifiable problems, and compare the result to the README's AIME24, AIME25, HMMT25 and LiveCodeBench v6 figures using a harness you control. If your numbers land near the published ones, the efficiency argument holds for your workload. If they do not, the gap is in the harness or the checkpoint configuration, and the paper at arXiv 2511.06221 or 2606.16140 is where to look for the evaluation setup the repository does not provide.

Editorial conclusion

VibeThinker is worth adopting if you need a small dense reasoning model for verifiable domains (competition mathematics, competitive programming, constrained instruction following) and you are willing to download weights from Hugging Face or ModelScope, then reproduce the reported scores yourself with your own harness. It is the wrong tool if you need a documented inference API, a serving recipe, or any evaluation that the README does not cover, because the repository supplies papers and weight links rather than integration code. Before committing, verify three things: that the exact checkpoint you pull matches the reported configuration, that your evaluation harness matches the one behind the AIME and LiveCodeBench figures, and that the 3B model's CLR test-time scaling is something you can afford to run, since it multiplies inference cost in exchange for the published gains.

Official sources

1. Issues
2. License: MIT
3. README
4. WeiboAI/VibeThinker on GitHub