Tokens y costes: qué pagas de verdad con LLMs

Hay una conversación que casi nadie quiere tener sobre el desarrollo con IA, y es la del dinero. Los artículos sobre capacidades, agentes y arquitecturas abundan. Los que explican cuánto cuesta de verdad mantener eso en producción, mucho menos. Y sin embargo, es la conversación que más proyectos hunde: sistemas que funcionan perfectamente en la demo y resultan económicamente inviables a escala. El marco general —qué es un agente y qué lo rodea— lo montamos en qué es el harness de un agente; esto es la cara económica de aquello.

Este artículo trata el tema que a nadie le gusta pero todos necesitan. Cómo funcionan los tokens, por qué el coste real rara vez coincide con lo que sugiere la tabla de precios, qué es el cache-aware ordering y qué palancas concretas tienes para que una aplicación con LLMs no se convierta en una sangría. Es menos glamuroso que hablar de agentes autónomos, pero es lo que separa un proyecto sostenible de uno que muere cuando llega la factura.

Qué es un token y por qué importa#

Un modelo de lenguaje no procesa palabras ni caracteres, sino tokens: fragmentos de texto que pueden ser una palabra, parte de una palabra o un signo. Como regla aproximada, en español un token equivale a unos cuatro caracteres, y un texto de cien palabras ronda los ciento treinta o ciento cincuenta tokens. No es una cuenta exacta —depende del idioma y del contenido— pero sirve para estimar.

Importa porque los tokens son la unidad de facturación. Pagas por los tokens que entran (el contexto que envías, tu prompt más todo lo que le adjuntas) y por los tokens que salen (lo que el modelo genera). Y aquí aparece la primera fuente de sorpresas: en muchas aplicaciones, sobre todo agénticas, los tokens de entrada superan con mucho a los de salida. Cada vez que un agente da un paso, reenvía todo su contexto acumulado. En un bucle de veinte iteraciones, ese contexto se envía veinte veces. La factura no la determina lo que el modelo dice, sino cuánto le haces leer una y otra vez.

Por qué el coste real sorprende#

La tabla de precios de un proveedor te dice el coste por millón de tokens. Parece que basta con multiplicar. Pero el coste real de una aplicación en producción diverge de esa cuenta ingenua por varias razones que conviene conocer de antemano.

La primera es la que acabamos de ver: el reenvío de contexto en bucles. Una tarea agéntica no es una llamada, son muchas, y cada una arrastra el contexto acumulado. El coste no crece linealmente con la complejidad de la tarea; puede crecer mucho más rápido si el contexto se acumula sin control.

La segunda es la variabilidad. Distintos usuarios, distintas peticiones y distintos caminos dentro de tu lógica consumen cantidades muy diferentes de tokens. Una estimación basada en el caso medio puede quedarse corta por un factor grande cuando llegan los casos pesados. Presupuestar con el promedio y encontrarse con la cola larga de peticiones costosas es un error clásico.

La tercera es que el volumen a escala amplifica cualquier ineficiencia. Un desperdicio de tokens que es trivial en desarrollo —unos cientos de tokens de más por petición— se convierte en una factura seria cuando multiplicas por millones de peticiones. Las ineficiencias que no ves en pruebas son las que te encuentras en la factura.

El caché: la palanca más importante#

Si hay una sola técnica que merece la pena entender para controlar costes, es el caché de prompts. Los proveedores permiten cachear porciones del contexto que se repiten entre llamadas, de modo que no pagas el precio completo por procesarlas una y otra vez. La parte cacheada tiene un coste sustancialmente menor que la parte procesada de nuevo.

Esto tiene una implicación de diseño enorme, y es donde entra el cache-aware ordering: ordenar el contexto de forma que lo que se repite quede al principio y lo que cambia al final. Los sistemas de caché suelen funcionar por prefijos: cachean desde el inicio del contexto hasta el primer punto donde algo cambia. Si colocas la parte estable de tu prompt —instrucciones del sistema, contexto fijo, definiciones de herramientas— al principio, y la parte variable —la petición concreta del usuario— al final, maximizas cuánto se puede cachear.

