Casi toda estimación de costo de un agente conversacional se construye igual y se equivoca por un orden de magnitud en la misma dirección. Alguien toma el largo de una pregunta típica, le suma el largo de una respuesta típica, lo multiplica por la cantidad esperada de conversaciones, y multiplica eso por una tarifa por token publicada.
El error no está en la aritmética. Está en que la pregunta y la respuesta son, en un agente de producción que hace algo útil, más o menos el uno por ciento de los tokens que te facturan.
Lo que sigue es un modelo de lo que realmente pagás cuando operás agentes para veinte clientes, medido en tokens y no en moneda, con los multiplicadores que esconde adentro y el único término cuyo crecimiento no es lineal.
Por qué el modelo está en tokens
Porque los precios por token se mueven más rápido que el modelo, y en las dos direcciones.
El AI Index 2025 de Stanford HAI registró que el costo de consultar un modelo que puntúa el equivalente a GPT-3.5 —64,8 en MMLU— "dropped from $20.00 per million tokens in November 2022 to just $0.07 per million tokens by October 2024": una reducción de más de 280 veces en unos dieciocho meses. Cualquier modelo de costos escrito en dólares en 2023 estaba errado por dos órdenes y medio de magnitud en 2024, y cualquier conclusión sacada de ahí sobre qué construir no valía nada un año después.
El reflejo es concluir que la inferencia tiende a cero y dejar de modelar. El AI Index 2026, publicado el 13 de abril de 2026, es el correctivo: la inversión corporativa global en IA llegó a 581.700 millones de dólares en 2025, un 130% más que el año anterior, con una capacidad de energía de data centers de IA de 29,6 GW. Capital de esa intensidad no es señal de que la restricción se haya ido — es señal de que se está comprando capacidad, y la capacidad que se compra después se cobra.
Así que la forma duradera del modelo es una cuenta de tokens. Multiplicá por lo que te cobre tu proveedor este trimestre. La estructura de abajo no cambia cuando cambia la tarifa.
La aritmética de un turno
Un turno conversacional no es un mensaje. Es un prompt armado con seis partes, cinco de las cuales el usuario nunca ve:
| Componente | Tamaño típico | Con qué frecuencia se envía |
|---|---|---|
| Instrucciones de sistema | 400–800 tokens | Cada turno, sin cambios |
| Resumen acumulado de la conversación | ~300 tokens | Cada turno, una vez activa la sumarización |
| Ventana de historial reciente | hasta ~1.500 tokens | Cada turno |
| Chunks recuperados | 5 × ~500 = ~2.500 tokens | Cada turno que toca la knowledge base |
| El mensaje del usuario | ~30 tokens | Cada turno |
| Completion | ~200 tokens | Cada turno |
Estos tamaños son nuestros, de deployments que operamos, no un benchmark publicado — tomalos como una forma y no como una constante. Lo que más los mueve es el tamaño de chunk y cuántos chunks devuelve el paso de retrieval, que es una decisión de configuración y no una propiedad del modelo.
Un turno de mitad de conversación queda entonces alrededor de 4.700 tokens de entrada y 200 de salida. La pregunta del usuario es el 0,6% de la entrada. El contexto recuperado es algo más de la mitad.
A seis turnos por conversación, una conversación cuesta aproximadamente 28.000 tokens de entrada y 1.200 de salida. Veinte clientes con 1.500 conversaciones mensuales cada uno son 30.000 conversaciones, o del orden de 850 millones de tokens de entrada por mes en toda la flota.
Ese es el número sobre el que se arma un caso de negocio. También es el piso, porque encima se apoyan cuatro multiplicadores.
Multiplicador 1: el loop de herramientas, ×2 a ×4
Un turno que llama a una herramienta no es una llamada al modelo. Es una llamada que decide qué herramienta invocar, después una que interpreta el resultado — y si el agente encadena dos búsquedas, o reintenta una que no devolvió nada útil, son cuatro o cinco. Cada una de esas llamadas reenvía el prompt completo, ahora crecido por los resultados de herramientas acumulados.
En un agente con muchas herramientas esta es la corrección más grande a la estimación ingenua, y es invisible en logs por conversación que solo cuentan turnos de usuario. Medí llamadas al modelo, no mensajes. La razón entre las dos es el multiplicador, y en agentes que hacen trabajo real lo vemos entre dos y cuatro.
Multiplicador 2: los chequeos también son llamadas al modelo
Los guardrails semánticos —enforcement de alcance, clasificación de injection, reglas de negocio personalizadas— son inferencia ellos mismos. Sus prompts son cortos, lo que hace que cada uno sea barato y que el total sea fácil de descartar. Siete chequeos por turno sobre prompts cortos es poco al lado de una llamada de razonamiento de 4.700 tokens, pero es una suma fija a cada turno incluyendo los que iban a ser baratos, y cae en el camino rápido donde además pagás en latencia.
La optimización es el orden, no la eliminación: chequeos deterministas antes que semánticos, para que una regex rechace lo que si no hubiera costado una llamada al modelo.
Multiplicador 3: la sumarización es un pico, no un ahorro
Comprimir no es gratis — el sumarizador lee la ventana que está comprimiendo. Cada compactación es una llamada extra sobre mil o dos mil tokens.
Sigue siendo la línea de mayor retorno del modelo, por una razón que vale enunciar con precisión y no como regla de dedo. Sin una ventana de historial acotada, el costo total en tokens de una conversación es cuadrático en su longitud. El turno n reenvía los turnos 1 a n−1, así que el total a lo largo de T turnos va como la suma de 1 hasta T — orden T². Una conversación de veinte turnos no cuesta tres veces una de seis; cuesta unas once veces más.
Un resumen acumulado acota el prompt por turno a una constante, lo que convierte el total en orden T. Eso no es un ahorro porcentual. Es un cambio en la curva de crecimiento, y es por lo que un agente de soporte que maneja hilos largos o sumariza o es un incidente de presupuesto esperando a un cliente conversador.
Multiplicador 4: las partes que facturan mientras no pasa nada
Cuatro líneas que no correlacionan con el volumen de conversaciones:
- Embeddings de ingesta. Cada documento se embebe una vez al subirlo. Barato por documento, real para un cliente que llega con un corpus de 4.000 páginas.
- Re-embedding. Cambiás la estrategia de chunking, o cambiás de modelo de embeddings, y cada documento de cada knowledge base se vuelve a embeber. Es una migración con precio de cambio de configuración, y es la razón por la que el modelo de embeddings es la elección más pegajosa del stack.
- Sincronizaciones programadas de fuentes. Una knowledge base conectada a un repositorio de documentos re-embebe lo que cambió, según un cronograma, hable o no alguien con el agente.
- Failover. Cuando un proveedor se degrada y el tráfico se corre a la siguiente entrada de una cadena, el costo unitario de cada conversación pasa a ser el del fallback — en silencio, mientras dure el incidente. Es un mecanismo de resiliencia con efecto secundario en la factura, y va en el modelo de costos porque se dispara justo cuando nadie está mirando el modelo de costos.
Un cliente inactivo no es un cliente gratis. Es un número más chico que no es cero, lo cual importa cuando estás poniendo precio a un nivel que espera poco uso.
Sensibilidad: qué perilla mueve realmente el número
Cuatro entradas, ordenadas por cuánto se mueve el total de la flota cuando las cambiás.
| Perilla | Efecto sobre el total | Rango realista |
|---|---|---|
| Chunks recuperados por turno | Lineal y dominante — el retrieval es más de la mitad de la entrada | de 5 a 3 chunks saca cerca de un cuarto de todos los tokens de entrada |
| Tope de historial | Cambia la curva de crecimiento, T² → T | la diferencia entre costo acotado y no acotado por conversación |
| Modelo por nivel de razonamiento | Lineal, grande y gratis de cambiar | clasificación y sumarización en el nivel barato; solo la respuesta en el caro |
| Saltos de herramientas por turno | Multiplicativo | ×2 a ×4, y el más difícil de bajar sin cambiar el comportamiento |
El orden es el hallazgo. Los equipos van primero por la tercera fila porque cambiar de modelo es una decisión visible con un número al lado, y vale hacerlo. Pero reducir a la mitad los chunks recuperados suele ser un ahorro mayor que cambiar de modelo, no cuesta más que una corrida de evaluación, y con frecuencia mejora la calidad de la respuesta — cinco chunks mediocres diluyen a los dos buenos.
La segunda fila es la que convierte un problema de costos en un incidente de costos, y es la más barata de arreglar.
Qué implica para cómo cobrás
La conclusión comercial se sigue de la aritmética y no de ninguna teoría de pricing.
No cobres por usuario ni por agente. Ninguno de los dos correlaciona con el costo. Un cliente con tres agentes y hilos largos con mucho retrieval cuesta múltiplos de un cliente con quince agentes respondiendo preguntas frecuentes, y un precio por agente le factura al segundo para subsidiar al primero.
No pongas el tope solo en mensajes. La cantidad de mensajes es un proxy del costo solo si los tokens por mensaje son parecidos entre clientes, y no lo son — la configuración de retrieval varía por cliente a propósito. Un tope de mensajes fijado desde tu cliente promedio es generoso con el más pesado y restrictivo con el más liviano.
Poné el tope en gasto, con un umbral blando por debajo. Un techo duro por ciclo de facturación acota la exposición; un umbral blando en algún porcentaje de ese techo es lo que te da una conversación con el cliente antes de que el techo le corte los agentes a mitad de mes. Dos números, y el segundo es el que evita que el primero sea un incidente de soporte.
Y la razón por la que todo esto es tratable con veinte clientes y no con veinte suscripciones es que el agregado existe. Las plataformas por cuenta producen veinte facturas y ninguna vista de flota; la pregunta "cuánto nos costó la inferencia el mes pasado" se vuelve arqueología entre veinte portales de facturación. Una sola instalación la convierte en una consulta, que es condición previa para poner precio con precisión a cualquier cosa.
Cinco cosas para medir antes de cotizarle a un cliente
Números, no opiniones. Todas están disponibles en la telemetría a nivel de run que ya deberías estar guardando.
- Tokens de entrada promedio por llamada al modelo, abiertos por tipo de nodo. Si las llamadas de razonamiento están por debajo de 2.000, probablemente estés recuperando de menos; si están por encima de 8.000, averiguá qué componente es el outlier.
- Llamadas al modelo por turno de usuario. Este es tu multiplicador de loop de herramientas. Cualquier cosa arriba de 4 necesita explicación.
- Turnos por conversación, en el percentil 90, no en la media. La media esconde los hilos largos, y en los hilos largos vive el término T².
- Porcentaje de turnos que pegan al retrieval. Si es 100%, algunos de esos turnos no necesitaban contexto, y cada uno lleva 2.500 tokens que no usó.
- Tokens por conversación por cliente. Después mirá la dispersión, no el promedio. La razón entre tu cliente más pesado y el más liviano es el único número que te dice si un precio puede cubrir a los dos.
Corré esas cinco contra un mes de tráfico real antes de aceptar un abono fijo por nada. La aritmética de arriba te deja a un factor de dos de la respuesta. Tu propia telemetría te lleva el resto del camino, y en la diferencia entre las dos está el margen.
