Databricks recortó hasta un 90% el coste unitario de la IA para programar sin topes a sus mejores ingenieros

Databricks puso el modelo de frontera Astra a disposición de todos sus ingenieros, unas 3.500 personas. El modelo era claramente mejor en los problemas difíciles, como el diseño de sistemas. El gasto subió alrededor de un 60%, y en las tareas cotidianas, que los modelos anteriores ya resolvían, la mejora no era evidente.

Ese detalle, de una entrevista que Databricks publicó el 22 de octubre con su cofundador Patrick Wendell, es la cifra más útil de una historia contada casi toda en porcentajes. Muestra la forma del problema que afronta cualquier empresa que escala agentes de código: el modelo caro compensa para una parte del trabajo, y la mayor parte del trabajo no es esa parte.

Cómo se descontroló la factura

Wendell describe una secuencia conocida. Para vencer la reticencia de los ingenieros, Databricks eliminó todas las barreras: el modelo más caro, tokens sin límite. Entonces la adopción despegó. Como las herramientas de código se cobran ahora por consumo y no por licencia, una persona puede, en sus palabras, “lanzar un pequeño bucle con el modelo más caro e irse a comer”. Los costes crecieron de forma exponencial mientras los ingresos no, hasta amenazar con anular las mejoras de eficiencia que justificaban el despliegue.

La empresa afirma que hoy su gasto en tokens por persona es prácticamente estable mientras el uso sigue creciendo, y que en algunos casos su coste unitario bajó hasta un 90%. Son cifras internas de una empresa que vende la herramienta que usó, y el texto no define la unidad ni la base de comparación. Las palancas que hay detrás son más trasladables que las cifras.

Cuatro palancas, por orden de tamaño

Cambiar el modelo por defecto a uno más barato cuando sea suficientemente bueno. Wendell lo llama aburrido y dice que fue el mayor efecto, un 50% o más por sí solo. Llegan constantemente modelos nuevos y más baratos; el ahorro solo se produce si alguien los evalúa rápido sobre el código de la propia empresa y cambia el valor por defecto en un único sitio.

Enrutar por tarea. Renombrar un componente no requiere el modelo que diseña sistemas. Databricks dice que su enrutador reduce el coste medio por tarea en más de un 30% con una calidad cercana a la del modelo más caro, y que quita a los desarrolladores la carga de elegir.

Mostrar a cada persona su propio gasto. Un desglose personal periódico con sugerencias vale alrededor de un 10%, según Databricks. Wendell menciona otra empresa que imprime el modelo y su coste en cada pull request.

Reducir los tokens de sobra. El harness que rodea al modelo importa tanto como el modelo. En el benchmark interno de Databricks, el mismo modelo en dos harnesses distintos difería más de 2x en coste, y ajustar el harness y la caché ahorró cerca de un 50%. Coincide con lo que vimos cuando Asana redujo 76 veces el coste de su agente de navegador, casi todo antes de cambiar de modelo.

Los topes rígidos castigan a quien más quiere conservar

La parte de la entrevista que más merece copiarse trata de los límites. Un tope rígido de gasto es la primera reacción obvia, y Databricks concluyó que es una mala reacción. Interrumpe a la gente a mitad de tarea y le cuesta horas de trabajo. Quienes lo alcanzan suelen ser los mejores usuarios. Y algunos responden pasándose a una cuenta personal, donde la empresa ya no ve nada.

Databricks sustituyó el tope por una fricción que aumenta de forma gradual.

Del acceso libre al corte: dónde está hoy Databricks

Sin límite, el modelo más caroTope rígido

1. Donde empezóTodas las barreras eliminadas para impulsar la adopción
2. AvisoEl desarrollador ve el gasto
3. AprobaciónAlguien autoriza continuar
4. Rebaja de modeloEl trabajo sigue en un modelo más barato
5. CorteÚltimo recurso

Coincide con la posición que defendimos cuando las plataformas empezaron a lanzar límites de gasto en IA: los topes rígidos sirven para explorar, mientras que el uso en producción necesita presupuestos con alertas y un camino definido más allá del límite. La rebaja de modelo es el paso elegante. El desarrollador sigue trabajando; la empresa deja de pagar precio de frontera en esa sesión.

Precio por tarea, medido sobre su propio código

Dos hallazgos del benchmark interno de Databricks, construido con pull requests reales y corregido ejecutando las pruebas, no con un LLM como juez, deberían cambiar cómo comparan modelos los equipos:

• Un modelo abierto, GLM 5.2, empató en calidad con Opus 4.8 de Anthropic con un coste por tarea aproximadamente un tercio menor.
• Un modelo 1,7 veces más barato por token costó más por tarea, porque consumía más tokens.

El precio por token es un mal indicador del coste. La unidad que importa es el coste de un cambio aceptado, que es el argumento de nuestro marco para calcular la inferencia por tarea completada y de la idea de que el modelo más barato es aquel cuyos errores puede permitirse detectar. El benchmark de Databricks, corregido por pruebas, es una versión práctica de ambos.

La capa de control es la condición previa

Todas las palancas anteriores dependen de una cosa: que todo el tráfico de las herramientas de código pase por una única capa capaz de verlo y dirigirlo. Databricks enruta Claude Code, Codex, Cursor y sus propias herramientas a través de un único gateway, que más tarde convirtió en su producto Unity Gateway. El consejo de Wendell a un CTO es directo: “averigüe adónde va el dinero”. La mayoría de las empresas no sabe decir cuánto gasta en IA por equipo o por modelo.

Esa capa se está convirtiendo además en una cuestión contractual, ahora que OpenAI quiere aprobar los gateways que ofrecen sus modelos. El argumento de ingeniería para tener una no está en duda. Una empresa que no ve su tráfico de IA no puede enrutarlo, presupuestarlo ni cambiarlo, y seguirá pagando el Lamborghini para ir a la tienda de la esquina.