Stats, Classic ML and Human Review Around LLMs: The Upgrade That Beats a Bigger Model

Before I worked on LLMs, I built classic machine learning: a next-best-action data pipeline and a claims fraud-detection model at an insurer, workforce forecasting at a large outsourcing firm, TF-IDF skill scoring for a labour-market dashboard. When generative AI arrived, it became tempting to set that toolbox aside, as if a model that can write a sonnet made logistic regression obsolete. Anyone who has shipped LLM systems will recognise what usually comes next. The system is too expensive, wrong too often, or impossible to defend to a risk committee, and the proposed fix is a bigger model.

The bigger model sometimes helps. Usually it is the most expensive way to buy a small improvement, and it leaves the underlying problems where they were: the system can’t say which answers to trust, can’t prove its error rate, and can’t learn from the people who correct it.

My thesis is that the cheapest, most reliable gains in an LLM system come from the statistics, classic machine learning and human review wrapped around the model, not from a bigger model. Routers and cascades cut cost. Small fine-tuned classifiers beat zero-shot prompting on narrow labels. Calibration and conformal prediction turn vague confidence into numbers a risk team can sign. Well-placed human reviewers catch the errors that matter and generate the training data that makes everything else improve. And honest evaluation statistics tell you whether any of it worked.

The article runs as follows. I start with why this matters now and what the research shows, including where it is thin. Then I set out a reference architecture, the “LLM sandwich”, and take each layer in depth: routing economics with a worked cost example, small classifiers and LLM-assisted labelling, calibration, conformal prediction for engineers, human-in-the-loop design, and the statistics of evaluation itself. I close with public and personal case examples, the strongest objections, implications by stakeholder, a 90-day plan and the limits of the evidence.

Context: why this matters now

Three forces make the surrounding toolbox more valuable in 2026 than it was in 2023.

Price dispersion is extreme. FrugalGPT’s authors noted in 2023 that fees across LLM APIs “can differ by two orders of magnitude”. That is still true within a single vendor’s lineup. On Anthropic’s published list prices, Claude Opus 5.5 costs $4 per million input tokens and $20 per million output tokens. Claude Haiku 5.5 starts at $0.10 and $0.50, a fortieth of the price. Anthropic itself describes the small model as built “for high-volume, latency-sensitive tasks such as classification, extraction, and routing.” When the vendors price routing as a separate job, sending every request to the flagship is a choice to overpay.

Trust has become the bottleneck, and review practice is uneven. McKinsey’s March 2025 State of AI survey (1,491 respondents) found that 27% of organisations using generative AI review all of its outputs before use, while a similar share check 20% or less. Reviewing everything doesn’t scale. Reviewing almost nothing is a bet. What’s missing in between is a principled way to decide which outputs a human should see. That is a statistics problem.

Risk owners want numbers, not adjectives. “The model is usually right” doesn’t get through a model-risk review. A sentence like this one does: “On a held-out set of 2,000 cases, the automated path’s error rate is 1.8% ± 0.6 points, and the system defers the 12% of cases where it can’t meet a 95% coverage guarantee to a human.” Producing that sentence takes calibration, conformal methods and evaluation statistics, none of which a bigger model provides.

The evidence: what the research actually shows

Routing and cascades cut cost dramatically

FrugalGPT (Chen, Zaharia and Zou, 2023) proposed three strategies for cutting LLM costs: prompt adaptation, LLM approximation, and the LLM cascade. A cascade sends a query to a cheap model first and escalates to a more expensive one only when a learned scorer judges the cheap answer unreliable. On their benchmarks, FrugalGPT could match the best individual model, GPT-4, “with up to 98% cost reduction”, or improve accuracy by 4% at the same cost.

RouteLLM (Ong et al., 2024) takes the other route: a router decides before generation which model to call. Its routers were trained on human preference data from Chatbot Arena, augmented with golden labels and an LLM judge. The authors compared four router designs: similarity-weighted ranking, matrix factorisation, a BERT classifier and a causal LLM classifier.

Exhibit 1

MT-Benchopen-ended chat>85%

MMLUknowledge, multiple choice45%

GSM8Kgrade-school maths35%

