Claude Sonnet 5 vs Sonnet 4.6: ¿Qué cambió y vale la pena actualizar?

Anthropic lanzó Claude Sonnet 5 el 30 de junio de 2026, y es un reemplazo directo para Sonnet 4.6. Cambias el ID del modelo y, en la mayoría de los casos, tu código sigue funcionando. Pero "en la mayoría de los casos" implica un cierto matiz en esa frase. Sonnet 5 viene con un nuevo tokenizador, pensamiento adaptativo activado por defecto y algunos parámetros de solicitud que ahora devuelven errores en lugar de ejecutarse. Este artículo detalla exactamente qué cambió, cuánto cuesta y si la actualización vale la pena para tu carga de trabajo.

La versión corta: el mismo precio por token, mejores puntuaciones en tareas de codificación y agénticas, tres pequeños cambios de código y una peculiaridad del tokenizador no obvia que afecta tus recuentos y presupuestos de tokens. Lee los detalles antes de activar el interruptor en producción.

La actualización de un vistazo

Sonnet 5 mantiene el mismo precio por token que Sonnet 4.6, por lo que, en base al precio por token, nada cambia en tu factura. Mejora los puntos de referencia que importan para el uso de herramientas y la codificación. Y cambia lo suficiente el comportamiento predeterminado como para que un intercambio a ciegas pueda sorprenderte.

Aquí está la comparación lado a lado.

Todo lo demás que funciona en Sonnet 4.6 funciona en Sonnet 5 sin otros cambios de código: salidas estructuradas, visión, almacenamiento en caché de prompts, uso de herramientas y procesamiento por lotes, todo se mantiene. La única característica de la plataforma que pierdes es el Nivel de Prioridad, que no está disponible en Sonnet 5.

Qué mejoró: los benchmarks

Sonnet 5 se posiciona como el modelo Sonnet más agéntico hasta la fecha, y las cifras reportadas lo respaldan en trabajos intensivos en herramientas. Estos son los benchmarks de lanzamiento de Anthropic, corroborados en los informes del día de lanzamiento. Trátalos como números reportados, no como pruebas independientes.

Ese es un salto real en las tareas donde Sonnet es más utilizado: escribir y corregir código con herramientas en el ciclo, y operar una computadora o terminal. Anthropic también informa que Sonnet 5 se acerca a Opus 4.8 una vez que se involucran herramientas, con solo unos pocos puntos de diferencia en tareas agénticas, mientras que cuesta mucho menos. Si tu aplicación tiene una forma agéntica, esta es la actualización que estabas esperando. Para la comparación directa con el modelo premium, consulta Sonnet 5 vs Opus 4.8.

Sonnet 5 también es más seguro que 4.6 según las medidas de Anthropic: una menor tasa de comportamientos indeseables, menor alucinación y adulación, y mejor resistencia a la inyección de prompts. Es el primer modelo de nivel Sonnet con salvaguardias de ciberseguridad en tiempo real. Un comportamiento a tener en cuenta: una negativa a una solicitud prohibida se devuelve como un HTTP 200 exitoso con stop_reason: "refusal", no como un error. Maneja esa razón de detención en el análisis de tu respuesta.

Los tres cambios reales en el código

La mayoría de las migraciones solo afectan estas tres cosas. Revísalas, ajústalas donde sea necesario, y el resto de tu integración permanecerá sin cambios.

1. El pensamiento adaptativo ahora está activado por defecto

En Sonnet 4.6, la ausencia del campo thinking significaba que no había pensamiento. En Sonnet 5, una solicitud sin el campo thinking se ejecuta con el pensamiento adaptativo activado. El modelo decide cuánto pensar basándose en la tarea, y tú diriges la profundidad con el parámetro de esfuerzo (low, medium, high o xhigh).

Esto es importante porque max_tokens es un límite estricto en la salida total, y la salida total ahora incluye los tokens de pensamiento más el texto de tu respuesta. Un max_tokens que en 4.6 estaba dimensionado solo para el texto de respuesta puede ahora truncar tu respuesta en Sonnet 5, porque el pensamiento consume parte del mismo presupuesto.

