El costo de usar IA: no todo el trabajo necesita el modelo más caro
Usar inteligencia artificial puede ahorrar tiempo. Pero la factura no termina en la suscripción mensual.
Cada vez que una IA lee un texto, responde una pregunta o genera contenido, también consume recursos. Muchos servicios cobran por esa actividad.
Esos cobros suelen calcularse con tokens. Un token es un pequeño fragmento de texto. Una palabra puede tener uno o varios tokens, según su longitud.
La inferencia es el trabajo que hace el modelo cuando recibe información y produce una respuesta. Cuanto más texto lee y escribe, más tokens consume.
Por eso, un agente de IA puede resultar más caro de lo esperado. Un agente no hace una sola pregunta. Lee archivos, usa herramientas, escribe resultados y vuelve a leer información.
Los modelos más capaces suelen costar más por token. Así que la pregunta ya no es solo qué modelo responde mejor. También importa qué tarea merece usarlo.
Y aquí aparece el problema para quienes no somos una gran compañía con presupuesto para pagar cualquier factura: queremos aprovechar los modelos más capaces, pero no podemos usarlos para todo.
La propuesta de Spotify es una alternativa concreta para ahorrar. No hace falta copiarla al pie de la letra. También puede servir como una línea de trabajo para adaptar o imitar.
El costo crece con el uso
Gartner estima que, hacia 2028, el costo de programar con IA puede superar el salario promedio de un desarrollador.
El problema no es únicamente el precio de cada token. También influye la cantidad de información que recibe el modelo en cada consulta.
Un agente puede enviar archivos completos, historiales largos o partes innecesarias de un proyecto. Si nadie lo limita, cada consulta puede arrastrar mucha información.
Además, las empresas empiezan a pasar de pagar una licencia por persona a pagar según el consumo. La velocidad aumenta, pero también puede aumentar la factura.
Spotify cita un dato cercano: una cuarta parte de los líderes de ingeniería ya gasta entre 200 y 500 dólares por persona al mes en tokens. Algunos gastan más de 2.000 dólares.
Esto pide un cambio de criterio. No conviene enviar cada tarea al modelo más caro. Conviene reservarlo para el trabajo que necesita más juicio.
El caso de Spotify
En septiembre de 2026, el equipo de ingeniería de Spotify publicó una explicación de este problema.
Su propuesta no fue crear un modelo nuevo. Fue repartir el trabajo entre varios modelos, según la dificultad de cada tarea.
En sus pruebas, este cambio redujo cerca del 90% de los tokens que Claude Code gastaba al leer archivos.
Para entender la propuesta, primero hay que distinguir dos tipos de trabajo.
Leer y escribir no siempre requiere razonar
La mayor parte de las tareas de un agente de código no necesita una decisión compleja.
Por ejemplo, puede leer cinco archivos para contestar una pregunta sobre un método. También puede crear un archivo de pruebas siguiendo el mismo patrón que otros veinte.
En ambos casos, la tarea puede consumir miles de tokens. Sin embargo, el modelo no necesita descubrir una solución nueva. Solo debe reconocer un patrón y repetirlo.
Usar el modelo más caro para ese trabajo es como contratar a un arquitecto para imprimir y encuadernar documentos.
La idea de Spotify es sencilla: un modelo más costoso toma las decisiones importantes. Un modelo más barato lee, resume o escribe cuando las reglas ya están claras.
Un modelo de frontera es un modelo muy capaz, pensado para resolver problemas difíciles. En este artículo, “modelo caro” se refiere a ese tipo de modelo.
Dos modos para repartir el trabajo
Spotify resolvió el problema con AiKA Modes, una función de Portal by Spotify, su plataforma basada en Backstage.
Un modo es una receta para un agente. Indica qué instrucciones debe seguir, qué modelo debe usar y qué herramientas puede utilizar.
El agente trabaja en un entorno temporal. Por eso, Spotify no necesita mantener un servidor propio para cada tarea ni gestionar las claves de API de forma manual.
En los ejemplos, Spotify usa Gemini 2.5 Flash para las tareas repetitivas. El sistema también permite elegir otros modelos configurados en Portal.
bulk-reader
bulk-reader sirve para leer varios archivos grandes cuando solo se necesita una respuesta breve.
El modelo trabajador lee los archivos y responde con viñetas. No añade saludos ni explicaciones innecesarias.
Cada viñeta incluye datos que ayudan a encontrar el contenido original, como el nombre del archivo, el tipo de información o el número de línea.
Claude recibe el resumen, no todos los archivos. Así puede trabajar con la información necesaria sin pagar el costo de leer el conjunto completo.
code-writer
code-writer sirve para generar pruebas, código repetitivo o archivos basados en un patrón existente.
Recibe una descripción de la tarea y un archivo de referencia. Luego copia los nombres, las reglas y el estilo del proyecto.
También debe devolver solo código. Si añade explicaciones o formato adicional, Claude debe gastar más tokens para limpiarlo.
Una definición mínima se parece a esto:
name: code-writer
description: Boilerplate code generator - delegates output-heavy work from Claude Code
instructions: You generate code files based on a spec and reference files. Match the existing patterns, conventions, naming, and style exactly. Output only the code.
model: gemini-2.5-flash
resourceLimits:
temperature: 0.2El archivo de referencia es importante. Sin un ejemplo, el modelo barato puede inventar código que no respeta las reglas del proyecto.
Las instrucciones no siempre bastan
Al principio, Spotify puso las reglas en el archivo llamado CLAUDE.md. Claude podía leerlas y decidir cuándo usar Portal.
El resultado fue irregular. Las reglas funcionaban como una recomendación. Claude podía ignorarlas y leer los archivos directamente.
La solución actual es un plugin de Claude Code llamado shunt. Este plugin obliga a revisar ciertas lecturas antes de que lleguen al modelo caro.
El sistema tiene tres partes: ganchos, scripts y skills.
Capa 1: ganchos
Un gancho es una comprobación automática que se ejecuta antes de una acción. En este caso, revisa si Claude intenta leer un archivo grande.
Shunt registra dos ganchos de tipo PreToolUse.
check-file-size se ejecuta antes de cada Read. Si el archivo supera 350 líneas, bloquea la lectura completa y recomienda usar /bulk-reader.
Las lecturas pequeñas o dirigidas sí pasan. Por ejemplo, Claude puede pedir solo una sección concreta con un desplazamiento y un límite.
check-bash-read revisa los comandos del sistema cat, head, tail, less y more cuando se usan con archivos grandes.
Una búsqueda dirigida, como cat archivo | grep, sí pasa. En ese caso, Claude no necesita leer todo el archivo.
El tamaño mínimo se configura con SHUNT_MIN_LINES.
Capa 2: scripts
Los scripts son comandos que preparan las solicitudes para los modos de Spotify.
El script recibe los argumentos, envía la petición al modelo trabajador, limpia los errores y muestra el consumo de tokens.
bulk-read envuelve cada archivo en etiquetas XML y lo envía junto con la pregunta. La respuesta no se guarda en el servidor.
Si hace falta una segunda pregunta, los archivos se envían de nuevo al modelo barato. No vuelven a entrar en el contexto de Claude.
bulk-read --question "What does this service do?" --paths src/Service.java src/Handler.javacode-write envía una especificación y un archivo de referencia. Después elimina el formato Markdown y puede guardar el resultado directamente en disco.
Claude no necesita recibir el código generado. El script solo necesita un patrón que copiar.
code-write --spec "Write tests for UserService" --reference tests/OrderTest.java --target tests/UserTest.javaCapa 3: skills
Las skills son archivos Markdown que explican a Claude cuándo y cómo llamar a los scripts.
Cuando un gancho bloquea una lectura, el mensaje dirige a Claude hacia /bulk-reader y muestra la sintaxis correcta.
El gancho es la parte importante. Aunque Claude no lea la skill, la lectura costosa sigue bloqueada.
Qué midieron
Spotify hizo las pruebas con un monorepositorio de Java. Un monorepositorio es un proyecto que guarda varios componentes relacionados en un mismo repositorio.
Compararon dos situaciones: Claude leyendo los archivos completos y Claude recibiendo el resumen creado por bulk-reader.
El ahorro medio en las lecturas grandes fue de cerca del 90%.
El ahorro de la generación de código es más difícil de calcular. Sin shunt, Claude lee los archivos de referencia y genera todo el código.
Con shunt, el modelo barato genera el código y lo guarda en disco. Claude no necesita leer ese resultado.
| Tarea | Sin repartir el trabajo | Repartiendo el trabajo |
|---|---|---|
| Entender varios archivos grandes | El modelo caro recibe todos los archivos | Un modelo barato resume y Claude recibe viñetas |
| Generar pruebas con un patrón claro | Claude lee las referencias y escribe el código | El modelo barato escribe el código directamente en disco |
| Corregir un error que ocurre entre tareas simultáneas | Claude analiza el problema | No se delega |
| Editar una función concreta | Claude lee el archivo completo | Claude hace una lectura dirigida y aplica el cambio |
Qué no conviene delegar
Los límites de esta estrategia son tan importantes como el ahorro.
La edición no se delega. Un resumen no siempre contiene números de línea confiables. Si Claude debe cambiar un archivo, necesita leer la sección exacta antes de editarla.
Por eso, los ganchos permiten las lecturas dirigidas. El reparto ahorra tokens al entender el código, pero no al aplicar un cambio preciso.
El razonamiento difícil tampoco se delega. En las pruebas, el modelo trabajador reconoció patrones generales, pero no detectó un error sutil relacionado con tareas simultáneas.
Claude encontró el error cuando recibió el contexto correcto. Por eso, Spotify reserva el modelo más capaz para depuración, decisiones de arquitectura y código importante para la seguridad.
El tiempo de respuesta también importa. Cada delegación hace un viaje adicional por la red: pasa por Claude Code, Portal y el modelo trabajador antes de volver.
Las respuestas tardan entre 10 y 30 segundos. Portal cancela una invocación después de 30 segundos, así que una generación grande debe dividirse.
Este retraso puede compensar cuando se leen archivos grandes. En archivos pequeños, el desvío puede tardar más que una lectura directa.
Por eso existe un umbral de líneas. No todo archivo merece una delegación.
La idea principal
Lo más valioso de la propuesta de Spotify no es Portal, AiKA ni el plugin. Es el criterio para decidir qué modelo usar.
Durante un tiempo tratamos la información como si fuera un recurso ilimitado. Añadimos más archivos, más historial y ventanas de contexto más grandes.
Pero demasiada información puede confundir a un modelo. También puede aumentar la factura.
Un agente que lee más de lo necesario puede responder peor y costar más. Ese hábito se vuelve difícil de sostener cuando los modelos más capaces también suben de precio.
La estrategia de Spotify se puede aplicar sin usar su plataforma:
- Separar el trabajo que necesita criterio del trabajo repetitivo.
- Impedir que el modelo caro lea archivos enormes sin necesidad.
- Enviar el trabajo repetitivo a un modelo más barato.
- Dar instrucciones precisas sobre el formato de la respuesta.
- Devolver un resumen o un archivo terminado, no todo el material original.
- Reservar el modelo más capaz para depurar, decidir y editar código importante.
Este patrón no sirve solo para programar. También puede ayudar a resumir documentos, clasificar archivos, preparar borradores o traducir textos con un formato conocido.
La regla es la misma: usar un modelo con más capacidad cuando hay que decidir, y uno más barato cuando hay que procesar mucho volumen.
Los modos se pueden compartir y reutilizar. Puede existir uno para escribir documentación, otro para resumir revisiones y otro para traducir.
El plugin decide cuándo delegar. El modo decide cómo responder. Cambiar el modelo trabajador no obliga a cambiar todo el sistema.
Para un equipo pequeño, la solución puede ser un gancho, un script y un modelo local o económico. Para un equipo grande, puede ser una plataforma interna.
La herramienta cambia. El criterio no.
La velocidad de los agentes sigue siendo una ventaja. Pero esa ventaja pierde valor si cada tarea envía el proyecto completo al modelo más caro disponible.
Ideas principales
- Usar IA cuesta más que una suscripción. Cada lectura y respuesta también puede generar un cobro.
- Los agentes consumen muchos tokens al leer y escribir, no solo al tomar decisiones.
- Un modelo muy capaz no siempre es necesario para repetir un patrón conocido.
- Spotify redujo cerca del 90% de los tokens en sus pruebas de lectura masiva.
- Las instrucciones pueden ayudar, pero un gancho puede impedir una lectura innecesaria.
- La edición, la depuración y las decisiones importantes deben quedarse en manos del modelo más capaz.
- Una delegación puede tardar más que una lectura directa cuando el archivo es pequeño.
- El criterio se puede aplicar sin Portal: separar el trabajo que necesita juicio del trabajo que necesita volumen.
Recursos
- Artículo original: Portal by Spotify cut my Claude Code token usage by 90%, Spotify Engineering, 3 de septiembre de 2026.
- Plugin shunt y modos: spotify/portal-ai-plugins
- Documentación de AiKA Modes: Modes en Portal by Spotify
- Predicción citada: Gartner, 24 de junio de 2026