Claude 5.5: Deja de pagar por tareas fallidas

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

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

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

Sonnet 5.5 y Opus 5.5 hacen que esta distinción sea especialmente importante. Uno tiene un precio pensado para volumen. El otro, para tareas más complejas. Ambos tienen un nuevo comportamiento de esfuerzo y los dos pueden resultar sorprendentemente económicos dentro de un bucle de agente bien optimizado con caché

Si copias tu configuración antigua en cualquiera de los dos modelos, el resultado puede ser más lento, más caro o devolver un error 400

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

1TAREA → SONNET 5.5 → VALIDACIÓN → OPUS 5.5 SI ES NECESARIO → RESULTADO VERIFICADO
2             ↘ esfuerzo ↗         ↘ 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 a la newsletter aquí

La métrica que debería definir tu stack

La mayoría de las comparativas de modelos empiezan por los dólares por millón de tokens

Tu agente no entrega tokens. Entrega tareas completadas

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

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

Eso significa que la validación no puede ser un simple visto bueno tras leer una respuesta que parece brillante. Para código, usa el test que bloquearía el merge. Para extracción de datos, compara los campos obligatorios con un conjunto etiquetado. Para investigación, registra si la fuente citada respalda realmente cada afirmación. Incluye el coste de las tareas que nunca se aprueban, no solo los ejemplos bonitos de tu demo

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

Lo que dice realmente la tabla de precios de 5.5

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

1SONNET 5.5
2Entrada nueva  $2       Salida  $10
3Lectura de caché   $0.20    Escritura en caché  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Entrada nueva  $4       Salida  $20
7Lectura de caché   $0.20    Escritura en caché  $5 / 5m, $8 / 1h

Ambos modelos tienen una ventana de contexto de 1M de tokens y una salida máxima de 128K tokens. Son límites máximos, no una invitación a llenarlos.

Especificaciones y precios de los modelos

La línea extraña es la lectura de caché

Opus cuesta el doble en entrada y salida nuevas, pero un prefijo en caché cuesta lo mismo: $0.20 por millón en ambos modelos. Eso no hace que una ejecución con Opus sea igual de barata: sigue pagando más por entradas nuevas, salidas y escrituras en caché. Pero sí significa que la diferencia de precio entre modelos puede reducirse en sesiones con muchas lecturas

Hay un segundo matiz que suele pasar desapercibido. Ese "40 % menos que Opus 5" de Anthropic es una estimación del \coste de ejecución\ típico. Los precios de tokens nuevos de Opus 5.5 bajaron un 20 %; el de lectura de caché cayó un 60 %. Son cifras relacionadas, pero no intercambiables

El esfuerzo es una decisión de enrutamiento, 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 aplicaciones de Claude, Anthropic indica que es medium. Opus 5.5 usa medium por defecto en la API. Estos niveles no equivalen exactamente a lo que significaban esas mismas palabras en los modelos anteriores.

Mi mapa inicial:

• Sonnet low Para peticiones muy concretas 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 presenta un patrón de complejidad demostrado
• Opus medium Para trabajos ambiguos, que afectan a varios archivos o de largo alcance, donde Sonnet se queda dando vueltas al problema
• Xhigh/max Solo cuando tus evaluaciones demuestren que la mejora justifica el tiempo y los tokens extra

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

La nota al pie de Anthropic explica este resultado contraintuitivo: con max, el modelo iniciaba revisiones de código adicionales con más frecuencia. En dos de los 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 donde no tocaba. Si tu agente ya pasa sus validaciones, esos turnos extra de revisión pueden convertirse en un coste y en una fuente de nuevos errores

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

Por cierto, no configures max_tokens a la baja y lo llames optimización. Ese límite cubre tanto el razonamiento interno como la salida visible. Si lo cortas a mitad de tarea, puedes acabar pagando una respuesta truncada y una segunda ejecución en lugar de ahorrar dinero

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

Es una afirmación de lanzamiento muy potente. Aun así, tu configuración en producción debe superar tu propia línea base

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

