As the focus in LLM-based coding shifts from static single-step code generation to multi-step agentic interaction with tools and environments, understanding which tasks will challenge agents and why becomes increasingly difficult. This is compounded by current practice: agent performance is typically measured by aggregate pass rates on benchmarks, but single-number metrics obscure the diversity of tasks within a benchmark. We present a framework for predicting success or failure on individual tasks tailored to the agentic coding regime. Our approach augments Item Response Theory (IRT) with rich features extracted from tasks, including issue statements, repository contexts, solutions, and test cases, and introduces a novel decomposition of agent ability into LLM and scaffold ability components. This parameterization enables us to aggregate evaluation data across heterogeneous leaderboards and accurately predict task-level performance for unseen benchmarks, as well as unseen LLM-scaffold combinations. Our methods have practical utility for benchmark designers, who can better calibrate the difficulty of their new tasks without running computationally expensive agent evaluations.
Figures & tables
Figure 1: Agent and task features predicting success probability. On the agent side, the features are two categorical variables, the LLM and the scaffold; on the task side, they are vectors extracted from rich task artifacts. From these we estimate the agent’s ability and the task’s difficulty , then apply the logistic model from IRT ( Baker, 2001 ) to predict the probability that the agent succeeds on the task.
Setting
# Bench.
Method
Held-Out
Metric
Objective
New Tasks
Single
IRT with task features
Random subset of tasks (in-distribution)
Mean 5-fold CV AUC-ROC over tasks
Test whether task features explain task difficulty.
New Responses
Single & Multi
IRT with agent features
Random subset of responses (in-distribution)
Mean 5-fold CV AUC-ROC over responses
Test whether LLM and scaffold abilities combine additively.
New Agents
Single
IRT with agent features
Agents whose LLM and scaffold were individually seen
Mean 5-fold CV AUC-ROC over agents with seen LLMs and scaffolds
Test generalization to unseen model–scaffold combinations.
New Benchmarks
Multi
IRT with task & agent features
Entire benchmark (out-of-distribution)
Validation AUC-ROC on held-out benchmark
Test out-of-distribution generalization for early-stage benchmark design.
Table 1: Experimental settings. We evaluate response prediction under four settings.
Method
SWE-bench Verified
SWE-bench Pro
GSO
Terminal-Bench 2.0
Baseline
0.718 ± 0.001
0.656 ± 0.001
0.718 ± 0.007
0.732 ± 0.002
Embedding
0.824 ± 0.002
0.752 ± 0.003
0.756 ± 0.010
0.767 ± 0.010
LLM-as-a-judge
0.840 ± 0.001
0.743 ± 0.003
0.778 ± 0.015
0.794 ± 0.007
Combined
0.841 ± 0.003
0.763 ± 0.003
0.787 ± 0.014
0.792 ± 0.013
Oracle
0.945 ± 0.000
0.918 ± 0.000
0.916 ± 0.002
0.932 ± 0.001
Table 2: AUC-ROC (mean ± std of 5-fold cross-validation means across 20 random seeds) on held-out tasks for each of the four benchmarks . All feature vector-based predictors significantly beat the Baseline , which always predicts the agent’s empirical success rate from the training data. Oracle is a standard IRT trained on all tasks, serving as an upper bound on performance.
Feature Source
SWE-bench Verified
SWE-bench Pro
GSO
Terminal-Bench 2.0
LLM-as-a-judge features
Problem statement only
0.786 ± 0.002
0.718 ± 0.002
0.710 ± 0.012
0.789 ± 0.007
Full w/o repository state
0.840 ± 0.001
0.732 ± 0.003
0.775 ± 0.017
0.797 ± 0.006
Full w/o tests
0.837 ± 0.001
0.735 ± 0.002
0.766 ± 0.011
0.798 ± 0.005
Full w/o solution
0.833 ± 0.002
0.748 ± 0.002
0.728 ± 0.010
0.797 ± 0.005
Full
0.845 ± 0.002
0.750 ± 0.003
0.774 ± 0.016
0.799 ± 0.006
Table 3: Feature source ablation: AUC-ROC (mean ± std of 5-fold cross-validation means across 20 random seeds) of predictors with some feature sources removed. For LLM-as-a-judge features, we remove each of the three agentic feature sources one at a time. For embedding features, we compare a problem-statement-only predictor (the method of Truong et al. (2025) applied without modification) and one that additionally includes the solution.
Method
SWE-bench Verified
Terminal-Bench 2.0
Baseline
0.852 ± 0.010
0.839 ± 0.001
IRT-Agent
0.930 ± 0.002
0.923 ± 0.001
Oracle
0.949 ± 0.002
0.935 ± 0.001
Table 4: AUC-ROC (mean ± std of 5-fold cross-validation means across 20 random seeds) of predictors fitted on held-out agent data. Baseline predicts the task’s empirical solve rate; Oracle is a standard IRT trained on all data.
Method
SWE-bench Pro
GSO
Baseline
0.571
0.637
Embedding
0.667
0.724
LLM-as-a-judge
0.696
0.743
Combined
0.674
0.719
Oracle
0.913
0.912
Table 5: AUC-ROC of predictors fitted on three benchmarks when evaluated on a fourth held-out benchmark. Baseline predicts the LLM’s empirical success rate ignoring the scaffold; Oracle is an IRT with agent features trained on all data from all four benchmarks.
Figure 2: Adaptive evaluation of a new agent on SWE-bench Verified. Mean absolute error between the running ability estimate θ^i and the full-benchmark IRT ability θi⋆ , averaged over 30 held-out LLM-scaffold pairs. Shaded regions show 95% bootstrap confidence intervals over held-out agents.
Appendix figures & tables19 assets
Supplementary material from the paper’s appendix.
Appendix
Feature source
Extracted by
# extracted
# in default set
Problem statement
Claude Opus 4.6 (main prompt)
15
10
Test cases
Claude Opus 4.6 (main prompt)
3
1
Solution
Claude Opus 4.6 (main prompt)
2
1
Repository state
GPT-5.4 (auditor agent prompt)
8
3
Total
28
15
Appendix
Table 6: LLM-as-a-judge feature inventory. The default set of 15 features is used, unchanged, for every benchmark and every experiment except the feature source ablations.
Ablation (Table 3 )
Ablation (Table 10 )
Sources in predictor
Sources in main prompt
Problem statement only
Problem statement
stmt.
stmt.
+ Repository state
stmt., repo.
stmt.
Full w/o solution
+ Tests
stmt., tests, repo.
stmt., tests
Full w/o tests
stmt., sol., repo.
stmt., sol.
Full w/o repository state
stmt., tests, sol.
stmt., tests, sol.
Full
+ Solution
stmt., tests, sol., repo.
stmt., tests, sol.
Appendix
Table 7: Configuration of each feature source ablation level. “Sources in predictor” lists the sources whose features enter the predictor at the given level. “Sources in main prompt” lists the sources provided in the main judge prompt (used to extract all features included at the given level except the repository state features, which are extracted via an independent pipeline).
Backbone
AUC-ROC ± std
Qwen3-VL-4B-Instruct
0.814 ± 0.017
Qwen3-VL-8B-Instruct
0.816 ± 0.017
Qwen3-VL-32B-Instruct
0.817 ± 0.018
Qwen3-8B
0.798 ± 0.021
Qwen3-14B
0.817 ± 0.021
Qwen3-32B
0.801 ± 0.026
Appendix
Table 8: Embedding backbone test . AUC-ROC is averaged over 5 cross-validation folds; standard deviation ( std ) is also shown.
Benchmark
Claude Opus 4.6
GPT-5.4
Claude Sonnet 4.6
SWE-bench Verified
0.842
0.835
0.838
SWE-bench Pro
0.759
0.760
0.758
GSO
0.804
0.701
0.746
Terminal-Bench 2.0
0.810
0.828
0.830
Appendix
Table 9: LLM-as-a-Judge backbone ablation. Grouped Ridge (Embedding + LLM Judge) AUC-ROC across backbones. Bold indicates best per dataset.
Feature Source
SWE-bench Verified
SWE-bench Pro
GSO
Terminal-Bench 2.0
Problem statement
0.786 ± 0.002
0.718 ± 0.002
0.710 ± 0.012
0.789 ± 0.007
+ Repository state
0.797 ± 0.002
0.735 ± 0.001
0.713 ± 0.012
0.796 ± 0.008
+ Tests
0.833 ± 0.002
0.748 ± 0.002
0.728 ± 0.010
0.797 ± 0.005
+ Solution
0.845 ± 0.002
0.750 ± 0.003
0.774 ± 0.016
0.799 ± 0.006
Appendix
Table 10: Hierarchical information source ablation. AUC-ROC (mean ± std of cross-validation means across 20 random seeds) of LLM-as-a-judge difficulty predictors as feature sources are added in order of increasing access (problem statement, repository state, test cases, solution). Each row adds one source on top of those in the previous row, and the top 15 features are selected by ridge regression coefficient from the cumulative features available at each row, similar to Table 3 . The solution contributes the largest gain on three of four benchmarks—most strikingly on GSO, where adding the solution lifts AUC from 0.728 to 0.774—but it is also the feature source which is the most difficult to obtain. On SWE-bench Verified, the test cases contribute a comparable amount (0.797 → 0.833).
Benchmark
Baseline
Embedding
LLM-as-a-Judge
Combined
Oracle
SWE-bench Verified
0.718
0.825
0.842
0.843
0.945
SWE-bench Pro
0.657
0.756
0.744
0.750
0.918
GSO
0.714
0.771
0.769
0.781
0.914
Terminal-Bench 2.0
0.734
0.795
0.805
0.807
0.932
Appendix
Table 11: Jointly training the linear difficulty predictor model with the IRT abilities results in slightly lower AUC for held-out tasks on most benchmarks compared to training a ridge regression and using frozen IRT abilities during evaluation.
Functional Form
Formula
AUC-ROC
Sum
θm+θs
0.939 ± 0.000
Maximum
max(θm,θs)
0.937 ± 0.000
Minimum
min(θm,θs)
0.937 ± 0.000
Product
sign(θm+θs)∣θmθs∣
0.933 ± 0.001
L2 norm
sign(θm+θs)θm2+θs2
0.938 ± 0.000
Harmonic mean
sign(θm+θs)θm+θs2θmθs
0.815 ± 0.004
Appendix
Table 12: Functional form test for the relationship between the LLM and scaffold ability parameters . All runs are conducted with the best backbone ( DeepSeek-R1-Distill-Qwen-32B ). AUC-ROC is the mean ( ± std) of 5-fold cross-validation means across 20 random seeds. In the weighted sum, wm and ws are additional learnable parameters (shared for all LLMs and scaffolds). Sum with variance term aims to capture each LLM’s sensitivity to scaffolds: combined with a good scaffold (positive θs ), an LLM with a high variance term λm will do better than predicted by regular sum, and combined with a bad scaffold (negative θs ), worse than predicted by regular sum.
Protocol
Baseline
Embedding
LLM-as-a-Judge
Combined
Oracle
Binary (main paper)
0.732 ± 0.002
0.767 ± 0.010
0.794 ± 0.007
0.792 ± 0.013
0.932 ± 0.001
All attempts
0.754 ± 0.002
0.777 ± 0.005
0.801 ± 0.005
0.796 ± 0.010
0.912 ± 0.001
Appendix
Table 13: Treating each attempt as an independent trial on Terminal-Bench 2.0 (mean ± std of cross-validation means across 20 random seeds). The Binary row reproduces the Terminal-Bench 2.0 row of Table 2 ; the All attempts row repeats the same experiment but treats each attempt as an independent observation for both training and evaluation. The Oracle drops by about 0.02 AUC under this protocol due to being evaluated on multiple attempts instead of one binary majority outcome; the predictor methods reach comparable AUC under both protocols.
Table 14: Bootstrapping results for the New Tasks experiment. All IRT-based methods significantly beat the naive baseline (two-sided p -value below the resolution of bootstrapping with 10,000 samples, which is equal to 0.0002; Holm-adjusted p -value below 0.0024).
Table 15: Bootstrapping results for the New Responses experiment. IRT-Agent —the proposed IRT model with LLM-scaffold decomposition—is not expected to (significantly) beat Standard IRT , because its intended use case is generalization to multi-benchmark IRT models.
Table 16: Bootstrapping results for the New Agents experiment. IRT-Agent significantly beats the naive baseline (two-sided p -value below the resolution of bootstrapping with 10,000 samples, which is equal to 0.0002; Holm-adjusted p -value below 0.0004).
Table 17: Bootstrapping results for the New Benchmarks experiment. All IRT-based methods significantly beat the naive baseline, both before and after the Holm-Bonferroni correction.
Terminal-Bench 2.0
GSO
domain_knowledge_required (1–5)
1
Basic shell commands anyone could use (ls, cd, cat, echo)
Deep understanding of systems (kernel, filesystems, protocols)
Deep understanding of library implementation
5
Obscure tools, APIs, or highly specialized domain knowledge
Expert knowledge (SIMD, memory layout, CPU caches)
Appendix
Table 18: Per-dataset scale text variants for features that differ across datasets. Five features ( solution_hint , logical_reasoning_required , atypicality , verification_difficulty , and codebase_scope ) use the same scale text across all datasets and are omitted.
Terminal-Bench 2.0
GSO
reproduction_clarity (1–5)
1
No setup steps, unclear how to begin
No benchmark or test scenario provided
2
Vague environment requirements mentioned
Vague description of slow use case
3
General setup described
General performance scenario described
4
Clear steps but some prerequisites unclear
Clear benchmark but some parameters unclear
5
Exact setup and execution steps with commands provided
Exact benchmark with input sizes and expected speedup
Appendix
Table 19: Per-dataset scale text variants for the 5 additional features (from the information ablation) that differ across datasets.
Benchmark
IRT-Agent
Standard IRT
Oracle
SWE-bench Verified
0.939 ± 0.000
0.940 ± 0.000
0.945 ± 0.000
SWE-bench Pro
0.870 ± 0.002
0.875 ± 0.002
0.919 ± 0.000
GSO
0.810 ± 0.014
0.814 ± 0.015
0.920 ± 0.001
Terminal-Bench 2.0
0.925 ± 0.000
0.925 ± 0.001
0.935 ± 0.000
All benchmarks
0.930 ± 0.000
—
—
Appendix
Table 20: AUC-ROC (mean ± std of cross-validation means across 20 random seeds) on held-out responses . IRT-Agent —our proposed IRT model with agent features—performs on par with Standard IRT despite being strictly less expressive, while enabling multi-benchmark training and predictions with high performance. Both approach Oracle , which is another standard IRT model trained on all data, including the held-out responses.
Figure 3: Task difficulty histograms. SWE-bench Pro is harder on average than Verified, GSO is the hardest, and Terminal-Bench 2.0 is highly heterogeneous.
Rank
LLM
Ability ( θm )
1
Gemini 3.1 Pro
3.660
2
GPT-5.3-Codex
3.440
3
Claude Opus 4.6
3.332
4
GPT-5.2-Codex
2.997
5
GPT-5.2
2.697
6
Claude Opus 4.5
2.607
Appendix
Table 21: Top-15 and bottom-15 LLMs by IRT ability. Teletype font indicates open-weight LLMs.
Rank
Scaffold
Ability ( θs )
1
AgentScope
1.453
2
Learn-by-interact
1.207
3
Ante
1.060
4
Junie
0.919
5
AutoCodeRover v20240620
0.896
6
Z.ai
0.805
Appendix
Table 22: Top-15 and bottom-15 scaffolds by IRT ability. Teletype font indicates open-source scaffolds.
Figure 4: Validation of decomposition. Strong correlation (Pearson r=0.974 ) between agent abilities learned on a fixed scaffold (Terminus 2) versus LLM abilities isolated via our decomposition method.
Repository benchmarks (e.g., SWE-bench) for coding agents often assume that lines of code edited can predict task difficulty, but such datasets' poor control over code and task types makes it hard to know which abilities truly drive agent errors. We present CABRA: a Coding Ability Blueprint for Rigorous Agent evaluation. CABRA builds tasks from scratch as call graph transformations and scales difficulty via a task size parameter on four axes: function traversal, search, runtime resolution, and instruction following. We run eight LLMs and six coding agents on 6,840 CABRA tasks to show: 1) LLM accuracy falls as task size~grows, but agents stay near-perfect by offloading work to tools (e.g., grep); 2) Larger CABRA tasks elicit more tool calls for reading and analysis, while a separate study on SWE-bench Verified shows these tool call counts predict agents' accuracy better than lines of code edited, suggesting task difficulty for agents can lie in understanding code to edit, not just in making edits; 3) Extending CABRA to an intense understanding task where models analyze divergent logic across two classes backs this finding, as agent accuracy finally falls. More broadly, we argue for synthetic evaluations like CABRA to unmask LLM weaknesses trivialized by tools (e.g., needle-in-a-haystack) and abilities beyond just editing (e.g., understanding) that coding agents still find difficult, pairing SWE-bench-style tasks with controlled diagnosis.
How can we predict which base checkpoint is worth an expensive round of agentic post-training? End-to-end pass@K tests whether successful behavior already appears in a base model's distribution, but it is a poor fit for agentic coding: many base checkpoints cannot reliably produce the well-formed tool invocation required to complete a task end-to-end. Single-shot or short-horizon tasks avoid these tool-calling failures by collapsing a multi-step interaction into a fixed prompt and a single patch, but they sidestep the core capability we care about: maintaining coherent state over many tool-using steps as the repository evolves. To bridge this gap, we treat successful post-trained agent trajectories as a lookahead signal of base-model potential. Replaying each trajectory and rerunning tests after every code-changing step identifies the decisive step: the first step whose cumulative patch flips the repository from failing to passing, certifying that the recorded action solves the task given the prior context. Motivated by a coverage principle for agentic traces, we build three screens at this step that do not require a base checkpoint to drive the harness from a cold start: (i) Decisive-Action BPB (bits per byte) measures the probability mass on the certified action, (ii) Patch MCQ tests the checkpoint's choice between that action and alternatives rejected by the same verifier, and (iii) prefix-conditioned pass@K evaluates support for functionally-correct generations and credits any continuation that the tests accept. Across ten pairs of public base and post-trained models, all three screens rank the cohort in close agreement with post-trained SWE-bench Verified pass@1. As our methods need only a benchmark's successful trajectories and its verifier, they can be applied to turn future agentic coding benchmarks into base-model evaluations.
Tan Yu, Alexander Bukharin, Khushi Bhardwaj +19
NVIDIA · University of Minnesota – Twin Cities · University of California, Berkeley
We introduce ISO-Bench, a benchmark for coding agents to test their capabilities on real-world inference optimization tasks. These tasks were taken from vLLM and SGLang, two of the most popular LLM serving frameworks. Each task provides an agent with a codebase and bottleneck description, whereby the agent must produce an optimization patch evaluated against expert human solutions. We curated 54 tasks from merged pull requests with measurable performance improvements. While existing benchmarks heavily use runtime-based metrics, such approaches can be gamed to pass tests without capturing the actual intent of the code changes. Therefore, we combine both hard (execution-based) and soft (LLM-based) metrics to show that both are necessary for complete evaluation. While evaluating both closed and open-source coding agents, we find no single agent dominates across codebases. Surprisingly, agents often identify correct bottlenecks but fail to execute working solutions. We also show that agents with identical underlying models differ substantially, suggesting scaffolding is as important as the model.