> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w30-model-harness-an-intelligent-routing-vision.md).

# W30-Model × Harness: una idea de enrutamiento inteligente

Hace poco leí el artículo de Databricks [Comparación de agentes de programación en el repositorio de varios millones de líneas de Databricks](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase).

Construye tareas de evaluación a partir de PR ya integrados en la empresa y compara distintos modelos y harnesses de agentes de programación sobre un repositorio real de varios millones de líneas. Su conclusión más relevante es que el propio harness cambia significativamente el resultado. La clasificación de los modelos resulta menos importante.

Databricks ejecutó tareas con el mismo modelo y el mismo nivel de esfuerzo de razonamiento mediante harnesses como Claude Code, Codex y Pi. En algunas comparaciones, la calidad era prácticamente igual, pero el costo difería en más del doble. Pi enviaba alrededor de un tercio del contexto en cada ronda, lo que le permitía completar las tareas con un conjunto de trabajo más pequeño y menos rondas.

Esto indica que solemos plantear mal una pregunta.

Siempre preguntamos qué modelo es mejor para programar. La unidad real de ejecución ya es un conjunto de configuraciones:

> model × harness × thinking effort × tools × policy

Aquí, el harness es el entorno de ejecución que sostiene el ciclo del agente. El modelo determina el techo de capacidad; el harness determina cómo comprende el repositorio, gestiona el contexto, llama a las herramientas, verifica los resultados y se detiene. El rendimiento final depende de la configuración completa.

### Un servicio que enrute entre configuraciones

Al terminar el artículo pensé en un servicio:

1. Evaluar continuamente las combinaciones más recientes de model × harness.
2. Identificar el tipo, la complejidad y el riesgo de las tareas que entran en el sistema.
3. Enrutarlas automáticamente hacia configuraciones óptimas de Pareto bajo restricciones de calidad, costo, latencia y riesgo.

Mantendría un mapa de rendimiento condicionado que cambia con el tiempo, en vez de una clasificación estática:

> Para cierto tipo de tarea, en un repositorio concreto y bajo ciertas restricciones, ¿qué configuración es la más adecuada?

La configuración A puede ser la mejor para modificar una feature flag; la B, para refactorizar entre módulos. La C puede tener una tasa de éxito unos pocos puntos porcentuales mayor, pero costar cinco veces más. No hay un campeón global, sino soluciones óptimas locales para distintas distribuciones de tareas.

Al recibir una tarea, el enrutador extrae primero algunas características: lenguajes y directorios afectados, alcance estimado del cambio, existencia de pruebas explícitas, cantidad de búsqueda de código necesaria, posibilidad de revertir y riesgo asociado a los permisos. Después elige una configuración de la frontera de Pareto vigente. Al terminar, los resultados de las pruebas, el retrabajo humano, el consumo de tokens, el tiempo de ejecución y las trazas de herramientas vuelven al sistema de evaluación.

Se forma así un ciclo cerrado:

> Conjunto privado de tareas → evaluación de combinaciones → identificación de tareas → enrutamiento entre configuraciones → resultados reales → actualización de la evaluación

### Tres piezas que ya existen

No es un territorio al que nadie se haya acercado. La mayoría de los productos actuales se ha detenido en distintas capas.

El primer grupo es el de los enrutadores de modelos.

