Costo y latencia: las palancas, en orden de fuerza

Una demo atiende un pedido y el costo es error de redondeo. El mismo sistema a un millón de llamadas por mes convierte el costo y la latencia en números que alguien en finanzas y alguien de guardia tienen que responder — y para entonces los movimientos baratos son más difíciles de retrofitear de lo que eran de diseñar de entrada. Esta página es el tablero de palancas para los dos, ordenado por cuánta fuerza tiene cada una. Nada de esto es exótico; todo es la diferencia entre un feature de IA que cierra y uno que silenciosamente no (principio 6 — costo y latencia son features, diseñados de entrada, no descubiertos en la factura).

Esta es una referencia para la superficie de la Claude API — las palancas off-platform, donde controlás el modelo, el pedido y el presupuesto directamente. Agentforce abstrae algunas (elige modelos y maneja el contexto por vos), pero la disciplina de abajo es idéntica: el pedido más barato y más rápido es el que tiene la forma para ser barato y rápido a propósito. Donde una palanca tiene su propia página de mecánica, esta página es el encuadre de producción y apunta ahí para el cómo.

Elegí el modelo primero — es la palanca más grande

Antes del caching, antes del batching, antes de cualquier ajuste a nivel de pedido: qué modelo llamás es la palanca más grande sobre el costo y la latencia. Un modelo más chico es más rápido y más barato por token por diseño; uno más grande razona más fuerte y cuesta más. Acertá esta decisión y el resto es ajuste fino. Errala — agarrá el modelo más capaz para una tarea que uno más chico resuelve — y pagás de más en cada llamada, para siempre, por un razonamiento que no necesitabas.

Los tres tiers, y para qué sirve cada uno:

Modelo	Velocidad relativa	Costo relativo	Para qué sirve
Haiku	El más rápido	El más bajo	Trabajo simple y de alto volumen — clasificación, extracción, resúmenes cortos, ruteo. El default para cualquier cosa que corrés mucho donde la tarea está bien definida.
Sonnet	Intermedio	Intermedio	La mayoría de los workloads de producción — el default balanceado cuando una tarea necesita capacidad real pero no el razonamiento más difícil. Donde aterriza la mayoría de los agentes y asistentes.
Opus	El más lento	El más alto	El razonamiento más difícil — análisis multi-paso, código complejo, los problemas donde una respuesta más débil es peor que una más lenta. Agarralo donde la tarea lo amerita, no por reflejo.

La regla que Anthropic dice sin vueltas: Haiku para tareas simples, Sonnet para la mayoría de los workloads de producción, Opus para el razonamiento más complejo. La trampa es ir hacia arriba por default "para estar seguro" — la elección que se siente segura es la cara, multiplicada por tu volumen de llamadas. Hacé coincidir el modelo con la tarea, medí, y bajá un tier donde el modelo más chico todavía pasa tus evals (por eso evaluación viene antes que esto — solo podés bajar un modelo de forma segura si podés probar que el más chico sigue funcionando).

Prompt caching — dejá de re-pagar el prefix estático

Si tu prompt carga un preámbulo estable grande — un system prompt, tool definitions, ejemplos fijos, un documento de grounding largo — y lo enviás en cada llamada, el modelo reprocesa esos tokens líderes idénticos cada vez. El prompt caching marca ese prefix estable una vez y reusa el procesamiento en las llamadas siguientes: hasta 90 por ciento de ahorro sobre la porción cacheada y hasta 80 por ciento menos de latencia sobre ella, porque el modelo vuelve a leer el prefix en vez de re-leerlo desde cero.

Como palanca de producción el encuadre es: el caching es la respuesta a un contexto estático grande y reusado, y rinde cuando las llamadas que comparten ese prefix llegan lo bastante seguido como para mantener el cache tibio. La mecánica — cache_control, el breakpoint, la economía read-vs-write que decide si rinde en un workload dado — vive en prompt caching. Acá alcanza con saber que es la primera palanca a nivel de pedido a la que recurrir una vez elegido el modelo, y que se apila con las demás.

Batch processing — cerca de la mitad de ahorro, cuando no necesitás la respuesta ya

Mucho trabajo de IA no necesita una respuesta inmediata: enrichment nocturno, clasificación en bulk, una corrida grande de evals, generar resúmenes sobre un dataset. Para ese trabajo, la Message Batches API procesa los pedidos de forma asíncrona a un descuento de cerca del 50 por ciento sobre tokens de input y output, con la mayoría de los batches terminando en menos de una hora (y un techo más largo para el resto).

