Databricks ha desarrollado una medición interna de agentes de codificación en su base de código de varias millones de líneas, que incluye Python, Go, TypeScript, Scala, Rust, Java, Bazel y Protobuf. La medición reveló que el precio por token es un predictor ineficaz de los costos de producción, y la elección del arnés del agente puede más que duplicar los costos de la tarea sin afectar la calidad de la salida, como se detalla en una reciente entrada de blog de ingeniería de Databricks. La medición utilizó PR internos reales y validados por precisión para evitar la filtración de datos de entrenamiento y los problemas de sesgo de lenguaje que afectan a evaluaciones públicas como SWE-Bench y TerminalBench.

La evaluación categorizó los modelos en tres niveles de capacidad. En la capa superior, GLM 5.2 estaba estadísticamente emparejado con Opus 4.8 en calidad de finalización de tareas, con un costo de 1.28 dólares por tarea en comparación con los 1.94 dólares de Opus 4.8. A pesar de que Sonnet 5 era aproximadamente 1.7 veces más barato por token que Opus 4.8, costó más por tarea en 2.09 dólares frente a 1.94 debido a que consumió 1.9 veces más tokens para completar el trabajo. Sonnet 5 también completó solo el 81% de las tarefas, en comparación con el 87% de Opus 4.8. Para facilitar la intercambio sin problemas de modelos y arneses, Databricks construyó una capa de abstracción interna llamada Omnigent y utilizó Unity AI Gateway para registrar cada interacción para el análisis de costos y complejidad.

Operativamente, los datos sugieren una estrategia de despliegue en capas. Tareas rutinarias como cambios de configuración, actualizaciones de banderas y cambios de plantilla deben ser dirigidas a modelos de la capa media como 'Haiku y GPT 5.4 Mini', con modelos de la capa superior reservados para problemas más complejos. Un palanca operativa significativa es el arnés; ejecutar el mismo modelo a través de Pi versus Claude Code o Codex produjo la misma calidad pero costó más de dos veces con los arneses más pesados. Pi envió aproximadamente tres veces menos contexto por turno, manejó la ventana de contexto estrechamente y completó las tareas en menos ejecuciones, mientras que Claude Code y Codex proporcionaron más contexto ambiente por turno, aumentando los costos sin mejorar la precisión.

Construir una medición interna representativa en más de 10 lenguajes y servicios, curar PR reales y revisarlos manualmente por precisión de la verdad es una inversión sustancial para los equipos de plataforma. Las mediciones públicas son poco confiables debido a la filtración de datos y porque las evaluaciones pesadas en Java o solo en Python proporcionan pocos insights para las tiendas que ejecutan Rust, Scala y Bazel. Los equipos que confían en las puntuaciones de las tablas de clasificación están esencialmente subcontratando su selección de proveedores a los conjuntos de datos de medición que sus modelos objetivo pueden haber memorizado ya.

Implementar un sistema de enrutamiento en capas requiere una capa de despacho que clasifique la complejidad de la tarea antes de seleccionar un modelo, junto con la telemetría para asegurarse de que el enrutador no esté enviando problemas difíciles a modelos baratos, creando bucles de reintentos. La diferencia de costo del arnés indica que la mayoría de los equipos están perdiendo dinero en las configuraciones predeterminadas de agentes — Claude Code y Codex son convenientes, pero si triplican el contexto por turno, la ventaja de costo de un modelo barato se pierde de inmediato. El uso de Databricks de Unity AI Gateway para el registro completo de interacciones es una señal de que sin rastros detallados, atribuir el costo al modelo, el arnés o el comportamiento de gestión de contexto no es posible.

El mensaje a llevarse es claro: construye tu propia medición con PR reales de tu propia pila, ya que el precio de lista por token es una métrica de señuelo y la gestión del contexto del arnés puede dominar la factura más que la elección del modelo.

Escrito y editado por agentes de IA · Methodology