Amazon reportedly cut ticket-labeling costs 98% by replacing Claude Sonnet with Strands Decider

What happened

Two Amazon engineers have replaced Claude Sonnet 4.6 with Strands Decider, a small decision model, for labeling tickets in an internal ticketing system, and report that the change matched the LLM's labeling quality at roughly 98% lower cost. According to their write-up on the Strands Agents blog, which reached Hacker News's front page, the per-ticket cost fell from about $0.0222 to about $0.0005 — around $22,200 per million tickets down to about $500 — savings the team expects to reach millions of dollars a year.

The system sorts customer escalations, capacity requests, automated alarms, security findings and other events into 20 fixed categories. Sonnet 4.6, Anthropic's model served through Amazon Bedrock, had been doing that job at scale, running a long system prompt on every ticket and generating JSON with reasoning against the label set.

Why a decision model fits

Strands Decider, which the Strands team launched about a month before the post, cannot generate text at all. It receives a state and a question with a set of options, and returns a probability and a confidence score for each option. The engineers, named Carr and Mehul, argue that this is exactly the shape of ticket classification: the ticket is the state, and the label catalog is the set of options.

They began with the 2B-parameter Decider, but an E4B build on Gemma 4 produced clearly better results on a test set, so they switched. On a separate held-out set of real tickets, the E4B model beat the production Sonnet setup.

The model runs on SageMaker ml.g5.xlarge instances, each with a single A10G GPU and 24 GB of memory. It uses about 19 GiB and answers in about 640 ms, with an autoscaling endpoint in an isolated network that blocks outbound access; weights are copied in from S3 at startup. The rest of the path is standard AWS plumbing: ticket events land in an SQS queue, a Lambda function calls the SageMaker endpoint, AppConfig holds the traffic switch, and CloudWatch carries logs, metrics and alarms.

The measured numbers

Running both systems on the same tickets produced these figures:

• Average time per call: 4,215 ms for Sonnet versus 897 ms for Decider, a 78% improvement.
• Input tokens per ticket: 6,554 versus 2,009.
• Output tokens per ticket: 170 versus 1.
• Total tokens per ticket: 6,724 versus 2,010, a 70% drop.

The token collapse comes from two places. Decider emits only the chosen option instead of a JSON answer, and its prompt is far shorter. Sonnet's production label descriptions alone exceeded Decider's 4,096-token window, so the engineers rewrote all 20 labels as one- or two-sentence criteria and passed them as the options of a single choice question, plus a "none" option. Long tickets are trimmed by dropping the oldest comments. On the day Sonnet was switched off, average Lambda execution duration fell 74%.

Costs are quoted at published us-east-1 list prices: $3.00 per million input and $15.00 per million output tokens for Sonnet on Bedrock, versus $1.408 per instance-hour for Decider on SageMaker. At 640 ms per request, one instance can handle about 5,600 tickets an hour — $250 per million at full utilization — but keeping headroom for bursts pushes the practical figure to about $500 per million.

The three-way switch

The team did not simply flip a switch. The labeling Lambda reads a three-way setting from AppConfig on every message: BEDROCK, where Sonnet labels everything; DUAL, where both models run in parallel, Sonnet's answer is applied and every disagreement is compared; and DECIDER, where Decider labels everything and Bedrock is not called. Judging disagreements on live traffic, they write, taught them more than any offline evaluation, and made rollback a 45-second config change.

One incidental discovery: JSON key order affected results. Resending identical content with keys reordered moved output probabilities by up to 0.19, so every request now uses sorted keys.

Caveats worth noting

The figures come from a vendor's own blog post written by the engineers involved, so the headline savings are self-reported rather than independently audited. The engineers are candid about the limits: the approach worked because the task is a closed choice from a stable catalog, volume is high, and latency mattered. If labels need explanation text, the catalog changes weekly, or the useful context does not fit into a few thousand tokens, a decision model probably cannot replace the LLM.

Why it matters

This is one of the clearest public data points yet on the cost gap between routing every job through a frontier LLM and matching the tool to the task. A classification job that cost $0.022 per ticket through a general-purpose model cost $0.0005 through a small decision model — roughly 44 times cheaper, with better latency. At agent scale, that gap compounds quickly. The post's operational pattern — dual-running the old and new systems on real traffic with instant rollback — is also a template any team can copy, whatever models they run.