Token Economics: Why Efficiency Is the Next AI Moat

El impuesto oculto

Cada producto impulsado por IA paga un impuesto que nunca aparece en el balance. No es infraestructura. No es personal. No son tarifas de licencia. Son tokens. Cada prompt, cada completion, cada llamada a herramienta, cada reintento — cada uno consume tokens, y cada token cuesta dinero. Con diez usuarios, el costo es un error de redondeo. Con diez mil usuarios, es una línea en el balance que tu CFO empieza a preguntar. Con un millón de usuarios, es el margen. Y la mayoría de los equipos no se dan cuenta de esto hasta que es demasiado tarde.

La industria de IA en 2026 está obsesionada con la capacidad del modelo. Ventanas de contexto más grandes. Mejor razonamiento. Entradas multimodales. Estos son avances significativos, y importan. Pero aquí está lo que nadie menciona en las keynotes: los equipos que construyen productos ganadores no son los que tienen acceso a los modelos más grandes. Son los que han descubierto cómo usar tokens sabiamente. La capacidad es el mínimo. La eficiencia es el diferenciador.

Piensa en lo que pasa cuando lanzas una feature de IA sin pensar en economía de tokens. Tu system prompt es de 4,000 tokens porque cargaste cada descripción de herramienta, cada instrucción de comportamiento, cada manejador de caso extremo — necesite el usuario o no. Tu historial de conversación crece linealmente porque nunca resumes ni podas. Tu agente llama herramientas especulativamente, quemando tokens en ida y vuelta de API que no devuelven nada útil. Tu modelo genera 500 tokens de preámbulo antes de llegar a la respuesta porque nadie le dijo que fuera conciso. Multiplica todo eso por cada usuario, cada sesión, cada día. Los números se componen de formas que pueden romper un modelo de negocio.

Este artículo es un análisis técnico de economía de tokens — los patrones, herramientas y decisiones arquitectónicas que separan a los productos de IA con economías unitarias sostenibles de los que sangran dinero a escala. Vamos a desglosar exactamente a dónde van los tokens, por qué la mayoría se desperdician, y qué puedes hacer al respecto. La tesis es simple: el próximo foso de la IA no es el acceso a modelos. Es la eficiencia de tokens.

El presupuesto de tokens

Antes de poder optimizar el gasto de tokens, necesitas entender a dónde van realmente los tokens. La mayoría de los equipos tienen una vaga noción de que "las llamadas API cuestan dinero", pero nunca han hecho un desglose forense de una sola interacción. Arreglemos eso. Aquí está la anatomía de una interacción típica impulsada por IA en un sistema de producción — no un chatbot, sino una feature real de producto que usa un LLM para cumplir una tarea:

Mira esa distribución. La salida real del modelo — lo que el usuario ve, lo que entrega valor — es solo el 15% del gasto total de tokens. El cuarenta por ciento va al system prompt y contexto que el modelo necesita para entender su rol. El veinte por ciento es entrada del usuario e historial de conversación. Y un cuarto completo va a llamadas a herramientas y sus resultados, la mayoría de los cuales el usuario nunca ve.

Ahora escalemos esa interacción individual a una base de usuarios real. Asume tres interacciones por usuario por día a 10,000 tokens cada una, usando un modelo con precio de $3 por millón de tokens de entrada y $15 por millón de tokens de salida. El costo combinado por interacción resulta en aproximadamente $0.03.

A $30,000 por día — $900,000 por mes — el gasto de tokens no es un centro de costos. Es el negocio. Y eso es un sistema simple de un solo modelo y un solo agente. En el momento en que introduces arquitecturas multi-agente, los números explotan. Un sistema de cinco agentes no cuesta cinco veces más. Cuesta cinco veces más por agente, por el número de comunicaciones inter-agente, por el contexto que cada agente necesita mantener independientemente. Hemos visto pipelines multi-agente donde el orquestador solo consume 30,000 tokens antes de que cualquier sub-agente empiece a trabajar — solo para enrutar la tarea, establecer contexto y coordinar el plan.

