Claude 5.5: Deja de pagar por tareas fallidas

La configuración de Sonnet y Opus que realmente importa: effort, caché, verificación y costo por tarea terminada

El modelo más barato no es el que tiene el precio por token más bajo

Es el que termina el trabajo, pasa la validación y no te obliga a pagar cinco veces más por el mismo contexto

Sonnet 5.5 y Opus 5.5 hacen que esa diferencia sea inusualmente importante. Uno tiene un precio pensado para volumen. El otro, para tareas más complejas. Ambos tienen un nuevo comportamiento de effort y los dos pueden resultar sorprendentemente económicos dentro de un loop de agente bien cacheado

Si copias tu configuración anterior en cualquiera de estos modelos, el resultado puede ser más lento, más caro o darte un error 400

Esta es la configuración que yo armaría en su lugar

1TAREA → SONNET 5.5 → VALIDACIÓN → OPUS 5.5 SI ES NECESARIO → RESULTADO VERIFICADO
2             ↘ effort ↗         ↘ caché + registro de uso ↗

Publico análisis prácticos sobre agentes de IA, flujos de trabajo y sistemas en producción en Substack

Suscríbete al newsletter aquí

El número que debería definir tu stack

Casi todas las comparaciones de modelos empiezan con dólares por millón de tokens

Tu agente no entrega tokens. Entrega tareas completadas

https://x.com/claudeai/status/2102435511222890900

Repito: sus pruebas. Tu arquitectura necesita tus propios números

Eso significa que la validación no puede ser un simple "me parece bien" después de leer una respuesta impresionante. Para código, usa la prueba que bloquearía el merge. Para extracción, compara los campos obligatorios contra un dataset etiquetado. Para investigación, registra si la fuente citada realmente respalda cada afirmación. Incluye el costo de las tareas que nunca pasan, no solo los ejemplos bonitos de tu demo

Y analiza la cola difícil por separado. Si la configuración más barata resuelve el 90 % de tus solicitudes pero se quema la mitad del presupuesto en el 10 % restante, su promedio puede ocultar la parte del flujo de trabajo que necesita otro modelo

Lo que realmente dice la lista de precios de 5.5

Al 3 de octubre de 2026, con las tarifas estándar de la API de Claude, por millón de tokens:

1SONNET 5.5
2Input nuevo  $2       Output  $10
3Lectura de caché   $0.20    Escritura de caché  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Input nuevo  $4       Output  $20
7Lectura de caché   $0.20    Escritura de caché  $5 / 5m, $8 / 1h

Ambos modelos tienen una ventana de contexto de 1 M de tokens y un output máximo de 128 K tokens. Estos son límites máximos, no una razón para llenarlos.

Especificaciones y precios de los modelos

El dato raro es la lectura de caché

Opus cuesta el doble en input y output nuevos, pero un prefijo cacheado cuesta lo mismo: $0.20 por millón en ambos modelos. Eso no hace que una ejecución de Opus sea igual de barata: sigue pagando más por input nuevo, output y escrituras de caché. Pero sí significa que la brecha de precio entre modelos puede achicarse en una sesión con muchas lecturas

Hay una segunda diferencia que muchos pasan por alto. Cuando Anthropic dice "40 % menos que Opus 5", es una estimación del \costo de ejecución\ típico. Los precios de tokens nuevos de Opus 5.5 bajaron un 20 %; el precio de lectura de caché cayó un 60 %. Esos números están relacionados, pero no son intercambiables

Effort es una decisión de ruteo, no un control deslizante de calidad

Sonnet 5.5 admite low, medium, high, xhigh y max. En la API, el valor por defecto es high; en las apps de Claude, Anthropic indica que medium es el predeterminado. Opus 5.5 usa medium por defecto en la API. Estos niveles no están calibrados para significar exactamente lo mismo que esas palabras significaban en los modelos anteriores.

Mi mapa inicial:

• Sonnet low Para solicitudes acotadas y sensibles a la latencia, con una validación barata
• Sonnet medium Para código bien especificado y tareas rutinarias de varios pasos
• Sonnet high Cuando la ejecución en medium falla una validación real, o la tarea tiene un patrón de complejidad demostrado
• Opus medium Para trabajos ambiguos, entre múltiples archivos o de largo alcance, donde Sonnet da vueltas alrededor del problema
• Xhigh/max Solo cuando tus evaluaciones muestran una ganancia que justifica el tiempo y los tokens extra

