Does the human review gate eat the savings?

Does human review defeat the point of the automation?

Human review defeats the point of the automation only when the gate costs more than the work it replaces, and whether it does is a number you can compute before a line of code is written. The objection is fair on its face: if a person has to read every document to confirm the machine read it right, the machine added a step instead of removing one. But a working gate does not route every item to a person. It routes the exceptions, and the real question is whether the time saved on the items that pass exceeds the time spent on the items that stop. That balance has a name, the break-even exception rate, and it comes from three numbers the business already has.

When a pilot stalls on cost, the break-even was usually never cleared and never computed. The vendor priced the software; the buyer absorbed the review. The software was a line item in the contract; the review landed on an operations team that was already busy, and the savings that justified the project quietly went to pay for checking its output.

What is the break-even exception rate, and how is it calculated?

The break-even exception rate is the exception rate at which a review gate stops earning, and it is the ratio of two measured times. Call M the minutes the manual process takes per item, and R the reviewer minutes spent per exception. A passed item costs no human time; a routed item costs R. Automation removes M per item and adds R only on the fraction that route, so it comes out ahead while the exception rate stays below M / R, and the break-even is e_be = M / R. Below it the workflow earns. Above it, the gate spends more human time than the manual process it was meant to remove.

The ratio carries the whole argument. When reviewing an exception costs less than doing the item by hand, R sits below M, the break-even lands above one, and the gate pays at any exception rate; even routing every item is cheaper than the manual process. When reviewing an exception costs more than doing the item by hand, the break-even drops below one and only measurement tells you which side of it your workflow is on. Reviewing costs more than it looks, more often than teams expect. A reviewer has to reconstruct what the machine did before deciding whether to trust it, and that is work the person doing the task from scratch never had to do.

Which three numbers do you need, and where do they come from?

Three measured quantities set the break-even, and the word that matters in each is measured. M, the manual minutes per item, comes from timing the people who do the work now, not from a process document that describes how the work is supposed to go. R, the reviewer minutes per exception, is timed on the review surface that will actually exist. A reviewer squinting at a raw document and a reviewer approving a pre-filled screen with the source beside it are doing different jobs at different speeds. The exception rate is sampled on real items rather than guessed, and the method for sampling it is the subject of which documents should skip human review. Guess any of the three and the break-even is a decoration; measure them and it is a decision.

What does the verification tax do to the answer?

The verification tax is the review time spent on items that pass, and leaving it out is the most common way a break-even gets computed too optimistically. A gate that routes only exceptions still usually spot-checks a fraction of the approvals. A queue nobody audits drifts without anyone noticing. Call v the fraction of passed items that get spot-checked and s the minutes each spot-check takes. The per-item human labor under automation is no longer just the exception cost; it is e×R + (1 - e)×v×s, and the break-even becomes e_be = (M - v×s) / (R - v×s). The tax lowers the break-even wherever it binds, below one. Time spent confirming the machine was right is still time, and it is charged against the same savings the exceptions are already eating. A reviewer who spot-checks even a fraction of the approvals is paid for those too, and a model that forgets them reports a break-even the workflow will never actually hit.

What does the model look like as a template you fill in?

The model is a template with four inputs and one output, and it is published blank, for a reader to substitute their own workflow into rather than to borrow a number that describes someone else's. Below is the operating break-even for an accounts payable invoice, with each row naming what to measure and where the number comes from; substitute your own values and read the break-even off the formula underneath.

Two quantities are deliberately absent from this break-even: total volume and the machine cost of a call. The operating break-even is a ratio of human times, so volume moves both sides together and cancels, and machine cost is paid on every item whether it routes to a person or not, so it never shifts the exception rate at which the gate's own labor stops earning. Both belong in the payback calculation below, which decides how fast the build repays its cost, not whether the running workflow earns.

What does a per-item cost line actually contain in 2026?

The per-item cost line is the machine cost of processing one item, and in 2026 it moves twice with nobody touching the code. Claude Sonnet 5 shipped on 30 June 2026⁰² as a documented drop-in upgrade for Claude Sonnet 4.6, and its new tokenizer produces approximately 30% more tokens for the same text.⁰¹ The figure carries its own qualifier: the exact increase depends on the content, and the launch post puts it at roughly 1.0 to 1.35 times by content type.⁰² That is the first move, the token count per item, and it arrived on an upgrade the documentation calls drop-in, because drop-in is a statement about the request schema and not about the bill.

The second move is the price per token. Per-token pricing is 3 and 15 US dollars per million input and output tokens, unchanged from Sonnet 4.6,⁰¹ but introductory pricing of 2 and 10 US dollars per million is in effect through 31 August 2026, with the standard 3 and 15 taking effect on 1 September 2026.⁰² Run the arithmetic a reader will run: today the same text costs about 1.30 times 2 US dollars, which is 2.60 against Sonnet 4.6 at 3.00, so the identical input is currently cheaper. On 1 September 2026 the same arithmetic runs against 3.00 and the direction of the error reverses. A cost line built on tokens carries that reversal silently; a cost line built on the workflow does not.

