LegalOn recorta un 65% su gasto diario en Codex sin perder velocidad

LegalOn ha reducido un 65% su gasto diario estimado en Codex sin perder velocidad de desarrollo. Lo informa el blog de OpenAI. El titular del artículo habla de reducir «a la mitad», pero la cifra real es mayor: si el gasto cayó un 65%, la compañía paga ahora alrededor del 35% de la suma anterior, es decir, aproximadamente 2,9 veces menos.

Qué hizo exactamente

El resumen publicado menciona dos medidas. La primera: LegalOn asignó las tareas a las opciones Astra, Sol y Luna. La segunda: la compañía gestionó los presupuestos de forma estratégica. El fragmento disponible no aclara qué hay detrás de los nombres Astra, Sol y Luna (si son modelos distintos, modos o configuraciones) ni en qué se diferencian en precio y capacidades. Por eso no especularemos.

La lógica, en cambio, es clara y familiar para cualquiera que pague por tokens: el trabajo rutinario no hay por qué canalizarlo por la opción más cara. Las correcciones sencillas, la generación de código repetitivo y los refactorizados menores pueden ir a un nivel más barato, mientras que las decisiones de arquitectura complejas y los contextos de depuración enrevesados se reservan para la opción más cara y potente.

Cifras y datos clave

• Reducción del gasto diario estimado en Codex: 65%.
• Velocidad de desarrollo: se mantiene, pero la fuente no ofrece datos cuantitativos.
• Opciones utilizadas: tres, Astra, Sol y Luna.
• Enfoque: elegir la opción según el tipo de tarea, más gestión de presupuestos.
• Tipo de métrica: gasto diario estimado, no facturas confirmadas de un periodo.

Dónde conviene ser prudente con la cifra

La palabra «estimado» importa aquí. Se trata de un cálculo, no de un cierre contable, y mucho depende de la base de comparación elegida. Si antes todas las solicitudes pasaban por la opción más cara, un ahorro del 65% parece realista e incluso modesto. Si la base era un esquema ya parcialmente optimizado, el resultado es más notable.

La segunda cuestión es la velocidad. «Mantuvimos la velocidad de desarrollo» puede referirse al tiempo de ciclo desde la tarea hasta el merge, al número de tickets cerrados o a la valoración subjetiva del equipo. Sin una métrica ni un periodo de medición, la afirmación sigue siendo una declaración, no una prueba. Por ahora, la fuente no muestra ni el número de iteraciones de revisión ni la proporción de tareas que hubo que rehacer con una opción más potente. Y son precisamente esas repeticiones las que se comen el ahorro.

Por último, se desconoce la escala: un 65% de una suma pequeña y un 65% del presupuesto de un equipo grande no significan lo mismo.

Qué se puede aplicar

Esta experiencia se puede aprovechar sin conocer los detalles de LegalOn.

• Clasifique las tareas por complejidad. Empiece con tres cestas: corrección mecánica, funcionalidad típica y problema fuera de lo común. Para cada una, elija la opción mínima que sea suficiente.
• Calcule el coste de la tarea, no de la solicitud. Un modelo barato que necesita tres intentos puede salir más caro que un solo intento con uno potente.
• Fije presupuestos por equipos o flujos de trabajo y revíselos a diario. La granularidad diaria de la que habla LegalOn permite detectar un exceso de gasto antes de que acabe el mes.
• Mida la velocidad antes de optimizar. Sin una línea base, no podrá comprobar que se mantiene igual.
• Vigile la proporción de escaladas del nivel barato al caro. Si crece, el enrutamiento está mal configurado.

El caso de LegalOn muestra que el gasto en programación con IA se puede controlar igual de bien que las facturas de la nube. La imagen completa solo se podrá valorar cuando aparezcan los detalles: qué son Astra, Sol y Luna y cómo se midió la velocidad.