Claude Opus 5 Cost-Aware Agent Orchestration on AWS

Claude Opus 5 arrived on Amazon Bedrock on July 24 with a tempting message: Anthropic's most advanced Opus model, matching Claude Fable 5's top-tier intelligence in many domains at Opus-tier economics. AWS also made zero data retention the default on Bedrock.

A cheaper frontier model does not remove the routing problem. It makes routing easier to justify and harder to audit. An autonomous agent can spend more simply because it now attempts longer tasks, invokes more subagents, or retries work that previously went to a cheaper tier.

The control plane needs to record why a model was selected, what fallback occurred, how much the completed task cost, and whether the data-retention policy changed with the route.

Start with task classes, not model rankings

Do not ask a model to choose another model from a vague instruction such as "use the cheapest capable option." Define task classes with measurable acceptance checks.

Routine extraction, formatting, and classification can use a fast low-cost tier. Repository-scale implementation, long document analysis, and multi-hour agent work may justify Opus 5. High-risk work should be pinned to a reviewed policy rather than dynamically escalated based on a model's self-reported confidence.

Each class needs a maximum cost, latency target, required capabilities, allowed providers, retention requirement, and fallback order. Keep the policy in version control. The agent may supply task features; it should not rewrite its own budget.

The routing record is part of the trace

Create a routing span before the model call. Capture the policy version, task class, candidate model IDs, selected model ID, selection reason, estimated input tokens, budget remaining, and retention mode. The model call becomes a child span with actual usage and response status.

gen_ai.route.policy.version = 2026-07-25.1
gen_ai.route.task.class = repository_implementation
gen_ai.route.candidates = [opus-5, sonnet-5]
gen_ai.route.selected = opus-5
gen_ai.route.reason = capability_gate
gen_ai.route.budget_remaining_usd = 8.40
gen_ai.route.data_retention = zero

Candidate arrays and cost fields may require namespaced attributes while OTel GenAI conventions evolve. Keep them in one helper and test the emitted contract. Never attach prompts, API keys, or user documents to the routing span.

Fallbacks must remain visible

AWS says Opus 5 can fall back to Opus 4.8 in higher-risk cyber scenarios and that API users can configure fallbacks. A successful response can therefore come from a model different from the one requested.

Record requested and resolved model IDs separately. Alert when fallback rate changes, even if request success stays flat. A model fallback can change capability, latency, price, safety behavior, or regional data path. Hiding it inside a generic 200 response makes cost and quality reports unreliable.

The same rule applies to your own router. If Opus 5 exceeds its latency budget and the request moves to another model, preserve both attempts under one trace. Attribute the wasted tokens and latency to the task. Provider dashboards often report attempts; finance needs cost per successful task.

Bedrock ZDR is a routing constraint

Zero data retention by default on Bedrock is a policy property, not a marketing footnote. A route that moves from Bedrock to another endpoint may change retention behavior. Put retention requirements into the task policy and exclude candidates that cannot satisfy them.

Record only the policy result in telemetry. Do not log sensitive content to prove that it was not retained by the model provider. Your own traces, gateways, and debug logs can violate the intended policy even when the provider honors ZDR.

Test the full path: application, router, gateway, model endpoint, observability exporter, and error store. A ZDR model call followed by a trace containing the complete prompt is not a zero-retention system.

A simple orchestration policy

The exact LiteLLM model identifiers and pricing should be verified against the installed release and provider price page before deployment. The durable part is the policy shape:

model_list:
  - model_name: opus-5
    litellm_params:
      model: bedrock/global.anthropic.claude-opus-5
  - model_name: sonnet-tier
    litellm_params:
      model: bedrock/anthropic.claude-sonnet

router_settings:
  enable_pre_call_checks: true
  allowed_fails: 1
  cooldown_time: 60

model_group_alias:
  deep-agent-work: opus-5
  routine-agent-work: sonnet-tier

Keep credentials in the runtime's secret store, not in the YAML. Add a pre-call hook that rejects a route when the estimated task cost exceeds its remaining budget or the endpoint does not meet the retention policy.

Do not launch with four dynamic tiers at once. Start with two: a routine tier and Opus 5 for a narrow set of complex tasks. More candidates create more policy branches, more fallbacks, and a larger evaluation matrix.

Measure cost per accepted task

Per-token price alone does not tell you whether Opus 5 is cheaper. Measure total cost through acceptance: initial call, tool calls, subagents, retries, fallback attempts, evaluator calls, and human rework.

A more capable model can be cheaper if it avoids retries. A cheaper model can be more expensive if it loops, calls tools repeatedly, or produces work that fails evaluation. Compare task cohorts with the same acceptance tests.

Use the LLM API Cost Calculator to model token mixes before rollout, then replace estimates with observed usage. Report median and p95 cost per accepted task. The tail matters because autonomous agents can produce rare, expensive runs that an average hides.

Rollout with a shadow decision

Run the new policy in shadow mode first. The existing model serves the request while the router records which model it would have selected and why. This validates task classification, budgets, and policy exclusions without sending duplicate model calls.

Next, route a small percentage of low-risk tasks and compare acceptance rate, latency, cost per accepted task, fallback rate, and human rework. Do not claim quality parity from a handful of examples. Use the same evaluation set and require statistical confidence appropriate to the decision.

Only then expand Opus 5 to long-running work. Add a per-task hard budget and a tool-call ceiling. Stop the task with a typed budget result rather than letting the agent silently downgrade and continue under a different quality profile.

Failure modes to alert on

Alert when resolved model differs from requested model above the expected baseline. Alert when retry cost exceeds a fixed share of task cost. Alert when the selected route violates its latency or retention policy. Alert when cost per accepted task rises even though per-token price falls.

Also watch classification drift. If the share of tasks labeled "complex" climbs after Opus 5 launches, the router may be turning the premium path into the default. Require a reason code and review the distribution by team and workflow.

What I would ship first

I would pin one routine tier and Opus 5 behind a versioned policy. I would instrument the routing decision and resolved model before changing traffic. I would make ZDR a candidate filter. I would cap task cost and tool calls, then evaluate cost per accepted task rather than tokens alone.

The existing multi-LLM routing guide covers composite routing and provider health. Coding-agent cost observability provides the cross-tool attribution model, and LiteLLM production monitoring covers gateway telemetry and fallback behavior.

Opus 5's launch makes premium capability more accessible. The platform advantage comes from routing it deliberately and retaining enough evidence to explain every expensive decision.

Source: Introducing Claude Opus 5 on AWS, AWS Machine Learning Blog, July 24, 2026.