Amazon engineers say they replaced Claude Sonnet 4.6 with Strands Decider for an internal ticket-labeling system, cutting model costs by about 98%. Their November 9 account describes a narrower job than general chat: assigning tickets to a catalog of 20 categories. It gives developers a concrete case for replacing text generation with a fixed-choice model, although the team hasn't published an accuracy table or the number of tickets evaluated.
The engineers project millions of dollars in annual token-cost savings. That remains Amazon's forecast, rather than a reported year of realized savings. The useful evidence is the per-ticket comparison and the deployment method described in the team's write-up. MrKeyoor has not independently reproduced these results.
Where the cost reduction comes from
Strands Decider returns probabilities for supplied options and a confidence score. It doesn't generate explanatory text. The team tried the original 2B model, then chose the E4B Gemma 4 build after getting better results on its tickets, according to the account.
At the published US East (N. Virginia) on-demand prices used in the comparison, Sonnet cost about $22,200 per million tickets. The hosted Decider deployment cost about $500. The team says those are list-price estimates and exclude Lambda costs. Decider's figure depends on keeping the instances busy, with spare capacity for traffic bursts. A lightly used endpoint therefore shouldn't be expected to reproduce that unit cost. The same report puts average model-call time at 897 milliseconds for Decider, against 4,215 milliseconds for Sonnet.
The migration also changed the input. Decider has a 4,096-token window, shorter than the existing label descriptions alone. The engineers rewrote each label as a one- or two-sentence criterion and added a none option. Long tickets lose their oldest comments to fit. As the team documents, both the model and its instructions changed. The cost comparison measures that whole replacement, and the omitted comments are a limitation worth testing on another queue.
The rollout offers a more transferable lesson
The labeling service reads a three-way configuration setting on every message. One mode uses Sonnet alone. A second calls both models, applies Sonnet's answer and compares Decider's result. The final mode uses Decider alone. The engineers say this made rollback a 45-second configuration change. Their deployment description offers a practical way to collect disagreements before handing a new model control of ticket labels.
They also found that changing JSON key order moved output probabilities by up to 0.19 for the same content. Requests now use sorted keys. That reported sensitivity means a comparison needs consistent serialization as well as the same ticket data.
The team's stated limits are useful screening questions: does the task need explanation text, do the labels change weekly, and can the useful context fit in a few thousand tokens? For the next assessment, watch for published error rates and evaluation-set details. Those would help readers judge whether the reported savings survive the mistakes that matter in their own queues.