Strong model GPT-4 Turbo, weak model Mixtral 8x7B. MT-Bench figure reported as “over 85%”. FrugalGPT (2023) reported cascades matching GPT-4 with up to 98% cost reduction on its own benchmarks.

Source: Ong et al., RouteLLM (arXiv 2406.18665); LMSYS blog (1 Jul 2024)

View data table

Benchmark	Cost reduction
MT-Bench	>85%
MMLU	45%
GSM8K	35%

The variation across benchmarks is the important detail. On MT-Bench, the best augmented router sent only 14% of calls to GPT-4. On MMLU it still needed 54%. Routing saves the most where traffic is mostly easy and the cheap model is genuinely good at the easy part. It saves the least where most queries really do need the strong model. Your traffic mix, not the paper’s, determines your savings.

Small, fine-tuned models still win narrow classification

Bucher and Martini (2024) compared fine-tuned BERT-style models with zero-shot GPT-3.5, GPT-4 and Claude Opus on sentiment, approval, emotion and party-position tasks across news, tweets and speeches. Their conclusion was that “fine-tuning with application-specific training data achieves superior performance in all cases.” Edwards and Camacho-Collados (LREC-COLING 2024) evaluated 16 classification datasets covering binary, multiclass and multilabel problems, and found that fine-tuning smaller models “can still outperform few-shot approaches of larger language models.”

The LLM still has a central role, just a different one: it is an excellent labeller. Wang et al. (2021) found that labels from GPT-3 cost 50% to 96% less than human labels for the same downstream performance, and that mixing GPT-3 and human labels did better when budgets were tight. Gilardi et al. (PNAS, 2023) found zero-shot ChatGPT beat crowd workers on four of five annotation tasks over 2,382 tweets, at under $0.003 per annotation, “about twenty times cheaper than MTurk”.

Exhibit 2

ChatGPT vs. crowd workers~20× cheaper per annotation~95%

GPT-3 vs. human labelsreported range 50–96%50–96%

Gilardi et al. report ChatGPT annotations at about 1/20th of MTurk cost (shown as ~95%). Wang et al. report GPT-3 labels cost 50–96% less than human labels depending on task; the bar shows the lower bound.

Source: Gilardi et al., PNAS (2023); Wang et al. (2021)

View data table

Comparison	Reported saving
ChatGPT vs. MTurk crowd workers	~20× cheaper (~95%)
GPT-3 vs. human labels	50–96%

Models’ stated confidence is a weak signal

Here the evidence is more nuanced than “LLMs don’t know what they know”. Kadavath et al. (2022) found larger pre-trained models “well-calibrated on diverse multiple choice and true/false questions” when the prompt was formatted appropriately. Models could also be trained to predict whether they knew an answer. But the GPT-4 technical report showed that the pre-trained model was well calibrated on a subset of MMLU while “the post-training hurts calibration significantly.” Post-training is exactly what turns a base model into the chat model you actually call. And when models verbalise confidence, Xiong et al. (ICLR 2024) found they “tend to be overconfident.”

Exhibit 3

White-box methodstoken probabilities0.605

Black-box methodse.g. “I am 90% sure”0.522

Random guessing0.500

The abstract reports the white-box vs. black-box gap as “narrow, e.g., 0.522 to 0.605 in AUROC”. Black-box methods include verbalised confidence, sampling and consistency; white-box methods use token probabilities.

Source: Xiong et al., ICLR 2024 (arXiv 2306.13063)

View data table

Method family	AUROC
White-box (token probabilities)	0.605
Black-box (verbalised, sampling, consistency)	0.522
Random guessing	0.500

LLM judges agree with humans about as often as humans agree with each other, with biases

Zheng et al. (2023) found that strong LLM judges such as GPT-4 achieve “over 80% agreement” with human preferences, about the level at which humans agree with each other. They also documented “position, verbosity, and self-enhancement biases”. Automated judges are a useful instrument. They are not a neutral one, and they need calibrating against people.

What the evidence does not show

Most of these studies use public benchmarks, not enterprise traffic. The classifier comparisons predate the 2025–2026 model generation. The routing savings depend on traffic mix. And few papers report end-to-end business outcomes. The evidence supports the direction of my argument strongly. It doesn’t tell you the size of the gain on your system. Only your own measurement can, which is the point of the last deep dive.

A framework: the LLM sandwich