Coge 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ínima y útil. Registra los campos de uso que necesitas. Ejecútala en cada modelo y nivel de esfuerzo contra la misma tarea y luego añade tu propia comprobación de aprobado/suspendido. 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 con high
8    messages=[{"role": "user", "content": "Sustituye esto por 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, "salida", usage.output_tokens)
15print("lectura de caché", usage.cache_read_input_tokens)
16print("escritura en caché", usage.cache_creation_input_tokens)

Esto asume que usas el paquete oficial de Python de Anthropic y la variable de entorno ANTHROPIC_API_KEY. Es una llamada aislada sin caché activada, así que lo normal es que las lecturas y escrituras en caché sean cero. La siguiente sección explica 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 un aprobado solo cuando el verificador confirme que el trabajo está terminado

Compara el coste total en dólares por tarea aprobada antes de elegir tu configuración por defecto

Mantén la prueba honesta:

• Congela el conjunto de tareas y el verificador antes de comparar configuraciones
• Usa las mismas herramientas, permisos, contexto y requisitos de salida en todos los candidatos
• Registra la tasa de acierto, el gasto total, el coste por acierto, 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 salida de 8K para una prueba de un solo turno. No copies ese límite en un agente de código de larga duración.

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

Define el límite según la tarea y controla el gasto con el esfuerzo, la caché y un presupuesto por tarea, en lugar de obligar a la respuesta a cortarse a medias

Guarda en caché la parte estable del trabajo

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

Por ejemplo, 200K tokens en caché leídos 50 veces son 10M 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 10M de tokens como entrada nueva costaría $40. Y la primera escritura en caché de 200K tokens (válida cinco minutos) suma otro $1.

Esto es solo una ilustración de los costes del prefijo: las entradas nuevas, las salidas, otras escrituras, la expiración del TTL y los fallos de caché reales engordan 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 corte de caché explícitos. La prueba anterior no hace ninguna de las dos cosas, así que sus contadores de caché normalmente se quedarán a cero
• Pon las instrucciones y herramientas estables antes de la petición cambiante del usuario
• Mantén el prefijo compartido idéntico entre turnos; comprueba los cache_read_input_tokens reales
• Trata un cambio de modelo como un nuevo presupuesto de conversación, no como una continuación gratuita. La caché es por modelo: una petición de Opus no puede leer el prefijo que Sonnet acaba de guardar
• Evita cambiar el nivel de esfuerzo principal en cada turno; eso altera el prompt renderizado e invalida los prefijos en caché

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

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

Documentación sobre prompt caching

No asumas un acierto de caché solo porque la respuesta ha sido rápida. Lee el objeto usage. Separa la entrada nueva, la creación de caché y las lecturas de caché

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

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

Escala tras ver evidencias, no por ansiedad

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

Usa el verificador como señal de enrutamiento

11  Sonnet 5.5 · esfuerzo elegido  → ejecuta la tarea
22  Verificador                    → acepta si pasa
33  Opus 5.5 · medium              → reintenta solo si hay evidencia de fallo
44  Verificador                    → acepta o escala con evidencias

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

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

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

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

El propio cambio de modelo puede romper un prefijo en caché. Tenlo en cuenta al comparar la ruta de rescate frente a una estrategia de Opus desde el principio

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

Si cada tarea fallida cuesta luego $0.20 terminarla con Opus, tu media ilustrativa será de $0.10 por tarea terminada: $0.06 más un rescate de $0.20 en una de cada cinco tareas. Eso es mejor que pagar $0.20 por Opus en todas las tareas. Pero si Sonnet cuesta $0.14 y solo aprueba la mitad, esa misma escalera sale por $0.24, incluso antes de sumar el coste del cambio de modelo. Con esa carga de trabajo, ir primero a Opus es más barato y rápido

Estas cifras son ejemplos, no resultados medidos con Claude. Su objetivo es hacer que la regla de enrutamiento sea falsable. La escalera solo merece la pena si las llamadas a Opus que te ahorras compensan los intentos fallidos de Sonnet, los fallos de caché y la latencia añadida

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

Esto no es automáticamente más barato. Registra con qué frecuencia consulta Sonnet 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 que nadie usa.

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 disparan la factura antes de que importe el modelo

No todo problema de costes se soluciona con un router nuevo

Revisa esto primero:

• Salidas que no paran de crecer En ambos modelos 5.5, los tokens de salida cuestan cinco veces más que los de entrada nueva. En una conversación, una respuesta larga también vuelve como contexto en los turnos siguientes. Pide el artefacto y una nota breve de finalización, no una transcripción narrada de cada paso. El razonamiento oculto también se factura como salida, así que una respuesta final escueta por sí sola no arreglará un problema de esfuerzo. Pero no elimines las evidencias que necesitas para verificar el resultado
• Imágenes más grandes de lo necesario Sonnet 5.5 puede procesar imágenes de mayor resolución que las versiones anteriores de Sonnet, lo que puede aumentar el recuento de tokens de imagen. Si el agente solo necesita la etiqueta de un botón o un párrafo, recorta o redimensiona antes. Si necesita un gráfico denso o detalles diminutos de la interfaz, mantén la resolución y mide el coste 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 kilométrico pueden acompañar a cada petición. Pon las reglas permanentes en un prefijo corto y estable; deja las evidencias temporales cerca de la tarea que las necesita. Recortar contexto no debería borrar datos que el modelo aún necesita para terminar bien
• Tarifas interactivas para trabajos que nadie espera La Message Batches API aplica un 50 % de descuento en entrada y salida en ambos modelos. Resulta útil para evaluaciones offline, backfills de documentos y otros trabajos asíncronos. No sustituye a un bucle 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 de bajar el esfuerzo hasta que la calidad se rompa

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

Los cuerpos de petición antiguos son un mal punto de partida para la familia 5.5.

En concreto:

• El razonamiento de Opus 5.5 siempre está activo Elimina thinking: {"type": "disabled"} y las antiguas configuraciones 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 emplearse la herramienta y valida el resultado en tu propio código

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

El razonamiento se incluye aunque el texto esté oculto

Estos son cambios en el comportamiento de la API, no trucos de redacción de 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 notará por primera vez el cambio de modelo. Aplica el mismo principio: dale al agente una definición de "terminado" acotada y oblígale a mostrar las evidencias

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

Este es un bloque inicial completo y reutilizable para CLAUDE.md. Adapta los comandos a tu proyecto

1# Contrato de trabajo
2
3Realiza únicamente el cambio solicitado. No alteres el trabajo no relacionado.
4Ejecuta los tests correspondientes después de editar. Informa de cualquier comprobación que no puedas ejecutar.
5Detente cuando el trabajo solicitado pase las pruebas. No añadas funciones extra ni bucles 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 hará que cada ejecución sea barata por arte de magia. Hace visibles el éxito y el fracaso. A partir de ahí, podrás comparar un flujo de trabajo con Sonnet primero frente a uno con Opus primero sobre las mismas tareas

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

1Cambio: migrar el endpoint de pago al nuevo cliente
2Terminado: cliente antiguo eliminado, tests del endpoint superados, diff limitado a esta ruta
3Parar: preguntar antes de borrar datos o cambiar algo fuera del repositorio
4Informar: archivos modificados, comprobaciones exactas realizadas, riesgo restante

Ese pequeño contrato le da al verificador algo concreto que inspeccionar. Y le da al modelo un motivo para parar. Una instrucción abierta como "revisa hasta que quede perfecto" puede convertir un cambio válido en otro bucle de pago

Para proyectos largos, guarda la checklist en un archivo que sobreviva a la compactación. Con subagentes, pide al agente principal que inspeccione sus evidencias antes de aceptar sus informes. Y si solo has pedido ideas, dile a Claude que no empiece a programar. Son límites del 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, y luego con Opus 5.5 en medium
• Registra entradas nuevas, salidas, escrituras en caché, lecturas de caché, latencia, reintentos y aprobado/suspendido por tarea
• Mantén el prefijo estable almacenable en caché y confirma los aciertos en el uso
• Escala solo los fallos, adjuntando sus evidencias
• Revisa la escalera cuando cambie la carga de trabajo. Un benchmark guardado no es una verdad permanente

Si el 10 % más difícil pasa sistemáticamente del fallo en Sonnet al éxito en Opus, plantéate enviar esa clase de tarea reconocible directamente a Opus desde el principio. Si Sonnet high aprueba esos mismos casos por menos dinero, déjalas ahí. Un router es una política basada en datos, no una opinión permanente sobre qué modelo es más listo

La actualización a 5.5 no consiste solo en "usar Sonnet para lo barato y Opus para lo difícil"

Es la oportunidad de dejar de ponerle precio al modelo y empezar a ponérselo al trabajo terminado

Si has llegado hasta aquí

-> Suscríbete a mi Substack

-> Únete a mi Telegram

-> Guarda este artículo en favoritos

-> Sigue a @0xwhrrari