LLM-as-a-Verifier
A General-Purpose Verification Framework
Any Modality Many Applications Verification Scaling
Overview
LLM-as-a-Verifier overview

We present LLM-as-a-Verifier, a general-purpose framework that provides fine-grained feedback for any modality without requiring additional training. By leveraging the full distribution of scoring-token logits, our method captures evaluation uncertainty and enables verification to scale along three dimensions: score granularity, repeated evaluation, and criteria decomposition. The resulting fine-grained feedback can be used for test-time scaling, progress tracking, and reinforcement learning.

Test-Time Scaling
State-of-the-art across domains

LLM-as-a-Verifier achieves state-of-the-art performance across coding, robotics, and medical domains: Terminal-Bench V2 (86.5%), SWE-Bench Verified (78.2%), RoboRewardBench (87.4%), and MedAgentBench (73.3%).

Reinforcement Learning
RL sample efficiency

LLM-as-a-Verifier as a dense reward signal improves the sample efficiency of both off-policy and on-policy RL algorithms. On LIBERO, LLM-as-a-Verifier achieves ≈ 1.8× higher sample efficiency than sparse reward baselines when fine-tuning a π0 policy with SAC. On the MATH reasoning benchmark, it achieves ≈ 1.1× higher sample efficiency when fine-tuning Qwen3-8B with GRPO.

Progress Tracking (Coding)
SUCCESS FAILED Task: pytorch-model-cli — run MNIST inference · Terminus-2 · Gemini 2.5 Pro
step 10/10
SUCCESS
FAILED

We observe a strong correlation between the chronological progression of code generation steps and the scores from LLM-as-a-Verifier. The successful trajectory of the pytorch-model-cli task follows a coherent sequence of events—Read model.py → Install g++ compiler → Install CPU-only torch → Update hidden_dim → DONE and exhibits consistently increasing verifier scores. In contrast, the failed trajectory is characterized by erroneous behaviors—it unnecessarily installs the large torchvision package, which exhausts the available disk space and hits a compilation error—resulting in significantly lower scores.

Progress Tracking (Robotics)
Task: Corn onto Plate
LLM-as-a-VerifierRoboRewardBench · Qwen 3.6
frame 1

LLM-as-a-Verifier generates a smooth, temporally aligned progress signal over the course of robot rollout while remaining robust to failure modes such as incorrect intent or imprecise grasping. The example above illustrates the “Corn on Plate” task from the RoboRewardBench-OOD dataset.

Three Simple APIs $pip install llm-verifier
llm_verifier.select
🏆 Best-of-N selection
from llm_verifier import select best = select(task, cands)

Score N candidates and return the best one — test-time scaling in a single call.

llm_verifier.compare
⚖️ Pairwise comparison
from llm_verifier import compare best = compare(task, a, b)

Directly score two candidates head-to-head with fine-grained preferences.

llm_verifier.track
📈 Progress tracking
from llm_verifier import track scores = track(task, traj)

Get a temporally aligned progress score over a rollout for monitoring or RL.

How does LLM-as-a-Verifier work?

The key idea behind it is simple

  • Use fine-grained scoring granularity (e.g., 1–20 instead of the standard 1–5 scale)
  • Take the expectation over the full logprob distribution of score tokens
  • Scale repeated evaluation and criteria decomposition
Motivation
Generation is Not the Bottleneck — Verification Is
Generation vs. verification

The key finding is that most agents already “know” how to solve the tasks. On Terminal-Bench, if you repeatedly sample 100 trajectories per task, they can outperform Claude Mythos and nearly solve the entire benchmark. But the problem is that they don't know which one is correct, particularly when dealing with long-horizon tasks. While standard LLM-as-a-Judge can be used here, they fail to provide sufficiently fine-grained feedback. When comparing complex solutions, judges often assign the same score, resulting in a tie and failing to discriminate between them. Coarse scoring leads to 27% ties on Terminal-Bench V2.

Methodology
Fine-Grained Reward Estimation

