Amazon Took a Frontier Model Out of Ticket Labeling: What the Numbers Show

Amazon engineers took Claude Sonnet 4.6 out of one ticket-labeling step and replaced it with a small model that can only pick from a list. Their post on the Strands blog, dated 9 November 2026, reports a cost per ticket about 98% lower and says the change "will save millions of dollars of token costs in a year". The speed and token counts are measured. The cost per ticket is calculated from list prices. The "millions" is a projection, and the post publishes neither the ticket volume nor an accuracy figure that a reader would need to check it.

The case supports one practical move for an IT leader. Find the high-volume steps where a frontier model, meaning the largest and most expensive class of model, only picks from a fixed list. Then test a cheaper option on those steps against your own accuracy bar before you switch anything.

What Strands Decider is

Strands Decider is a small open source model that three AWS engineers released on 1 October 2026. A large language model writes text. A decision model, the term AWS uses for this type, reads a situation and a list of options, then returns a score for each option. The launch post puts it this way: "Unlike LLMs that can generate arbitrary output, decision models are designed to pick between sets of options." The first version has 2 billion parameters and is built on an open model called Qwen3.5-2B.

The authors are direct about what it cannot do. In the same launch post they describe decision models as "significantly worse at solving complex problems than reasoning models" and say the model is "unsuited for coding, chatbots, document summarization" and similar work. Decider belongs to the Strands project, the open source agent toolkit from AWS, but it is a separate piece from the Strands Agents SDK. The saving in this story comes from swapping one model for another in one step, and the post does not credit the SDK with it.

What Amazon changed and what it measured

The step labels each ticket in what the 9 November post calls "one of the world's largest internal ticketing systems", which it does not name. Every ticket gets one of 20 categories, or "none". Before the change, Sonnet 4.6 read each ticket with a long system prompt and wrote its answer as JSON. After the change, a Decider build based on Gemma 4, which the post calls E4B, scores the labels and returns one choice. The team started with the 2 billion parameter version and moved to E4B because it did better on their test tickets. The model runs on a SageMaker GPU instance, fed by a queue and a Lambda function.

Every figure in the table is Amazon's own, from the same post. The cost row is an estimate from published us-east-1 list prices: $3.00 per million input tokens and $15.00 per million output tokens for Sonnet 4.6 on Bedrock, and $1.408 per hour for the SageMaker instance. The post sums this up as "about 44 times cheaper than Sonnet, a 98% reduction". It also shows a graph of average Lambda duration falling 74% on the day Sonnet was switched off. No accuracy figure sits beside these numbers, which is the largest gap in the account.

The comparison changed the prompt as well as the model. The post names two sources for the token cut: a one-token answer in place of JSON, and a much shorter prompt, because the 20 label descriptions were rewritten as one or two sentences each to fit Decider's 4,096-token limit. It does not say how much of the cut came from each, or whether the shorter prompt was tried with Sonnet. Some of that saving may have been available without changing models.

The team also compared both models on live tickets before moving production traffic. The post describes a three-way switch: Sonnet alone, both models side by side with Sonnet's label applied and Decider's compared against it, or Decider alone. The switch was a configuration setting, so in the authors' words "going back was a 45-second config change".

What is projected and what is missing

The post gives no ticket count, so the annual saving cannot be checked. Worked example, using only its published figures: the gap is about $21,700 per million tickets, so a saving of $1 million a year needs roughly 46 million tickets a year, and "millions" needs 92 million or more. That is our arithmetic. Amazon has not published the volume.

Four other gaps in the same post matter to anyone who wants to use it as the basis of a business case.

• The costs are list prices and leave out Lambda. The post does not say what Amazon's internal teams are actually charged.
• Accuracy is asserted without numbers. The post says the model "performed just as well" and that E4B beat production Sonnet on a separate set of tickets. It gives no accuracy percentage, test set size or agreement rate.
• The account comes from the people who build the model, published on a blog AWS owns. The research for this article found no independent confirmation as of 10 November 2026.
• The model is sensitive to input format. Sending the same ticket content with its JSON keys in a different order "moved the output probabilities by up to 0.19", so the team now sorts the keys on every request.