El problema de la composición es insidioso. Cada agente en el sistema tiene su propia ventana de contexto, sus propias descripciones de herramientas, su propio historial de conversación. No hay memoria compartida por defecto — cada agente reconstruye contexto desde cero. Un sistema de cinco agentes con 10,000 tokens de contexto por agente no son 50,000 tokens. Son 50,000 tokens más el overhead de orquestación, más el costo de serialización de pasar resultados entre agentes, más los reintentos cuando un agente malinterpreta un traspaso. En producción, hemos medido que el multiplicador real está más cerca de 8x, no 5x.

Es por esto que la economía de tokens importa. No porque los precios de API sean altos — de hecho han caído dramáticamente en los últimos dos años. Sino porque el uso escala de forma no lineal. Una reducción del 40% en tokens por interacción no te ahorra 40% a escala. Te ahorra 40% compuesto en cada usuario, cada sesión, cada agente, cada reintento. El apalancamiento es enorme.

Compresión sin compromiso

El ataque más directo al desperdicio de tokens es la compresión de salida — reducir el número de tokens en la respuesta del modelo sin perder el contenido informativo. Esto suena como una compensación, y durante años la suposición fue que lo es. Salidas más cortas deben significar salidas menos matizadas. Menos detalle. Menor calidad. Esa suposición resultó ser incorrecta.

En marzo de 2026, un artículo de investigación cuantificó algo que los profesionales habían observado anecdóticamente: la salida verbosa de LLM no solo cuesta más tokens — degrada activamente la calidad del razonamiento. El estudio midió una mejora de 26 puntos porcentuales en la precisión de tareas cuando los modelos se restringían a formatos de salida concisos. Veintiséis puntos. Eso no es una mejora marginal. Es la diferencia entre un sistema que funciona y uno que no.

El mecanismo es intuitivo una vez que lo ves. Cuando un modelo genera 500 tokens de preámbulo — "Estaré encantado de ayudarte con eso. Déjame analizar el problema que describes..." — esos tokens no son relleno gratis. Consumen presupuesto de salida que podría ir al razonamiento real. Cada token que el modelo gasta en cortesías sociales, frases de hedging y reformulaciones redundantes de la pregunta del usuario es un token que no gasta en trabajar a través del problema. La compresión no se trata de eliminar estilo. Se trata de reasignar el presupuesto de salida de la ceremonia a la sustancia.

Caveman (JuliusBrussee/caveman, 6,300+ estrellas) es la herramienta que operacionalizó esta perspectiva para flujos de trabajo de Claude Code. Es un skill a nivel de sistema que comprime la salida del modelo en tres niveles configurables. El modo Lite recorta lo innecesario manteniendo la salida profesional — oraciones completas, gramática apropiada, pero sin relleno. El modo Full despoja la salida a sus componentes esenciales, eliminando artículos, hedging y lenguaje decorativo. El modo Ultra va telegráfico: tokens mínimos viables mientras preserva significado y precisión técnica.

Los resultados en producción son impactantes. En nuestros benchmarks internos, el modo Full de Caveman logra una reducción promedio de tokens del 65% sin pérdida medible en la calidad de completación de tareas. En tareas de generación de código específicamente, la reducción se acerca al 70% porque la generación de código es particularmente propensa a explicaciones verbosas que el desarrollador nunca lee. Piensa en lo que significa 65% a escala: esa cifra de $30,000 por día baja a $10,500. Esa factura mensual de $900,000 se convierte en $315,000. Mismo producto. Misma capacidad. Misma experiencia de usuario. Economías unitarias fundamentalmente diferentes.

El principio más profundo aquí se extiende más allá de cualquier herramienta individual. La compresión es una filosofía de diseño. Cada system prompt que escribes, cada formato de salida que defines, cada instrucción que le das a un modelo — cada uno es una oportunidad para desperdiciar tokens en ceremonia o invertirlos en sustancia. Los equipos que internalizan este principio no solo ahorran dinero. Construyen mejores productos, porque sus modelos gastan más de su presupuesto en las partes que realmente importan.

Selección de modelo como arquitectura

Aquí hay una pregunta que revela cómo la mayoría de los equipos piensan sobre IA: "¿Qué modelo deberíamos usar?" La pregunta asume una sola respuesta. Un modelo, elegido en tiempo de desarrollo, usado para todo. Esa suposición es costosa, y es incorrecta. La pregunta correcta es: "¿Qué modelo deberíamos usar para esta consulta específica, en este momento, dado lo que sabemos sobre la complejidad de la tarea?"