Ordenar mal el contexto invalida el caché en cada llamada y multiplica el coste. Ordenarlo con conciencia del caché puede reducir el coste de las porciones repetidas de forma drástica. Es una de esas decisiones de arquitectura que no cambian lo que hace tu sistema, pero cambian radicalmente lo que cuesta. En aplicaciones agénticas, donde el contexto se reenvía constantemente, es probablemente la optimización de mayor impacto disponible.

Otras palancas concretas#

Más allá del caché, hay un conjunto de palancas que conviene tener presentes.

La compactación, que exploramos en detalle en la compactación del contexto de un agente, no es solo una técnica de fiabilidad; es también de coste. Un contexto que crece sin control es un contexto que pagas en cada iteración. Compactar el historial reduce directamente los tokens reenviados. Fiabilidad y coste apuntan, en este caso, en la misma dirección.

La elección de modelo por tarea reconoce que no toda operación necesita el modelo más capaz. Los proveedores ofrecen gamas: modelos potentes y caros para razonamiento complejo, modelos ligeros y baratos para tareas sencillas. Usar el modelo caro para clasificar un texto o extraer un dato simple es malgastar. Enrutar cada tarea al modelo más barato que la resuelve bien es una de las optimizaciones de mayor retorno.

El control del contexto inyectado enlaza con todo lo que hemos dicho sobre el paso del prompt al context engineering. Cada pieza de información que metes en el contexto la pagas. La disciplina de inyectar solo lo relevante —en lugar de volcar todo por si acaso— no es solo mejor para la calidad de la respuesta; es directamente más barata.

Y los presupuestos por tarea, que vimos al hablar de qué hace un agente en cada iteración, son la salvaguarda final. Un límite de tokens por tarea convierte un posible desbordamiento catastrófico en un fallo acotado. Es la diferencia entre un bug que te cuesta unos céntimos y uno que te cuesta la factura del mes.

Medir antes de optimizar#

Una advertencia de método. Es tentador aplicar todas estas técnicas de golpe, pero la optimización de costes, como toda optimización, empieza por medir. Sin instrumentación que te diga cuántos tokens consume cada tipo de petición y dónde se va el grueso del gasto, estás optimizando a ciegas.

Lo primero, por tanto, es la observabilidad de costes: registrar el consumo de tokens por petición, por tipo de tarea, por usuario si hace falta. Con esos datos identificas dónde está el gasto real, que casi nunca es donde intuías. A menudo, el 80 por ciento del coste viene de un 20 por ciento de las operaciones, y atacar ese 20 por ciento rinde mucho más que optimizar uniformemente. Medir primero, optimizar después, y optimizar donde los datos dicen que importa.

Lo que hay que retener#

El coste no es un detalle contable que resolver al final. Es una restricción de diseño que conviene tener presente desde el principio, porque las decisiones de arquitectura —cómo ordenas el contexto, cuánto reenvías, qué modelo usas para qué— determinan si un sistema es económicamente viable a escala.

Las ideas clave: pagas por tokens de entrada y salida, y en aplicaciones agénticas la entrada domina por el reenvío de contexto. El coste real diverge de la tabla de precios por los bucles, la variabilidad y la escala. El caché, ordenado con conciencia de prefijos, es la palanca de mayor impacto. La compactación, la elección de modelo por tarea y el control del contexto reducen el gasto de forma acumulativa. Y nada de esto se hace bien sin medir primero.

Hablar de costes no es lo más emocionante del desarrollo con IA, pero es lo que hace la diferencia entre un prototipo impresionante y un producto que sobrevive. En un campo lleno de demos deslumbrantes que nunca llegaron a producción, entender la economía de los tokens es una de las habilidades más infravaloradas y, precisamente por eso, una de las que más te distinguen.