Si una carga de trabajo se ejecutaba anteriormente sin pensamiento y deseas mantenerla así, desactiva el pensamiento explícitamente:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    thinking={"type": "disabled"},
    messages=[
        {"role": "user", "content": "Return the OpenAPI 3.1 path object for GET /invoices/{id}."}
    ],
)

print(response.content[0].text)

Para usar el pensamiento adaptativo con una profundidad controlada, establece el esfuerzo en lugar de deshabilitarlo:

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    effort="medium",
    messages=[
        {"role": "user", "content": "Draft integration tests for the POST /orders endpoint."}
    ],
)

Observa la forma: thinking={"type": "adaptive"}, no un presupuesto de tokens. Eso lleva al siguiente cambio.

2. El pensamiento extendido manual ha sido eliminado

El antiguo patrón thinking: {type: "enabled", budget_tokens: N} devuelve un error 400 en Sonnet 5. Ya estaba obsoleto en 4.6, por lo que la mayoría del código actual ya no lo usa, pero revísalo. Reemplaza cualquier presupuesto manual con pensamiento adaptativo y el parámetro de esfuerzo. Si establecías un budget_tokens grande para tareas difíciles, effort="high" o effort="xhigh" es la palanca de reemplazo.

3. Los parámetros de muestreo ahora devuelven 400

Establecer temperature, top_p o top_k a un valor no predeterminado devuelve un error 400 en Sonnet 5. Omitirlos o dejarlos en su valor predeterminado está bien. Esta restricción ya existía en Opus 4.7 y posteriores; es nueva para la clase Sonnet.

Si dependías de temperature=0 para una salida con sensación determinista, elimínalo y dirige el comportamiento a través de tu prompt del sistema en su lugar. Sé explícito sobre el formato, el tono y las restricciones en las instrucciones en lugar de hacerlo a través del muestreo. Una búsqueda rápida de estos parámetros en tu base de código te ahorrará una serie de errores 400 en producción.

Una cosa que no cambió desde 4.6: el prellenado de mensajes del asistente aún no es compatible y devuelve un error 400. Si forzabas el inicio de una respuesta prellenando el turno del asistente, usa salidas estructuradas o output_config.format o instrucciones del prompt del sistema en su lugar.

La peculiaridad del tokenizador de la que nadie te advierte

Sonnet 5 utiliza un nuevo tokenizador. El mismo texto de entrada produce aproximadamente un 30% más de tokens que en Sonnet 4.6, aproximadamente 1.3 veces. Esto no es un cambio de API. Las formas de solicitud, respuesta y streaming son idénticas, y no necesitas escribir código nuevo para ello. Pero cambia todo lo que mides o presupuestas en tokens.

Esto es lo que debes volver a medir:

• Recuentos de tokens y campos usage. El mismo prompt reporta más tokens con Sonnet 5. No reutilices tus recuentos de 4.6. Vuelve a ejecutar el recuento de tokens con claude-sonnet-5 para cualquier prompt que monitorees.
• Tu ventana de contexto de 1M contiene menos texto. Cada token ahora cubre menos texto en promedio, por lo que la misma ventana de contexto se ajusta a menos caracteres de tu contenido. Si estabas empaquetando contexto cerca del límite, verifica que aún quepa.
• Los presupuestos de max_tokens dimensionados cerca de la salida esperada pueden truncarse. Un presupuesto que cómodamente contenía tu respuesta típica en 4.6 podría recortarla en Sonnet 5. Combinado con el pensamiento adaptativo que comparte ese presupuesto, esta es la causa más común de respuestas inesperadamente cortas después de una actualización.
• El costo por solicitud de texto equivalente puede ser mayor. La tarifa por token no cambia, pero más tokens por solicitud significa que pagas más por el mismo texto.

Ese último punto merece un ejemplo práctico. Digamos que un prompt más una respuesta eran 10,000 tokens en Sonnet 4.6. El mismo texto es aproximadamente 13,000 tokens en Sonnet 5. A una tasa por token idéntica, esa solicitud cuesta aproximadamente un 30% más, aunque la hoja de precios parezca sin cambios. Modela tus cargas de trabajo reales con el recuento de tokens antes de asumir una paridad de costos plana. El desglose de precios de Sonnet 5 profundiza en esto con la matemática de introducción versus estándar.

