The release offers a claim to investigate, not a savings guarantee
Anthropic’s September 22 Opus 5.5 announcement presents the model as a new Claude 5.5 family release and says it performs at the level of Claude Fable 5.1 on most work while costing 40% less to run than Opus 5. The company describes performance and cost benefits and cites selected evaluations and tester examples. Those are vendor-reported claims; they are not a forecast for a different business’s tasks, inputs, tools, or review process.
For an owner, the important question is whether a task that matters can be completed with the same quality and less total effort. A lower per-token price can be offset by more retries, longer prompts, failed tool calls, or extra reviewer time. Conversely, a more capable model may reduce rework on a difficult job. The release is a reason to test, not to revise a budget on headline arithmetic.
Choose a task that has an observable finish line
Select one bounded task with a clear “accepted” condition: for example, produce a structured draft, reconcile a defined set of records, or create a first-pass internal report. Choose cases that resemble actual work, with sensitive information removed. Include routine cases and a few difficult ones such as missing context or conflicting instructions. Have the person who owns quality define the expected result before either model runs.
Record the prompt, context, model and effort settings, tools, output format, and human intervention. Preserve the same conditions for each candidate. Score correctness, critical mistakes, required edits, time, failures, and cost per accepted result. If the work includes tools, inspect the tool selection and arguments, not just the final response. A model that produces polished prose but chooses the wrong record is not the cheaper option.
Separate the vendor benchmark from your workflow evidence
Read the vendor’s test description closely. Note the tasks, scoring method, effort level, sample size, and exclusions. A benchmark may be well designed for its purpose and still say little about your workflow. A customer example can reveal a promising use case without proving a typical result. Keep those categories of evidence distinct in the decision record.
If the result is mixed, route by a stable difference only after testing that difference. A simple task type or validation failure may be a clearer routing signal than a second model’s subjective confidence. Start with one candidate on one path. Add a fallback or specialist model only when the team can explain what it handles and why that complexity pays for itself.
Run a reversible pilot and keep the old path
Begin in a test environment where outputs are reviewed and no model can commit a customer-facing action. Define the period or case set in advance and specify who may expand access. Keep the current configuration available, and make a rollback decision easy. Watch for quality changes and operational issues such as rate limits, prompt drift, context length, or an integration that rejects the output format.
Do not claim a percentage improvement from a handful of examples. Report exactly what was tested, how many cases were accepted, and where reviewers intervened. If the sample is too small to support a broad claim, say so. A modest local test is still enough to decide whether a larger, more formal evaluation is worth running.