La tabla de precios dice que pasar de Opus 4.8 a Sonnet 5 cuesta el doble: diez dólares por millón de input contra cinco, y cincuenta contra veinticinco en output. Limpio y simple. Pero cuando mides tu factura real al final del mes, el número no es 2x. Puede ser 2.56x o incluso llegar a 2.7x. Esa diferencia fantasma no aparece en ninguna tabla de precios y entender de dónde sale es lo que separa una migración rentable de una que te explota el presupuesto.

¿Por qué la factura real no coincide con el precio de lista?

Hay un malentendido que conviene corregir de entrada. Si vienes de Opus 4.8, el tokenizer es exactamente el mismo. Sonnet 5 y Opus 4.8 comparten el tokenizer que se introdujo con Opus 4.7, así que mil tokens en uno son mil tokens en el otro. El conteo no cambia, solo el precio se duplicó.

El 2.56x aparece cuando migras desde modelos anteriores a Opus 4.7. Si tu punto de partida es Opus 4.6, Sonnet antiguo o versiones previas de Haiku, esos usaban un tokenizer distinto que producía menos tokens para el mismo texto. El tokenizer actual puede generar hasta 35% más tokens sobre el mismo contenido [01:07].

Piénsalo como un taxi. El nuevo taxi cobra el doble por kilómetro. Si además tu GPS ahora mide la misma ruta como 28% más larga, tu factura no es 2x, es 2.56x. Y si el GPS estira la medición a 35%, aterrizas en 2.7x. Tu número real depende del modelo de origen y del contenido específico de tus prompts.

¿Cómo medir tu delta real sin adivinar?

No uses un multiplicador genérico. El endpoint count_tokens es gratuito, tiene rate limits separados de message creation y te da el conteo exacto. Llámalo dos veces con el mismo payload: una con tu modelo actual y otra con claude-sonnet-5. Divides nuevo entre viejo y ese cociente es tu tokenizer ratio para ese prompt.

¿Qué es el count_tokens endpoint? Es un servicio gratuito de la API que devuelve el conteo exacto de tokens para un payload sin generar respuesta. Sirve para estimar costos antes de migrar.

No lo hagas con un solo ejemplo. Recolecta un set representativo de tu tráfico real e incluye en cada muestra tu system prompt, las herramientas que pasas si usas tool use y mensajes realistas. Si solo mides una bombilla cuando también corres una lavadora, tu estimación de consumo no vale nada [02:20].

Corre el conteo sobre todo el set, calcula el promedio y mira la dispersión. Algunos prompts pueden dar 1.05 y otros 1.35. La variación te dice qué workloads están más afectados y dónde concentrar la optimización.

¿Qué son los refusals y por qué te cobran por respuestas que no recibes?

Aquí viene la parte que muerde en silencio. Un refusal llega como HTTP 200, así que tu monitoring de errores no lo ve. La única señal es stop_reason con valor refusal, y existen dos tipos con implicaciones de facturación muy distintas.

• Pre-output refusal: el modelo rechaza antes de generar nada. El content viene vacío y el costo es cero. Ni siquiera cuenta contra rate limits.
• Mid-stream refusal: el modelo empieza a generar, produce tokens y entonces se detiene. Los input tokens se cobran y los output tokens ya generados también se cobran a tarifa normal.
• Mid-stream con fallback en non-streaming: el output parcial se elimina de tu respuesta pero sigue facturado en usage.iterations. Pagas por tokens que no ves en ningún lado del response body.

Este último escenario es el más peligroso porque el gap solo es visible leyendo iterations [03:53]. Si tu monitoreo se queda en el cuerpo de la respuesta, esos costos fantasma se acumulan sin alerta.

¿Cómo decidir cuándo pagar el premium de Sonnet 5?

No compares precios de lista. La métrica correcta es costo por tarea completada: costo por intento dividido por tasa de éxito. Es el único número que refleja lo que realmente te cuesta resolver un problema, no lo que cuesta intentarlo.

¿Cómo calculo el costo por tarea completada? Divides el costo de un intento entre la tasa de éxito del modelo. Si Sonnet 5 cuesta $4.50 por intento y acierta el 80%, tu costo real es $5.63 por tarea.

Si un modelo más barato cuesta un dólar pero acierta solo el 54%, su costo real es $1.85 por tarea. Suena ganador, pero si cada fallo requiere supervisión humana, ese costo invisible cambia la ecuación. Para tareas cortas donde ambos modelos tienen la misma tasa de éxito, Opus gana: mismo conteo de tokens y mitad de precio. Para tareas agénticas largas donde resolver en un solo paso cambia el resultado, Sonnet 5 justifica el premium si su tasa de éxito es materialmente más alta.

¿Qué hago si una ruta específica tiene muchos refusals? Compara el setup de fallback contra apuntar esa ruta directamente al modelo más permisivo desde el inicio, así evitas el round trip extra y los tokens fantasma del intento declinado.

En la siguiente clase vas a tomar este modelo de costos y agregarle la capa que lo hace viable a escala: prompt caching con el nuevo mínimo de 512 tokens, caps de gasto para loops agénticos que se descontrolan y Batches como mecanismo de descuento para workloads que toleran latencia. Vas a construir un framework de decisión basado en costo real por tarea completada, no por request individual.

¿Ya mediste tu tokenizer ratio real o sigues estimando con el 2x de la tabla? Cuéntame qué número te salió.