Amazon reemplazó Claude Sonnet 4.6 por Strands Decider, un modelo de decisión, en uno de sus mayores sistemas internos de tickets, y el costo por ticket bajó cerca de un 98 por ciento: de 0,0222 a unos 0,0005 dólares, unas 44 veces menos. Las cifras vienen de los propios ingenieros que hicieron el cambio, en un post del 9 de noviembre de 2026, y son autorreportadas.
Lo que hace valioso ese post no es el número del titular. Carr Onstott y Mehul Jaiswal, los dos ingenieros de Amazon detrás del cambio, son inusualmente francos sobre lo que tuvieron que reconstruir para llegar ahí y sobre los casos en los que no lo harían. Esa es la parte que un CTO debería leer dos veces.
¿Cuánto cuesta Claude Sonnet frente a un modelo de decisión?
En esta tarea, Sonnet costaba unas 44 veces más por ticket y cada llamada tardaba casi cinco veces más. La tarea consiste en etiquetar cada ticket entrante en una de 20 categorías: escalamientos de clientes, solicitudes de capacidad, alarmas automáticas, hallazgos de seguridad, etc. Antes del cambio, Sonnet 4.6 leía un system prompt largo en cada ticket y generaba una etiqueta en JSON con su razonamiento.
| Métrica | Claude Sonnet 4.6 | Strands Decider E4B |
|---|---|---|
| Tiempo promedio por llamada | 4.215 ms | 897 ms |
| Tokens de entrada por ticket | 6.554 | 2.009 |
| Tokens de salida por ticket | 170 | 1 |
| Tokens totales por ticket | 6.724 | 2.010 |
| Costo por ticket | 0,0222 USD | ~0,0005 USD |
| Costo por 1 millón de tickets | ~22.200 USD | ~500 USD |
Cómo se construyeron los números: Sonnet 4.6 en Bedrock a precio de lista (3 dólares por millón de tokens de entrada y 15 por millón de salida), contra una instancia ml.g5.xlarge de SageMaker a 1,408 dólares por hora. La cifra de 500 dólares por millón incluye margen para picos y excluye el costo de Lambda. La duración promedio de Lambda cayó un 74 por ciento el día que se apagó Sonnet. El post habla de “millones de dólares” ahorrados al año, pero no desglosa ese total.
Lo que el post no da es una cifra de precisión. Dice que el modelo E4B superó al Sonnet de producción en un conjunto separado de tickets y que en producción rindió igual de bien. Yo lo tomaría como una afirmación de ingeniería creíble, no como un benchmark publicado.
¿Qué es Strands Decider?
Strands Decider es un modelo de decisión pequeño, lo que sus autores llaman un system one model, que puntúa un conjunto fijo de opciones en lugar de generar texto. Le das un estado (el ticket) y un conjunto de opciones (el catálogo de etiquetas), y devuelve una probabilidad por opción más una confianza calibrada (calibrated confidence). Es un proyecto de Strands Labs, el brazo experimental de Strands Agents, publicado bajo licencia Apache 2.0.
Viene en varios tamaños. El modelo de referencia es un 2B basado en Qwen3.5; la familia Gemma 4 suma las versiones E2B, E4B, 12B y 26B-A4B. Las cifras de Amazon salen del E4B, que el equipo eligió porque superó claramente al 2B en su conjunto de prueba.
Si los modelos de decisión (decision models) son nuevos para ti, explicamos el concepto y cómo se comparan las principales opciones en Microsoft-Decision-1 vs Jev.
SLM vs LLM: ¿por qué pierde un modelo frontera en clasificación de texto?
Porque estás pagando por palabras que nadie lee. Mira la fila de salida: 170 tokens por ticket con Sonnet, uno con Decider. Esos 170 tokens eran razonamiento y formato JSON, cobrados a la tarifa de salida en cada ticket, para una decisión que tiene exactamente 21 respuestas posibles.
Este es el patrón que yo buscaría en cualquier portafolio de cargas de trabajo con LLM. Un modelo frontera es la herramienta correcta cuando la respuesta es abierta: escribir, planificar, programar. Cuando la respuesta es una elección cerrada dentro de una lista conocida, como en la clasificación de texto (text classification), un modelo generativo está haciendo el trabajo de un clasificador a precio de generalista. Y además es más lento, porque tiene que generar texto hasta llegar a una respuesta que un modelo de puntuación lee en una sola pasada. A alto volumen, esa diferencia deja de ser una optimización y pasa a ser una línea del presupuesto.
La confianza importa tanto como el precio. Amazon aplica una etiqueta solo cuando la confianza supera un umbral que el equipo ajustó, así que los tickets dudosos no reciben una etiqueta equivocada. Una etiqueta generada con un párrafo de razonamiento no te da nada equivalente sobre lo cual poner un umbral.
Si quieres ver la misma lógica de costos aplicada dentro de la familia Claude, la comparamos turno a turno en Claude Haiku 5.5 vs Sonnet 5.5 vs Opus 5.5.
¿Qué tuvo que cambiar Amazon para pasar de Sonnet a un modelo de decisión?
Mucho más que el modelo. El post enumera seis cambios:
- Reformularon la tarea como una pregunta de opción única: las 20 etiquetas más una opción “ninguna”.
- Reescribieron cada descripción de etiqueta. Las descripciones de producción no cabían en la ventana de 4.096 tokens del modelo, así que cada una pasó a ser un criterio de una o dos oraciones.
- Recortaron los tickets largos, descartando los comentarios más antiguos para que cupieran en la ventana.
- Ordenaron las claves del JSON en cada solicitud. Solo el orden de las claves movía las probabilidades de salida hasta en 0,19.
- Ajustaron el umbral de confianza antes de aplicar etiquetas.
- Agregaron un interruptor de despliegue de tres posiciones en AWS AppConfig:
BEDROCK(solo Sonnet),DUAL(ambos en paralelo, comparando resultados) yDECIDER(solo Decider). Volver atrás tomaba un cambio de configuración de 45 segundos.
El punto 4 es el que yo subrayaría para cualquier equipo que planee algo parecido. Un modelo cuya salida se mueve 0,19 según el orden de las claves es sensible al formato de entrada, y eso solo lo descubres midiendo. El modo DUAL es lo que hizo seguro el cambio: ambos modelos corrieron sobre tráfico real y sus respuestas se compararon antes de apagar Sonnet.
La arquitectura es AWS sin sorpresas: eventos de tickets a una cola SQS, una Lambda que llama a un endpoint de SageMaker con el modelo, AppConfig para el interruptor y CloudWatch para métricas y alarmas, todo definido en CDK con etapas Beta, Gamma y Prod. El endpoint escala automáticamente, corre aislado de la red y copia los pesos del modelo desde S3 al arrancar. Una instancia atiende unos 640 ms por solicitud, aproximadamente 5.600 tickets por hora a plena carga, con el modelo usando unos 19 GiB en una A10G de 24 GB.
¿Cómo se instala Strands Decider?
Instala el paquete desde PyPI:
pip install strands-decider
Al momento de publicar esta nota (10 de noviembre de 2026), los modelos Gemma 4, incluido el E4B que está detrás de las cifras de Amazon, todavía no estaban en PyPI. Para usarlos, instala desde la rama main del repositorio:
pip install "strands-decider @ git+https://github.com/strands-labs/strands-decider"
El quickstart del README le hace al modelo de referencia 2B una pregunta de opción, una de sí/no y una de puntuación en un solo comando:
strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
--state "Help! My payouts have been failing for 3 days! " \
--choice "Which team should handle this?=billing,sales,retail" \
--noul "Does this convey urgency?" \
--score "How frustrated is the writer?=calm,frustrated,depressed"
También puede correr como servidor HTTP:
strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --port 8000
El servidor incluido escucha en 127.0.0.1 sin autenticación, y la documentación lo describe como pensado para experimentos locales. Amazon no lo expuso: corrió el modelo en un endpoint de SageMaker aislado de la red. No necesitas GPU, porque los cuatro modelos Gemma 4 corren en CPU, pero la memoria suma: el E4B necesita unos 15 GB en bf16 sobre GPU.
¿Cuándo no conviene un modelo de decisión?
Los propios autores ponen los límites, lo cual es buena señal. Un modelo de decisión es la elección equivocada cuando:
- las etiquetas necesitan un texto explicativo;
- el catálogo de opciones cambia cada semana;
- el contexto necesario para decidir no cabe en unos pocos miles de tokens.
Y solo compensa cuando el volumen es alto y la latencia importa. Dos matices más sobre los números: los costos son a precio de lista y sin Lambda, y la cifra por ticket asume que la instancia trabaja cerca de su capacidad, con margen para picos. Una carga de bajo volumen sobre una GPU casi siempre ociosa no vería un 98 por ciento.
Mi lectura: la pregunta correcta para un líder de ingeniería no es “¿deberíamos reemplazar nuestro LLM?”. Es “¿cuáles de nuestras llamadas a un LLM son en realidad clasificaciones?”. La mayoría de los equipos tiene más de las que cree (enrutamiento, triaje, etiquetado, moderación, detección de intención) y cada una es candidata para la misma auditoría que hizo Amazon.
¿Y tú? ¿Qué tarea de tu equipo sigue pagando precios de LLM frontera cuando, en el fondo, es una clasificación?
- Un LLM frontera (Claude, GPT, Gemini)
- Un modelo pequeño o de decisión
- Un clasificador clásico (reglas o ML tradicional)
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: ¿Qué es Flide? El motor que sirve modelos de decisión tipo Jev hasta 9,5 veces más rápido que vLLM