El patrón de cascada de modelos trata la selección de modelo como una decisión en tiempo de ejecución, no una elección de configuración. En lugar de enviar cada consulta a tu modelo más capaz (y más caro), construyes una capa de enrutamiento que clasifica las consultas entrantes por complejidad y las dirige al modelo más barato que pueda manejarlas competentemente. La arquitectura se ve así:

Las matemáticas de este patrón son transformadoras. Veámoslo. Sin una cascada, cada consulta va a Sonnet a $3 por millón de tokens de entrada. Con una cascada, el 80% de las consultas van a Haiku a $0.25 por millón de tokens, el 15% va a Sonnet a $3, y el 5% va a Opus a $15. El costo combinado por millón de tokens de entrada baja de $3.00 a $0.65 — una reducción del 78%. Y eso es solo el lado de entrada. Los ahorros en salida son aún mayores porque el precio de salida de Haiku es proporcionalmente más barato que el de Sonnet.

Pero el costo no es el único beneficio. La latencia mejora dramáticamente. Haiku responde en milisegundos donde Opus toma segundos. Para el 80% de las consultas que son genuinamente simples — clasificación, extracción de entidades, llenado de plantillas, Q&A directo — el usuario obtiene una respuesta más rápida y más barata sin pérdida de calidad. El usuario no sabe ni le importa qué modelo respondió su pregunta. Le importa que la respuesta fue correcta y rápida.

El router de complejidad en sí es el desafío de ingeniería. Un enfoque ingenuo — usar coincidencia de palabras clave o longitud de consulta como proxy de complejidad — mal enruta demasiadas consultas. Un enfoque sofisticado usa un clasificador ligero (corriendo en Haiku) para evaluar la complejidad de la consulta en múltiples dimensiones: ¿requiere razonamiento multi-paso? ¿Necesita sintetizar información de múltiples fuentes? ¿Involucra generación creativa? ¿Hay ambigüedad que requiere juicio? El clasificador agrega un pequeño costo fijo por consulta pero se paga muchas veces al prevenir invocaciones costosas de modelo en tareas simples.

Hay una sutileza aquí que la mayoría de los equipos no ven: la cascada también te da degradación elegante. Cuando Opus tiene límite de velocidad o experimenta picos de latencia, el sistema absorbe automáticamente el impacto porque solo el 5% del tráfico depende de él. Tu nivel del 80% en Haiku es esencialmente inmune a problemas del proveedor upstream. Esta resiliencia es un bonus arquitectónico del patrón de cascada, no su propósito principal, pero nos ha salvado en producción más de una vez.

El patrón de cascada también compone bellamente con la compresión. Haiku procesando un prompt comprimido es la unidad más barata posible de cómputo de IA. Cuando combinas una reducción de tokens del 65% de Caveman con una reducción de tráfico del 80% del enrutamiento en cascada, los ahorros compuestos se acercan al 93%. Eso no es una optimización de costos. Es la diferencia entre un producto viable y una imposibilidad económica.

Ingeniería de contexto

La compresión reduce el desperdicio de salida. Las cascadas de modelos reducen el desperdicio de enrutamiento. Pero la mayor fuente de desperdicio de tokens en la mayoría de los sistemas no es ninguna de estas. Es el contexto. El system prompt, el historial de conversación, las definiciones de herramientas y el estado acumulado que el modelo necesita para hacer su trabajo. En un sistema bien diseñado, el contexto es la línea más grande en el presupuesto de tokens — y es donde se esconden las mayores ganancias de eficiencia.

La ingeniería de contexto es la disciplina de gestionar lo que entra en la ventana de contexto del modelo con el mismo rigor que aplicarías a gestionar una base de datos o una jerarquía de memoria. No es prompt engineering — eso es sobre la redacción. La ingeniería de contexto es sobre arquitectura: qué información se carga, cuándo se carga, cuánto tiempo permanece y cuándo se desaloja. El objetivo es minimizar los tokens en la ventana de contexto en cualquier momento mientras se maximiza la capacidad del modelo para realizar la tarea actual.

Usamos cuatro estrategias centrales, cada una apuntando a una fuente diferente de inflación de contexto:

