When I first saw “switching models saved millions,” my reaction was: has the compute race started again?
My side project hits the same issue: client inquiries, research, and email drafts all go to the same AI model. It felt convenient at first, but the bill gradually climbed while I was spending on contracts, support, and automation in parallel. Choosing an expensive tool does not mean every task deserves the most expensive model.
What Amazon did was not force one model out and another in. It added a “scheduling layer” to AI: assess task difficulty first, then decide which type of model should handle it. Cheaper models take simple, repetitive, rule-based work; costlier models handle complex judgment. This approach is called Strands Decider.
It’s not a new model; it’s more like a project assistant that assigns work
I’ve made this mistake too: whenever a model update landed, I wanted to migrate every workflow immediately. Prices did not fall, and results got worse. I eventually realized that clearly separating tasks matters more than chasing the latest model.
The article says Amazon used Strands Decider in real business scenarios to choose among different models and reportedly saved millions of dollars. There is no universal button everyone can copy. The key is splitting my own work into “simple judgment” and “complex judgment.”
For example, if a client wants an order status that comes from a fixed sheet and clear rules, a cheaper model can handle it. If a client is comparing three options and wants an explanation of the trade-offs, that is worth handing to a more capable model. The point is not to have AI choose the strongest model forever, but to let it choose based on the task.
Replicating it today: the budget and first step are clear
Money: Start with existing model credits rather than buying more software. If I wanted to try an open-source framework, a personal project can often start at $0. Enterprise deployments need separate estimates for services, labor, and usage. “The model is cheaper” does not mean “the whole system is cheaper.”
Time: Spend one to two days cataloging 20 recent, real tasks. Label each one by “Are the rules clear?”, “Does this need long-form reasoning?”, and “How costly is an error?” Then decide how to route them. The technical barrier is manageable: I do not need to write complex code, but I should be able to read an API, recognize model names, and understand usage logs. If I cannot yet, I can simulate the system with a spreadsheet and manual rules.
First step: Open the usage or billing page in the AI tool I already use and identify the five most expensive task categories. I would not rush to replace models. Instead, I would start with one category, such as email rewriting or research summaries. The open-source version of Strands Decider has examples on GitHub; I would first get one small workflow running that “assesses task difficulty and routes the task to a model.”
If I were in one of these three stages, this is how I would start
Just getting started
If I do not have stable clients yet, I would not immediately build a routing system. I would use one capable model with transparent pricing and get one paid or acquisition workflow working. Once usage stabilizes, I would consider routing. There is no urgency to try it now; first, I need to find out whether anyone will pay.
Serving one or two clients
If I am already handling client inquiries, contract drafts, or content production, I would first build a “task tiering sheet.” Fixed-format work goes to a cheaper model; work requiring judgment or explanation gets an upgrade. I would track costs and rework for two weeks to see whether the savings exceed the time spent maintaining the system.
Scaling up
If I am leading a three-to-five-person team, or automated workflows are making frequent calls, I would put model selection, budget caps, and logs together so a looping task cannot burn through the budget. I would treat Strands Decider as a reference rather than hand the entire business over without testing. I would keep one manual approval step, then expand the scope gradually.
What I am learning is that saving money on AI projects often comes down to avoiding running every task at the highest price, rather than finding the lowest price. I can spend a week taking inventory, then decide whether it is worth building.