Claude’s lower costs make the human review bill harder to ignore

The Signal · Economics analysis · September 29, 2026

If a model call gets cheaper while the review process stays slow, the expensive part of your AI workflow moves. It may move directly onto the person who has to check the output.

Anthropic’s September releases make this worth measuring again. Opus 5.5, announced September 22, lists standard input and output at $4 and $20 per million tokens and cache reads at $0.20. Anthropic reports lower typical task costs than Opus 5. Sonnet 5.5, announced September 28, keeps Sonnet 5’s $2 input and $10 output pricing but is reported to require fewer tokens for many tasks.

Those are different mechanisms: a lower unit price and less consumption at the same unit price. Neither guarantees a lower cost for your accepted work.

The denominator should be usable output

Suppose a hypothetical operations team processes 100 requests. Its model and tool charges total $20, but only 80 results are accepted without another run. Review and correction take two hours, valued internally at $40 per hour.

The total is $100, or $1.25 per accepted result. These are invented inputs to illustrate the calculation, not vendor prices, market wage claims, or Xovion results.

Now imagine another configuration incurs $35 in model and tool charges, produces 95 accepted results, and needs one hour of review at the same internal rate. Its total is $75, or about $0.79 per accepted result. The higher model bill produces the lower workflow cost under those assumptions.

This arithmetic does not justify buying the most expensive model. It shows why measuring only the API line item can lead you toward the wrong configuration.

Count the work the first attempt created

Separate at least four things in the experiment: model usage, external tools, human review, and correction. Keep failed attempts in the total. A run that ends with no usable deliverable still consumed resources.

Be careful with the word “accepted.” If a person approves an inaccurate result because it looks polished, your acceptance measure is weak. Use an observable rule appropriate to the task: extracted fields match their sources, the intended record changed, or the document answers the specified question without unsupported additions.

For low-risk drafts, quick sampling might be enough. For consequential records, the verification step needs to be stronger. The cost of review should reflect that requirement instead of disappearing from the comparison.

Reasoning effort is a purchasing choice

Anthropic’s Sonnet announcement shows performance and cost varying with effort settings, and notes that the best setting depends on the work. A model name by itself is therefore an incomplete configuration.

Start with the smallest effort level that meets your acceptance rule, then compare a more demanding setting on the cases that fail. Do not assume a longer run is a better run. It might be useful investigation, or it might be extra work that your task never required.

Similarly, cache savings depend on what your requests actually reuse. A workflow with changing documents and little repeated context should not inherit the economics of a benchmark dominated by reusable input. Check the billable categories in your own usage records.

Keep waiting time in view

Time matters even when it does not appear as a direct charge. A customer waiting on a call, an employee blocked on a decision, and a nightly background job have different tolerance for latency.

Do not combine all three into one average. A slightly more expensive fast configuration may be sensible for an interactive task. A slower, cheaper configuration may be appropriate for a batch process with a clear deadline. If retries make either one miss its deadline, the apparent savings are misleading.

A practical purchasing test

Choose one recurring workflow. Hold the input set, tools, and acceptance rule steady. Compare your current configuration with one candidate, then inspect the rejected cases. Record the review burden alongside the model bill.

If the new setup wins only on easy requests, route those requests to it and leave difficult cases with the established process. If the workload is too small to repay migration and maintenance, keep what works.

The takeaway from these releases is an opportunity to remeasure, not a promised percentage saving. Treat vendor cost claims as hypotheses. Your useful result is the one the next person can trust and use at a total cost the business can justify.

Related: GPT‑6.1 Sol and the model-switch test.

Primary sources: Opus 5.5 and Sonnet 5.5, checked September 29. All worked-example figures are hypothetical; no Xovion savings are claimed.