Amazon replaces Sonnet 4.6 with the Strands Decider and saves millions

Amazon has a post about switching from Claude Sonnet 4.6 to a smaller model with routing via a component they call the Strands Decider. They claim to have saved millions. The post has gotten a lot of attention on Hacker News. It's an interesting post, not because of the headline number, but because it's a window into what large organisations are doing in 2026 to reduce inference cost. It's not "use the cheaper model everywhere". It's "route everything to the cheapest model that can handle it, and make sure that the cheaper model can handle it".

This post is about what the Strands Decider approach seems to be, what it tells us about the discipline of model routing, and where the low-hanging fruit ends and the hard work begins.

What Amazon reported

The source material is a post on the Strands Agents blog: "Amazon saves millions by replacing Sonnet 4.6 with Strands Decider". It's about a migration where they switched workloads that were previously running on Claude Sonnet 4.6 to a smaller, cheaper model. The Strands Decider is used to make the decision about which model to use for each request. They claim to have saved millions.

It's a vendor blog post, so take the numbers with a healthy amount of scepticism. Success stories are hand-picked for vendor case studies. The numbers for cost aren't audited. The mechanism is interesting. Not the size. The mechanism is the bit that other organisations can actually copy.

The Strands Decider pattern

The basic approach is model routing. Instead of routing all requests to the most capable model you have, you route all requests to the least capable model that can correctly handle them. And you have a decision layer to make that decision for each request.

The Strands Decider, as presented, is a layer in front of a set of models. It makes decisions about which model to use for each request. Simple, well-understood tasks get routed to a small, cheap model. More capable tasks get escalated. The result is the routing decision. Not the models. The models are interchangeable commodities.

It's not a new idea. It's the same kind of pattern that's been in web infrastructure for decades. Cache the cheap stuff. Escalate the hard stuff. The difference now is the scale where it's worthwhile to do it. When inference was a niche cost, routing was a premature optimisation. Now that inference is a line item in the millions, routing is the highest-leverage cost lever. It's often better than swapping models or quantising or caching, by itself.

Why this beats just using a cheaper model

The naive way to reduce cost is to globally switch from the expensive model to the cheap model. It works... until it doesn't. The cheap model does a good job for 80% of requests. It fails silently for the other 20%. And then you see it in user complaints or retries or downstream errors that cost more than the savings.

With model routing you have the capable model for the cases where you need it. And you only use the cheap model where you've verified that it works. You save because of the volume you're switching to the cheap tier. Not because you're removing the capable tier. It's a less dramatic number. But it's a more resilient number. Because it doesn't involve trading correctness for cost.

Another benefit is that model routing is reversible and incremental. You can switch 10% of your traffic. Measure. Switch 30%. Measure again. A global model swap is a big-bang switch. It's harder to reverse. With model routing you have a dial, not a switch.

The hard part: knowing which model can handle which request

The hard bit of this, and the bit the blog post doesn't really dive into, is the routing decision itself. How do you know which model can handle a request? You need to know something about the request before you answer it. And you need to know something about the capabilities of each model under your particular workload.

There are a few approaches. And they all have costs.

• Rules/heuristics. Route by type of request. Length of request. Intent you detect. Cheap to implement. Easy to reason about. But brittle. The rules change as your workload changes. You have edge cases. Most production routing starts here. Most production routing stays here longer than it should.

• Classifier. Train a small model to predict which tier the request should be in. More robust than rules. But it's an additional model to manage. Additional failure mode. You have to keep the training pipeline in sync with your workload. The classifier is now a cost and liability.

• Cascading with verification. First route to the cheap model. Then check the output with a cheap validator. If it fails, escalate. More robust. But adds latency. The validator is a model/heuristic of its own. And it may be wrong. And you have double the work on the escalated path.

• Empirical measurement. Run the models on a sample of traffic. Compare the outputs. Route based on equivalence. The most honest but slowest to set up. You need a ground truth/judge. And you need to keep doing it as models and workloads change.

You often end up with a combination of the above. The Strands Decider as presented seems to combine routing logic with measurement. That's the right instinct. The details of how you make the decision are the interesting bit. And that's the bit that's not going to be fully revealed in a vendor blog post.

What the savings actually depend on

There are three things that go into the headline number. And organisations considering this approach should look at how they apply to their own situation.

• Volume distribution. You only save money with routing if you can handle a large fraction of your traffic on the cheap tier. If 90% of your requests actually need the capable model, then you're only saving 10% at best (minus routing layer costs). Your savings are a function of how much of your workload is simple. That's workload specific.

• Cost gap. Your savings are also a function of how much cheaper the cheap tier is. If the gap is 2x, then routing is a nice optimisation. If the gap is 10x or more, then routing is the dominant cost lever. We're in a market where we have big gaps between frontier and mid-tier models. So it's worth doing now.

• Verification cost. Every wrong routing decision costs you either a failed request (if you under-escalated) or wasted work on the cheap tier then a call to the capable tier (if you over-escalated). You need the routing layer to be accurate enough that you don't lose savings to the verification/escalation costs. That's the number you should measure. Not the headline saving.

The uncomfortable part: measuring without a ground truth

The hardest thing about model routing is not model routing. It's knowing whether your routing decision was right. Without a ground truth to compare to.

In practice organisations use one of three proxies. They use user feedback. That's sparse and biased. Or they use a judge model. That's another model. With its own errors. And costs. Or they use task-specific validators. Schema checks. Test execution. Retrieval accuracy. That's only for structured outputs.

None of those are great. And all of them are better than no measurement. The organisations that get model routing right are the ones that treat measurement as a first-class engineering problem, not a post-thought. And are willing to accept that their routing policy is sometimes wrong. And needs updating.

Conclusion

The Amazon account of replacing Sonnet 4.6 with the Strands Decider is an interesting data point. But the takeaway isn't "use the Strands Decider". The takeaway is that model routing is the highest-leverage cost lever for organisations running inference at scale. And the hard work is in the routing decision and measurement. Not in swapping one model for another.

If you're considering this for your own stack, then first measure your workload. What fraction of your requests might plausibly be handled by a model an order of magnitude cheaper. And how would you know if you're wrong? That's the precondition for everything else. And it's the bit that most teams miss.

Sources

• Strands Agents blog, "Amazon saves millions by replacing Sonnet 4.6 with Strands Decider": https://strandsagents.com/blog/amazon-saves-millions-replacing-sonnet-with-strands-decider/
• Hacker News discussion: https://news.ycombinator.com/item?id=50436640
• Anthropic Claude model documentation: https://www.anthropic.com/claude

← back to posts