Puedes medir el cambio tú mismo con el endpoint de recuento de tokens:

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-5",
    "messages": [
      {"role": "user", "content": "Summarize the changelog for our billing API v3 release."}
    ]
  }'

Ejecuta la misma llamada con claude-sonnet-4-6 y compara los recuentos. Esa diferencia es el impacto real en tu presupuesto.

Cuánto cuesta la actualización

Por token, Sonnet 5 cuesta lo mismo que Sonnet 4.6: $3 por millón de tokens de entrada y $15 por millón de tokens de salida a tarifas estándar. Hay una tarifa introductoria de $2 por millón de entrada y $10 por millón de salida vigente hasta el 31 de agosto de 2026, después de lo cual pasará a la tarifa estándar de $3 / $15.

Así que, durante la ventana introductoria, el texto equivalente es más barato por token que la tarifa estándar de 4.6, lo que compensa en parte el aumento de ~30% de tokens del tokenizador. Después del 31 de agosto, las tarifas por token coincidirán con las de 4.6 nuevamente, y el efecto del tokenizador significa que una solicitud equivalente puede costar más de lo que costaba la misma solicitud en 4.6. Modela esto contra tu tráfico real. Para las tarifas de procesamiento por lotes y caché de prompts, consulta la página de precios de Anthropic en lugar de asumir un descuento fijo.

Si también estás considerando la generación anterior en cuanto a costos, las guías de precios de Sonnet 4.6 y costo de la API de Claude te dan las bases para comparar.

¿Deberías actualizar? Un veredicto por tipo de usuario

El cambio del ID del modelo es trivial. Si lo haces o no depende de lo que ejecutes.

Actualiza ahora si desarrollas agentes, herramientas de codificación o flujos de trabajo intensivos en herramientas. Esta es la victoria más clara. Las mejoras en SWE-bench Pro y OSWorld se sitúan exactamente donde operan las aplicaciones agénticas, y las mejoras de seguridad reducen los comportamientos indeseables en bucles autónomos. Realiza la revisión de los tres parámetros, vuelve a medir tus presupuestos de tokens y lánzalo.

Actualiza, pero prueba con cuidado, si ejecutas cargas de trabajo de producción de alto volumen. El mismo precio por token es una buena noticia, pero el tokenizador significa que tu gasto total de tokens y tu comportamiento de truncamiento de max_tokens cambian. Realiza un pase de conteo de tokens y una suite de regresión antes de dirigir tráfico real. El precio introductorio hasta el 31 de agosto te da una ventana para validar a una tarifa más baja.

Actualiza deliberadamente si dependes de temperature, budget_tokens o prellenado. Estos ahora devuelven 400. La migración es sencilla, moviendo el determinismo a tu prompt del sistema y cambiando los presupuestos por esfuerzo, pero no es un trabajo nulo. Arregla esto antes del cambio, no después.

Espera si necesitas específicamente el Nivel de Prioridad. No está disponible en Sonnet 5. Si tu SLA depende de ello, mantente en 4.6 para esas rutas hasta que cambien tus requisitos.

Para la mayoría de los equipos, la respuesta es actualizar, y pronto, porque obtienes un mejor rendimiento agéntico al mismo precio de cabecera. Trátalo como una migración real con un pase de prueba, no una edición de un solo carácter que lanzas un viernes. Si estás comparando generaciones de forma más amplia, la guía de la API de Sonnet 4.6 documenta la superficie de la que te estás moviendo.

Detecta regresiones con una suite de solicitudes guardadas en Apidog

La forma más segura de actualizar es comparar Sonnet 5 con Sonnet 4.6 usando tus propios prompts, no una tabla de benchmarks. Ese es exactamente el tipo de prueba antes y después para la que está diseñada una plataforma de API.