Carga progresiva de habilidades. La mayoría de los sistemas de agentes cargan cada definición de herramienta en el system prompt por adelantado. Un agente de 50 herramientas tiene 3,000 tokens de descripciones de herramientas antes de que el usuario diga una sola palabra. Esos son 3,000 tokens cobrados en cada interacción, independientemente de si el usuario necesita alguna de esas herramientas. La carga progresiva de habilidades invierte esto: empieza con un conjunto mínimo de herramientas centrales (5-7, aproximadamente 300 tokens), y carga dinámicamente herramientas adicionales a medida que la conversación revela qué se necesita. Si el usuario pregunta sobre consultas de base de datos, carga las herramientas SQL. Si pregunta sobre despliegue, carga las herramientas de infraestructura. La gran mayoría de las interacciones usarán menos del 10% de las herramientas disponibles, así que los ahorros son sustanciales.

Resumen agresivo. Cuando una subtarea se completa — un archivo ha sido analizado, una consulta ha sido ejecutada, un bloque de código ha sido generado — el contexto completo de esa subtarea raramente importa para lo que viene después. Lo que importa es el resultado: un resumen de 2-3 oraciones de lo que se hizo, lo que se encontró y lo que significa. Reemplazar 2,000 tokens de contexto detallado de subtarea con un resumen de 50 tokens es una reducción del 97.5% en ese segmento. A lo largo de una conversación larga con muchas subtareas, esta es la diferencia entre agotamiento de contexto a las 50 interacciones y rendimiento sostenido a lo largo de 500.

Descarga al sistema de archivos. No todo necesita vivir en la ventana de contexto. Resultados intermedios, estructuras de datos grandes, bloques de código generados, salidas de análisis — todo esto puede escribirse a disco y leerse de vuelta solo cuando se necesite. La ventana de contexto se convierte en un registro de trabajo, no un medio de almacenamiento. Este es el mismo principio que hace que la memoria virtual funcione en sistemas operativos: mantienes los datos calientes en almacenamiento rápido (contexto) y paginas los datos fríos a almacenamiento más lento (sistema de archivos) donde pueden recuperarse bajo demanda.

Ventanas de contexto streaming. El historial de conversación crece linealmente por defecto. Cada intercambio — mensaje del usuario más respuesta del modelo — se suma al contexto. Después de 30 intercambios, podrías tener 15,000 tokens de historial, la mayoría de los cuales es irrelevante para la pregunta actual. Una ventana de contexto streaming implementa una ventana deslizante sobre el historial de conversación: mantén los últimos 10 intercambios textuales, comprime los intercambios 11-30 en resúmenes, y descarta todo lo más antiguo. El modelo obtiene recencia y continuidad sin el crecimiento de costo lineal.

DeerFlow (gio-moros/deer-flow) implementa estos patrones a nivel de framework para orquestación multi-agente. Su arquitectura usa carga progresiva de habilidades para mantener el contexto de cada sub-agente liviano, resumen agresivo al pasar resultados entre agentes, y descarga al sistema de archivos para artefactos intermedios. El orquestador mantiene un modelo del mundo comprimido — un resumen en ejecución de lo que cada agente ha hecho y encontrado — en lugar de reenviar contexto completo entre etapas. El resultado es un sistema multi-agente donde el tamaño del contexto escala logarítmicamente con la complejidad de la tarea, no linealmente.

El efecto compuesto de las cuatro estrategias es dramático. En nuestros sistemas de producción, la ingeniería de contexto reduce los tokens promedio por interacción en un 60-70% comparado con una implementación ingenua. Combinado con compresión de salida y cascada de modelos, la reducción total se acerca al 90%. Eso no es teórico — está medido en millones de interacciones de producción. Y el impacto en rendimiento es positivo, no negativo, porque un contexto más liviano significa que el modelo se enfoca en lo relevante en lugar de buscar a través de miles de tokens de ruido.

El foso de la eficiencia

Alejémonos de los detalles técnicos y hablemos de lo que la eficiencia de tokens significa estratégicamente. Porque el argumento a favor de la eficiencia no es solo "ahorrar dinero". Es "construir cosas que tus competidores no pueden".

Un producto eficiente en tokens sirve a más usuarios al mismo costo de infraestructura. Eso suena obvio, pero las implicaciones son profundas. Si tu competidor gasta $0.10 por interacción y tú gastas $0.01, puedes ofrecer diez veces más interacciones de IA por usuario al mismo costo — o el mismo número de interacciones a una décima parte del precio. En un mercado donde las features de IA se están comoditizando rápidamente, la capacidad de ofrecer más IA por menos dinero es la ventaja sostenible. No el acceso a modelos. No los fosos de datos. Economías unitarias.

