Degradar es la última palanca, no la primera
Pasar de Opus 4.8 a Sonnet 4.6 reduce los precios por token un 40 por ciento, y vuelve a tirar los dados de cada respuesta que da tu producto. Ese es el intercambio al que la mayoría de los equipos recurren primero, y suele ser prematuro, porque ya hay dos descuentos mayores en la hoja de precios del modelo que usas hoy: el prompt caching lee el contexto repetido a aproximadamente una décima parte del precio de entrada, y la Batch API aplica un descuento fijo del 50 por ciento a cualquier cosa que pueda esperar. Ninguno cambia una sola respuesta. Se acumulan. Y si los aplicas primero, la degradación para la que te estabas preparando a menudo deja de ser necesaria.
Para mantener los números honestos seguiremos trabajando con el mismo paciente: el chatbot de soporte cuya factura de $1,460 desmontamos en la primera parte. Cuatro palancas, aplicadas en orden, sin cambio de modelo para el tráfico que importa:
| Concepto | Importe |
|---|---|
| Factura de la parte 1 | $1,460 |
| + prompt caching | $1,332 |
| + enrutamiento | $799 |
| + recorte de salida | $673 |
El chatbot de la parte 1, cuatro palancas después
Opus 4.8, 10,000 conversaciones / mes · palancas aplicadas de izquierda a derecha
Modelado sobre los supuestos de la parte 1 (10,000 conversaciones de cuatro turnos; un bloque de sistema de 1,500 tokens; preguntas de 500 tokens, respuestas de 700 tokens; Opus 4.8 a $5 / $25 por 1M). El caché usa ventanas de 5 minutos y respeta el prefijo mínimo almacenable en caché de 4,096 tokens de Opus 4.8, así que solo empieza a amortizar a partir del turno 3. El enrutamiento envía la mitad más fácil de las conversaciones a Haiku 4.5 ($1 / $5) y cambia esas respuestas. El recorte reduce las respuestas ~30% dejando la entrada sin cambios, lo que mantiene la estimación conservadora.
Palanca 1: prompt caching, el descuento escondido en tu contexto repetido
La primera parte mostró que el contexto reenviado es la línea más grande de una factura conversacional: el mismo prompt del sistema y el mismo historial creciente, facturados de nuevo en cada turno. El caché ataca exactamente esa línea. Marcas el prefijo estable de tu petición, pagas un sobreprecio único por escribirlo (1.25x el precio de entrada en el nivel de 5 minutos, 2x en el de 1 hora), y cada petición posterior que empieza con los mismos bytes lo lee de nuevo a aproximadamente una décima parte del precio.
| Nivel de caché | Sobreprecio de escritura | Precio de lectura | Se amortiza |
|---|---|---|---|
| 5 minutos | 1.25x el precio de entrada, una vez | ~0.1x el precio de entrada | En el 2.º uso del prefijo |
| 1 hora | 2x el precio de entrada, una vez | ~0.1x el precio de entrada | En el 3.er uso |
Dos salvedades honestas antes de que apuntes un 90 por ciento. Primera, el descuento se aplica a la parte en caché, no a la factura: nuestro chatbot baja de $1,460 a $1,332, un recorte del 9 por ciento, porque sus conversaciones son cortas. En Opus 4.8 nada por debajo de 4,096 tokens puede almacenarse en caché, así que un chat de cuatro turnos solo cruza ese umbral en el turno tres; los turnos más profundos y caros obtienen el descuento, los primeros no. Segunda, el sobreprecio de escritura significa que almacenar en caché un prefijo que nadie reutiliza es una forma de pagar de más. El caché brilla cuando el contexto es grande o las conversaciones son profundas, que es exactamente donde la primera parte dijo que está el dolor.
Palanca 2: la Batch API, un 50 por ciento fijo de descuento en todo lo que puede esperar
La Batch API es el descuento más simple del catálogo: envías el trabajo de forma asíncrona, recibes los resultados en un plazo de minutos a horas y pagas el 50 por ciento del precio estándar por cada token del trabajo, tokens en caché incluidos. No hay ninguna concesión en calidad; es el mismo modelo produciendo las mismas respuestas, solo que sin que nadie mire un spinner de carga.
La trampa está en la definición de "puede esperar". Un cliente en mitad de una conversación no puede, así que el tráfico en vivo de nuestro chatbot no obtiene nada de esta palanca, y por eso no aparece en la cascada de arriba. Pero casi todos los productos de IA arrastran una carga de trabajo en la sombra que sí puede esperar: los resúmenes nocturnos de esas conversaciones de soporte, la clasificación masiva, la generación de informes, los pipelines de contenido. Calcula su coste por separado y procésalos por lotes por defecto; pagar la tarifa en vivo por trabajo que nadie está esperando es la fuga más silenciosa de la mayoría de las facturas.
Palanca 3: enruta por dificultad, no por defecto
No todas las conversaciones necesitan tu mejor modelo. Los restablecimientos de contraseña y las preguntas sobre el estado de un envío no requieren Opus 4.8; requieren una consulta correcta y una frase amable, que Haiku 4.5 entrega a $1 / $5 por millón de tokens, cinco veces más barato por token. En nuestro modelo, enviar la mitad más fácil de las conversaciones a Haiku lleva la factura de $1,332 a $799, el mayor salto individual de la cascada.
Trata esta palanca de forma distinta a las dos anteriores, porque es la primera que cambia las salidas. El caché y el procesamiento por lotes devuelven respuestas idénticas; el enrutamiento asigna a la parte enrutada un modelo diferente. La disciplina que lo mantiene seguro: clasifica de forma conservadora, enruta solo el tráfico que un modelo más barato supera de forma demostrable en tu propio conjunto de pruebas, y mantén una vía de escalado de vuelta al modelo grande en cuanto la conversación deje de ser fácil.
Palanca 4: recorta el lado de la salida, porque se factura a cinco veces la entrada
Cada modelo Claude cobra los tokens de salida a exactamente cinco veces los de entrada, así que la longitud de tus respuestas es una decisión de precio, la tomes de forma deliberada o no. Las respuestas de soporte rellenas de preguntas repetidas y cortesías de cierre cuestan dinero de verdad a gran volumen. Indicar al asistente que responda en la forma más corta que resuelva por completo el ticket recorta nuestras respuestas modeladas en torno a un 30 por ciento y la factura de $799 a $673, y en la familia Opus el ajuste de esfuerzo es el mismo dial un nivel más arriba: bájalo para el tráfico rutinario y el modelo gasta menos tokens de razonamiento para llegar al mismo sitio.
El límite aquí no es técnico, sino humano: recorta más allá del punto de utilidad y las respuestas empiezan a leerse como secas, lo que reaparece más tarde en forma de contactos repetidos. Elimina el relleno, conserva la sustancia.
De dónde sale realmente ese 50 a 90 por ciento
Acumula las palancas en nuestro chatbot y la factura queda en $673, un 54 por ciento por debajo de donde la dejó la primera parte, con la mitad difícil del tráfico todavía en exactamente el mismo modelo produciendo exactamente las mismas respuestas. Que tu propia cifra caiga más cerca de 50 o de 90 lo deciden dos propiedades de tu carga de trabajo: cuánto de tu entrada es contexto repetido y cuánto de tu trabajo puede esperar.
| Carga de trabajo | Ahorrado |
|---|---|
| Chatbot de soporte en vivo | -54% |
| Pipeline nocturno de documentos | -64% |
| Agente asíncrono, contexto compartido pesado | -88% |
Cuánto profundiza el recorte depende de la forma
Porcentaje de la factura mensual ahorrado, modelado por carga de trabajo
Tres cargas de trabajo modeladas, los mismos modelos en todas. Chatbot: los supuestos de la parte 1 más las tres palancas anteriores ($1,460 a $673). Pipeline: 60,000 documentos al mes en Sonnet 4.6 ($3 / $15), un bloque de instrucciones compartido de 2,500 tokens (en caché) más un documento de 3,000 tokens de entrada y 500 tokens de salida, ejecutado durante la noche a través de la Batch API ($1,440 a $518). Agente: 100,000 llamadas asíncronas al mes en Opus 4.8 con un paquete de contexto compartido de 10,000 tokens mantenido activo, 200 de entrada / 300 de salida por llamada, procesado por lotes ($5,850 a $675). Los aciertos de caché dentro de las ejecuciones por lotes son de mejor esfuerzo, así que trata los extremos derechos como techos.
Un chatbot en vivo se sitúa en el extremo modesto, porque las conversaciones cortas usan caché tarde y nada del tráfico en vivo se puede procesar por lotes. Un pipeline nocturno de documentos lo hace mejor: su bloque de instrucciones se almacena en caché a la perfección y cada token del trabajo se lleva el descuento por lotes. Y el agente asíncrono con un gran paquete de contexto compartido es la forma para la que se hicieron los descuentos; nueve décimas partes de su entrada se leen desde caché y toda la ejecución va por lotes, así que el 88 por ciento de la factura simplemente desaparece.
La comprobación de elegibilidad
Antes de tocar la cadena del modelo, recorre tu carga de trabajo por esta tabla una vez.
| Palanca | Tu carga de trabajo necesita | Ahorro realista | Ten cuidado |
|---|---|---|---|
| Prompt caching | Un prefijo estable por encima del mínimo del modelo, reutilizado dentro de la ventana de caché | ~90% de descuento sobre la parte repetida | El sobreprecio de escritura es contraproducente por debajo de 2-3 reutilizaciones; los chats cortos empiezan a usar caché tarde |
| Batch API | Tolerancia a latencias de minutos a horas | Un -50% fijo sobre todo el trabajo | Nunca para un usuario que espera; los aciertos de caché dentro de los lotes son de mejor esfuerzo |
| Enrutamiento por dificultad | Una parte del tráfico que un modelo más barato gestiona de forma demostrable | Hasta 5x en la parte enrutada | Cambia las salidas; prueba la calidad primero y mantén una vía de escalado |
| Recorte de salida + esfuerzo | Facturas con mucha salida (la salida cuesta 5x la entrada) | Proporcional al recorte | Demasiado agresivo se lee como respuestas secas e incompletas |
Ejecuta la auditoría en este orden: primero el caché si algún contexto se repite, procesa por lotes todo lo que un usuario no esté esperando, recorta la salida que de todos modos nunca leías, y después enruta la parte demostrablemente fácil. Solo cuando las cuatro estén en su sitio merece respuesta la pregunta de la degradación, y para entonces es una pregunta mucho más pequeña. Y si la cifra en la que aterrizas sigue pareciendo demasiado alta para lo que la funcionalidad genera, la pregunta ya no es cómo ejecutarla más barata; es si debería existir siquiera, que es exactamente para lo que sirve la tercera parte.