La decisión es sobre tolerancia a la latencia, no sobre capacidad — son los mismos modelos, la misma calidad, la mitad del precio, a cambio de "pronto" en vez de "ya". Así que la pregunta de producción es simplemente: ¿un humano o un sistema downstream necesita esta respuesta en tiempo real? Si no, batcheala. El desliz que hacen los equipos es correr todo por el camino vivo y síncrono por costumbre y pagar tarifa completa sobre trabajo que podía haber esperado una hora.

`max_tokens` — un tope duro y una guarda contra runaways

max_tokens pone un límite duro sobre el largo de la respuesta generada. Hace dos trabajos a la vez. Primero, los tokens de output cuestan más que los de input, así que topear la salida es un control directo de costo sobre la parte más cara de una respuesta. Segundo, es una guarda contra runaways: acota el peor caso, así un prompt que se descarrila — un modelo que no para, un loop que sigue generando — no puede disparar una factura sin límite ni colgar un pedido indefinidamente.

Es un instrumento romo: cuando una respuesta llega al tope se corta donde cae, posiblemente a mitad de oración, así que poné el tope real que tu salida necesita y no un número que trunque respuestas buenas. Pero cada llamada de producción debería llevar uno. Un max_tokens sin tope es un pasivo abierto sobre el costo y la latencia de un solo pedido.

Streaming — mismo costo, mucha menos latencia percibida

El streaming no cambia lo que pagás ni cuánto tarda de verdad la respuesta completa — cambia lo que el usuario siente. Con streaming prendido, el modelo envía los tokens a medida que los genera, así el usuario ve la respuesta empezar casi de inmediato en vez de mirar un spinner hasta que aterriza la respuesta entera. El tiempo total de generación es el mismo; lo que baja es el time-to-first-token, y para cualquier cosa que un humano lee en tiempo real ese es el número que gobierna si la cosa se siente ágil o rota.

Así que el streaming es la palanca para la latencia percibida, y prenderlo es casi gratis para cualquier superficie conversacional de cara al usuario. No hace nada por un batch job o una llamada de backend que ningún humano mira — ahí, la latencia total es la única latencia que importa. No confundas las dos: el streaming hace que una respuesta lenta se sienta rápida, no la hace barata ni efectivamente más rápida.

Presupuestos de tokens y la Usage and Cost API — no podés sostener un techo que no medís

Cada palanca de arriba es una conjetura hasta que medís el resultado. La Usage and Cost API es la superficie de gestión de costo: da acceso programático y granular al uso de tokens y al gasto de tu organización — desglosado por modelo, workspace y service tier, con el costo reportado en USD — así podés reconciliar contra la factura, atribuir el gasto, y poner alertas sobre umbrales de gasto en vez de enterarte a fin de mes.

La disciplina que esto habilita es la que cierra el loop: poné un presupuesto de tokens — un techo explícito por feature, por tenant, por corrida — medí el consumo real contra él, y alertá cuando te acercás a la línea. Esta es la respuesta directa a la falla "sin techo de costo" (gotchas de producción la cubre como trampa con nombre): un sistema shipeado sin presupuesto y sin alertas puede multiplicar su factura por diez en un pico de tráfico o una regresión de prompt y la primera señal que recibe alguien es la factura. Un techo medido convierte el costo de una sorpresa en un número que dirigís.

El hilo

El costo y la latencia no son cosas que le pasan a una IA de producción — son cosas que diseñás, más o menos en este orden de fuerza: elegí el modelo correcto (la palanca más grande sobre ambos), cacheá el prefix estable que reenviás, batcheá el trabajo que puede esperar, topeá la salida con max_tokens, hacé streaming donde un humano está mirando, y medí todo contra un presupuesto de tokens con alertas para que el techo sea real. Cada palanca se apila; ninguna es exótica. El equipo que trata esto como features — modelados contra el volumen real antes del launch — shipea una IA que cierra. El equipo que lo trata como algo que se ve después shipea una que funciona en la demo y se apaga el primer mes que llega la factura. La Claude API off-platform te da cada palanca directamente; Agentforce te entrega algunas ya tiradas — de cualquier forma la pregunta es la misma, hecha antes de shipear y no después: ¿cuánto cuesta esto a volumen, y qué tan rápido se siente?

Prompt caching — la mecánica detrás de la palanca de caching: cache_control, breakpoints, y la economía read-vs-write
Context windows — qué llena la ventana y por qué la parte estática es la que vale la pena cachear
Qué es la evaluación — por qué solo podés bajar un tier de modelo de forma segura si podés probar que el más chico todavía pasa
Tracing y monitoreo — el lado de observabilidad de la misma disciplina de medirlo
Principios de AI Engineering — costo y latencia son features (6), el contexto es un presupuesto (10)
Style Guide de producción — la compuerta pre-ship de la que un techo de costo y un presupuesto de latencia son filas
Deployar a producción — donde se toman las decisiones de tier de modelo y rollout

Reference: