Reliability Is Engineered, Not Hoped For (3 of 11)

Picture two analysts. One is a genius four days out of five and confidently, plausibly wrong on the fifth — wrong in a way you can’t spot until it’s already in the report. The other is merely solid, every single day, with no surprises. Which one do you want owning a step in a process that runs ten thousand times a week?

If you said the genius, you’ve never had to clean up after one.

This is the uncomfortable thing about putting language models into real workflows. The question everyone asks first — can it produce a good answer? — turns out to be almost the wrong question. The one that decides whether you can sleep at night is: how often does it fail, under what conditions, and can we catch it when it does? That’s what every success rate on the heatmap is really measuring. Not brilliance. Dependability under load.

We named the whole machine in The Harness Behind “Good Enough”: a harness is the complete, task-specific infrastructure that surrounds a language model to make it reliably do a defined piece of work. There we promised that a failed call becomes a different attempt, automatically. This post is the deep version of that one sentence — the reliability layer of the harness, the part that catches bad responses, reroutes around broken providers, and refuses to count a model’s failures against it unfairly. Reliability isn’t a property you find in a model. It’s something the harness builds around the model — and then measures.

See it live: every success rate folded into the costs on the heatmap is what this post is about — reliability you can measure, not hope for.

Two identical averages, two very different models

Start with a number that lies to you: the average.

Two models can post the same average quality score on the exact work you run and behave nothing alike in practice. One clusters tightly around its average — boring, predictable, every result within a narrow band. The other swings: dazzling highs, occasional face-plants, same arithmetic mean. On paper they’re twins. In production, the first is a colleague and the second is a liability.

Averages hide volatility, and volatility is the thing that breaks automated processes. A process can’t use occasional genius. It can only use a result it can trust to be there, in roughly the same shape, every time it asks. So the bench doesn’t reward the model that hits the highest peak. It rewards the one that clears the quality bar reliably, on your category of work, at the lowest price. A model that’s spectacular on average but erratic on the work package in front of you is exactly the trap.

Which means the interesting engineering isn’t in coaxing one perfect answer out of a model. It’s in what the harness does on the bad days. The model is an interchangeable part; the reliability lives in the machine around it.

When the output is the wrong shape

The most common bad day isn’t a wrong answer. It’s a malformed one.

A huge fraction of real LLM work asks the model to return structured output — a specific set of fields, in a specific shape, that the next step in the pipeline can actually consume. And models, even excellent ones, occasionally hand back something that’s almost right: a truncated object, a missing field, a stray sentence wrapped around otherwise-valid data, the right content in the wrong envelope.

The naive thing to do is fail. Throw the response away, surface an error, let it crash downstream. That’s how you turn a 2% malformation rate into a 2% outage rate.

Instead, the harness routes a bad response into a recovery cascade. First it tries to coerce or repair what came back into the required shape — much of the time the content is fine and only the packaging is off, and that’s salvageable without bothering the model again. If repair can’t rescue it, the harness retries. And if it still won’t come back clean, it stops trusting that model for this particular job, excludes it, and hands the work to a different one.

So a single bad response has three possible fates: a quietly repaired result, a successful second attempt, or a clean handoff to another model. What it almost never becomes is a crash three steps downstream. That escalation — failure here triggers a different attempt over there — is the same mechanism we walk through in Picking the model at runtime. A failure doesn’t end the work. The harness reroutes it.

Not every failure is the model’s fault

Here’s the nuance that separates a real measurement from a naive one.

If you count every failure against a model, you will systematically slander the good ones. Because a lot of what looks like failure has nothing to do with the model’s ability.

An account hits a billing problem. A request gets rate-limited because you sent too many at once. A content filter refuses a perfectly reasonable prompt. The provider’s infrastructure times out. A request is malformed because of our configuration mistake, not the model’s reasoning. None of these are the model being bad at its job — and a model that happens to sit behind a flaky account or a twitchy gateway shouldn’t score worse than an identical model that got lucky with its plumbing.

