What happened
In a November 9, 2026 Strands Agents blog post, Amazon engineers Carr Onstott and Mehul Jaiswal describe changing the model behind an internal ticketing system. Sonnet 4.6 had classified tickets across the company into 20 categories, including customer escalations, capacity requests, automated alarms, and security findings. The earlier setup sent a long system prompt with each ticket and asked the model to reason against fixed labels and generate JSON.
The replacement is Strands Decider E4B, which the post describes as a decision model rather than a text generator. It receives a state and a question with a set of options, then returns a probability for each option and a confidence score. For this use, the ticket is the state and the catalog of labels supplies the options. The engineers started with Strands Decider 2B, found the E4B Gemma 4 build performed better on a test set, and then tuned the confidence threshold for applying a label. They report that E4B beat the production Sonnet system on a separate set of tickets; the post does not give the size or detailed composition of that set.
Amazon ran E4B on SageMaker ml.g5.xlarge instances, each with one 24 GB A10G GPU. The model used about 19 GiB, and one request took about 640 ms on one instance. The endpoint autoscaled with traffic; its network was isolated from outbound access, and SageMaker copied model weights from S3 at startup. The surrounding path used an SQS queue for ticket events, a Lambda function to read ticket data and call the SageMaker endpoint, AppConfig for the model switch, and CloudWatch for logs, metrics, and alarms. Amazon says the stack was defined in CDK with Beta, Gamma, and Prod deployment stages.
A three-way AppConfig setting controlled rollout. BEDROCK used Sonnet for every ticket; DUAL called both models in parallel, applied Sonnet’s result, and compared it with Decider’s; DECIDER used Decider alone. Amazon reports average call time falling from 4,215 ms to 897 ms and total tokens per ticket falling from 6,724 to 2,010. Input tokens fell from 6,554 to 2,009, while output tokens fell from 170 to one. The team rewrote the 20 label descriptions as short criteria because the production descriptions alone exceeded Decider’s 4,096-token window. Long tickets also lose their oldest comments to fit. Lambda execution duration reportedly fell 74% after Sonnet was turned off.
At published us-east-1 on-demand prices, Amazon puts Sonnet at $0.0222 per ticket and Decider at about $0.0005, or roughly $22,200 versus $500 per million tickets. The Decider estimate assumes real-world headroom for bursts; at full utilization, Amazon estimates about $250 per million. These figures exclude Lambda, which the engineers say also runs for less time per ticket. The post says the change is about 44 times cheaper, a 98% reduction, and could save millions of dollars in annual token costs.
What the archive adds
New Runtime covered Strands Decider 2B on October 11, 2026, describing decision models as a fast path for bounded choices while questioning whether their narrow outputs can carry operational responsibility. Amazon’s case is a new fact on that story: it reports a production use, a measured comparison, and a staged path for judging disagreements before switching over.
Trend signal
This case supports agent economics moving to completed work: the useful comparison is the cost of assigning a ticket label, not the price of a token in isolation. It also qualifies the pattern: the reported savings depend on a fixed 20-label catalog, a shorter prompt, and instance utilization, so the result is not a general claim that smaller decision models are cheaper for every agent task.
Why now
The engineers say the change followed the launch of Strands Decider about a month earlier. The post frames the intervention around a high-volume workflow where the incumbent model was already handling a narrow choice from a fixed catalog, making the cost and latency of each call consequential.
Why it matters
For teams building agents, this is a reminder to separate open-ended reasoning from bounded choices. If a workflow repeatedly asks a model to select one option from a stable catalog, a decision-oriented interface may avoid generating explanations or structured text that the application does not need. But the economics are workload-specific: Amazon’s estimate rests on ticket volume, a GPU endpoint, utilization assumptions, shortened label criteria, and the handling of long-ticket context.
The rollout method is as reusable as the model choice. Running both systems in parallel let the team compare outputs on live tickets while continuing to apply Sonnet’s labels; a configuration switch provided a quick route back. That makes the migration a measured operational change rather than a one-shot bet. The reported sensitivity to JSON key order is another practical warning: input serialization can affect model decisions, so teams should stabilize request formatting before comparing runs or interpreting disagreement rates.
What happens next
- More production classification workflows will test decision models against general-purpose LLMs. (6 months, 65%). Watch for: published case studies reporting both agreement or quality measures and cost per million classified items.
- Teams adopting decision models will standardize inputs and retain a fallback path. (6 months, 60%). Watch for: rollout designs that log disagreements between a decision model and an incumbent system before changing production ownership.
Limits and uncertainty
The post is an Amazon engineering account, not an independently audited evaluation. It does not publish the test-set size, a detailed accuracy or error-rate comparison, confidence-threshold values, or the ticket distribution. The reported cost comparison uses published list prices and depends on traffic utilization; Amazon’s practical estimate includes headroom, while its full-utilization figure is lower. The post also says long tickets drop their oldest comments, but does not quantify how often that occurs or its effect on classification quality. The key-order sensitivity is described as observed, without a reported test methodology beyond a probability shift of up to 0.19.
Skill to build now
Take one recurring classification task with a fixed label catalog and measure its current cost per completed item, latency, and error rate. If the task does not need explanatory prose, test a bounded-choice interface against the existing model on a separate dataset; then run both in parallel on a sample of live traffic, log disagreements, and keep an explicit configuration rollback. Stabilize the order of structured input keys before comparing outputs.
Reader takeaway
A decision model is not a universal substitute for an LLM. Amazon’s result is a case for matching model shape to task shape: a stable, high-volume choice among 20 labels can be cheaper when the system asks for a choice rather than generated prose. Validate quality, utilization, and context loss on your own workload before projecting the savings.