Tokenpocalypse: 4 palancas para bajar el costo de tus coding agents

Si el mes pasado firmaste el cheque de Claude Code o Cursor y te dolió, no estás solo. El 7 de agosto, Databricks publicó Managing AI Coding Costs at Scale (282 puntos en Hacker News, 235 comentarios) con un diagnóstico que ya estaban masticando varias empresas en silencio: el costo de los coding agents escala exponencial con el uso, no lineal. Y dos casos frontera confirmados por 404 Media con audio filtrado de Accenture: Uber quemó todo su presupuesto de IA en 4 meses y tuvo que capear el uso de Claude Code, y Accenture descubrió que los grandes quemadores de tokens no son los engineers, son los equipos no-técnicos convirtiendo PDFs a markdown en una especie de eutanasia corporativa del presupuesto.

Esto se conecta con lo que ya cubrimos en Permission fatigue en coding agents: la interfaz humana del agente está rota. Pero ese post era sobre seguridad. Hoy toca el otro lado, el bolsillo. Y la buena noticia es que las mitigaciones son técnicas, no políticas.

Por qué la curva es exponencial y no lineal

Si tuvieras un junior que cobra $5 por PR, probablemente le darías cada vez más tareas. Lo mismo pasa con Claude Code: el primer mes lo usás para autocompletar y refactors. El segundo mes le pedís tests. El tercer mes le pedís migrar un servicio entero. El cuarto mes le pedís que arme un feature flag system desde cero. El uso crece más rápido que la productividad que devuelve cada nuevo uso, porque las tareas más grandes son desproporcionadamente más costosas: más contexto, más iteraciones, más tokens de salida.

Databricks lo llama la "Efficiency Frontier": hay una curva de Pareto entre calidad y costo, y la mayoría de los equipos está operando bien arriba del punto donde un modelo más chico resolvería la tarea igual de bien. La analogía que usan en los comentarios de HN es útil: es como pagar Premium en una app de delivery cuando Free te alcanza. El problema es que con coding agents el "premium" no se ve hasta que llega la factura.

El otro multiplicador silencioso es la "session memory": Claude Code y Codex arrastran contexto de sesión, y los prompts de "followup" suelen incluir el diff completo de los últimos 5 turnos. Si tu sesión dura 2 horas, los últimos 20 minutos son 80% contexto reciclado, 20% trabajo nuevo. Es como pagar un consultor senior y hacer que relea sus propios memos antes de cada respuesta.

La foto real: cuánto gastan los devs hoy

Una de las cosas más interesantes de los comentarios de HN es el contraste entre quién gasta cuánto. Un dev anónimo de un startup con presupuesto ilimitado reporta $80 por día, con un flujo que incluye Fable 5 High para planning, Opus 5 para ejecutar, Codex Computer Use para QA, y thermonuclear review skill tres veces por cambio. Eso es $2.400 al mes en un solo developer. A escala de empresa eso se vuelve ridículo rápido.

Pero el dato más contraintuitivo viene del audio de Accenture filtrado a 404 Media: los engineers no son los que más gastan tokens. Son los equipos no-técnicos haciendo cosas triviales pero con contexto masivo. El ejemplo canónico que destapó el CTO de Accenture: convertir un PDF a imágenes y después a markdown para pasárselo al LLM. Un PDF de 50 páginas se convierte en un input de 100.000 tokens cuando un resumen estructurado serían 2.000. Multiplicá eso por 200 personas en la organización y la factura se explica sola.

La señal de alerta operativa: si tu gasto en coding agents creció 3x el último trimestre pero el output de tu equipo engineering no creció proporcionalmente, el problema no es la IA, es que el modelo se está usando en tareas donde el ROI es negativo.

Palanca 1: ruta de modelos, no un solo modelo

La primera palanca de Databricks y la más subestimada. La mayoría de los setups actuales tienen un solo modelo configurado: Claude Opus 5 para todo, o GPT-5.6 Sol para todo, o el que sea. Es como tener un auto deportivo para ir a buscar el pan. El truco es separar las tareas en dos o tres tiers de modelo:

• Tier 1 (barato y rápido): autocompletar, refactors mecánicos, generar tests a partir de una función existente. Modelos como GLM 5.2, Haiku 4.5, o GPT-5 Nano entran acá. Cuestan entre 1/20 y 1/50 del tier alto.
• Tier 2 (medio): implementar features nuevas a partir de specs claras, debuggear, escribir documentación. Acá caen Sonnet 4.5, GPT-5.6 Sol Medium, o Qwen 3 Max si confiás en open weights.
• Tier 3 (caro pero para cosas que valen la pena): decisiones arquitectónicas, refactors grandes, code review profundo donde la calidad importa más que la velocidad. Opus 5, Sol Ultra, Fable 5 High.

Un dev senior en HN lo dijo bien: "los modelos más fuertes son más token-efficient para tareas abiertas" porque resuelven a la primera y cometen menos errores, así que la iteración de corrección se evapora. Pero para tareas cerradas y bien especificadas, un modelo chico resuelve en un solo turno lo que Opus 5 resuelve en tres.

Palanca 2: reducir el overhead de tokens, no la inteligencia

Acá viene el consejo que más impacto operativo tiene y que menos se aplica. Databricks lo lista como "Cost Lever #4: Reducing Token Overhead", y los comentaristas de HN apuntan a herramientas concretas que viven en este espacio.

El truco es entender que tu coding agent está leyendo lo mismo muchas veces. Cada vez que le hacés un followup, el sistema le pasa el contexto de los últimos N turnos. Si esos turnos incluyen archivos completos de 500 líneas que ya no son relevantes, estás pagando por re-procesarlos. Las tres tácticas concretas:

• Compactación periódica de sesión. Cada 20-30 minutos, el agente debería resumir el estado de la sesión y empezar un contexto nuevo con el resumen. Claude Code tiene un comando /compact, Codex tiene compact, y los open agents lo implementan en hooks custom.
• Contexto estructurado en vez de archivos crudos. En vez de pegarle al LLM el código fuente completo, pasale una spec estructurada de qué hace cada módulo. Bajás 10x el input sin perder la información que el modelo necesita para razonar.
• Agentes mínimos que protegen la window. En los comentarios de HN nombran dos: pi y smol. Son coding agents minimalistas diseñados específicamente para mantener el contexto limpio. No son la opción para un workflow de 8 horas, pero para tareas quirúrgicas (debugging, refactor de un archivo) son significativamente más baratos.

Regla práctica: si tu prompt de input tiene más de 20.000 tokens, hay un 80% de probabilidad de que la mitad sea ruido. La compactación y la selección de contexto te devuelve ese dinero en cada llamada.

Palanca 3: AI Gateway como capa de control

Esta es la palanca "empresarial" pero se puede implementar a escala de equipo chico. Databricks la presenta como un design pattern, y Cloudflare OS (que cubrimos en cloudflare-os-plataforma-agentic-open-source) lo implementa como pieza central de su propuesta agentic.

La idea es poner un proxy entre tu equipo y los providers de LLM. En vez de que cada dev tenga su API key y le pegue directo a Anthropic o OpenAI, todas las requests pasan por un gateway que:

• Loggea por usuario, equipo y proyecto. Sabés quién gasta qué, no tenés que esperar la factura mensual del proveedor.
• Permite rate limits y budget caps por equipo. Si el equipo de marketing se pasó de rosca con los PDFs a markdown, podés capearlos sin bloquear al equipo de engineering.
• Cachea prompts idénticos. Si 5 devs le preguntan a Claude Code exactamente lo mismo (los templates de PR description son un caso clásico), el segundo al quinto sale gratis.
• Hace fallback automático a modelos más baratos cuando la tarea matchea ciertos criterios (autocompletar = nano, refactor = sonnet, etc).

La implementación de un gateway mínima se puede hacer con OpenRouter (que ya tiene un nivel de routing básico) o con Portkey o con el patrón AI Gateway de Cloudflare. No necesitás una plataforma entera; un script de 200 líneas con un middleware en tu editor y un Redis ya te da el 60% del valor.

Palanca 4: governance de qué se le pide al agente

La última palanca es la más cultural pero la que más ahorra. Es la contracara del permission fatigue: si los humanos aprueban cualquier cosa por cansancio, los agentes también ejecutan cualquier cosa por falta de scope. Y ahí es donde se van los tokens.

Las tres reglas concretas que extraje del cruce Databricks + Accenture + comentarios de HN:

• Scope explícito por sesión. Cuando arrancás una sesión de Claude Code, declarale el scope: "esta sesión es para refactorizar el módulo de autenticación, no vas a tocar tests ni dependencias". En Claude Code esto se hace con un mensaje inicial; en Codex con un AGENTS.md. Es tu auditoría barata contra el "un momentito que también aprovecho a..." que es donde se fuga el budget.
• Distinguir tareas de un solo turno de tareas multi-turno. Las primeras pueden ir a un modelo barato sin sesión persistente. Las segundas justifican Opus 5 pero con un /compact cada 30 minutos. Si no distinguís, todo va al tier caro y la factura explota.
• Educar a los no-engineers sobre el costo real. Accenture descubrió que sus equipos no-técnicos quemaban tokens en cosas que un script de Python resolvería. No es que sean vagos, es que no saben lo que cuesta cada llamada. Una comunicación interna de 1 página con "estas 5 operaciones cuestan X tokens, estas 5 cuestan Y" puede bajar la factura 30% sin tocar el setup técnico.

El elefante en la sala: la IA como commodity de costo

Hay un patrón en todos los casos confirmados: el gasto en IA escala más rápido que el valor que devuelve porque todavía la tratamos como recurso infinito. Y no lo es. La gráfica de adopción típica tiene tres fases: hype (gasto descontrolado), shock de factura (alguien se asusta con el número), y optimización (lo que estamos viviendo ahora).

La posición de Databricks es que la "Efficiency Frontier" no es un punto estático: se mueve constantemente porque los modelos mejoran y los precios bajan. Pero también se mueve el uso: cada nueva capacidad que el modelo gana habilita tareas nuevas que antes eran inviables, y esas tareas nuevas son las que revientan el budget.

La conclusión práctica para el día a día es que tenés que hacer lo que ya hacés con AWS o con un cluster de Kubernetes: medir, alertar, optimizar. Si tu equipo gasta más de N dólares al mes en coding agents y no sabe exactamente en qué, está volando a ciegas. El primer paso no es comprar una plataforma de observability, es exportar los logs de uso del provider, agruparlos por proyecto, y decidir qué tareas pueden bajar de tier.

Si te interesa la parte de seguridad que se cruza con esto (porque el permission fatigue también ahorra tokens: cada approve/deny errado es contexto quemado en prompts que no debieron lanzarse), el post Permission fatigue en coding agents cierra el loop. Y si querés ver el lado de la plataforma con governance ya integrada, Cloudflare OS: la plataforma agentic open source es el siguiente nivel de las cuatro palancas que cubrimos acá.

La tokenpocalypse no se resuelve con un button de "stop spending", se resuelve con las mismas prácticas que aprendiste optimizando cualquier infraestructura: el modelo correcto para la tarea correcta, el contexto correcto, la observación correcta, y el scope correcto. Cuatro palancas técnicas que ya tenés disponibles, solo falta sentarse a configurarlas.