So the harness classifies failures. It sorts them into categories — account and quota problems, rate limits, content-filter refusals, infrastructure and timeouts, parse errors, our own config bugs — and separates those from genuine model errors. The non-model categories are excluded from the model’s quality and success-rate stats. They don’t penalize it, because they aren’t about it.

There’s a cost wrinkle here too. Some failure categories come with a useful fact: the provider didn’t bill us for that one. The harness marks those so they don’t pollute the cost side of the ledger either — you shouldn’t pay, in your accounting, for a call that never charged you. (How that flows into the price you actually compare is the subject of What a token really costs.)

The result is a success rate that means what it says: how often this model, doing this task, actually delivered — with the noise of everything that isn’t the model stripped out. That the number is honest is exactly what makes the bench a trustworthy readout of the harness rather than a vanity metric.

A clean “no” is not a failure

There’s a second kind of result people mistake for failure, and getting it wrong is expensive in the opposite direction: retrying forever.

Sometimes the model is asked to do something that simply cannot be done. Read a page behind a link that’s dead. Extract a figure from a document that’s paywalled. Summarize a source that doesn’t exist anymore. The correct outcome here is for the model to determine that the work can’t be completed and say so. That’s not a malfunction. That’s a finished, accurate, definitive negative — and it’s exactly what you wanted.

Treating that like a transient error and retrying it is one of the quieter ways to burn money and time. You’d be re-running a call that has no chance of a different result, again and again, against a link that’s still dead.

So the harness draws a hard line between “the model failed and re-running it could plausibly succeed” and “the model correctly concluded there’s nothing to retrieve.” Retries are reserved for the first kind — genuine, recoverable failure. The second is recorded as a clean result and the work moves on. The discipline is knowing the difference, because retrying a definitive negative isn’t resilience. It’s a loop.

When a whole provider goes down

Repair and reroute handle the per-call bad day. But occasionally the problem isn’t one call — it’s an entire provider falling over. An account gets suspended. A systemic, hard failure starts hitting everything you send to that vendor.

Retrying individual calls into a provider that’s structurally broken is worse than useless; it’s a way to fail slowly and loudly while spending money on each attempt. So the harness trips a kill-switch: the broken provider is disabled, and traffic immediately reroutes to others that are still healthy. No human has to be awake for the rerouting to happen.

The deliberate part is what comes after. Re-activation is a manual, human decision — there is no silent auto-reset. That’s a safety property, not an oversight. A provider that’s flapping — failing, recovering, failing again — must not be allowed to quietly slide back into rotation on its own and start poisoning live work between flaps. Someone looks, confirms it’s actually fixed, and turns it back on. The harness will route around a dead provider all day; it will not let a half-dead one sneak back in unsupervised.

Where all of this lands on the bench

Every one of these mechanisms — the recovery cascade, the error classification, the definitive-negative line, the kill-switch — is a moving part of the same harness, and they converge on one number: a success rate, computed per capability and per model. Not a global “is this model reliable” score, but a specific one: how often this model delivers a usable result on this kind of work.

And that number does real work. A model that needs frequent retries to get to a good answer is genuinely more expensive per useful result — you paid for the misfires on the way to the win. So the success rate is used to penalize the model’s cost. Two models can quote the same headline price per million tokens; the one that fails more often costs more to actually rely on, and the harness prices that in. The exact arithmetic — how a wobbly success rate inflates the effective price you compare — is what we mean by blended cost.

This is why “can it produce a good answer?” was the wrong question to lead with. Of course it can, sometimes. The questions that decide whether you can run it are how often, under what conditions does it fail, and do we catch the failures when it does. Reliability isn’t found. The harness engineers it around the model — repair, classify, reroute, refuse to retry the impossible, kill a dead provider — and then measures it, honestly, with the noise removed. Swap the model underneath and the machine keeps its shape; only a row of configuration changes.

Next we turn the lens on a thornier subject: once you’ve caught the failures, how do you score the successes? Judging quality at scale is its own layer of the harness, and it’s where we head in Measuring quality.

If you’ve ever shipped a model that was magnificent in the demo and unpredictable in production, you already know which number matters. Subscribe — the next few posts are about earning the right to trust a score.