El 90% de tus tokens no necesita el modelo más caro

El 3 de septiembre, Dimitri Mazmanov —Principal Product Manager en Spotify— publicó en el blog de ingeniería de la compañía un artículo con un título deliberadamente concreto: «Portal by Spotify cut my Claude Code token usage by 90%». La idea que hay detrás es tan simple que da un poco de vergüenza no haberla aplicado antes: no todas las tareas que le pedís a una IA merecen el mismo modelo.

Buena parte de lo que consume un asistente de programación no es razonamiento. Es acarreo. Abrir cuarenta archivos para responder «¿dónde se configura esto?», resumir un módulo largo, generar un archivo de pruebas que copia un patrón que ya existe. Nada de eso exige el modelo más caro del mercado, pero por defecto todo eso pasa por el modelo más caro del mercado, y cada línea leída se paga.

Primero, por qué esto es un problema de presupuesto y no de ingeniería

Tres meses antes de ese artículo, Gartner publicó una proyección que conviene leer despacio: para 2028, el gasto en agentes de IA para desarrollo superará el salario promedio de un programador. No el costo de la herramienta: el salario de la persona.

El dato de hoy sostiene la proyección. Según la misma investigación, cerca de una cuarta parte de los líderes de tecnología ya gasta entre 200 y 500 dólares por desarrollador por mes solo en tokens. Nitish Tyagi, analista principal de Gartner, lo resume en una idea que debería estar pegada en la pared de todo comité de TI: sin un modelo operativo con gobernanza, los costos escalan más rápido que las ganancias de productividad que estas herramientas prometen entregar.

El cambio de fondo es de modelo comercial. Durante veinte años el software empresarial se presupuestó por asiento: sabías cuántas licencias tenías y cuánto costaba el año. La IA agéntica se factura por consumo, y el consumo lo determina el comportamiento diario de cada usuario. Es la diferencia entre alquilar una oficina y pagar la nafta: lo primero se firma una vez, lo segundo depende de cómo maneja cada uno.

Qué hizo Spotify, en castellano

Mazmanov montó un sistema de enrutamiento de modelos (model routing) sobre Portal, la plataforma interna de desarrollo de Spotify. El mecanismo tiene tres capas, y vale entenderlo porque lo interesante es la estructura, no la herramienta:

• Ganchos (hooks). Antes de que el asistente ejecute una acción, un control la intercepta. Si intenta leer un archivo de más de 350 líneas —umbral configurable—, la lectura se bloquea y se redirige.
• Guiones (scripts). Envuelven la tarea y la mandan al modelo barato con instrucciones estrictas de formato: viñetas estructuradas, sin saludos, sin prosa, sin preámbulos. Cada palabra de cortesía es un token facturado.
• Instrucciones (skills). Documentos que le explican al asistente cuándo conviene delegar.

Sobre esa base definió dos «modos» de trabajador: uno que lee y resume en volumen y otro que escribe código repetitivo siguiendo patrones que ya existen en el repositorio. Ambos corren sobre un modelo económico —Gemini 2.5 Flash— mientras el modelo de frontera queda reservado para lo que de verdad requiere criterio. El ahorro promedio medido en las lecturas masivas fue cercano al 90%.

La letra chica del 90%

Conviene ser preciso, porque el titular es más generoso que el cuerpo del artículo. El 90% es el ahorro promedio en una clase de operación —las lecturas masivas de archivos—, no el recorte de la factura total. Cuánto baja el gasto real depende de qué proporción de tu consumo sea acarreo y qué proporción sea razonamiento.

Ese matiz no debilita el caso: lo vuelve utilizable. La pregunta correcta para un gerente no es «¿cuánto ahorró Spotify?» sino «¿qué porcentaje de mi consumo es trabajo que no requiere el modelo caro?». En la mayoría de los equipos que vi, esa fracción es alta y nadie la midió nunca.

Lo que más me interesa: la regla se hace cumplir, no se sugiere

Hay un detalle de diseño que se lee al pasar y que a mí me parece el verdadero aporte. Las tres capas no son redundantes: son una escalera de obligatoriedad.

La capa de instrucciones le sugiere al asistente que delegue. La capa de ganchos le impide no hacerlo. El propio autor cuenta que el complemento que terminó usando reemplaza el enrutamiento voluntario —donde el modelo decide si le conviene— por bloqueos duros sobre las operaciones caras.

Una política que depende de que alguien se acuerde de cumplirla no es un control. Es una expectativa con nombre elegante.

Es exactamente lo mismo que discutimos en gobernanza de gastos, de accesos o de compras. Una política de viáticos que vive en un PDF genera un promedio; una que está codificada en el flujo de aprobación genera un límite. Con los costos de IA pasa igual: la distancia entre «recomendamos usar el modelo económico para tareas rutinarias» y «el sistema no te deja gastar de más en tareas rutinarias» es toda la diferencia.

Dónde no conviene delegar

El artículo es honesto con sus límites, y esa honestidad es lo que lo vuelve creíble. El enrutamiento se excluye deliberadamente en tres frentes:

• Edición de código. Los resúmenes del modelo barato no traen números de línea confiables; para modificar, el modelo principal tiene que leer directamente.
• Trabajo que depende de razonamiento. Los modelos trabajadores pasan por alto errores sutiles. Depuración, decisiones de arquitectura y revisión de código crítico para la seguridad quedan explícitamente fuera del enrutamiento.
• Tareas chicas. Cada delegación es un viaje de red de 10 a 30 segundos, con un tope de 30. Debajo del umbral de líneas, la demora cuesta más de lo que ahorra el token.

Ahí está el intercambio real: se cambia dinero por latencia y se acota el alcance a lo que no exige criterio. Es una decisión de ingeniería con forma de decisión de negocio, y por eso se toma con números y no con entusiasmo. Es el mismo razonamiento que planteé al comparar orquestación de agentes contra un solo agente: el esquema orquestador–trabajadores no es más elegante, es más barato, y solo mientras sepas qué tareas caen de cada lado.

Cómo se traduce esto a una empresa que no es Spotify

Nadie en Paraguay necesita construir una plataforma interna de agentes para aprovechar la idea. Lo que se transfiere es el criterio, y aplica igual si tu consumo de IA está en atención al cliente, en análisis de documentos o en el área de sistemas. En orden de retorno:

• Medí antes de optimizar. Pedí a tu proveedor o a tu equipo el consumo desagregado por caso de uso y por usuario, no la factura consolidada. Si no podés ver dónde se va el gasto, cualquier ahorro que declares después va a ser una anécdota.
• Clasificá el trabajo en dos niveles. Rutinario y predecible de un lado —resumir, extraer, clasificar, transcribir, generar formatos repetidos—; criterio, ambigüedad y riesgo del otro. La primera lista casi siempre es más larga de lo que el equipo supone.
• Poné el corte en el sistema, no en el instructivo. Límites de gasto por proyecto, alertas por umbral, modelo económico por defecto y el caro por excepción justificada. Que la opción barata sea la que ocurre sola.
• Escribí qué queda excluido. Decisiones con impacto legal, financiero o de seguridad no se enrutan al modelo barato ni se automatizan sin revisión humana. Definilo antes y por escrito, no cuando ya pasó algo.
• Exigí transparencia de consumo al contratar. Gartner señala que muchos proveedores no explican con claridad cómo se calcula y se factura el consumo, y eso impide pronosticar. Es una cláusula de contrato, no un detalle técnico: si no podés auditar el medidor, no podés controlar la cuenta.

Vale una advertencia de la que casi no se habla: el modelo más caro no siempre es el mejor para tu tarea, y el ranking cambia cada pocas semanas. Ya lo planteé al mirar cómo se mueve la carrera entre modelos — si tu arquitectura está atada a un proveedor, cada movimiento del mercado es un proyecto de migración en lugar de una línea de configuración. La conclusión con la que cierra el artículo de Spotify apunta justamente ahí: lo valioso es que enrutar deja de ser un problema de ingeniería de sistemas y pasa a ser un problema de configuración.

La conclusión ejecutiva no es que haya que gastar menos en IA. En muchos casos habrá que gastar más, porque el trabajo que habilita lo justifica. Es que el gasto en IA dejó de comportarse como una licencia y empezó a comportarse como consumo de energía: variable, sensible al hábito y silencioso hasta que llega la factura. Las empresas que lo traten como una partida a gobernar —con medición, umbrales y excepciones documentadas— van a poder sostener la inversión. Las que lo traten como una suscripción más se van a enterar del problema tres trimestres tarde.

Referencias

• Mazmanov, D. (3 de septiembre de 2026). «Portal by Spotify cut my Claude Code token usage by 90%». Spotify Engineering. — Fuente primaria del caso: la arquitectura de tres capas, los dos modos de trabajador, el umbral de 350 líneas, la latencia de 10 a 30 segundos y el ahorro medio del 90% en lecturas masivas.
• Gartner (24 de junio de 2026). «Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges». Comunicado de prensa. — Proyección a 2028, gasto actual de 200 a 500 dólares por desarrollador al mes en cerca de una cuarta parte de las organizaciones, y las declaraciones de Nitish Tyagi sobre gobernanza y transparencia de facturación.
• Torales, R. (4 de agosto de 2026). «Orquestación de agentes de IA: cuándo uno no alcanza y cuánto cuesta que sean varios». — Los cinco patrones de orquestación en producción y el punto de equilibrio entre suscripción y consumo por API.
• Torales, R. (23 de julio de 2026). «La carrera de la IA se acelera: Kimi K3, GPT-5.6 y Claude». — Por qué conviene diseñar arquitecturas independientes del modelo y decidir por costo por tarea.

Nota: las cifras de ahorro corresponden a la medición interna reportada por Spotify sobre su propio entorno y no constituyen un resultado garantizable en otros contextos. Este artículo es un análisis de gestión sobre gobernanza del costo de IA y no una recomendación de producto ni de proveedor.