Given a task prompt \(x\), a language model \(p_\theta\), a criterion \(c\), and two candidate trajectories \(\tau_i\) and \(\tau_j\), we construct scoring prompts and obtain their conditional distributions \(p_{\theta}(v \mid x,c,\tau_i)\) and \(p_{\theta}(v \mid x, c, \tau_j)\) by extracting the logprobs from <score_A> and <score_B> tags using the following prompt:

You are an expert [domain] reviewer. You will see a task description and two trajectories. Evaluation Criteria: [domain specific criteria] Task: {task prompt} Trajectory A: {A} Trajectory B: {B} Carefully analyze each trajectory, then provide your final scores: <score_A> INTEGER_1_TO_20 </score_A> <score_B> INTEGER_1_TO_20 </score_B> Rating Rules: Rate correctness on a 1–20 scale based on evaluation criteria (1 = incorrect, 10 = borderline, 20 = correct) Note: We use a letter-based scale instead of digits to enable logprob extraction for granularity scaling.

Rather than collapsing each distribution to a single discrete score, we approximate the reward of a trajectory as:

\[ R(x, \tau) = \frac{1}{CK} \sum_{c=1}^{C} \sum_{k=1}^{K} \sum_{g=1}^{G} p_{\theta}(v_g \mid x, c, \tau)\,\phi(v_g) \]

where \(C\) is the number of evaluation criteria, \(K\) is the number of repeated verifications, \(G\) is the number of score tokens (granularity level), \(p_{\theta}(v_g \mid x, c, \tau)\) is the probability assigned by model \(\theta\) to score token \(v_g\), and \(\phi(v_g)\) maps each score token to a scalar value.

Probabilistic Pivot Tournament (PPT)
Probabilistic Pivot Tournament

To select the best of \(N\) candidates under a constrained verification budget, PPT compares each candidate against a small set of \(k \ll N\) pivots, cutting cost from \(\mathcal{O}(N^2)\) to \(\mathcal{O}(Nk)\).

(1) Candidates: the candidate pool \(\{\tau_1,\dots,\tau_N\}\) to be ranked.

(2) Ring pass: a random Hamiltonian cycle scores the \(N\) adjacent pairs so every candidate appears once in the “A” slot and once in “B”, canceling the model's positional bias.

(3) Pivot selection: candidates are ranked by their ring-pass scores \(w_{(i)}\), and the top-\(k\) candidates form the pivot set \(\mathcal{P}\).

(4) Pivot tournament: every non-pivot–vs–pivot and pivot–vs–pivot pair is scored with the fine-grained reward estimation above, concentrating the budget on uncertain top candidates and cutting cost from \(\mathcal{O}(N^2)\) to \(\mathcal{O}(Nk)\).

(5) Selection: comparisons are aggregated into weight \(w_i\) and count \(c_i\); the candidate with the highest normalized \(w_i/c_i\) is returned.

Analysis
Verification as a New Scaling Axis
Verification scaling

We find that verification accuracy consistently improves as we scale across multiple dimensions: (1) the granularity of score tokens, (2) the number of repeated evaluations, and (3) the decomposition of evaluation criteria.

What drives granularity scaling?

Better separation between positive and negative solutions. To isolate why finer granularity improves verification, we decompose the pairwise score gap between correct (\(s_c\)) and incorrect (\(s_i\)) trajectories into a signal and a noise component. We define the signal-to-noise ratio as below, where \(\mathbb{E}(s_c-s_i)\) captures how strongly the verifier prefers the correct trajectory over the incorrect one (signal strength), and the denominator, \(\mathrm{Var}(s_c - s_i)\), captures how inconsistent that preference is across pairs (noise).

\[ \mathrm{SNR}(G) = \frac{\mathbb{E}[s_c - s_i]}{\sqrt{\mathrm{Var}(s_c - s_i)}} \]
Signal-to-noise ratio grows with the number of scoring tokens \(G\) (Terminal-Bench V2, \(k{=}16\)).
Granularity \(G\)141620
SNR (k=16)0.7750.7860.7970.799
What drives repeated evaluation?

Variance reduction. LLM-as-a-Verifier consistently outperforms LLM-as-a-Judge , achieving 77.4% verification accuracy while eliminating ties entirely across all repeated verification budgets. Even at \(k = 16\), where repeated verification reduces judge ties, the verifier still maintains 7.2% higher accuracy.

