Presupuestos de tokens: un patrón de UX para el gasto en IA de código

Pide a un asistente de código que inspeccione un repositorio y la parte costosa es la lectura. En una prueba con un monorepo Java que cubre cuatro escenarios, el enfoque bulk-reader de Portal de Spotify ahorró aproximadamente el 90 % de los tokens que Claude Code habría consumido en lecturas directas de archivos.

La mayoría de las herramientas de IA para código tratan el uso de tokens como un número oculto. El contador aparece después del hecho, o no aparece en absoluto, de modo que el usuario solo conoce el costo cuando llega la factura. La acción costosa suele ser la que el usuario menos comprende.

Los presupuestos de tokens son una función de UX. Deciden qué hace primero el asistente, qué solicita en segundo lugar y qué puede ver el usuario antes de que llegue la factura.

Hacer visible el costo antes de la acción

Un presupuesto de tokens funciona como un indicador de combustible, no como una multa. Si la interfaz oculta la ruta costosa, dirige sin consentimiento. El usuario necesita ver qué solicitud consumirá una gran cantidad de contexto, cuál se completará con poca y cuál puede evitarse.

La transparencia de costos es una etiqueta clara cerca de la acción: esta lectura añadirá una gran carga de contexto. El usuario debe poder elegir una ruta más económica sin leer una tabla de precios. La gestión del contexto pertenece antes de la respuesta amplia, porque es en la respuesta amplia donde crece el gasto.

Las cifras no son hipotéticas. Un cuarto de los líderes de ingeniería gastan, según se informa, entre $200 y $500 por desarrollador al mes en tokens, y algunos gastan, según se informa, mucho más de $2,000. Para 2028, los costos de IA para código se proyectan por encima del salario medio de un desarrollador. Un presupuesto debe estar en la interfaz cuando el gasto ya es real.

Usar el paso determinista económico por defecto

La objeción más fuerte es que los pasos económicos se sienten como un recorte. Los usuarios quieren que el asistente lea el archivo completo, comprenda el repositorio y responda en un solo paso. Si la herramienta bloquea esa ruta, puede sentirse como un castigo.

La respuesta es hacer que la ruta económica sea el valor por defecto, no el plan B. El hook check-file-size del plugin shunt bloquea las llamadas Read de Claude Code cuando un archivo supera el umbral por defecto de 350 líneas y dirige a Claude a usar la skill /bulk-reader. El usuario sigue obteniendo la respuesta, pero la herramienta gasta tokens en un resumen o una pregunta acotada en lugar de en texto sin procesar.

Los pasos deterministas económicos también necesitan un presupuesto de modelo. Los ejemplos de bulk-reader y code-writer del autor usan Gemini 2.5 Flash como modelo de trabajo, mientras que el campo model de Portal puede aceptar otros modelos configurados. La elección de modelo debe permanecer visible, pero la ruta más económica debe ejecutarse primero.

La delegación también necesita un presupuesto de tiempo. Las respuestas de delegación de Portal generalmente tardan entre 10 y 30 segundos, y una sola invocación de Portal tiene un límite de 30 segundos. Un buen patrón de UX divide el trabajo grande en llamadas más pequeñas, muestra la división y permite al usuario detenerse antes de que comience la siguiente llamada.

Hacer legible el ahorro

Los ahorros solo son útiles cuando son legibles. Un descuento oculto no genera confianza. La interfaz debe mostrar lo que se evitó, no solo lo que se gastó. Cuando el ahorro es visible, el asistente deja de ser una caja negra y se convierte en una herramienta con un costo conocido.

La visualización tiene tres partes, en orden:

• Exponer los costos de contexto: la vista previa muestra la carga de contexto antes de la acción.
• Usar pasos deterministas económicos por defecto: el valor por defecto ejecuta primero la lectura acotada o el resumen.
• Hacer legibles los ahorros: el recibo indica qué se ahorró y por qué.

La visualización debe ser lo suficientemente pequeña para leerse mientras el usuario trabaja. No debe requerir una página de configuración, un panel financiero ni un informe separado. El usuario debe ver la consecuencia de costo donde se elige la acción. La visualización debe actualizarse después de la acción y mostrar la unidad, como tokens, para que el usuario pueda comparar acciones.

El recibo es la capa de confianza. Le dice al usuario que la herramienta eligió una ruta más económica, no solo una factura más pequeña. El usuario puede entonces decidir si mantiene el valor por defecto o lo anula.