TOOL | Eval statistics
Eval Sample Size and Power Calculator
Find how many eval runs you need to detect a pass-rate drop at a target power, across two-arm, fixed-baseline, and paired McNemar designs.
An eval's run count is knowable before it starts. Detecting a 5-point drop from a 90% baseline at 80% power takes 686 runs per arm. Repeating each case is a separate protocol; what that run will cost follows from both.
Our run-count derivation assumes a one-sided test. Report the rate with a confidence interval; the McNemar calculator covers the paired design. How many items the set needs is a different count, and a live canary needs a stopping rule.
Showing your last valid result. Update the inputs above to recompute.
Runs per arm
686
1,372 total across two fresh arms to detect a 5-point drop from a baseline of 90% at 80% power (two-sided alpha 0.05).
Paired (McNemar) | matched items
0
Runs by design
The default sizes two fresh arms; use the fixed-baseline count only when the baseline is a large, trusted reference you are not re-running.
| Design | Runs needed | What it assumes |
|---|---|---|
| Two fresh arms (pooled) | 686 per arm | 1,372 total | Candidate and baseline both re-run; neither treated as fixed. |
| Two fresh arms, continuity-corrected | 726 per arm | 1,452 total | Fleiss (Casagrande, Pike, Smith) correction for the discrete test. |
| Fixed baseline (one-sample) | 316 runs | Baseline is a large, trusted historical reference held constant. |
Runs per arm by drop size
Halving the drop you want to catch roughly quadruples the runs, because the count scales with the inverse square of the effect size.
| Drop (pts) | Runs per arm | Total runs | With continuity |
|---|---|---|---|
| 1 | 14,751 | 29,502 | 14,951 |
| 2 | 3,841 | 7,682 | 3,941 |
| 3 | 1,774 | 3,548 | 1,841 |
| 5 | 686 | 1,372 | 726 |
| 10 | 199 | 398 | 219 |
| 15 | 100 | 200 | 113 |
| 20 | 62 | 124 | 72 |
Is another block of runs worth its price?
Run it
Run the block just priced () and come back with the result. Then write the ship/hold decision in the release gate designer. The release gate designer records the decision and its conditions.
Net value
0.00
Value of the block minus its cost.
Power of the next block
Value of the next block
Cost of the block
Break-even cost per run
Break-even regression cost
Smallest detectable change
6.2 points
Connor 1987, exact form, paired, two-sided, 80% power.
| Figure | Value |
|---|
At one run per side, the Connor count and Miller's Equation 9 differ by a few items: Connor's formula takes the squared change out of the discordance under the alternative, and Equation 9 uses the discordance as it stands.
| Items | 5% discordance | 10% discordance | 20% discordance | 30% discordance |
|---|
This mode shows what a given number of items can detect. Sizing a new eval for a target drop is on the "How many runs" mode. The repeated-run variance planner measures the rerun disagreement this mode takes as input.
n per arm = (z(1-alpha/2)*sqrt(2*pbar*(1-pbar)) + z(power)*sqrt(p0*(1-p0)+p1*(1-p1)))^2 / delta^2How?
How this is calculated
The default design compares two builds run fresh: a candidate against a
baseline, both measured with the same harness. Sizing it is a
two-proportion power calculation. Write p0 for the baseline
pass rate, p1 = p0 - delta for the degraded rate you want to
flag, and pbar = (p0 + p1) / 2 for the pooled proportion under
the null. With z(1-alpha/2) the two-sided significance
quantile and z(power) the power quantile, the runs needed per
arm are the formula above, the uncorrected two-sample approximation given
by Casagrande, Pike and Smith (1978). The result is rounded up.
Worked example (the defaults). Baseline 90%, drop 5
points, so p0 = 0.90, p1 = 0.85,
delta = 0.05, pbar = 0.875. Two-sided alpha 0.05
gives z = 1.95996; power 80% gives z = 0.84162.
The null spread is sqrt(2 * 0.875 * 0.125) = 0.46771 and the
alternative spread is sqrt(0.9*0.1 + 0.85*0.15) = 0.46637. So
n = (1.95996*0.46771 + 0.84162*0.46637)^2 / 0.05^2 = 685.6,
which rounds up to 686 runs per arm, or 1,372 total.
Fixed baseline (one-sample). When the baseline is a large,
trusted historical reference held constant, only the candidate arm carries
noise, the single-proportion form in the NIST/SEMATECH e-Handbook 7.2.4.2:
n = (z(1-alpha/2)*sqrt(p0*(1-p0)) + z(power)*sqrt(p1*(1-p1)))^2
/ delta^2. On the same inputs that is
(1.95996*0.3 + 0.84162*0.35707)^2 / 0.0025 = 315.8, or
316 runs. It is cheaper because it does not pay for a
second noisy arm.
Continuity correction. The Fleiss
(Casagrande, Pike and Smith 1978) adjustment nudges the count up to keep
the discrete pass/fail test at its stated false-alarm rate:
n' = (n/4)*(1 + sqrt(1 + 4/(n*delta)))^2. On the worked
example that turns 686 into 726 per arm.
Paired (McNemar) design. If the same items are scored
under both conditions, size the number of matched items with Connor's 1987
normal approximation. With psi the discordant proportion
(items that flip) and delta the marginal difference:
pairs = (z(1-alpha/2)*sqrt(psi) + z(power)*sqrt(psi - delta^2))^2 /
delta^2. At a 20% discordance rate on the worked example that is
626 matched items. The estimate needs
psi >= delta; below that it is dropped rather than shown as
a nonsensical count.
Assumptions. All four designs use the normal approximation, which holds when the counts are moderate and the pass rate is not near 0% or 100%; near the ceiling, prefer an exact interval. Runs are assumed independent, one minimum detectable drop is chosen up front, and the two-arm test uses the pooled variance under the null. The default test here is two-sided. The companion analysis at how many runs a reliable eval needs tables the one-sided fixed-baseline case, whose counts run lower for the same inputs, and explains why a single green re-run answers a different question than "would this eval catch the regression you care about."
The detectable change at a given number of items is the Connor 1987 formula inverted by bisection. With z(1-alpha/2) (or z(1-alpha) one-sided) and z(power) the normal quantiles and psi the discordance, the Connor count at a change d is n(d) = (z(1-alpha/2)*sqrt(psi) + z(power)*sqrt(psi - d^2))^2 / d^2, the paired formula above. The detectable change is the d in (0, psi] for which n(d) equals your item count. The range caps at psi because a paired change larger than the discordance needs more one-way flips than there are flips. The shortcut form (z(1-alpha/2) + z(power))*sqrt(psi / n) is printed beside it. On the returns-desk example (40 items, 22.5% discordance), the Connor formula gives a detectable change of 20.4 points and the shortcut gives 21.0.
When runs per side K exceeds 1, the formula follows Miller Equation 9. Each version's run-to-run variance is half the rerun disagreement, so together they equal the rerun disagreement, and the version-to-version part is the discordance minus the rerun disagreement, floored at zero. The planning variance is V(K) = (psi - rerun) + rerun / K, where rerun is the rerun disagreement, and the detectable change is (z(1-alpha/2) + z(power))*sqrt(V(K) / n). The K = 1 row prints the Connor count and the Equation 9 count side by side. On the example at K = 3 with 11.5% rerun disagreement, the detectable change drops to 17.1 points.
A judge with Youden J below 1 attenuates the observed change. The true detectable change is the observed figure divided by J, and the item count scales by at least about 1 / J squared. When the judge J differs between the two systems, the page prints both values and warns that one J cannot correct the comparison.
The unpaired contrast shows what the same budget detects on different item sets: the two-arm detectable change at n items per arm at the stated baseline. On the example at a baseline of 70%, the unpaired figure is 30.7 points, compared with 20.4 paired.
A discordance that cannot occur at the stated baseline is refused: the share of items flipping one way cannot exceed the baseline passing or failing share. The smallest set that can detect any paired change at a given discordance is the count where the Connor formula returns the discordance itself as the detectable change; below it, no paired change is detectable. On the example, that minimum is 33 items.
Value of the next block. The mode asks whether a fixed block of extra runs is worth its price. It treats the block as fresh evidence sized on the entered run count alone; everything the reader already knows goes into the prior belief. Power at the entered block size is the standard two-proportion or fixed-baseline calculation inverted: instead of solving for the count at a target power, the mode computes the power at a given count.
The decision has two possible errors, each with a cost the reader enters. Shipping a real regression costs the entered regression stake; holding a release that was fine costs the entered hold stake. At any belief that a regression is present, the expected loss of the better action is the smaller of the two products: the belief times the regression stake, or one minus the belief times the hold stake. Without running the block, decide now and accept that loss. With the block, the expected loss falls to a weighted mix of the loss after a flag and the loss after a clear, where the flag probability and the two posteriors come from Bayes' rule on the block's power and the entered prior. The value of the block is the difference: the expected reduction in loss from having the evidence before deciding.
Under the null hypothesis (no real difference), a two-sided test at level alpha reports a drop with probability alpha/2. The mode uses alpha/2 as the null flag rate and alpha/2 as the uninformative threshold. A block whose power does not exceed that threshold cannot separate signal from the test's own false-flag rate.
When the better action is the same at the prior and at both posteriors, the value is exactly zero at this block size, because no outcome the block can produce changes anything. A larger block raises the power, which moves the posteriors, and can reach a belief where the better action flips.
No confidence interval appears on this mode's figures, and none is owed. Nothing here is estimated from data: the prior is entered by the reader, power is computed from entered rates, and both stakes and the cost are entered.
Formula: n per arm = (z(1-alpha/2)*sqrt(2*pbar*(1-pbar)) + z(power)*sqrt(p0*(1-p0)+p1*(1-p1)))^2 / delta^2
Questions
How many eval runs do I need to catch a regression?
Enough to see the smallest drop you would roll back a release for, at the power you want. Fix three inputs, the baseline pass rate, the drop to detect, and the target power, and the runs needed is determined. Catching a 5-point drop from a 90% baseline at 80% power takes 686 runs per arm on the two-proportion design, or 316 against a fixed baseline. Sub-point drops need four-figure counts and are effectively out of reach on a normal CI budget. To see how many minutes that run count adds to each CI tier, enter it in the CI time and cost planner.
Why does the count balloon for small drops?
Runs scale with the inverse square of the drop you want to catch. Halving the effect size roughly quadruples the runs. Raising power from 80% to 90% adds about a third more runs across the board. The table above makes both curves concrete for a 90% baseline.
Should I use the two-arm or the fixed-baseline number?
Use two arms when you re-run the baseline fresh each time, so both sides carry sampling noise. Use the fixed-baseline count only when the baseline is a large, trusted historical reference you hold constant. The two-arm count is roughly twice the fixed-baseline count because it pays for a second noisy arm.
When is a paired design worth it?
When you can score the same items under both conditions. A paired McNemar test spends only on the items that flip pass or fail, so it usually needs far fewer items than two independent arms. It requires a discordance rate at least as large as the drop you are testing for.
Is it worth running more eval cases, or should I decide with what I have?
Switch to the "Is another block worth it" mode and enter the cost of one run, the cost of shipping a regression, and the cost of holding a good release. The mode computes how much the next block reduces the expected loss of a wrong decision. When the reduction exceeds the block's price, the runs pay for themselves. When the prior, the stakes and the block's power together leave the decision on the same side at every posterior, the page reports that no run at this block size changes the answer.
This mode computes no run price, no failure cost and no error-rate threshold. Price a run in the budget planner; price a wrong ship in the failure cost page; find the error rate a system is allowed to have in the acceptable error rate calculator.
Could my 40-item eval even see a 3-point drop?
It depends on the discordance. Discordance is the share of items where the two versions give different verdicts, and only those items can move the pass rate. On the returns-desk example (40 items, 22.5% discordance), the smallest detectable change is about 20 points, which is far larger than 3 points. Detecting a 5-point change at the same discordance and power takes 705 items, and a 3-point change takes far more. The chart shows how the detectable change falls as the item count grows.
Do repeats help as much as more items?
Repeats divide down the run-to-run part of the discordance and leave the version-to-version part untouched, so each extra repeat buys less. On the returns-desk example (40 items, 22.5% discordance, 11.5% rerun disagreement), Equation 9 gives a detectable change of 21.0 points at one run per side, 18.1 at two, 17.1 at three and 16.2 at five. Whether the next budget goes to repeats or to new items depends on what each costs, and the repeated-run variance planner weighs that.
How does a judge's accuracy change what the eval can detect?
A judge that misclassifies some items shrinks the apparent change. If the true change is 5 points and the judge's Youden J is 0.7, the scored data shows only about 3.5 points. The eval then needs at least about twice as many items to see the same true change, because the required count scales by at least about 1 / J squared. Load the scorecard from the judge bias correction calculator's scorecard mode, or type J into the Judge Youden J field, to see the corrected figure. When J is very low, the corrected count grows quickly and the page warns that the judge is weak.
Sources
- NIST/SEMATECH e-Handbook of Statistical Methods, 7.2.4.2 Sample sizes required
- Casagrande, Pike & Smith (1978), An improved approximate formula for calculating sample sizes for comparing two binomial distributions, Biometrics 34(3):483-486
- Connor (1987), Sample size for testing differences in proportions for the paired-sample design, Biometrics 43(1):207-211
- Wichura (1988), Algorithm AS 241: The Percentage Points of the Normal Distribution, Applied Statistics 37(3):477-484
- Miller (2024), Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations