Baseten Grid pregunta cuánto cuesta terminar una tarea de programación

Un agente de programación prepara un cambio limpio para una prueba que falla. El cambio no supera la integración continua, así que el desarrollador le pide que lo intente de nuevo. El segundo intento modifica más partes del repositorio y la persona que revisa el parche dedica media hora a algo que debía llevar cinco minutos. ¿Qué modelo salió más barato?

El 4 de noviembre, Baseten presentó Grid en vista previa pública. Reúne una puerta de acceso a modelos autorizados, un enrutador y controles centralizados de uso y protección. El servicio puede interponerse entre las herramientas de programación compatibles y sus modelos, de modo que un equipo aplique las mismas reglas a todas las solicitudes. Su página de acceso anticipado dirige a los equipos a una lista de espera.

El denominador cambia la lectura del coste

Coste por tarea aceptada. Ilustración original de Telli.sh.

El precio por token mide una unidad de uso del modelo. Un equipo tiene que entregar un cambio que cumpla sus criterios de aceptación. Una solicitud puede generar una respuesta y una ejecución puede producir un diff, pero la tarea aún puede estar incompleta. Contabilizar esos hechos por separado hace útil un experimento de enrutamiento.

Supón que dos rutas reciben 100 tareas parecidas cada una. La ruta más económica gasta 50 dólares en todos sus intentos y completa 50 tareas aceptables. La otra gasta 90 dólares y completa 90. En este ejemplo, ambas gastan un dólar en uso del modelo por resultado aceptado. Al sumar el tiempo de revisión humana, los cargos de herramientas y la espera de los reintentos, la comparación puede cambiar en cualquier dirección.

Incluye los fallos en el numerador. Una ruta que abandona las solicitudes difíciles puede parecer eficiente si desaparece el coste de los intentos abandonados. Mantén también la misma definición de éxito. Para un cambio de documentación, un diff aprobado quizá baste. Una migración necesita pruebas con los datos existentes y una forma de revertir el cambio.

El tipo de trabajo importa. Una migración de API en todo el repositorio puede resultar difícil por el contexto, la coordinación y la cantidad de cambios pequeños. Un parche de una línea puede resultar aún más complicado por un fallo de concurrencia difícil de detectar. El número de archivos y la longitud de la petición solo sirven de indicadores si predicen resultados en tu entorno.

El experimento del enrutador muestra una disyuntiva

Experimento de enrutamiento. Ilustración original de Telli.sh.

El informe técnico de Baseten compara el uso exclusivo de Opus 5.5 con el reparto de tareas entre ese modelo y GLM 5.3 Flash. En su combinación de tareas de DeepSWE, SWE Atlas QnA y Terminal-Bench, la empresa informa de un punto con un coste un 72 % menor y una tasa de éxito a menos de 0,8 puntos porcentuales de la obtenida al usar siempre Opus. El informe compara el enrutador con una asignación aleatoria de coste similar. Esto importa porque enviar más trabajo al modelo barato reduciría el coste medio incluso si la elección se hiciera al azar.

El umbral refleja cuánto vale pagar por la probabilidad de éxito esperada. Dar prioridad al coste puede enviar más tareas a la ruta barata. Otro ajuste puede favorecer al modelo más capaz cuando el resultado tiene más consecuencias. Los resultados de Baseten describen los modelos, tareas y supuestos de precios que eligió. Tu equipo tendrá otra combinación de trabajo y otros costes de fallo.

El anuncio del producto contiene una afirmación distinta y redondeada de hasta un 70 % menos de coste en pruebas iniciales. Separa esa afirmación del 72 % del experimento y de su comparación de tasas de éxito. El informe técnico muestra cómo varía el coste según la probabilidad de éxito. Un equipo puede elegir un punto acorde con sus prioridades y comprobar después si funciona en tareas reales.

Una puerta de acceso puede hacer visibles las reglas

El anuncio de Grid describe modelos autorizados, controles por equipo y visibilidad sobre el uso. Un equipo de plataforma puede dar acceso a los modelos que su organización ya ha evaluado y comprobar cómo se distribuye el uso. Esto ayuda a entender dónde gasta incluso antes de delegar la elección de ruta.

