Lista de verificación de costo por tarea de Sonnet 5 para facturas de Claude

En una carga de trabajo real de Claude, Sonnet 5 puede parecer más barato en la tarjeta de tarifas, pero el nuevo tokenizador de Sonnet 5 puede hacer que el mismo texto consuma entre 1.0 y 1.35 veces la cantidad de tokens, dependiendo del contenido. El intercambio es el costo por tarea: multiplica los tokens de entrada por la tarifa de entrada, los tokens de salida por la tarifa de salida, divide por un millón y luego suma las lecturas en caché, los reintentos y las llamadas de fallback.

El precio por token no es la factura

Una tarifa por token se convierte en una factura solo después de multiplicarla por los tokens que tu ruta de serving emite realmente. Eso incluye tokens de prompt, tokens de completion, reintentos y cualquier lectura en caché que tu stack facture por separado. El nombre del modelo cambia la tarifa, la carga de trabajo cambia la cantidad y la factura es el número que necesitas explicar.

Los prompts cortos pueden hacer que la tarifa domine. El contexto largo, los system prompts repetidos y los bucles intensivos en herramientas pueden hacer que la cantidad de tokens domine. Un cambio de precio destacado puede dejar el gasto mensual plano cuando el nuevo modelo cambia cuántos tokens consume cada tarea.

La deriva del tokenizador cambia la cantidad de tokens

El calendario inicial de Sonnet 5 operó a $2 por millón de entrada y $10 por millón de salida hasta el 31 de agosto, con un paso planeado a $3 y $15 después. La tabla de precios de lanzamiento de Fable 5.1 mostraba las mismas tarifas de $2 y $10. El 10 de agosto, Anthropic hizo permanentes las tarifas de $2 y $10 de Sonnet 5 y abandonó el salto planeado de septiembre a $3 y $15.

Claude Sonnet 5 apareció el 30 de junio, posicionado por Anthropic como el lanzamiento de Sonnet más agéntico. Anthropic lo describió como más fuerte que Sonnet 4.6 en razonamiento, uso de herramientas, programación y trabajo de conocimiento, y más cercano a Opus 4.8. Anthropic presentó el precio de lanzamiento como una forma de mantener la migración aproximadamente neutra en costos para los usuarios.

Esa framing de neutralidad de costos asume que la cantidad de tokens se mantiene fija. Las cargas de trabajo que usan herramientas pueden añadir llamadas de herramientas, razonamiento intermedio y contexto repetido antes de que se devuelva la respuesta final, por lo que la misma tarea puede consumir más tokens bajo el nuevo tokenizador.

Calcula el costo por tarea antes del cambio

Empieza con una clase de tarea, no con todo el producto. Elige una solicitud representativa de producción: una respuesta de soporte, una edición de código, un resumen de documento o un turno de agente que usa herramientas. Registra los tokens de entrada, los tokens de salida y cualquier token en caché que tu capa de serving reporte.

Ejecuta la misma solicitud en el modelo que estás reemplazando y en el modelo candidato. Mantén el prompt idéntico. Mantén la configuración de serving idéntica. Registra la cantidad de tokens de cada ejecución y luego multiplica cada campo de tokens por la tarifa aplicable. Captura el costo por tarea del modelo anterior antes de cambiar el pin, porque la cantidad de tokens del nuevo modelo no será visible hasta que ejecutes el mismo tráfico.

Más tokens pueden superar la tarifa; menos tokens compunden el cambio de tarifa; tokens estables hacen que la tarifa sea toda la historia. El costo por tarea te dice en qué caso estás.

Haz lo mismo con la ruta de fallo. Un reintento puede añadir otro costo de salida, un fallback puede enviar el mismo prompt a un segundo modelo y un trabajo por lotes puede cambiar la tarifa efectiva. Estos no son casos extremos; son parte de la configuración de serving que ya operas.

Las lecturas en caché importan cuando los prefijos repetidos dominan tu tráfico. Si tu system prompt, esquema de herramientas o contexto recuperado es estable, las lecturas en caché pueden cambiar el costo más que la tarifa base. Mide la tasa de acierto de caché antes de asumir que el nuevo modelo ahorrará dinero.

Haz el cambio reversible

La lista de verificación siguiente convierte un cambio de tarifa en una decisión de presupuesto. El orden importa: confirma el precio, mide el delta, calcula la tarea y luego cambia la configuración de serving. Cada elemento es testeable si ya tienes logs.

• Confirma la tarjeta de tarifas actual del modelo candidato.
• Mide el delta de tokens en una muestra de prompts en vivo.
• Calcula el costo por tarea usando campos de entrada, salida y cualquier campo en caché.
• Compara el costo por tarea con el modelo que estás reemplazando.
• Revisa la configuración de serving por límites de contexto, reintentos y comportamiento por lotes.
• Actualiza el pin del modelo, el fallback, las alertas de presupuesto y las evaluaciones.
• Vuelve a ejecutar la misma tarea en el modelo antiguo y nuevo antes del cambio.

Si algún elemento falla, detente.

Trata la re-ejecución como un control. Si el costo por tarea es mayor, aún puedes cambiar por calidad, pero necesitas conocer el impacto en el presupuesto antes de hacerlo. Si el costo por tarea es menor, aún necesitas las alertas y las evaluaciones para detectar regresiones después de que la cantidad de tokens cambie en producción.