Verifier vs Judge: accuracy and tie rate across repeated evaluations
What drives criteria decomposition?

Complexity reduction. Granularity and repeated evaluation both assume the rubric itself is adequate. In long-horizon agentic tasks, a judgment like “is this trajectory correct?” conflates several logically distinct factors, and a verifier asked a compound question often latches onto whichever factor is most salient in the prompt. We instead replace the single monolithic rubric with an ensemble over \(C\) simpler sub-criteria. For code-agent trajectories we decompose correctness into three factors that are each easier to verify — Specification (all task requirements satisfied), Output (final output format matches the expected result), and Errors (no failure signals in logs and tool outputs) — and average the expected scores across criteria. Any single criterion alone reaches 75.2–76.4% accuracy; their ensemble reaches 78.3%.

Criteria decomposition scaling
Case Study: Terminal-Bench

To concretely illustrate how scaling granularity to \(G{=}20\) and our probabilistic formulation sharpen the verifier's signal, we analyze a representative trajectory pair from the query-optimize task on Terminal-Bench V2. The agent is given a slow SQL query and asked to produce an equivalent optimized version; both candidates run faster, but only one validates equivalence against the canonical database. Over 100 repeated evaluations, a discrete 1–5 judge collapses these nuanced assessments into ties (88/100). Taking the expectation over the same 5-point distribution eliminates ties entirely and ranks the correct trajectory higher in 69/100 runs; scaling granularity to \(G{=}20\) sharpens the signal further, ranking it strictly higher in 77/100 runs.

Methodcorrect > incorrect ✅correct = incorrect ⚖️correct < incorrect ❌
Judge (discrete, G=5)12/10088/1000/100
Verifier (continuous, G=5)69/1000/10031/100
Verifier (continuous, G=20)77/1000/10023/100
Experiments
Test-Time Scaling Results
Per-Benchmark Performance

Across challenging benchmarks such as Terminal-Bench V2, SWE-Bench Verified, and MedAgentBench, LLM-as-a-Verifier outperforms frontier models including Claude Opus 4.8, GPT 5.5, and Gemini models. Results for Terminal-Bench and SWE-Bench are reported from the official leaderboards.

BenchmarkBaseline models (accuracy)LLM-as-a-Verifier
#1#2#3Pass@1OracleOurs
Terminal-Bench V2GPT-5.5 (84.7%)Opus 4.7 (80.2%)Gemini 3.1 Pro (80.2%)83.1%92.1%86.5%
SWE-Bench VerifiedOpus 4.5 (76.8%)Gemini 3 Flash (75.8%)MiniMax M2.5 (75.8%)76.1%84.4%78.2%
MedAgentBenchOpus 4.8 (70.2%)Gemini 3.5 Flash (66.3%)GPT-5.5 (65.1%)70.2%75.0%73.3%
Preference Accuracy on RoboRewardBench

For RoboRewardBench, we curate pairs of rollout videos that follow the same natural-language instruction but make different amounts of progress; the reward model must output a preference indicating which rollout makes more progress. LLM-as-a-Verifier outperforms fine-tuned robotics reward models.

MethodAccuracy (%)
TOPReward74.7
Robometer-4B78.8
RoboReward-8B81.4
LLM-as-a-Judge (Discrete)70.8
LLM-as-a-Verifier (Ours)87.4
Progress Tracking Results

We quantify progress tracking with the Value-Order Correlation (VOC) — the Spearman rank correlation between a step's chronological index and the verifier's predicted value for the prefix ending at that step. A verifier that tracks progress assigns monotonically higher scores to later prefixes of a successful rollout (\(\mathrm{VOC}\to 1\)):

\[ \mathrm{VOC} = \mathrm{rank\text{-}correlation}\!\left( \mathrm{argsort}(s_{t_1}, s_{t_2}, \cdots, s_{t_K}),\ (t_1, t_2, \cdots, t_K) \right) \]
VOC on Terminal-Bench V2

Successful rollouts show near-monotonic progress, while failed rollouts correlate more weakly.

Trajectory outcomeSpearman VOC
Successful0.848
Failed0.769
Success − Failed (gap)+0.079
VOC on RoboRewardBench