I think of a production LLM system as a sandwich. The model is the filling. The statistics and classic ML on both sides are what make it safe to pick up.

Exhibit 4

1. 01RouteA cheap classifier or gate decides: skip, small model, big model, or straight to a human.
2. 02GenerateThe LLM does the open-ended work, only where it is needed.
3. 03ScoreCalibrated scores, judge agreement or conformal sets, never self-reported confidence.
4. 04ReviewLow-confidence and high-stakes cases go to a sized human queue; a random sample of the rest is audited.
5. 05LearnCorrections update router labels, classifier training sets, calibration maps, judge weights and eval sets.

Author’s framework.

Each layer answers one question. Routing: does this request need the expensive model at all? Scoring: how likely is this output to be right, in a number that means what it says? Review: who looks at what, and how many people does that take? Learning: how does every human decision make the next automated one better? A sixth question, evaluation, sits across all of them: how do we know any of this worked?

Deep dive 1: Routing and cascades, mechanics and economics

Mechanics. There are two patterns. A router classifies the request up front and sends it to one model. It adds almost no latency, but it must predict difficulty from the request alone. A cascade calls the cheap model first, scores its answer, and escalates when the score is below a threshold. It sees the actual answer, so its decisions are better informed, but escalated requests pay for two calls and wait for both. Routers can be classic classifiers (logistic regression on embeddings works surprisingly well), small fine-tuned models, or a cheap LLM asked a yes/no question.

Economics. The cost of either pattern is dominated by one number: the share of traffic that reaches the expensive model. The worked example below uses published list prices and simple assumptions.

Exhibit 5

$18,000

$9,450

$5,850

$5,715

$450

All OpusCascade 50%Cascade 30%Router 30%All Haiku

Illustrative arithmetic from published list prices — not measured data. Per request: Opus $0.018, Haiku $0.00045. Router: 30% sent to Opus, 70% to Haiku, router cost ignored. Cascade: Haiku answers everything, then the stated share is re-run on Opus. Excludes reasoning tokens, prompt caching and batch discounts, which change absolute figures but not the pattern.

Source: Prices: Anthropic models overview (Opus 5.5 $4/$20, Haiku 5.5 from $0.10/$0.50 per million input/output tokens)

View data table

Strategy	Monthly cost	vs. all-Opus
All requests to Opus 5.5	$18,000	—
Router, 30% to Opus	$5,715	−68%
Cascade, 30% escalated	$5,850	−68%
Cascade, 50% escalated	$9,450	−48%
All requests to Haiku 5.5	$450	−98%

Three conclusions follow from the arithmetic. First, because the small model costs a fortieth of the large one, the cascade’s “wasted” first call barely registers: $450 a month against thousands. Second, the saving is close to the share of traffic you keep away from the big model, so moving escalation from 50% to 30% matters far more than which pattern you use. Third, the all-Haiku column is a reminder that the cheapest option is always available. The real question is how much quality you lose on the hard tail, and only an evaluation on your traffic can answer it.

Failure modes. The danger is the hard query routed down. A cascade’s scorer can be confidently wrong, and a router can misjudge difficulty on unfamiliar inputs. Routers also drift as traffic changes, so a router trained on launch traffic degrades with everything else. Latency is the other trap: a cascade that escalates half its traffic makes half your users wait for two models.

How to measure. Track three numbers weekly: the escalation (or routed-up) share, quality on a labelled sample of routed-down traffic, and cost per request. Plot quality against cost for several thresholds, as RouteLLM does, and choose the operating point deliberately. Don’t let the threshold be whatever someone typed on day one.

Deep dive 2: Small classifiers, and the LLM as labeller

Mechanism. For a narrow, stable label set (intent, sentiment, policy category, document type, routing class), a fine-tuned small model learns the decision boundary from your own examples. A zero-shot LLM approximates it from a description. With enough labelled data, the model that has seen the boundary wins. It is also typically far cheaper and faster per call, runs on modest hardware, and produces a probability you can calibrate.

The pipeline I recommend. Use the LLM to bootstrap labels, people to check them, and a small model to serve:

1. Write a precise labelling guide, the same one you would give a human annotator.
2. Have the LLM label a few thousand examples, with a short rationale per label.
3. Have humans review a stratified sample, oversampling classes the LLM is unsure about and disagreements between two LLM runs.
4. Train the small model on the corrected labels, and evaluate it on a human-labelled held-out set, never on LLM labels alone.
5. Run active learning. Send the examples the small model is least certain about back to human review, and retrain. Ein-Dor et al. (EMNLP 2020) found active learning “can boost BERT performance, especially in the most realistic scenario”: small annotation budgets and skewed classes.

Exhibit 6

LLM + human reviewOpen-ended, little data: prompt, evaluate, review

LLM, distilled over timeOpen-ended, lots of data: fine-tune or distil to cut cost

LLM labels → small modelNarrow, little data: bootstrap labels with an LLM, check, then train

Classic MLNarrow, lots of data: gradient boosting or a fine-tuned small model

Labelled data available →Task open-endedness →

Author’s framework.

Failure modes. LLM labels carry the LLM’s systematic errors, and a model trained on them inherits those errors at scale. Unless a human-labelled test set exists, nobody will notice. Small classifiers are also brittle when the label set changes: a new product category means relabelling and retraining. The LLM handles that with a prompt edit.

How to measure. Use macro-averaged F1 on a human-labelled test set, plus a confusion matrix, compared with the zero-shot LLM on the same set. If the small model doesn’t win on your data, keep the LLM. The point is to measure, not to be loyal to either tool.

Deep dive 3: Calibration, or making scores mean what they say

What calibration is. A score is calibrated if, among all the cases scored 0.8, about 80% are actually correct. Accuracy and calibration are different properties. A model can be accurate and badly calibrated (right most of the time, but scoring its wrong answers just as high as its right ones), and then you can’t use its scores to decide what to automate.

How to see it. A reliability diagram, which scikit-learn calls a calibration curve, bins predictions by score and plots the average score in each bin against the observed accuracy. Perfect calibration is the diagonal. Overconfident systems sag below it.

Exhibit 7

Perfect calibrationRaw scoresAfter recalibration

Illustrative — not measured data. Shows the typical shape of an overconfident system (below the diagonal) and the same scores after a monotonic recalibration fitted on held-out data.

Why verbalised confidence fails. When you ask a chat model for a number, you get text that looks like a probability. It was produced by the same process that produces every other token, shaped by post-training towards sounding helpful and sure. The GPT-4 report’s finding that post-training “hurts calibration significantly”, and Xiong et al.’s finding that verbalised confidence is overconfident, both point the same way. Treat a stated confidence as one weak feature, never as a threshold.

What to calibrate instead. Use behavioural signals you can compute:

• Token log-probabilities, where the API exposes them.
• Agreement across several samples or several judges.
• Retrieval scores, such as the top reranker score or the share of the answer supported by retrieved passages.
• A small classifier’s probability.
• A model’s P(True) when asked to verify an answer it has already given, which Kadavath et al. found more informative when the model compares several of its own samples.

Then fit a calibration map on held-out labelled data:

• Temperature scaling divides a model’s logits by a single learned parameter. Guo et al. (2017) found this “single-parameter variant of Platt Scaling” surprisingly effective for modern neural networks. Because it doesn’t change which class is top, it doesn’t change accuracy.
• Platt (sigmoid) scaling fits a logistic curve to the scores. It works well with small calibration sets.
• Isotonic regression fits any monotonic curve. It is more flexible but overfits easily. scikit-learn’s guidance is that it does as well as or better than sigmoid only “when there is enough data (greater than ~ 1000 samples).”

The non-negotiable rule, also from the scikit-learn guide, is to fit the calibrator on data disjoint from the data used to train the model. Otherwise the scores will be pushed towards 0 and 1, which is overconfidence by construction.

Failure mode. Calibration is fitted to a distribution. When traffic drifts, the map drifts with it. Recheck the reliability diagram on fresh labels every month, or whenever your drift monitors fire.

Deep dive 4: Conformal prediction, explained for engineers

Calibration gives you scores that mean what they say on average. Conformal prediction gives you something risk teams value more: a guarantee. Angelopoulos and Bates describe the guarantees as “explicit, non-asymptotic” and valid “even without distributional assumptions or model assumptions”, and the method wraps “any pre-trained model, such as a neural network.”

The recipe (split conformal, classification). Assume you want a 90% coverage guarantee, so α = 0.10.

