Selective Verification (Sevra): budget-aware reasoning, benchmarks

Think Again or Think Longer? Selective Verification for Budget-Aware Reasoning, submitted 18 Jun 2026 by Sajib Acharjee Dip, Dawei Zhou and Liqing Zhang, proposes Sevra, a serving-layer controller that decides whether to keep a frozen solver's initial answer or invoke active verification.

What is Sevra and how does it work?

Sevra, short for Selective Verification for Reasoning Allocation, is a serving‑layer controller that learns recoverability‑aware gates from serving‑visible attempt state and then decides per example whether to preserve an initial answer or run verification. The authors implemented the controller using logs from a frozen Qwen3-4B solver and trained the gates from those intervention outcomes.

Sevra treats extra reasoning as a deployment allocation problem: verification is invoked selectively rather than always-on, so compute and verification tokens are spent only where the controller predicts recovery is likely or audit/regression risk requires it.

How does selective verification compare on benchmarks?

Selective verification reached 76.3% accuracy on MathFive, compared with 75.5% for always verifying; it reduced post‑generation tokens by 26.8% and cut harmful flips from 2.2% to 1.0%. An alternative tested was an 8,192‑token initial solve, which reached 76.0% accuracy while using 28% fewer total model tokens than the selective policy's realized tokens on that frontier, showing selective recovery helps but is not always the most efficient point on the cost frontier.

In frozen transfer to GSM the selective policy verified only 3.0% of examples, raised accuracy from 93.4% to 94.5%, and reduced verification tokens by 91.2% relative to always verifying; the paper notes a longer initial solve can match that accuracy with fewer realized tokens. On CommonsenseQA the authors report that always‑on verification hurts performance, while Self‑Consistency@5 improves accuracy but costs about five times more realized tokens.

Why it matters

Sevra reframes extra reasoning as an allocation decision at deployment, not just a new verification architecture. That matters for teams who must balance accuracy, compute cost, auditability and regression risk: the paper gives concrete switches to reduce unnecessary verification while still repairing failures on some datasets. The empirical numbers show selective recovery can reduce verification work substantially (verification tokens down 91.2% on GSM) while improving or matching accuracy versus always verifying.

What to watch

Tune the initial budget first, the authors advise: use a longer initial solve before adding selective recovery; then apply selective verification when explicit checks, bounded retries, auditability, or regression‑risk control matter. The next signals to watch are how selective policies transfer across more solvers than the frozen Qwen3-4B used here, and whether longer initial solves consistently dominate selective recovery on other tasks.

References and data points above are taken from the arXiv submission "Think Again or Think Longer? Selective Verification for Budget-Aware Reasoning" (submitted 18 Jun 2026) by Sajib Acharjee Dip, Dawei Zhou and Liqing Zhang.