Lower cost per task is not a cheaper token. Route work by task shape, not model tier.

AWS positions Claude Sonnet 5.5 for faster, lower-cost execution of well-scoped work. Production teams should route models by uncertainty and measure cost per accepted outcome.
AWS released Claude Sonnet 5.5 on Amazon Bedrock on 28 September and positions it for focused coding and knowledge work at lower cost per task than Opus 5.5 for most well-scoped jobs. The useful deployment lesson is not that one model is cheaper. It is that model routing should follow task shape, because judgment-heavy work and execution-heavy work have different cost and latency profiles.
AWS explicitly separates the two: Opus 5.5 for release debugging, multi-PR feature stacks, security review and long analyses; Sonnet 5.5 for tasks where the approach is already clear and speed matters. That is a routing policy, not a benchmark trophy.
Route by uncertainty, not by model prestige
Teams often default to the strongest model for every step because it simplifies architecture. That can be operationally expensive. If the task is deterministic enough to define success in advance, a faster model can execute while a stronger model is reserved for ambiguous decisions.
The control should live above the model call. Classify work by uncertainty, consequence and verification cost. A bug fix with a reproducible test, a SQL transformation with row-count checks or a document edit with explicit acceptance criteria can be routed differently from a security review or migration plan where the model must choose the approach.
Model selection should be a policy decision about task uncertainty, not a permanent preference for the biggest model.
Measure cost per accepted outcome
AWS describes Sonnet 5.5 as delivering lower cost per task for most work at faster speed. That wording matters. Token price alone does not tell teams whether a routing decision is efficient. A cheaper trajectory that fails more often or requires a second pass can cost more than a slower successful one.
Production dashboards should therefore combine model spend with completion rate, latency, retries and human escalation. Compare accepted tasks per dollar and per minute for each task class. Where verification is objective, automate it and use the result to decide whether the cheaper route is actually cheaper.
Keep governance consistent across routes
On Bedrock, AWS says Sonnet 5.5 runs with familiar controls including IAM, CloudTrail, CloudWatch and Bedrock Guardrails, with Global CRIS available for inference. Routing between models should not create separate security regimes. The same identity, logging, data-handling and approval policy should follow the task whichever model executes it.
The practical rollout is straightforward: define task classes, assign a default model to each class, set escalation conditions and log the route decision beside outcome and cost. Then review the policy from production evidence. The goal is not to minimise model spend in isolation. It is to spend frontier-model capacity where uncertainty justifies it and use faster models where success is already easy to verify.
Sources
- Introducing Claude Sonnet 5.5 on AWS · AWS Machine Learning Blog
Written by the Devence Lab research team.