1. Hold out a calibration set of n labelled examples the model hasn’t trained on. A few hundred to a thousand is typical.
2. For each one, compute a nonconformity score: how badly the model fits the true answer. The simplest is 1 minus the model’s probability for the true label.
3. Sort the scores and take the ⌈(n + 1)(1 − α)⌉-th smallest as your threshold, q̂. With n = 999 and α = 0.10, that is the 900th smallest score.
4. At prediction time, include in the prediction set every label whose nonconformity score is at most q̂.
5. The guarantee: the prediction set contains the true label at least 90% of the time, averaged over future cases, provided that future cases are exchangeable with the calibration set (roughly, drawn from the same distribution).

Why engineers should care: the set size is your routing signal. If the set has one label, the model is confident in a way that carries a guarantee, so automate. If it has two or three, send it to a human with the shortlist pre-filled. If it is empty or contains everything, something is off-distribution, so escalate. This turns “review the uncertain ones” into a rule you can defend in a sentence.

Extending it to LLMs. Three papers show how:

• Multiple choice. Kumar et al. (2023) applied conformal prediction to multiple-choice question answering and found its uncertainty estimates “tightly correlated with prediction accuracy”. They also probed what happens when questions come from subjects outside the calibration data, which is exactly where exchangeability breaks.
• Free-form generation. Quach et al. (ICLR 2024) sample candidate answers until a calibrated stopping rule says the set is sufficient, with a rejection rule to prune bad candidates. The returned set contains at least one acceptable answer with high probability.
• Factuality. Mohri and Hashimoto (2024) apply the idea to factual claims: the system backs off to less specific statements until a guarantee holds. They report “80-90% correctness guarantees” while keeping “the majority of the LM’s original output”.

Failure modes. The guarantee is marginal: 90% averaged over all cases, not 90% for every subgroup. It can be 99% on easy cases and 70% on a minority segment. The guarantee also depends on exchangeability, which drift breaks. So conformal prediction needs a drift monitor next to it and periodic recalibration, and per-segment checks where fairness matters.

Deep dive 5: Human-in-the-loop design

Human review is the most expensive component in the sandwich and the one most often designed by accident. Four design decisions matter: where to place humans, how many to hire, what they see, and where their corrections go.

Where to place humans. Two dimensions decide it: how uncertain the system is (from calibrated scores or conformal set size) and how costly an error would be.

Exhibit 8

Human approvesConfident but high-stakes: human signs off, or reviews a large sample in regulated settings

Human decidesUncertain and high-stakes: the model drafts and shortlists; a person makes the call

Automate + auditConfident and low-stakes: automate, and review a random sample to measure the error rate

Automate + learnUncertain, low-stakes: fall back gracefully or ask the user; queue for active learning

Model uncertainty →Cost of an error →

Author’s framework.

The bottom-left quadrant is the one teams forget. If you only review what the model is unsure about, you never see its confident mistakes, and you can’t estimate the error rate of the automated path. A small random audit fixes that. At 18,800 automated decisions a day, a 2% audit is 376 reviews. That is enough to estimate a 2% error rate to within about ±1.4 points each day (95% interval, normal approximation), and much tighter over a week.

Queue sizing is arithmetic, not hope. Suppose 20,000 items arrive a day and the threshold sends 6% to review: 1,200 items. At four minutes each, that is 80 hours of review a day, or about 13 reviewers at six productive hours each. Lower the threshold so 12% go to review and you need about 27. Little’s law (average queue length equals arrival rate times average wait) gives the backlog: at 150 items an hour and a target two-hour wait, expect about 300 items in the queue at any moment. Do this arithmetic before choosing a threshold. The threshold is a staffing decision as much as a statistical one.

What reviewers see. Show the model’s answer, its evidence (retrieved passages, the conformal shortlist) and the reason it was flagged. Make agreeing with the model no easier than disagreeing, for example by requiring a reason code either way. Track per-reviewer agreement with the model over time. A reviewer who agrees 100% of the time is either reviewing very easy cases or not really reviewing.

Where corrections go. Every human decision is a label. Send it, with versioning, to:

• The router’s training set.
• The small classifier’s active-learning pool.
• The calibration set.
• The evaluation set.
• The weights of any automated judges.