What does a refused request cost, and why does no error dashboard count it?

A refused request costs a full billed call and returns nothing, and no error dashboard counts it because it does not arrive as an error. Anthropic's documentation states that requests touching prohibited or high-risk cybersecurity topics may be refused, and that refusals return as a successful HTTP 200 response with stop_reason refusal rather than as an error.⁰¹ So a refusal is a paid non-answer that leaves the error rate green while the workflow quietly stops answering. The dashboard is watching for a status code the refusal never raises. The same page notes a quieter cost in the same family: max_tokens is a hard limit on thinking plus response text, so turning on adaptive thinking spends the budget the answer used to have unless the ceiling is raised to match.⁰¹ Neither line is large per call, and neither shows up in a cost model that counts only successful answers and failed requests.

What is missing from this model, and who carries the token risk?

The model so far prices the running workflow and omits the build, which is the fourth input and the one number this page cannot state. The operating break-even tells a controller whether a live workflow pays; the build payback is a separate calculation, payback = build cost / (per-item saving × volume per period), and it is the one that decides whether the project is worth starting. The per-item saving is M - (e×R + (1 - e)×v×s + machine cost per item), so the build pays back faster at higher volume and slower at a higher exception rate, and the two calculations must not be collapsed into one.

The build is quoted as a fixed price against the workflow rather than against tokens, which is what moves the token risk off the client's forecast. When the price is fixed against the workflow, a tokenizer that adds 30% and a pricing step-up on 1 September are the builder's problem, not a line in the client's business case that quietly went wrong. Payment is staged and the final tranche is tied to the agreed bar. What that bar is, and who signs it, is the subject of is 95% accuracy good enough. The bar decides what counts as an exception in the first place, and the exception rate is one of the three numbers this whole model runs on.

What exception rate should you plan for before anything is measured?

No exception rate is worth planning against before it is measured. A borrowed rate describes someone else's documents, and the break-even is sensitive to exactly the number you would be guessing. The rate depends on the document type, the state of the data, and where the accuracy bar is set, and none of those transfer from another firm's workflow to yours. The substitute for a borrowed number is a measurement you can run in an afternoon: sample a couple of hundred items you already processed, apply your routing rules, and count how many would have gone to a person. That count, on your own backlog, beats any industry figure and cannot be faked, and the routing post above gives the sampling method.

When is automating not worth it?

Automating is not worth it whenever reviewing an exception costs about as much as doing the item by hand. Then the break-even sits near zero, and no realistic exception rate clears it. Three shapes fail the test. A task that is already fast to do manually leaves no room for a gate, since R climbs toward M and the ratio collapses. A workflow where almost nothing can be checked against a second source routes nearly everything, so the exception rate approaches one and the gate becomes the data-entry team it was meant to replace. And a workflow whose errors are rare but catastrophic is not a break-even question at all; there the gate stays wide regardless of what the arithmetic says. Naming these cases costs pipeline, and it buys the only thing a cost model cannot fake, which is a reader who can trust the cases where the answer is yes.

What do you measure first, before talking to anyone?

Measure the three numbers first, on one real workflow, before talking to anyone. Time the manual item, time a review on the screen that will exist, and sample the exception rate on a backlog you already have; the template above turns those three into a break-even you can defend in a budget meeting. If the workflow was a pilot that stalled, the mechanisms it skipped are set out in why your AI pilot did not reach production. Once the three inputs are measured rather than guessed, the Ship engagement is one workflow taken to production on your stack, and the workflow review at /assessment is thirty minutes that produces the three numbers this model needs. That is the one next step this post asks for.

Frequently asked questions

Does human review defeat the point of the automation?

Only when the gate costs more than the work it replaces. If a workflow routes just its exceptions and reviewing an exception is cheaper than doing the item by hand, the gate earns; if reviewing costs as much as doing the work, it does not. Which case you are in is a number, not an opinion.

What three numbers set the break-even?

The manual minutes per item, the reviewer minutes per exception, and the measured exception rate. Each is measured on a real workflow rather than estimated: the manual time from the people who do the work now, the review time on the screen that will actually exist, and the exception rate sampled from items you already processed.

Why did your token cost change when nobody touched the code?

Per-item cost has two moving parts, and both move in 2026. Claude Sonnet 5's new tokenizer produces approximately 30% more tokens for the same text, and introductory pricing steps up to standard pricing on 1 September 2026. Price the workflow at a fixed amount and neither change reaches the client's forecast; price it on tokens and both land there unannounced.

When is automating not worth it?

When reviewing an exception costs about as much as doing the item by hand, so the break-even exception rate sits near zero and no realistic rate clears it. Tasks that are already fast to do by hand, and workflows where almost nothing can be checked against a second source, both fail this test.