[Not Diamond](https://docs.notdiamond.ai/docs/key-concepts) analiza la entrada y optimiza entre los modelos candidatos según calidad, costo o latencia con criterios de Pareto. [OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router) también elige el modelo según el tipo y la complejidad de la tarea. Not Diamond permite además entrenar enrutadores personalizados con datos de evaluación propios y ya ha anunciado Code Router, orientado a agentes de programación.

El objeto principal de decisión de estos productos sigue siendo el modelo. Not Diamond puede envolver modelos personalizados o flujos de agentes como endpoints candidatos, por lo que técnicamente permite llegar al enrutamiento de combinaciones por una vía indirecta. Pero todavía no trata el harness como una dimensión independiente, observable y evaluable de forma continua.

OpenRouter también va más allá de una pasarela de modelos corriente. Pareto Code Router actualiza sus niveles de calidad según benchmarks externos de programación. Auto Exacto ajusta el orden de los proveedores mediante el rendimiento en tiempo real, la tasa de éxito de las llamadas a herramientas y las evaluaciones internas. Ambos ya demuestran que las evaluaciones y las señales de producción pueden alimentar el enrutamiento, aunque todavía no conocen el repositorio ni el harness del cliente.

El segundo grupo es el de las plataformas de evaluación y observabilidad.

El posicionamiento público de [Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026) ya integra Gateway, experimentos, puntuación en producción, trazas de producción y enrutamiento en un mismo flujo. Los equipos pueden comparar modelos con tráfico real y ajustar la política de enrutamiento según precisión, costo y latencia.

Esto se acerca mucho al enrutamiento guiado por evaluación continua, pero su presentación pública sigue centrada en modelos y endpoints de modelos. Que los resultados de evaluación influyan en el enrutamiento no significa que el sistema actualice automáticamente su estrategia dentro del espacio de combinaciones model × harness.

El tercer grupo es el de las capas de control de harnesses.

[Omnigent](https://omnigent.ai/docs/build/harnesses) ofrece una capa unificada sobre harnesses como Claude Code, Codex, Cursor y Pi. Manteniendo el modelo, las herramientas y las políticas, basta cambiar una línea de configuración para sustituir el harness. También permite sobrescribir por separado el harness y el modelo durante la ejecución. Ya dispone de hooks de políticas para limitar los modelos caros según la complejidad de la tarea. La versión v0.5.0, publicada en julio de 2026, añadió enrutamiento inteligente en el que un routing judge elige el modelo según la tarea.

Por eso Omnigent es lo más cercano a esta idea. Ya permite sustituir, combinar y gobernar harnesses. Databricks cuenta además con un conjunto de evaluación basado en PR internos y datos reales de llamadas recopilados por Unity AI Gateway. Al final del artículo, Databricks anuncia explícitamente que más adelante presentará el enrutamiento inteligente de Unity AI Gateway y Omnigent.

Sin embargo, hasta ahora la implementación pública de enrutamiento inteligente de Omnigent sigue eligiendo el modelo dentro de un harness ya seleccionado. La documentación pública no muestra una selección automática por tarea entre Claude Code, Codex, Pi y otros harnesses. Tampoco muestra que esa selección se actualice de forma continua con benchmarks de PR. Los productos actuales presentan evaluación de combinaciones, abstracción del harness, identificación de complejidad, enrutamiento de modelos y una pasarela. Todavía no he visto un servicio independiente ofrecido al mercado que convierta directamente la evaluación continua de combinaciones sobre tareas privadas de una empresa en una política de enrutamiento automático de harnesses y modelos.

Sigue habiendo espacio, aunque es más estrecho de lo que parecía al principio.

### Lo realmente difícil es el sistema de evaluación

El algoritmo de enrutamiento quizá no sea la principal barrera competitiva. Lo difícil es obtener de forma continua comparaciones fiables.

#### 1. La evaluación debe pertenecer a un repositorio concreto

Los benchmarks públicos solo aportan información previa. No pueden tomar la decisión final por una empresa.

Databricks no utilizó directamente SWE-bench porque sus problemas públicos pueden haber entrado en los datos de entrenamiento y tampoco representan su repositorio interno, que contiene Scala, Go, Rust, Java, Python, Bazel y Protobuf. Extrajeron tareas de PR humanos integrados recientemente, ocultaron la implementación original y utilizaron las pruebas existentes para verificar el resultado del agente.

Por eso, un enrutador que aporte valor real no puede limitarse a vender una clasificación para todo el sector. Tiene que construir un mapa privado de rendimiento sobre el código, las pruebas, las normas de ingeniería y la distribución de tareas de cada empresa.

#### 2. El espacio de combinaciones crece deprisa

Diez modelos, cinco harnesses y tres niveles de esfuerzo de razonamiento ya producen ciento cincuenta configuraciones. Si añadimos distintos conjuntos de herramientas y políticas de contexto y permisos, probar todas las posibilidades pronto deja de ser viable.

El sistema necesita evaluar por etapas: descartar primero las configuraciones claramente inferiores con muestras pequeñas y concentrar después el presupuesto cerca de la frontera de Pareto. Cuando aparece un modelo o harness nuevo, unas pocas tareas de exploración deben estimar en qué rango de capacidad se sitúa. Esto se parece más al diseño de experimentos y a un contextual bandit que a una simple clasificación.

#### 3. La complejidad no es una etiqueta del prompt

Un cambio aparentemente sencillo puede volverse de alto riesgo por la propiedad del código, las dependencias o la falta de pruebas. La complejidad también puede variar durante la ejecución: al principio el agente solo tiene que modificar un archivo, pero al profundizar descubre que debe ajustar un protocolo y migrar datos.

El enrutamiento no puede limitarse a clasificar una vez al entrar. Necesita leer los metadatos del repositorio y permitir pasar a una configuración más capaz durante la ejecución. Un modelo barato puede explorar primero y entregar la tarea a uno más potente si descubre efectos entre módulos. Un harness ligero puede localizar el problema y cambiar a otro que gestione mejor el contexto cuando empiece una modificación larga.

Esto crea un nuevo problema: cómo conservar el estado útil al cambiar sin arrastrar también el ruido de contexto del harness anterior.

#### 4. La estrategia óptima exige pagar por explorar

Si todas las tareas de producción se envían al campeón actual, el sistema pierde pronto los datos de comparación. Las conclusiones anteriores también caducan cuando se actualizan los modelos, cambian los precios o evoluciona el harness.

Por eso, el enrutamiento continuo debe reservar una pequeña parte del tráfico para explorar, utilizando tareas canario o repeticiones sin conexión a producción para probar nuevas combinaciones. También debe distinguir las causas de fallo: falta de capacidad del modelo, mala gestión del contexto por el harness, herramientas no disponibles o un entorno de pruebas inestable. Estos problemas no pueden comprimirse en una sola puntuación.

Volver a ejecutar un benchmark de forma periódica es solo una parte de la evaluación continua. El sistema también debe mantener los datos actualizados, atribuir las causas de los fallos y controlar el riesgo de la exploración.

### Dónde estaría la barrera competitiva del producto

Las pasarelas y las API unificadas pueden volverse intercambiables con facilidad. El valor a largo plazo probablemente provenga de tres tipos de datos.

Primero, la distribución de tareas de cada empresa. Cuáles son frecuentes, cuáles son caras y qué fallos causan pérdidas reales.

Segundo, las trazas de ejecución de cada combinación. Cómo lee el contexto, llama a las herramientas, consume tokens y corrige errores un mismo modelo a través de distintos harnesses.

Tercero, los resultados finales. Si pasan las pruebas, si se acepta el PR, cuánto cambia una persona y si el código se revierte después de desplegarse.

Solo al conectar esos tres tipos de datos puede el enrutador entender qué significa realmente barato y eficaz. Optimiza el costo total desde que entra una tarea hasta que se acepta. El precio de una llamada a la API es solo una parte.

Esto también crea un ciclo de mejora impulsado por los datos. Cuanto más tiempo se usa el sistema, mejor comprende el repositorio y los hábitos de ingeniería de la empresa. Cuanto más preciso es el enrutamiento, más tareas le confía el equipo. Los nuevos resultados reales siguen mejorando el enrutamiento. Los modelos y los harnesses pueden sustituirse, pero los activos de evaluación y el historial de decisiones de la empresa permanecen en la capa de control.

### Una forma más realista de empezar

La primera versión del producto no debería asumir directamente todo el tráfico de los agentes de programación. Una vía más prudente sería empezar como sistema de decisión fuera de producción:

1. Conectar el repositorio y los PR integrados recientemente.
2. Generar automáticamente un conjunto privado de tareas verificables.
3. Volver a ejecutarlas periódicamente con unas pocas configuraciones de model × harness.
4. Producir una frontera de costo y calidad por tipo de tarea.
5. Empezar recomendando configuraciones y habilitar después el enrutamiento automático para tareas de bajo riesgo.
6. Calibrar el clasificador y el conjunto de evaluación con los resultados de las ejecuciones reales.

Así se pueden demostrar primero dos cosas: que existen diferencias estables entre las combinaciones y que el ahorro del enrutamiento basta para cubrir el costo de la evaluación.

Si esas dos condiciones no se cumplen, el enrutamiento automático solo añade complejidad. Si se cumplen, el sistema puede pasar gradualmente de herramienta de recomendación a plano de control.

### Mi juicio

Hay una necesidad real en esta dirección. Aumenta el número de modelos y las diferencias entre harnesses empiezan a afectar directamente al costo y la calidad. Sin embargo, las empresas siguen acostumbradas a fijar un modelo y un agente de programación por defecto para todas las tareas. Esa configuración estática probablemente desperdicia cómputo y deja algunas tareas en un nivel de capacidad inadecuado.

Databricks es hoy quien más se acerca al ciclo completo. Omnigent aporta la abstracción del harness; Unity AI Gateway, la entrada unificada y los datos de las llamadas; y los PR internos, el conjunto privado de evaluación. El siguiente paso anunciado en el artículo podría ser precisamente completar la conexión entre evaluación y enrutamiento.

La oportunidad para una empresa independiente no consiste en adelantarse con una clasificación de modelos más grande. Una posición más valiosa sería una capa de control de configuraciones de agentes neutral respecto a los proveedores: evaluar continuamente las tareas de cada empresa, tratar el harness como una dimensión enrutable y hacer elecciones explicables entre calidad, costo, latencia y riesgo.

La ventana existe, pero no permanecerá vacía mucho tiempo. Not Diamond puede extenderse a flujos de agentes; Braintrust puede automatizar más la conexión entre evaluación y Gateway; y Databricks puede convertir su sistema interno en producto. Un producto nuevo tiene que demostrar pronto algo más concreto:

> En repositorios empresariales reales, enrutar entre configuraciones cuesta menos que usar siempre el modelo más potente y el harness por defecto, sin reducir la calidad de la entrega final.

Si esto puede demostrarse de manera estable, la unidad de competencia entre agentes de programación volverá a subir un nivel. Los modelos y los harnesses seguirán siendo importantes, pero una mayor parte del valor recaerá en el sistema que elija continuamente la mejor combinación.

### Referencias

* [Comparación de agentes de programación en el repositorio de varios millones de líneas de Databricks](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)
* [Omnigent: harnesses](https://omnigent.ai/docs/build/harnesses)
* [Omnigent: políticas integradas](https://omnigent.ai/docs/policies/builtin)
* [Omnigent v0.5.0](https://omnigent.ai/releases/0.5.0)
* [Databricks: Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway)
* [Not Diamond: conceptos clave](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond: entrenar un enrutador personalizado](https://docs.notdiamond.ai/docs/router-training-quickstart)
* [OpenRouter: Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)
* [OpenRouter: Pareto Router](https://openrouter.ai/docs/guides/routing/routers/pareto-router)
* [OpenRouter: Auto Exacto](https://openrouter.ai/docs/guides/routing/auto-exacto)
* [Braintrust: los mejores enrutadores de LLM y plataformas de enrutamiento de modelos de 2026](https://www.braintrust.dev/articles/best-llm-routers-2026)