That last destination is where a little statistics goes a long way.

Failure modes. Review queues fail in predictable ways. Thresholds get set without staffing arithmetic, so the backlog grows until someone lowers the bar. Reviewers rubber-stamp under time pressure. Corrections go into a spreadsheet nobody trains on. Each of these is a design flaw, not a reason to abandon human review.

Deep dive 6: The statistics of evaluation

Every claim in this article, such as “the router kept quality” or “the classifier beat zero-shot”, rests on an evaluation score. Most evaluation scores in industry are reported without error bars, which means nobody knows whether a difference is real.

Evan Miller’s Adding Error Bars to Evals (2024) argues that “evaluations are experiments” and should be analysed as such. His recommendations are practical:

• Report a standard error with every score, and a 95% interval of about ±1.96 standard errors.
• Use clustered standard errors when questions share a passage or source. He shows they “can be over 3X larger than naive standard errors”. On one benchmark the clustered figure was 1.34 against 0.44 naive.
• Compare models with paired differences on the same questions, which shrinks the error because scores are correlated.
• Resample answers to reduce within-question noise. Two samples per question cut that variance by a third, and four cut it by half in his example.
• Run a power analysis before building an eval. In his worked example, detecting a 3-point difference with 80% power at the 5% significance level takes roughly 969 questions, and he recommends at least 1,000 for new evaluations.

Exhibit 9

±11.1

±7.8

±5.5

±3.5

±2.5

±1.8

501002005001,0002,000

Arithmetic illustration using the normal approximation 1.96 × √(p(1 − p)/n) with p = 0.8 and independent questions. Clustered questions widen these intervals; paired comparisons between models narrow the interval on the difference.

Source: Method: Miller, Adding Error Bars to Evals (2024)

View data table

Questions	95% CI half-width (points)
50	±11.1
100	±7.8
200	±5.5
500	±3.5
1,000	±2.5
2,000	±1.8

The implication is uncomfortable. Many teams pick prompts, models and routing thresholds on evaluation sets of 50 to 100 examples, where a 5-point “win” is well inside the noise. Either grow the set, use paired comparisons, or report the decision as a judgement call, not a measurement.

Failure mode. Evaluating on data the system was tuned on. Keep a sealed test set that nobody optimises against, and refresh it from production traffic each quarter so it tracks drift.

Case examples

UK government’s Consult tool (public). In October 2025 the UK government reported using its AI tool Consult to analyse more than 50,000 responses to the Independent Water Commission’s call for evidence. The analysis took about two hours, cost £240, and was followed by 22 hours of expert checking. The structure is the sandwich in miniature: the model does the volume, people check, and statistics establish whether the result can be trusted. The government measured agreement against two independent groups of human experts.

Exhibit 10

Consult vs. experts (1)0.79

Consult vs. experts (2)0.82

Human vs. human0.74

Government-reported figures; the two Consult scores are its agreement with two separate expert groups. The release also reports Consult agreed with expert groups almost 83% of the time vs. 55% between the two human groups. The “75,000 days / £20m a year” savings figure in the same release is a projection.

Source: GOV.UK, 16 Oct 2025

View data table

Comparison	F1
Consult vs. expert group (1)	0.79
Consult vs. expert group (2)	0.82
Human expert group vs. human expert group	0.74

The lesson is not that the AI beat the humans. It is that measuring human–human agreement gave the result meaning. Without that baseline, a 0.79 F1 is an uninterpretable number. With it, the team could say the tool was within the range of expert disagreement, which is the claim a decision-maker needs.

Claims fraud detection at an insurer (my work). At AIA Digital+ I built fraud detection for claims, with a projected 25% reduction in claims processing time. Later, at the DOH–DAP Hack4Health 2024 hackathon, I took first place with a fraud-detection platform for unified health data.

Skill-gap scoring with TF-IDF (my work). For a labour-market skill-gap dashboard, raw frequency counts of skills in job postings put generic skills like “communication” at the top of every list and buried the technical skills that drive curriculum decisions. Weighting each skill by term frequency times inverse document frequency (TF-IDF), a technique decades older than transformers, surfaced the distinctive skills instead.

Counterpoints

Implications by stakeholder

Exhibit 11

	Executives	Engineering leads	Practitioners	Risk & compliance
