You are deciding whether Claude 5.5 should take over a recurring workflow. The visible number is the token price. The consequential number is what you spend before the work is good enough to use.

That distinction can reverse the apparent answer. A model with cheaper tokens can cost more when it needs repeated instructions, generates unnecessary output, or loses an important decision during revision. A model with a higher run cost can be the economical choice when it reaches an accepted result with less human repair.

Use cost per accepted outcome as the denominator

The 20% token-price reduction associated with Opus 5.5 is meaningful, but it answers only one part of the purchasing decision. It tells you how an underlying unit of model usage changed. It does not tell you what a finished product requirement, customer analysis, launch brief, prototype, or executive memo will cost.

For a recurring workflow, calculate:

• Model cost: the charges generated across the entire session, including retries and revisions.
• Direction cost: the human time required to assemble context, explain constraints, and frame the assignment.
• Review cost: the time a qualified person spends checking accuracy, completeness, and fitness for use.
• Repair cost: the human and model work required when a correction is misunderstood or causes another requirement to regress.
• Failure exposure: the expected consequence of an unacceptable result escaping review. This matters more for consequential decisions than for disposable drafts.

Your useful equation is: total task cost divided by accepted outcomes. Token cost belongs in the numerator. It should not become the denominator.

Define acceptance before running the test. For a product brief, acceptance might require a clear problem statement, named user, explicit scope boundaries, unresolved risks, and no invented evidence. For an analysis, it might require traceable inputs, consistent calculations, and a decision the reader can actually make. If acceptance remains subjective, an attractive first draft will quietly replace economic measurement.

Keep quality as a constraint rather than averaging it away. A cheaper result that fails a mandatory requirement is not a small saving. It is a rejected outcome.

Steerability is an economic variable

Model ergonomics is the effort required to direct a system, understand what it produced, correct it, and choose the next action. That effort sits inside the cost of every delegated task, even when it never appears on an AI invoice.

This becomes visible after the first answer. Many evaluations stop at first-pass quality, but production work rarely does. A stakeholder changes a constraint. New evidence arrives. The output needs to become an adjacent artifact. The economically valuable behavior is not merely producing an impressive draft; it is accepting a correction without discarding decisions that still stand.

Opus 5.5 proved easier to steer for writing and unusually capable at visual work in one practitioner’s testing. Treat that as a reason to test the relevant behavior, not as a portable benchmark. The gain will depend on your task, context, reviewer, and definition of acceptable work. Early impressions of Sonnet 5.5 were also preliminary, so do not transfer a result from one Claude variant to another without testing it separately.

Watch for four expensive forms of friction:

• Requirement repetition: you keep restating a constraint that was already explicit.
• Correction spillover: the requested fix lands, but an unrelated section or decision deteriorates.
• Invisible deviation: the output looks polished enough that a missing requirement takes effort to discover.
• Continuation loss: an adjacent task reopens decisions that the previous step had already settled.

These failure modes make a model expensive through interaction, not computation. They matter most in connected work: strategy that becomes a roadmap, discovery findings that become requirements, or a product decision that must remain consistent across several artifacts.

Run a three-prompt test on your real assignment

Do not benchmark Claude 5.5 with a trivia question or a pristine task invented for evaluation. Use a recurring assignment that already consumes meaningful time. Compare it with the model, workflow, or human process currently doing the job.

Use the same context, requirements, and acceptance criteria for every candidate. Then run this three-prompt sequence:

1. Produce the real deliverable. Supply the context your normal workflow permits, identify the audience and decision, and state the acceptance criteria. This measures initial comprehension and usable first-pass quality.
2. Make a material correction. Change a requirement that commonly changes in production. Name what must be revised and what must remain fixed. This tests whether the model can incorporate feedback without causing regressions.
3. Continue into connected work. Request the next artifact or decision using the revised state. Tell the model to flag conflicts rather than silently rewrite settled constraints. This tests retention and handoff quality.

A compact scorecard keeps visual polish from dominating the decision:

Signal	What to record	What it reveals
Acceptance	Accepted, rejected, or requiring material rewrite	Whether the run created a usable outcome
Model spend	Total session charges, including corrections and retries	The direct consumption cost
Human handling	Active time spent preparing, reviewing, explaining, and repairing	The operational cost hidden from the model invoice
Correction burden	Every additional turn needed to make the requested change hold	How expensive the model is to steer
Constraint retention	Which named decisions survived the correction and continuation	Whether connected delegation is reliable
Failure severity	The consequence if a missed issue reached the next user or system	How much review and control the workflow requires

Run the sequence on genuine examples across the task’s normal range. A single clean example can reveal behavior, but it cannot establish dependable economics. Reuse the same evaluation when the model, variant, system prompt, context pipeline, or tool access changes. Those changes can alter the result even when the visible assignment remains identical.

Record active human time rather than total wall-clock time. Waiting for a response and spending an expert’s attention are different costs. Also separate required review from repair: review may remain necessary regardless of model quality, while repair is the avoidable work a better workflow should reduce.

Route tasks instead of declaring one winning model

A company-wide question such as “Is Claude 5.5 cheaper?” is too broad to produce an operating decision. The useful decision is whether a specific Claude 5.5 variant is economical for a named task under a defined quality bar.

Route work according to what the scorecard exposes:

• Stable, constrained work: favor the lowest-cost option that consistently clears acceptance. Extra intelligence has little value when the task is already reliable and corrections are rare.
• Correction-heavy work: give steerability more weight. A model that preserves constraints through revision can justify a higher per-run cost by reducing expert repair.
• Connected assignments: evaluate the full chain, not each artifact in isolation. Saving on the first draft is irrelevant if the continuation loses the decisions that make the chain coherent.
• Consequential work: keep review and controls proportional to failure severity. Stronger output can reduce repair, but it does not automatically remove the need for accountable human approval.
• Poorly specified work: fix the workflow before blaming the model. If the task has no stable inputs or acceptance criteria, the test will measure ambiguity rather than model economics.

Separate three kinds of return when presenting the result. A cost effect means the same accepted task became cheaper. A throughput effect means the same people can complete more accepted work. A scope effect means the model makes a previously impractical assignment worth attempting. All can matter, but combining them into a single savings claim makes the business case impossible to audit.

My rule is simple: do not move a task because the model is cheaper to call. Move it when the complete workflow produces an accepted outcome with better economics, and keep the old route available until that result holds across representative work.

Key takeaways

• Measure total cost per accepted outcome, not price per token or quality of the first draft.
• Include human direction, review, repair, and failure exposure alongside model charges.
• Test production behavior with an initial assignment, a material correction, and a connected continuation.
• Track whether corrections hold without damaging decisions that should remain fixed.
• Evaluate Opus and Sonnet separately rather than treating Claude 5.5 as one economic unit.
• Route each task to the lowest-cost workflow that reliably clears its own acceptance bar.

Choose one recurring task with a visible correction loop and run the three-prompt test against its current baseline. That will tell you more about Claude 5.5’s value to your organization than a general model ranking or a cheaper token ever could.

References

• Nate’s Newsletter — Does your work cost less on Opus 5.5 now that its tokens are 20% cheaper? My 3-prompt guide shows which jobs do before you move them.

---