Claude Sonnet 5 vs Opus 4.8 (2026): 60% más barato en el papel

Para la mayoría de los equipos la respuesta es "Sonnet 5 por defecto, Opus 4.8 para la cola difícil". Aquí está el veredicto en una línea por escenario.

El resto de este artículo es la evidencia detrás de esa tabla, más una forma de hacer A/B en 10 líneas sobre tu propia carga antes de decidir.

Ambos modelos comparten la misma ventana de contexto nominal de 1M y una salida máxima de 128K. Las diferencias son precio, tokenizador y el comportamiento de pensamiento por defecto.

Los precios introductorios ($2/$10 y $5/$25) y la división introductorio-frente-a-estándar con el corte del 31 de agosto provienen de la documentación de precios publicada por Anthropic al 1 de julio de 2026. Nota en la tarifa de salida estándar: tras la ventana introductoria Sonnet 5 queda en $15/M frente a los $25/M de Opus 4.8, así que la brecha de salida se reduce del 60% al 40%. FACTA es neutral respecto al proveedor y no recomienda ninguno en particular.

En tarifas por token, Sonnet 5 es genuinamente más barato, y lo es en todas las líneas: entrada, salida y lecturas cacheadas.

Durante la ventana introductoria (hasta el 31 de agosto de 2026), Sonnet 5 está a $2/$10 frente a los $5/$25 de Opus 4.8. Eso es un 60% menos en entrada y un 60% menos en salida. Después del 31 de agosto entra la tarifa estándar de $3/$15, un 40% menos en ambas líneas. Las lecturas de entrada cacheada son $0,2/M frente a $0,5/M, un recorte del 60% que se mantiene con independencia de la ventana introductoria y que importa mucho para tráfico productivo con mucho prompt cache.

Así que si tu carga está dominada por tokens de entrada y produce una salida corta y acotada, Sonnet 5 hace exactamente lo que promete el titular. Donde la historia se complica es en cualquier cosa que genere mucha salida, que es la mayor parte del trabajo agentivo.

Una línea de la tabla de especificaciones merece más peso del que suele recibir: la entrada cacheada. Sonnet 5 lee la entrada cacheada a $0,2/M frente a los $0,5/M de Opus 4.8. Si tus prompts llevan un prefijo estable grande (un prompt de sistema, un esquema de herramientas, un conjunto de documentos recuperado que se repite entre llamadas), el prompt caching es donde está el dinero real, y la lectura de caché de Sonnet 5 es un 60% más barata con independencia de la ventana introductoria. La trampa está en el lado de escritura: Sonnet 5 escribe caché a $2,5/M (5 minutos) o $4/M (1 hora) frente a $6,25 y $10 de Opus 4.8, así que cachear se amortiza más rápido en Sonnet 5, pero solo si tu tasa de acierto es lo bastante alta para amortizar la escritura. Por debajo de una relación lectura-escritura de 1:1 a 1,5:1, cachear cuesta más de lo que ahorra en cualquiera de los dos modelos.

Sonnet 5 incluye un nuevo tokenizador. Es la parte del lanzamiento con más probabilidades de sorprenderte en la factura, y también la parte que más se suele malinterpretar.

Los hechos verificados, directamente de la documentación de Anthropic: el mismo texto de entrada produce aproximadamente 30% más tokens en Sonnet 5 que en Sonnet 4.6. Mediciones de la comunidad sitúan el rango entre 1,0 y 1,35x según el contenido. No es un cambio de API (peticiones, respuestas y streaming mantienen la misma forma), pero mueve todo lo que cuentas en tokens:

La interpretación que hay que evitar: este 30% se mide contra Sonnet 4.6, no contra Opus 4.8. Anthropic introdujo este estilo de cambio de tokenizador antes, alrededor de Opus 4.7, así que Opus 4.8 ya usa un tokenizador de generación previa comparable. Para el mismo texto, Sonnet 5 y Opus 4.8 caen en un rango de tokens similar. El tokenizador muerde más fuerte cuando migras de Sonnet 4.6 a Sonnet 5 y reutilizas presupuestos viejos de tokens, no cuando eliges entre Sonnet 5 y Opus 4.8.

La conclusión práctica: si vienes de Sonnet 4.6, recuenta tus prompts con el endpoint de conteo de tokens y revisa cualquier max_tokens dimensionado cerca de tu salida esperada antes de confiar en el encuadre de "el mismo precio $3/$15". Mismo precio por token, más tokens, factura más alta.

Los benchmarks de código son ruidosos, pero SWE-bench Pro es el que merece la discusión porque corre contra issues reales de GitHub de extremo a extremo. Aquí es donde caen ambos, con Sonnet 4.6 como referencia.