Stop	Approving model upgrades as the default fix	Choosing thresholds by intuition	Treating “I’m 90% sure” as a probability	Accepting accuracy without error bars
Start	Asking for the cost–quality curve, not one number	Budgeting review queues with arithmetic	Calibrating scores on held-out, disjoint data	Asking for coverage guarantees and audit samples
Fund	Labelling and reviewer capacity as a product line	A routing layer and a sealed eval set	Time to build classifiers where volume justifies it	Independent checks of human–human agreement baselines
Measure	Cost per resolved case; automated error rate	Escalation share; queue wait; drift in calibration	F1 with intervals; reliability diagrams	Per-segment coverage; reviewer override rates

Author’s framework.

Executives should change the question they ask when an AI system disappoints. Instead of “should we upgrade the model?”, ask: what share of traffic actually needs the big model, what is the error rate of the automated path, and how do we know? Those answers usually point to cheaper fixes.

Engineering leads should treat the router, the calibration map, the review queue and the eval set as first-class components, with owners, versions and tests, not glue code around the model.

Practitioners gain the most career leverage. Engineers who can say “here is the reliability diagram and here is the conformal coverage by segment” are rare, and the techniques are learnable in weeks.

Risk and compliance teams should ask for guarantees with stated assumptions, not reassurances. “90% coverage, marginal, assuming exchangeability, rechecked monthly against drift” is a statement they can audit.

What to do next: a 90-day plan

Exhibit 12

1. DAYS 1–30Measure honestlyBuild a sealed, human-labelled eval set of at least several hundred cases (aim for 1,000). Report every score with a 95% interval and compare variants with paired differences. Log behavioural signals per request: token log-probs where available, judge scores, retrieval scores, sample agreement.
2. DAYS 31–60Route and calibrateLabel traffic by difficulty and train a simple router or cascade threshold; plot quality against cost and pick the operating point deliberately. Fit a calibration map (temperature, Platt or isotonic) on disjoint data and publish a reliability diagram. Where labels are narrow and volume is high, bootstrap a small classifier with LLM labels and human checks.
3. DAYS 61–90Guarantee and learnAdd split-conformal prediction sets and use set size to route to automation, shortlist review or escalation. Size the review queue with arithmetic and add a random audit sample of automated cases. Pipe every human correction into the router, classifier, calibration and eval sets, and reweight judges from human agreement.

Author’s framework.

A simple test tells you it is working. By day 90 you should be able to state, with an interval, the error rate of the automated path, the share of traffic reaching the expensive model, and the coverage guarantee on the review decision. You should also be able to say what each number was 30 days earlier.

Limitations and methodology

These conclusions rest on evidence with real limits.

• Benchmarks, not enterprise traffic. Routing savings (RouteLLM, FrugalGPT) come from public benchmarks with specific model pairs. Your traffic mix and model pair will produce different numbers, possibly much smaller ones.
• Model generations. The classifier comparisons (Bucher and Martini; Edwards and Camacho-Collados) predate the 2025–2026 model generation. The gap may be narrower now, and I haven’t found a comparable study on the newest models.
• Calibration findings depend on the model. The GPT-4 report’s calibration result concerns one model and an MMLU subset. Xiong et al.’s AUROC figures are an example from their abstract, not a universal constant.
• Conformal guarantees are conditional on assumptions. Coverage is marginal and assumes exchangeability. Drift and subgroup differences can break both.
• Illustrative exhibits. The cost exhibit is arithmetic on list prices with stated assumptions, and excludes reasoning tokens, caching and batch discounts. The reliability diagram is illustrative. The confidence-interval exhibit assumes independent questions.
• Government figures. The Consult figures are government-reported, and its savings figure is a projection.
• Field notes. My field notes describe systems I built. Their figures come from my own project records and haven’t been independently audited.

Closing

The LLM is the most impressive component in any system it sits in, and usually the least controllable. Everything around it can be measured, tested, versioned and improved: the router, the classifier, the calibration map, the conformal threshold, the review queue and the evaluation set. And all of it costs less than an upgrade to the next model tier.

That is the argument in one line. Before you buy a bigger model, build the instruments that tell you what the current one is doing. Usually they will show you a cheaper fix. When they don’t, they will at least show you that the upgrade worked.