LLM-as-a-Verifier attains the highest correlation between step index and predicted progress, outperforming fine-tuned robotics reward models.

MethodSpearman VOC
LLM-as-a-Verifier (Qwen 3.6 35B)0.966
RoboReward-8B0.877
Robometer-4B0.780
TOPReward (Qwen 3.6)0.565
Reinforcement Learning Results

The fine-grained verifier score is a drop-in dense reward for both off-policy and on-policy RL, improving sample efficiency by ≈1.8× on LIBERO and ≈1.1× on MATH.

Off-policy RL: dense progress rewards for DSRL-SAC

When fine-tuning a \(\pi_0\) policy on LIBERO with SAC, we relabel each rollout with the verifier's per-step progress score \(\rho_t\) as a dense shaped reward, then store the transitions in the replay buffer \(\mathcal{D}\) and train the SAC critic on returns sampled from \(\mathcal{D}\):

\[ r_t = r^{\text{env}}_t + \lambda\,\rho_t \qquad\quad \mathcal{D} \leftarrow \mathcal{D} \cup \{(s_t, a_t, r_t, s_{t+1})\} \]
Sample Efficiency on LIBERO (\(\pi_0\) + DSRL-SAC)

Environment timesteps required to reach each target success rate (averaged over \(n{=}5\) seeds).

Target SR (%)SparseLLM-as-a-VerifierSteps savedSpeedup
20132,80074,30058,5001.79×
40309,400168,500140,9001.84×
60993,800600,000393,8001.66×
On-policy RL: dense reasoning rewards for GRPO

When fine-tuning Qwen3-8B on MATH with GRPO, sparse correctness rewards give no gradient when every sampled answer is wrong. We score each completion's reasoning trace with the Probabilistic Pivot Tournament (PPT) and add this reasoning-quality score to the correctness and format rewards to provide additional signal:

\[ r_i = r_{\mathrm{correct},i} + r_{\mathrm{format},i} + \beta\, r_{\mathrm{reasoning},i} \]
Sample Efficiency on MATH (Qwen3-8B + GRPO)

Sampled completions required to reach each target success rate (averaged over \(n{=}3\) seeds; each step samples 1024).

Target SR (%)SparseLLM-as-a-VerifierCompletions savedSpeedup
2040,89036,0104,8801.14×
4047,99043,4504,5401.10×
6055,86050,7805,0801.10×
Appendix
Recovering Continuous Rewards for Logit-Restricted Frontier Models

Some frontier models (e.g., GPT-5.5, Claude Opus) expose only sampled completions and withhold token-level logprobs, which our continuous reward requires. A simple two-stage workaround recovers most of the calibrated signal: the closed model supplies domain-specific reasoning, and an open verifier supplies the calibrated probability distribution it withholds.

🔒
Closed Frontier Model
GPT-5.5 · Claude Opus
logprobs withheld
reasoning + draft score
🔓
Open Verifier
Gemini 2.5 Flash (G=20)
reads <score_A>/<score_B> logprobs
expectation over logits
📈
Continuous Reward
\(R(x,\tau)\)

On Terminal-Bench V2, routing GPT-5.5's reasoning through Gemini 2.5 Flash recovers a +5.2-point accuracy gain over directly using the closed model's integer scores (80.1% vs. 74.9%) and eliminates its 10.9% tie rate entirely — without any access to the frontier model's logits.

\(K\)GPT-5.5 (Discrete)GPT-5.5 → Gemini 2.5 Flash (Continuous)
Accuracy (%)Tie rate (%)Accuracy (%)Tie rate (%)
174.910.980.10.0
276.39.180.50.0
477.67.081.00.0
878.45.880.90.0
1679.15.081.20.0

BibTeX

@misc{kwok2026llmasaverifiergeneralpurposeverificationframework,
      title={LLM-as-a-Verifier: A General-Purpose Verification Framework},
      author={Jacky Kwok and Shulu Li and Pranav Atreya and Yuejiang Liu and Yixing Jiang and Chelsea Finn and Marco Pavone and Ion Stoica and Azalia Mirhoseini},
      year={2026},
      eprint={2607.05391},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2607.05391},
}