Las cifras de SWE-bench Pro y GDPval-AA v2 se recopilaron de los materiales de lanzamiento de Anthropic, 30 de junio de 2026; la brecha de razonamiento sin herramientas de ~6,6 puntos proviene de la System Card de Anthropic. Trata las puntuaciones de leaderboard como una instantánea y consulta la Transparency Hub de Anthropic para la fuente por benchmark. Dos cosas en esa tabla deciden la mayoría de las decisiones de routing.

Opus 4.8 mantiene la ventaja de 6 puntos en SWE-bench Pro. Sonnet 5 en 63,2% es un salto real sobre el 58,1% de Sonnet 4.6, pero el 69,2% de Opus 4.8 sigue siendo el número a batir para issues agentivos difíciles y multi-archivo. Seis puntos en SWE-bench Pro son la diferencia entre "cierra el issue en la primera ejecución" y "lo cierra tras un reintento", y en bucles agentivos largos eso se acumula en gasto de tokens. Si tu trabajo vive en ese techo, el modelo más barato no es realmente más barato una vez que cuentas los reintentos.

Sonnet 5 gana en trabajo de conocimiento por un pelo. En el leaderboard de trabajo económico GDPval-AA v2, Sonnet 5 supera a Opus 4.8 por tres puntos Elo (1.618 a 1.615). Eso está dentro del ruido, pero el punto se sostiene: para tareas profesionales generales que no son la codificación más difícil, Sonnet 5 está a la par con un modelo que cuesta más del doble. Leídas juntas, las tablas dicen una cosa con claridad: Opus 4.8 es significativamente mejor cerrando issues de código difíciles, y Sonnet 5 está a la par en salida profesional general. Ese es todo el caso para ruteear en lugar de elegir un único ganador.

El precio de etiqueta es un número. La factura es otro. Aquí hay dos cargas que producen conclusiones opuestas, con los supuestos declarados para que puedas sustituir los tuyos.

Escenario A — salida acotada de alto volumen (bot de soporte, clasificación, extracción)

Supón 300M tokens de entrada al mes con la mitad servida desde caché, y 30M tokens de salida al mes.

Aquí el descuento es exactamente lo que dice el titular. La salida acotada hace que las tarifas más baratas por token vayan directas al resultado final.

Escenario B — codificación agentiva (ejecuciones largas multi-paso, pensamiento activado)

Supón 5 desarrolladores, 25 tareas/día cada uno, 20 días laborables (2.500 tareas/mes). Por tarea: 60K de entrada en ambos. Salida: 12K en Opus 4.8, pero unos 30K en Sonnet 5 porque el pensamiento adaptativo está activado por defecto y razona más por tarea.

Con precios estándar, una carga agentiva con mucha salida puede costar ligeramente más en Sonnet 5 que en Opus 4.8, porque los tokens de pensamiento extra caen en la línea de salida. El modelo ilustrativo de arriba muestra +5%; una estimación independiente de coste de ejecución lo situó más cerca de +15% ($2,29 por tarea frente a Opus, instantánea de finales de junio de 2026). El número exacto depende de cuánto piensen tus tareas. La dirección no: el descuento de etiqueta no sobrevive el contacto con ejecuciones agentivas largas.

Esta es la única cosa más importante de interiorizar antes de migrar una flota de agentes. El modelo más barato solo es más barato para el trabajo que no le hace pensar duro.

Elige anthropic/claude-sonnet-5 cuando la salida esté acotada y el volumen sea alto. En concreto:

Elige anthropic/claude-opus-4.8 cuando la tarea sea lo bastante difícil para que una primera respuesta errónea cueste más que la diferencia de precio:

La trampa es tratar esto como un cambio binario. La mayoría de las cargas productivas son mixtas: muchas llamadas baratas acotadas más una pequeña cola de tareas genuinamente difíciles. Forzar todo en un modelo paga de más en el 80% fácil o rinde de menos en el 20% difícil.

La solución es el routing. Envía el trabajo acotado de alto volumen a Sonnet 5 y la cola difícil a Opus 4.8, detrás de un único endpoint, de modo que cambiar de modelo sea un cambio de un string, no una reintegración. A través de un gateway neutral respecto al proveedor ambos modelos viven en la misma API compatible con OpenAI, así que un router es una búsqueda en diccionario, no un segundo SDK.

La parte difícil del routing no es la fontanería, es la señal: ¿cómo decides, por petición, si una tarea es difícil antes de ejecutarla? Tres señales funcionan en la práctica. La longitud de entrada es el proxy más barato, ya que las peticiones por encima de algún umbral de tokens tienden a ser las tareas multi-archivo y de alto contexto que recompensan a Opus 4.8. Una etiqueta de tipo de tarea de tu propia aplicación (clasificación frente a trabajo agentivo abierto) es más precisa si ya la tienes. Y una comprobación de confianza sirve como respaldo: ejecuta Sonnet 5 primero y escala a Opus 4.8 solo cuando la salida del modelo más barato falle un paso de validación. El patrón de escalado mantiene la cuota de Opus pequeña, que es el punto entero, ya que Opus es el tier caro que quieres tocar lo menos que el trabajo permita.