Apidog es una herramienta todo en uno para el desarrollo y prueba de APIs. Cuando llamas a la API de Claude, estás accediendo a un endpoint HTTP con encabezados de autenticación, un cuerpo de solicitud JSON y una respuesta JSON. Apidog te permite guardar esa solicitud una vez y volver a ejecutarla como una colección reutilizable, lo que convierte una migración de modelo en una prueba repetible en lugar de un reintento manual.

Un flujo de trabajo de migración práctico se ve así:

1. Guarda tus solicitudes de la API de Mensajes de producción como una colección de Apidog, una por cada prompt representativo.
2. Almacena tu ANTHROPIC_API_KEY como una variable de entorno para no pegarla nunca en el cuerpo de una solicitud.
3. Configura dos entornos que solo difieran por el valor de model: claude-sonnet-4-6 y claude-sonnet-5.
4. Añade aserciones sobre la forma de la respuesta y sobre los recuentos de tokens de usage, luego ejecuta la colección contra ambos entornos.
5. Compara las dos ejecuciones. Los deltas en el recuento de tokens te mostrarán el impacto real del tokenizador en tus prompts, y cualquier aserción fallida es una regresión a investigar antes de implementar.

También puedes simular el endpoint de Claude en Apidog para construir y probar tu integración circundante, incluyendo la ruta stop_reason: "refusal", sin gastar tokens. Si tu aplicación tiene una forma agéntica y llama a otras herramientas, Apidog es donde también pruebas y simulas esas APIs descendentes.

Descarga Apidog para construir la suite de comparación, o abre Apidog en el navegador para comenzar desde una solicitud. Si te estás moviendo de Postman para esto, la guía de pruebas de API sin Postman cubre el flujo equivalente.

Preguntas frecuentes

¿Es Claude Sonnet 5 un reemplazo directo para Sonnet 4.6? En su mayor parte sí. Cambias el ID del modelo de claude-sonnet-4-6 a claude-sonnet-5, luego revisas tres cosas: el pensamiento adaptativo ahora está activado por defecto (lo que afecta a max_tokens), el pensamiento extendido de budget_tokens devuelve 400, y los parámetros de muestreo no predeterminados devuelven 400. Todo lo demás se mantiene. Consulta la guía de la API de Sonnet 5 para la configuración completa de la solicitud.

¿Sonnet 5 cuesta más que Sonnet 4.6? Por token, no. Ambos tienen un costo de $3 por millón de tokens de entrada y $15 por millón de tokens de salida a tarifas estándar. Pero el nuevo tokenizador de Sonnet 5 produce aproximadamente un 30% más de tokens para el mismo texto, por lo que una solicitud equivalente puede costar más incluso a la misma tarifa por token. Hay una tarifa introductoria de $2 / $10 por millón hasta el 31 de agosto de 2026.

¿Por qué mi respuesta se trunca después de la actualización? El pensamiento adaptativo está activado por defecto en Sonnet 5, y los tokens de pensamiento comparten el mismo presupuesto de max_tokens que el texto de tu respuesta. Un presupuesto que encajaba con tu respuesta en 4.6 puede truncarla ahora. Aumenta max_tokens, o establece thinking={"type": "disabled"} si no quieres que el pensamiento esté activado en esa llamada.

¿Necesito cambiar mi código para el nuevo tokenizador? No. Las formas de solicitud, respuesta y streaming son idénticas, por lo que no se requieren cambios de código. Pero deberías volver a medir cualquier cosa presupuestada en tokens: recuentos de tokens, dimensionamiento de max_tokens y estimaciones de costos por solicitud. No reutilices tus recuentos de tokens de Sonnet 4.6.

¿Qué pasó con temperature y budget_tokens? Ambos ahora devuelven un error 400 en Sonnet 5 cuando se establecen con valores no predeterminados. Elimina temperature, top_p y top_k no predeterminados, y dirige el comportamiento a través de tu prompt del sistema. Reemplaza el pensamiento extendido de budget_tokens con pensamiento adaptativo más el parámetro de esfuerzo. La guía de cambios en la API de Fable 5 y Mythos cubre el mismo patrón en el nivel superior.