Esta es una hipótesis de partida, no una jerarquía universal. En los resultados de FrontierCode publicados por Anthropic para Sonnet 5.5, xhigh obtuvo mejor puntaje que max. Más esfuerzo no garantiza un mejor resultado

La nota al pie de Anthropic explica este resultado contraintuitivo: en max, el modelo iniciaba revisiones de código adicionales con más frecuencia. En dos casos analizados, eso provocó un timeout o ediciones fuera del alcance de la tarea.

El modo de fallo no fue "el modelo no pensó lo suficiente", sino gastar esfuerzo en el lugar equivocado. Si tu agente ya pasa sus validaciones, los turnos extra de revisión pueden convertirse en un costo y en una fuente de nuevos errores

https://x.com/edwinarbus/status/2104675431853248816

Además, no pongas max_tokens bajo y lo llames optimización. Ese límite cubre tanto el razonamiento como el output visible. Si lo cortas a mitad de la tarea, puedes terminar pagando una respuesta truncada y una segunda ejecución en lugar de ahorrar dinero

https://x.com/claudeai/status/2104633115620823187

Es un argumento de lanzamiento convincente. Pero una configuración de producción igual tiene que superar tu propia línea base

Haz un barrido pequeño antes de inventar un router de modelos

Toma entre 10 y 30 tareas que realmente te importen. Incluye trabajo fácil, trabajo ambiguo y esos fallos molestos que ves en tus logs. Asígnale a cada tarea un verificador: tests, una comparación estructurada, una respuesta conocida o una rúbrica humana definida antes de la ejecución