La eficiencia también desbloquea casos de uso que son económicamente imposibles para competidores menos eficientes. Considera una feature que requiere 50 interacciones de IA por usuario por día — algo como un asistente de código siempre activo que monitorea tu trabajo, sugiere mejoras y detecta errores en tiempo real. A $0.10 por interacción, esa feature cuesta $5 por usuario por día — $150 por mes. Ningún producto de consumo puede justificar eso. A $0.01 por interacción, cuesta $15 por mes. Eso es un nivel de suscripción viable. La feature no cambió. El modelo no cambió. La arquitectura sí. La eficiencia de tokens no optimizó un producto existente — hizo posible un nuevo producto.

El paralelo con la computación en la nube es instructivo. AWS no ganó las guerras del cloud porque tenían los servidores más grandes. Google tenía servidores más grandes. Microsoft tenía más relaciones empresariales. AWS ganó porque se obsesionaron con las economías unitarias: costo por hora de cómputo, costo por gigabyte de almacenamiento, costo por solicitud de red. Redujeron esos costos implacablemente, y esa eficiencia les permitió fijar precios por debajo de los competidores mientras mantenían márgenes. Las empresas que invirtieron en eficiencia operacional temprano obtuvieron una ventaja que se compuso durante años. La misma dinámica se está desarrollando en IA ahora mismo.

Hay un efecto flywheel en juego. Los productos eficientes en tokens atraen más usuarios porque pueden ofrecer más valor a precios más bajos. Más usuarios generan más datos de uso. Más datos de uso permiten mejores clasificadores de enrutamiento, estimadores de complejidad más precisos y heurísticas de compresión más efectivas. Mejor eficiencia permite precios aún más bajos y features más ricas. La brecha se compone. Para cuando un competidor se da cuenta de que necesita optimizar su economía de tokens, la empresa eficiente tiene tres años de datos de producción impulsando sus modelos de optimización. Ese es el foso.

Esto no es especulación. Ya estamos viendo la divergencia en la práctica. Los equipos que tratan el gasto de tokens como un costo fijo — algo determinado por los precios del proveedor del modelo — chocan con un techo. Sus features de IA se limitan a interacciones de alto valor y baja frecuencia porque cualquier otra cosa no es económica. Los equipos que tratan el gasto de tokens como una variable de ingeniería — algo que optimizan activamente a través de compresión, cascadas e ingeniería de contexto — están construyendo productos con IA tejida en cada interacción, cada flujo de trabajo, cada superficie. El primer grupo tiene features de IA. El segundo grupo tiene productos de IA. El mercado está decidiendo quién gana.

Lo que viene

La próxima generación de productos de IA no vendrá de quien tenga acceso al modelo más grande. El acceso a modelos fundacionales ya se está comoditizando — cada proveedor principal ofrece capacidades comparables, y la brecha entre el mejor y el segundo mejor se reduce con cada ciclo de lanzamiento. El diferenciador no será el modelo. Será el sistema alrededor del modelo: cómo se presupuestan los tokens, cómo se gestiona el contexto, cómo se toman las decisiones de enrutamiento, cómo se comprime la salida.

Las herramientas y patrones que hemos cubierto — compresión de salida con Caveman, cascada de modelos con routers de complejidad, ingeniería de contexto con carga progresiva y resumen agresivo, coordinación multi-agente con DeerFlow — no son técnicas exóticas. Son fundamentos de ingeniería aplicados a un nuevo dominio. La misma disciplina que nos llevó a optimizar consultas de base de datos, comprimir payloads de red y cachear resultados computados ahora necesita aplicarse al gasto de tokens de IA. Los equipos que hagan esto bien no solo ahorrarán dinero. Construirán productos que son fundamentalmente imposibles de igualar para competidores menos eficientes.

La eficiencia de tokens no es una optimización de costos. Es la estrategia de producto. Las empresas que entiendan esto lanzarán productos de IA a precios que parecen irracionales para sus competidores — hasta que esos competidores se den cuenta de que la brecha es demasiado grande para cerrar.