Claude Opus 5.5 costs less; test whether it keeps the exception

An engineer asks for the next step. The runbook says restart, but a newer note says to wait for replication to catch up. A model can explain the restart beautifully and still give the engineer the wrong instruction.

This illustrative case makes a useful test for Claude Opus 5.5. Its lower token prices are attractive when the cheaper answer still preserves the condition that matters. Anthropic’s release announcement lists $4 per million input tokens, $20 per million output tokens and $0.20 per million cache-read tokens. Its reported 40% saving over Opus 5 comes from typical default-setting workloads, not a guaranteed discount on every team’s work.

The model is available as claude-opus-5-5 through the Claude Platform and through AWS, Google Cloud and Microsoft Azure. The cost comparison for a service team begins with its own task and chosen client.

Leave the conflicting note in the test

Give both configurations the same runbook and the newer replication exception. Ask for the next action. A useful answer identifies the conflict, keeps the hold in place and explains what evidence would permit proceeding.

Removing that awkward note would make the test easier while removing its purpose. The earlier model-evaluation guidance focuses on the operational exception that distinguishes useful reasoning from a plausible answer under the wrong conditions. Here, fluency about restarting is not enough.

Hold the evidence, permitted tools and acceptance criteria steady. Then compare task acceptance and total effort alongside token cost. If an engineer has to restore the missing hold and ask again, that work belongs in the comparison. A cheaper first answer is not the whole price of an acceptable result.

Check the client that carries the conversation

Picture the next turn in the replication conversation. The model has returned an answer, and the client is about to send the engineer’s follow-up with the earlier conversation. The response can include a reasoning block for the client to carry forward, not merely the answer text shown to the engineer. Integration has its own test here: Anthropic says Opus 5.5 cannot run with thinking disabled. Its preserved-thinking rules control reuse of reasoning blocks from previous turns: the block must come from a compatible model, and the system prompt, tools and preceding messages must stay unchanged.

The engineer might ask, “What evidence would show replication has caught up?” The client can append that message to the unchanged conversation while retaining the returned block. But suppose it also tidies an earlier instruction or replaces a tool definition before sending. It has now changed the context the old block belonged to. The preserved-context check can reject that block, or a configured drop path can continue without it. Keeping the block’s bytes while rewriting its earlier conversation is not preserving the same context.

Opus 5.5 always runs the prefix check. Account age changes the default response to a mismatch, not whether checking happens. With mismatch behavior unset, ordinary requests from accounts created on or after 00:00 UTC on August 31, 2026 receive a 400 error; on older accounts, failing blocks reach the model without that error. Message Batches handles the unset case differently, dropping failing blocks where an ordinary request would error. Explicit mismatch settings require the documented beta header and can select rejection or dropping. A successful response alone therefore does not prove the client preserved context. Test the actual client and mismatch handling before live use; the replication case separately checks whether its answer keeps the hold.

Compare the cost of the accepted result

Keep the earlier route available until both tests work, then bound a production trial to the task and permissions reviewed. This article reports no independent Opus benchmark or observed failure in the fictional case.

Save the decision beside its model configuration, client result and total cost. You should be able to see whether the new route used fewer resources while retaining the reason to wait. That is a saving the engineer can actually use when the answer arrives.