La decisión de routing, de extremo a extremo:

La forma honesta de decidir esto es ejecutar ambos sobre tu propia carga y leer los conteos de tokens. Un gateway neutral respecto al proveedor expone ambos modelos en un endpoint compatible con OpenAI, así que lo único que cambia entre ejecuciones es el string del ID de modelo.

Una trampa: Sonnet 5 rechaza temperature, top_p y top_k no predeterminados con un error 400, así que deja los parámetros de muestreo en sus valores por defecto (los ejemplos de abajo lo hacen).

Python: A/B de ambos modelos en un bucle

from openai import OpenAI

client = OpenAI(base_url="https://tu-gateway.ejemplo/v1", api_key="TU_GATEWAY_KEY")

prompt = "Refactoriza esta función para eliminar el bucle anidado: ..."
for model in ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(model, u.prompt_tokens, u.completion_tokens)

Lee la columna completion_tokens de cada uno. Esa columna, multiplicada por la tarifa de salida, es donde el modelo "más barato" puede dejar de serlo sin que te des cuenta.

Node: misma forma

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://tu-gateway.ejemplo/v1", apiKey: process.env.GATEWAY_KEY });

const prompt = "Refactoriza esta función para eliminar el bucle anidado: ...";
for (const model of ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(model, r.usage.prompt_tokens, r.usage.completion_tokens);
}

Ejecuta esto sobre 20 o 30 tareas representativas, suma los tokens de entrada y salida por modelo y multiplica por las tarifas de la tabla de especificaciones. Ese número le gana a cualquier benchmark para decidir qué modelo ruteear a dónde.

Sonnet 5 es un reemplazo directo de Sonnet 4.6 en forma, pero cuatro cambios de comportamiento devolverán errores 400 si tu código viejo asume los valores por defecto de 4.6. Estos también aplican respecto al código de Opus 4.8 en la mayoría de los casos.

El de max_tokens es el fallo tramposo. Si dimensionaste los presupuestos de salida ajustados a Sonnet 4.6, la misma generación en Sonnet 5 produce más tokens para el mismo texto y puede chocar contra el techo a mitad de respuesta. Sube el presupuesto o enviarás respuestas truncadas. También hay una nueva salvaguarda que conviene conocer: Sonnet 5 es el primer modelo de tier Sonnet con rechazos de ciberseguridad en tiempo real, que se devuelven como un HTTP 200 exitoso con stop_reason: "refusal" en lugar de un error, así que maneja ese stop reason de forma explícita.

El pensamiento adaptativo es el cambio con más probabilidades de mover tu factura, y viene con un dial. En lugar del viejo knob budget_tokens, Sonnet 5 expone un parámetro effort (low, medium, high) que intercambia profundidad de razonamiento por gasto de tokens. Si migraste una carga de Opus 4.8 esperando que Sonnet 5 fuera más barato y la factura salió plana, lo primero que probar es bajar effort en las llamadas que no necesitan razonamiento profundo. effort alto en una llamada de clasificación es puro despilfarro, y es de donde viene gran parte del coste sorpresa del Escenario B. Define effort de forma deliberada por ruta en lugar de dejar cada llamada en el valor por defecto.

• Anthropic, documentación "What's new in Claude Sonnet 5" (tokenizador, cambios de comportamiento, precios), verificada el 1 jul 2026: https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5
• Anthropic, post de lanzamiento "Introducing Claude Sonnet 5", 30 jun 2026: https://www.anthropic.com/news/claude-sonnet-5
• Anthropic Transparency Hub (fuente por benchmark): https://www.anthropic.com/transparency
• Anthropic System Card (brecha de razonamiento sin herramientas, ~6,6 puntos)
• Artificial Analysis, estimación de coste de ejecución ($2,29/tarea), instantánea de finales de junio 2026
• MarkTechPost, recopilación de benchmarks (SWE-bench Pro, GDPval-AA v2), 30 jun 2026

Sobre FACTA

FACTA es una consultora de IA. Ayudamos a los equipos a elegir el modelo adecuado para cada tarea, ruteear entre tiers y medir coste por resultado en lugar de coste por token.

Escribimos estas comparaciones porque el precio de etiqueta es el número que citan los proveedores y la factura es el número que realmente decide el routing. Una línea de dos modelos es una oportunidad para acertar esa línea en lugar de usar por defecto un solo modelo para todo.

Si estás diseñando una configuración de routing de modelos por tiers — o quieres una evaluación neutral respecto al proveedor de qué modelo Claude encaja en qué porción de tu carga — podemos ayudar.

Neutral respecto al proveedor por diseño. Coste por resultado por costumbre.