Esta es la prueba de API más pequeña que sirve. Registra los campos de uso que necesitas. Ejecútala en cada modelo y nivel de effort contra la misma tarea, y luego agrega tu propia validación de aprobado/reprobado. No es un benchmark completo de agentes

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # repetir con claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # repetir en high
8    messages=[{"role": "user", "content": "Reemplaza esto con una tarea real."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("nuevo", usage.input_tokens, "output", usage.output_tokens)
15print("lectura de caché", usage.cache_read_input_tokens)
16print("escritura de caché", usage.cache_creation_input_tokens)

Esto asume que usas el paquete oficial de Python de Anthropic y una variable de entorno ANTHROPIC_API_KEY. Es una llamada aislada sin caché habilitado, así que se esperan cero lecturas y escrituras de caché. La siguiente sección muestra qué cambia eso

Para un agente real, suma el uso de todas las llamadas a la API bajo un mismo ID de tarea, incluyendo reintentos y llamadas a herramientas. Cuenta como aprobado solo cuando el verificador confirme que el trabajo terminó

Compara el total de dólares por aprobación antes de elegir tu configuración por defecto

Mantén la prueba honesta:

• Congela el set de tareas y el verificador antes de comparar configuraciones
• Usa las mismas herramientas, permisos, contexto y requisitos de output en cada candidato
• Registra la tasa de aprobación, el gasto total, el costo por aprobación, la latencia y los fallos más largos o caros
• Cuenta stop_reason: "max_tokens" como un intento incompleto, no como un éxito barato

El ejemplo de código anterior usa un límite de output de 8 K para una prueba de un solo turno. No copies ese límite en un agente de código de larga duración.

Anthropic recomienda mucho más margen para trabajo agéntico porque el razonamiento oculto consume del mismo límite.

Define el límite según la tarea y luego controla el gasto con effort, caché y un presupuesto por tarea, en lugar de forzar a la respuesta a cortarse a mitad del trabajo

Cachea la parte estable del trabajo

Los agentes envían una y otra vez las mismas instrucciones de sistema, definiciones de herramientas, mapa del repositorio y conversaciones previas. Si ese prefijo es estable, el prompt caching cambia la economía mucho más que una pequeña reescritura del prompt

Por ejemplo, 200 K tokens cacheados leídos 50 veces son 10 M de tokens de lectura de caché. A $0.20 por millón, esas lecturas cuestan $2 en cualquiera de los modelos 5.5.

En Opus 5.5, enviar esos mismos 10 M de tokens como input nuevo costaría $40. La primera escritura de caché de cinco minutos para 200 K tokens suma otro $1.

Esto es solo una ilustración de los cargos por prefijo: el input nuevo, el output, otras escrituras, la expiración del TTL y los fallos de caché reales se suman a la factura

Las reglas prácticas:

• En la API de Claude, activa el prompt caching con cache_control={"type": "ephemeral"} a nivel superior o con puntos de quiebre de caché explícitos. La prueba anterior no hace ninguna de las dos cosas, por lo que sus contadores de caché normalmente quedarán en cero
• Pon las instrucciones y herramientas estables antes de la solicitud cambiante del usuario
• Mantén el prefijo compartido idéntico entre turnos; verifica los cache_read_input_tokens reales
• Trata un cambio de modelo como un nuevo presupuesto de conversación, no como una continuación gratis. La caché es por modelo: una solicitud de Opus no puede leer el prefijo que Sonnet acaba de cachear
• Evita cambiar el effort de nivel superior en cada turno; eso modifica el prompt renderizado e invalida los prefijos cacheados

En los modelos compatibles, un cambio de effort por mensaje puede conservar la caché anterior, pero requiere el header beta de Anthropic y no es lo mismo que cambiar el output_config de nivel superior.

Sonnet 5.5 también tiene una salvedad con between_tools: en ese modo, el effort no puede cambiar a mitad de la conversación.

Documentación de prompt caching

No asumas un acierto de caché solo porque la respuesta fue rápida. Lee el objeto usage. Separa el input nuevo, la creación de caché y las lecturas de caché

Ambos modelos 5.5 necesitan al menos 512 tokens en un prefijo cacheable. Un system prompt diminuto no generará los ahorros del ejemplo anterior. La vida útil por defecto de la caché es de cinco minutos, lo cual encaja perfecto con un loop rápido de herramientas.

Una escritura de una hora cuesta más y solo tiene sentido cuando las sesiones reales suelen pausarse lo suficiente como para perder la ventana de cinco minutos. Mide esas pausas antes de pagar por un TTL más largo

Escala tras ver evidencia, no por ansiedad

La mayoría de los equipos arma el router al revés: clasifican una tarea como "difícil", la mandan al modelo caro y nunca descubren si el camino más barato habría pasado

Usa el verificador como señal de ruteo

11  Sonnet 5.5 · effort elegido  → ejecutar la tarea
22  Verificador                  → aceptar si pasa
33  Opus 5.5 · medium            → reintentar solo con evidencia de fallo
44  Verificador                  → aceptar o escalar con evidencia

La validación puede ser una suite de tests, una validación de esquema, una respuesta conocida o un revisor. Debe explicar qué falló.

"La respuesta me parece floja" es una mala señal para escalar; "el endpoint modificado falla dos pruebas de integración" sí sirve

No repitas ciegamente un prompt idéntico. Dale al siguiente intento la validación fallida, los artefactos relevantes y una instrucción específica para corregir el error. Ponle un tope a la escalera para que un agente no se queme el presupuesto intentando arreglar una tarea que requiere una decisión humana

Puedes probar un reintento con Sonnet high en tu barrido offline. Déjalo en la ruta en vivo solo si reduce el costo por tarea verificada. No hay motivo para que cada fallo pague dos ejecuciones de Sonnet antes de llegar a Opus

El cambio de modelo en sí puede romper un prefijo cacheado. Tenlo en cuenta cuando compares la ruta de rescate contra una estrategia de Opus primero

El punto de cruce es fácil de pasar por alto. Supongamos que un intento con Sonnet cuesta $0.06 y aprueba el 80 % de tus tareas.

Si cada tarea fallida cuesta luego $0.20 terminarse en Opus, tu promedio ilustrativo es de $0.10 por tarea terminada: $0.06 más un rescate de $0.20 en una de cada cinco tareas. Eso supera pagar $0.20 por Opus en todas las tareas. Pero si Sonnet cuesta $0.14 y solo aprueba la mitad, la misma escalera sale $0.24, incluso antes de sumar el costo del cambio de modelo. En esa carga de trabajo, ir directo a Opus es más barato y rápido

Esos números son ejemplos, no resultados medidos de Claude. Su propósito es hacer que la regla de ruteo sea comprobable. La escalera solo se justifica si las llamadas a Opus que te ahorras superan los intentos fallidos de Sonnet, los fallos de caché y la latencia adicional

También hay un camino intermedio: la herramienta beta advisor tool de Anthropic. Sonnet puede seguir ejecutando la tarea y pedirle ayuda a Opus para una decisión difícil, en lugar de entregarle todo el trabajo a Opus.

Esto no es automáticamente más barato. Registra con qué frecuencia Sonnet consulta realmente al advisor, cuánto cuestan esas llamadas y si mejoran la tasa de aprobación final. Si el ejecutor casi nunca pregunta, el advisor es solo una función sin usar.

Con estos modelos 5.5, el consejo en sí se devuelve cifrado al cliente, así que evalúa el trabajo resultante en lugar de fingir que puedes auditar el texto privado del consejo

Cuatro fugas que inflan la factura antes de que importe el modelo

No todo problema de costos merece un router nuevo

Revisa esto primero:

• Output que no deja de crecer En ambos modelos 5.5, los tokens de output cuestan cinco veces más que los tokens de input nuevos. En una conversación, una respuesta larga también puede volver como contexto en turnos posteriores. Pide el artefacto y una nota breve de finalización, no una transcripción narrada de cada paso. El razonamiento oculto también se cobra como output, así que una respuesta final escueta por sí sola no va a resolver un problema de effort. No elimines la evidencia que necesitas para verificar el resultado
• Imágenes más grandes de lo que la tarea necesita Sonnet 5.5 puede procesar imágenes de mayor resolución que versiones anteriores de Sonnet, lo que puede aumentar el conteo de tokens de imagen. Si el agente solo necesita la etiqueta de un botón o un párrafo, recorta o redimensiona primero. Si necesita un gráfico denso o detalles mínimos de UI, mantén la resolución y mide el costo en lugar de reducirla a ciegas
• Contexto que nadie usa Las definiciones de herramientas, logs obsoletos, resultados de búsqueda antiguos y un CLAUDE.md enorme pueden acompañar cada solicitud. Pon las reglas permanentes en un prefijo corto y estable; mantén la evidencia temporal cerca de la tarea que la necesita. Recortar contexto no debería borrar datos que el modelo todavía necesita para terminar bien
• Tarifas interactivas para trabajo que nadie está esperando La Message Batches API descuenta un 50 % en input y output en ambos modelos. Sirve para evaluaciones offline, backfills de documentos y otros trabajos asíncronos. No reemplaza un loop de herramientas en vivo donde alguien necesita el siguiente paso ya

El patrón es el mismo en los cuatro casos: elimina el trabajo que la tarea no necesita antes de comprar más inteligencia o bajar el effort hasta que la calidad se rompa

Las trampas de migración que convierten un ahorro en un error 400

Los cuerpos de request antiguos son un mal punto de partida para la familia 5.5.

En particular:

• El thinking de Opus 5.5 siempre está activado Elimina thinking: {"type": "disabled"} y las configuraciones antiguas fijas de budget_tokens; controla la profundidad con output_config.effort
• Forzar la elección de herramienta falla en ambos modelos 5.5

Los valores any y tool en tool_choice devuelven un 400. Usa auto, especifica cuándo debe usarse la herramienta y valida el resultado en tu propio código

• Los bloques de thinking no son bloques de texto Lee el contenido por type, no por content[0]. En loops de herramientas, devuelve los bloques de thinking sin modificar junto con el turno del asistente
• Tu UI puede parecer muda En Opus 5.5, el progreso entre herramientas puede llegar en bloques de thinking que aparecen vacíos con la configuración de visualización por defecto. Si antes le mostrabas esas notas a los usuarios, solicita un modo de visualización de thinking compatible y renderiza los bloques por tipo. De lo contrario, el agente puede estar trabajando mientras la interfaz parece congelada
• Las versiones antiguas de la herramienta computer-use pueden fallar Revisa la versión actual de la herramienta antes de migrar un agente de navegador/computadora
• Un límite de max_tokens más bajo puede cortar el trabajo

El thinking se incluye incluso cuando el texto está oculto

Estos son cambios en el comportamiento de la API, no trucos para escribir prompts.

Guía de migración de Opus y guía de migración de Sonnet

Deja el contrato en Claude Code, no en tu cabeza

La API es donde puedes medir cada campo de uso. Claude Code es donde mucha gente va a notar por primera vez el cambio de modelo. Aplica el mismo principio: dale al agente una definición de "terminado" acotada y luego haz que muestre la evidencia

En Claude Code, /model selecciona el modelo y /effort elige el nivel de effort compatible. Revisa la configuración activa antes de comparar sesiones. El valor por defecto de la API de Sonnet no describe de forma confiable lo que está usando tu app de Claude o tu sesión de Claude Code en este momento

Este es un bloque inicial completo y reutilizable para CLAUDE.md. Cambia los comandos para que coincidan con tu proyecto

1# Contrato de trabajo
2
3Haz únicamente el cambio solicitado. Conserva el trabajo no relacionado.
4Ejecuta las pruebas correspondientes después de editar. Reporta cualquier validación que no puedas ejecutar.
5Detente cuando el trabajo solicitado pase las pruebas. No agregues funciones extra ni loops de revisión.
6Termina con: Cambiado / Verificado / Riesgo restante.
7Pregunta antes de realizar acciones destructivas, publicar o hacer cambios fuera de este repositorio.

Ese bloque no va a hacer que cada ejecución sea barata por arte de magia. Hace visibles el éxito y el fracaso. A partir de ahí, puedes comparar un flujo de trabajo con Sonnet primero frente a uno con Opus primero sobre las mismas tareas

El mensaje de la tarea igual tiene que ser específico. Esta es la diferencia entre "arregla el código de pagos" y un trabajo que un agente realmente puede terminar

1Cambio: migrar el endpoint de pago al nuevo cliente
2Listo: cliente antiguo eliminado, pruebas del endpoint aprobadas, diff limitado a esta ruta
3Detener: preguntar antes de borrar datos o cambiar algo fuera del repo
4Reportar: archivos modificados, validaciones exactas ejecutadas, riesgo restante

Ese pequeño contrato le da al verificador algo concreto para inspeccionar. También le da al modelo un motivo para detenerse. Una instrucción abierta como "revisa hasta que quede perfecto" puede convertir un cambio aprobado en otro loop de pago

Para proyectos largos, guarda la checklist en un archivo que sobreviva a la compactación. Para subagentes, pídele al agente principal que revise su evidencia antes de aceptar sus reportes. Y si solo pediste ideas, dile a Claude que no empiece a construir. Esos son límites de flujo de trabajo, no prompts para que "sea más inteligente"

La configuración que yo lanzaría primero

• Elige entre 10 y 30 tareas reales y define una validación para cada una
• Haz un barrido con Sonnet 5.5 en medium y high, luego con Opus 5.5 en medium
• Registra input nuevo, output, escrituras de caché, lecturas de caché, latencia, reintentos y aprobado/reprobado por tarea
• Mantén el prefijo estable cacheable y confirma los aciertos en usage
• Escala solo los fallos, adjuntando su evidencia
• Revisa la escalera cuando cambie la carga de trabajo. Un benchmark guardado no es una verdad permanente

Si el 10 % difícil pasa repetidamente del fallo en Sonnet al éxito en Opus, considera rutear esa clase de tarea reconocible directamente a Opus desde el inicio. Si Sonnet high aprueba esos mismos casos por menos dinero, déjalos ahí. Un router es una política medida, no una opinión permanente sobre qué modelo es más inteligente

La actualización a 5.5 no es solo "usa Sonnet para lo barato y Opus para lo difícil"

Es una oportunidad para dejar de ponerle precio al modelo y empezar a ponerle precio al trabajo terminado

Si llegaste hasta acá

-> Suscríbete a mi Substack

-> Únete a mi Telegram

-> Guarda este artículo en favoritos

-> Sigue a @0xwhrrari