En la práctica hay varias decisiones. ¿Qué proveedor puede ver código propietario? ¿Qué modelo está autorizado para un repositorio concreto? ¿Qué equipo asume el coste de los reintentos? ¿Quién puede cambiar la ruta después de un incidente? Una puerta de acceso puede reunir esas decisiones en un punto común, siempre que quienes la administran entiendan qué abarca cada control.

La puerta de acceso a modelos y el entorno de ejecución del agente son puntos de control distintos. La primera puede decidir qué modelo recibe la solicitud. El entorno determina si el agente puede leer credenciales, escribir un archivo o realizar una llamada de red. Las restricciones de ruta son útiles si funcionan junto con esos permisos de ejecución. Una ruta económica necesita las mismas limitaciones para las herramientas con privilegios.

También importa la evidencia que se guarda. Los registros de enrutamiento pueden explicar por qué cambió el coste, pero también contener código, rutas y detalles de un incidente de cliente. Decide qué puede registrar la plataforma, quién puede verlo y cuánto tiempo puede conservarse. Una política que el desarrollador no puede consultar dificulta investigar por qué se rechazó una solicitud o acabó en una ruta inesperada.

Prueba el enrutamiento antes de cambiar la configuración predeterminada

1. Elige dos o tres grupos de tareas frecuentes. Incluye uno sencillo, como actualizaciones rutinarias de pruebas, y otro más difícil, como migraciones con requisitos de compatibilidad hacia atrás.
2. Define antes de empezar qué evidencia hace falta para aceptar el trabajo. Para una tarea de programación puede incluir una prueba de regresión aprobada, un diff limpio, el visto bueno de la persona que revisa y la comprobación de que no se tocaron archivos imprevistos.
3. Registra una referencia con el modelo predeterminado actual. Incluye los fallos, los reintentos y el trabajo que el desarrollador termina a mano. Conserva las restricciones de seguridad y datos aplicadas en producción.
4. Compara el enrutamiento en tareas equivalentes. Si tienes acceso, consulta las herramientas compatibles y sus permisos en la documentación oficial antes de conectar una cuenta.
5. Decide cuándo pasar a otro modelo. Si falla el primer intento, un segundo modelo puede ayudar. Un ciclo sin límite puede costar más que usar un modelo potente desde el principio. Fija un límite y anota por qué se cambió de modelo.
6. Conserva una forma de anular la elección para las tareas en las que un resultado erróneo tendría consecuencias graves. Después de la prueba, examina las excepciones junto con el coste total y las cifras de aceptación.

En un piloto interno puedes comparar un periodo en que los desarrolladores eligen modelos con otro en que funciona el enrutamiento, usando trabajo similar. El primer grupo puede aprovechar su conocimiento del repositorio. El segundo puede beneficiarse de reglas comunes y mayor visibilidad. Documenta las diferencias entre tareas para saber dónde ayuda la automatización y dónde sigue siendo útil el criterio humano.

Compara las mismas tareas en las mismas condiciones

Un mes de pull requests terminadas es un buen punto de partida. Etiqueta el trabajo según su petición inicial, como actualizar una dependencia, corregir un fallo con una prueba reproducible, hacer un cambio que cruza repositorios o investigar un despliegue fallido con una petición abierta. Guarda la revisión del repositorio y una comprobación de aceptación por tarea. Repite una muestra con una referencia estable y con el enrutador. Usa las mismas herramientas, límites de tiempo y entorno de pruebas en las dos ejecuciones.

Actualizar una dependencia es un caso poco ambiguo. La tarea se cumple si cambia la dependencia indicada, pasan las comprobaciones de compatibilidad y no se introducen cambios ajenos. Una tarea que toca un contrato de facturación requiere una revisión más estricta. También puede hacer falta que una persona interprete requisitos incompletos. Mantener visibles estas categorías permite entender de dónde sale el menor gasto medio. Si la ruta económica gana en las actualizaciones de dependencias, pero necesita varios intentos en cambios de facturación, el equipo puede asignarles rutas distintas.

Mide cuánto tarda una persona en decidir si el resultado es aceptable. Supón que la referencia produce 19 resultados aceptados de 20 por 19 dólares y que el enrutador entrega 18 aceptados por 9 dólares. En este ejemplo, el coste del modelo por resultado aceptado sería de 1,00 y 0,50 dólares. Si la revisión requiere 20 minutos adicionales para arreglar un fallo del enrutador, cambia la comparación. La organización puede tener en cuenta ese trabajo adicional manteniendo el tiempo y el dinero como medidas distintas.