Where a small decision model falls short

One outside review comes from eesel AI, on a page last edited 8 October 2026. eesel sells a competing helpdesk agent, so read it as a competitor's critique. It reports that the launch version scored 0.723 on JevBench, a public test of decision tasks, and a later version 0.762, against 0.996 for the large model GPT-6 Luna. It also lists a 4,096-token default limit, no hosted API and no Bedrock listing as of that date, a local server with no authentication, and waits of 16 to 18 seconds on a server CPU for inputs of about 3,000 tokens. A Hacker News user quoted on the page reported a bias toward the first option listed. Amazon ran a different build from the ones scored, and neither Strands post cites a public benchmark for it.

The Amazon authors set their own limits. Their post says: "If your labels need explanation text, if the catalog changes weekly, or if you can't fit the useful context into a few thousand tokens, a decision model probably can't replace the LLM's job." Running the model yourself also adds infrastructure and upkeep, and the hardware you need depends on the response time you must meet.

Analysts are more modest about savings from smaller models in general. The Register reported on 3 November 2026 that a Gartner note puts the best case for open models on routine agent steps at a twentieth of the frontier cost, and the realistic saving "closer to five or six times" per task, because open models "can be more verbose and retry more often". Gartner's analysts call the cost saving "a bonus" next to control of data. Amazon's 44 times describes one narrow step, so budget from measurements of your own workflow, including the steps that keep the larger model.

Sometimes no model is the right answer. If a ticket's queue, sender or a field value already decides the label, a rule costs almost nothing and gives the same answer every time. Where steps must run in a set order for audit reasons, a fixed workflow is the safer design. AWS made a similar point when it let agents call Step Functions workflows as tools, writing on 2 November 2026 that "Step Functions runs each step exactly as you defined it". The guide page on workflows versus agents covers how to make that choice.

How to find your own candidates

The dollar total is unproven, but the pattern is worth acting on. Move a closed-choice step off a frontier model only when your own test shows acceptable accuracy and a lower total cost to run. A step is a candidate when it passes four tests.

1. The answers are a fixed list. Labels, queues, priorities, yes or no, approve or refer. If the output is free text, the step stays with a language model.
2. The volume is high. Worked example at the post's list prices: one instance left running all month, about 730 hours at $1.408, costs about $1,030. That equals the Sonnet bill for roughly 46,000 tickets at $0.0222 each. Amazon's $500 per million assumes instances kept busy at very high volume. At low volume an idle instance still bills by the hour, and this sum leaves out staff time to run and test it.
3. The input is short and the list is stable. The context has to fit in a few thousand tokens, and a label list that changes every week means constant retesting.
4. You can check accuracy first. Agreement with the current model is a start, but two models can share a mistake. You need a set of tickets labeled by people, results broken out by category, and a stated tolerance for the errors that cost most.

Two findings would change this view. One is a test where the small model misses on the categories that are costly to get wrong, such as security findings. The other is a volume too low to cover a dedicated instance, in which case a cheaper hosted model is the simpler move. An earlier post covers routing between large and small models in general, including when to escalate.

What to do this month

1. List every step in your AI workflows where the output is one choice from a fixed list, with its monthly call count and model.
2. Pull last month's bill for those steps and work out cost per thousand decisions, using the method in the guide to agent cost monitoring.
3. Check each step for a rule that would give the same answer with no model at all.
4. For the largest remaining step, run a cheaper model in parallel until every category, including the rare ones, has enough human-checked tickets to judge.
5. Put the model choice behind a configuration switch, and rehearse switching back once before you rely on it.

For teams that want a second pair of eyes on which steps need a frontier model, QueryNow reviews agent workflows as part of its AI agents work.