Averigua con qué tareas aprendió el enrutador

El informe técnico de Baseten cita DeepSWE 1.1, SWE Atlas QnA y Terminal-Bench 2.1. El estudio compara Claude Opus 5.5 y GLM 5.3 Flash en distintas tareas, y evalúa el enrutador con datos reservados. Eso ayuda a decidir hasta dónde se pueden generalizar los resultados. Las preguntas para orientarse en el repositorio tienen un patrón de coste diferente del de las tareas que ejecutan una terminal, usan herramientas externas o modifican varios archivos. La evaluación del cliente debe representar las solicitudes que realmente espera enviar.

El informe describe Cost, Balanced e Intelligence como opciones por solicitud que desplazan el umbral de enrutamiento. Un equipo de producto puede utilizarlas en una comparación en paralelo. Compara los ajustes con un conjunto fijo de repeticiones autorizadas y anota el modelo elegido si tu integración lo muestra. Examina las discrepancias. Si las elecciones caras se concentran en casos difíciles o sensibles, es posible que la política aporte valor. Si se acumulan en una tarea simple y frecuente, puede convenir ajustar la clasificación de tareas o la política.

Examina los casos lentos y caros

La latencia media puede ocultar la espera de un parche difícil que pasó por varios modelos. Mide el tiempo transcurrido desde la petición hasta el resultado aceptado. Etiqueta cualquier reintento, cambio de modelo, tiempo agotado o traspaso. Un panel que solo muestra la respuesta del primer modelo puede indicar una mejora en una tarea que alguien tuvo que reiniciar. Incluye el coste y el tiempo después de cada traspaso.

Pon límites a la prueba antes de ampliarla. Fija un presupuesto para toda la tarea y una regla para detenerse o pasar a un modelo más capaz. Un intento fallido debe dejar evidencias suficientes para que el siguiente pueda continuar. Evita repetir pruebas o leer los mismos archivos solo porque el enrutador eligió otro modelo. La medida útil es cuánto avanzó el trabajo.

Para un despliegue, empieza por un grupo acotado con una regla de aceptación automática y excepciones que pueda examinar una persona. Añade luego un grupo cuya aceptación exija criterio. Compara por separado el coste por tarea aceptada, la proporción de cambios de modelo y el tiempo de revisión. Si la ventaja se mantiene, la organización tendrá una base más sólida para elegir el valor predeterminado.

Conserva una referencia útil cuando cambie un modelo

Un resultado obtenido una semana puede quedar desactualizado cuando cambia un modelo, una herramienta o un repositorio. Guarda el identificador del modelo, la revisión de prueba y las reglas de aceptación junto con la decisión de enrutamiento. Vuelve a ejecutar un conjunto pequeño de tareas representativas cuando cambie la política. Conserva algunos fallos caros en el conjunto, porque su coste tiende a desaparecer en los promedios.

Pide a una persona que revise un caso donde las rutas discrepan sin decirle qué modelo se eligió. Si no puede saber qué resultado es aceptable, afina la comprobación de aceptación antes de acumular más ejecuciones. Es más fácil comparar políticas cuando el equipo coincide en cómo reconocer un éxito.

La política debe evolucionar al mismo ritmo que el trabajo

El enrutamiento aporta valor cuando evita que el equipo repita la misma pequeña decisión. Es especialmente útil cuando rendimiento y precio pueden medirse para la misma unidad de trabajo. Con el tiempo cambiarán los modelos, los precios y el repositorio. Conserva las tareas de referencia y actualiza las pruebas para que la política pueda acompañar esos cambios.

La cifra que merece llegar a una reunión de planificación es lo que pagó el equipo por entregar trabajo aceptado, con las ventajas y costes bien identificados. Así, tanto quien dirige el trabajo técnico como quien gestiona el presupuesto pueden tomar una decisión.

Fuentes

• Anuncio de Baseten del 4 de noviembre sobre la vista previa de Grid
• Informe técnico de Baseten del 4 de noviembre sobre el enrutador

---

Para conservar un registro en el que puedas buscar las conversaciones y decisiones de tu trabajo, crea una cuenta de Telli.sh.