HarnessRouter, un proyecto de código abierto bajo licencia Apache 2.0, propone el Unified Harness Protocol (UHP), una interfaz HTTP común para enviar tareas a entornos de agentes como Codex, Claude Code o Hermes y recibir de vuelta el progreso, los archivos y el resultado con el mismo formato. Detrás está Epsilla, una startup de Y Combinator. La idea es que un producto pueda cambiar de motor de agentes, o comparar varios, modificando un identificador en la petición en lugar de reescribir toda la integración.
Las claves de UHP y HarnessRouter en 30 segundos
- UHP define cómo una aplicación crea tareas, sigue su progreso, gestiona sesiones, archivos, cancelaciones y errores ante cualquier entorno de agentes.
- HarnessRouter es el servidor de referencia, autoalojable con Docker, y su repositorio enumera 26 entornos base.
- Las cifras de ahorro proceden de una única prueba sintética del propio proyecto.
- La adopción por Qoder, de Alibaba, la anuncia Epsilla, no Alibaba.
El proyecto ha ganado visibilidad esta semana gracias a un hilo y un artículo largo del divulgador Akshay en X, que lo presenta como la llegada de una «Harness Engineering 2.0», una expresión suya. Su texto explica el problema de fondo y muestra cómo instalar el servidor y lanzar una tarea, aunque también pide al lector que dé una estrella al repositorio y no aclara si tiene alguna relación con el proyecto. Este artículo contrasta sus datos con el repositorio, la especificación y la web de HarnessRouter.
Enrutar el motor del agente, no solo el modelo
En el vocabulario actual de la IA, un harness es el entorno completo de un agente: el bucle que planifica, llama a herramientas, edita archivos, ejecuta comandos y decide cuándo ha terminado. Codex, Claude Code, Gemini CLI, Hermes u OpenCode son ejemplos. Dos de ellos pueden usar modelos parecidos y comportarse de forma distinta por sus instrucciones, sus herramientas, la gestión del contexto o los permisos, algo que ya analizamos al explicar por qué el harness pesa más que el prompt y, a veces, que el modelo.
El artículo de Akshay distingue entre enrutar modelos y enrutar harnesses. Elegir el modelo que responde a cada petición, por precio, latencia o disponibilidad, se hace en la capa de inferencia y deja intacto el bucle del agente. Cambiar de harness, en cambio, supone cambiar el entorno que planifica, usa herramientas y gestiona el espacio de trabajo, y cada uno tiene su propio formato de tareas, de eventos y de sesiones. Integrar un segundo harness obliga a repetir el trabajo de traducir progreso, archivos, cancelaciones y errores.
UHP se presenta como una pieza más de una cadena de protocolos: MCP conectó a los modelos con herramientas y datos, A2A abordó la comunicación entre agentes, y UHP pretende normalizar la relación entre una aplicación y el entorno que ejecuta la tarea completa. A diferencia de MCP o A2A, por ahora no tiene detrás a varias grandes empresas: según su propia documentación de gobierno, UHP se mantiene en el repositorio de HarnessRouter con un modelo dirigido por sus mantenedores, en el que cada cambio debe llegar a la vez a la especificación, la implementación de referencia y las pruebas de conformidad.
Cómo funciona el protocolo
UHP define un contrato HTTP con forma parecida a la Responses API de OpenAI. La aplicación crea una tarea con POST /v1/responses e indica la entrada, el modelo y el identificador del harness configurado en el campo metadata.harness_id. Cada respuesta corresponde a una tarea; una sesión agrupa respuestas que comparten conversación y directorio de trabajo, y las tareas de seguimiento usan previous_response_id para continuar en la misma sesión. El progreso llega por Server-Sent Events (SSE), con eventos numerados de texto, uso de herramientas, archivos y estado.
Un harness configurado combina un harness base con un modelo por defecto, instrucciones, skills, herramientas y servidores MCP. Los archivos pequeños viajan en la petición y los grandes se suben aparte; lo que genera el agente queda como artefactos descargables. El protocolo no unifica el comportamiento de los agentes: cada uno sigue eligiendo su plan, sus herramientas y su forma de trabajar. Tampoco permite reanudar en Claude Code una sesión empezada en Codex; para pasar el trabajo hay que abrir otra sesión y entregarle el contexto, como a otro desarrollador.
La especificación se publica con esquema OpenAPI 3.1, definiciones JSON Schema y un conjunto de pruebas de conformidad. El artículo de Akshay cita la versión 2026-09-12, pero la web del protocolo muestra ya la 2026-10-19, y su registro de cambios recoge versiones intermedias del 4 de octubre y actualizaciones del conjunto de pruebas hasta el 3 de noviembre.
HarnessRouter: el servidor y sus límites
HarnessRouter es la implementación de referencia. Su Community Edition se instala con una imagen de Docker que incluye una consola web, una pasarela que atiende la API de UHP y un ejecutor que lanza los harnesses en espacios de trabajo por sesión. Necesita unos 4 GB de disco y una clave de un proveedor de modelos. El ejemplo básico es este:
docker run -d --name harnessrouter
-p 127.0.0.1:3000:3000
-v harnessrouter:/data
harnessrouter/harnessrouterLa consola arranca con usuario y contraseña harnessrouter, y el propio README pide cambiarlos de inmediato y mantener la instancia en local hasta hacerlo. Una vez creada una clave de API, una aplicación solo tiene que cambiar el valor de harness_id (por ejemplo, de codex a hermes) para enviar la misma tarea a otro motor.
Sobre cuántos harnesses admite hay varias cifras. El README del repositorio habla de 26 bases, entre ellas Codex, Claude Code, Hermes, Pi, DeepSeek Harness, OpenCode, Gemini CLI, Aider, OpenHands y Qoder Cloud Agent. La web del proyecto y el mensaje de Akshay dicen 30. Y en la consola de la edición comunitaria, según el propio Akshay, aparecen 11 integrados, el resto se configura a partir de esas bases. La empresa ofrece también una versión gestionada, HarnessRouter Cloud, que ejecuta cada tarea en entornos aislados.
La documentación es clara sobre las limitaciones de la versión autoalojada. Las sesiones se separan con usuarios del sistema operativo y espacios de trabajo distintos, pero no con contenedores independientes. El ocultado de secretos protege los registros guardados, aunque un agente puede leer y transmitir cualquier valor al que tenga acceso, así que las credenciales de los proveedores deben quedar fuera de su alcance. Para exponer el servidor fuera de la propia máquina hace falta TLS y los controles de la especificación de seguridad.
Las cifras de ahorro, con matices
El mensaje viral asegura que, según pruebas oficiales, cambiar solo el harness con el mismo modelo redujo el coste entre un 25 % y un 64 % en varias tareas de cumplimiento sanitario, y que la diferencia entre la configuración más cara y la más barata llegó al 99,8 %. La página de pruebas de HarnessRouter describe algo más acotado: un único experimento controlado con datos sintéticos, llamado Care Prep, con ocho combinaciones de Codex, Claude Code y Hermes y cuatro modelos, y cinco ejecuciones por configuración.
En esa prueba, el coste fue de 0,47 créditos con Hermes y gpt-5.2 a 223 créditos con Claude Code y claude-opus-4.8, lo que sí cuadra con el 99,8 %. Pero el propio proyecto atribuye la mayor parte de esa distancia al nivel del modelo. Con el modelo fijo, cambiar solo el harness multiplicó el coste entre 1,5 y 2,1 veces, lo que equivale a ahorros de entre un 32 % y un 53 % aproximadamente según las cifras publicadas, no del 25 % al 64 %. La propia página advierte que es «one controlled test, not a universal ranking» y que su indicador de calidad no es una validación clínica. Para medir cargas propias, la web ofrece Harness Arena, que lanza la misma tarea en varias combinaciones y compara tiempo, coste y precisión.
También hay que matizar la adopción por Qoder, el entorno de programación con agentes de Alibaba. La anuncia Epsilla; el blog de Fondo, que cubrió el lanzamiento el 15 de octubre, precisa que esa afirmación procede de la empresa, y este medio no ha encontrado confirmación de Alibaba ni de Qoder. Lo que sí aparece en el repositorio es Qoder Cloud Agent como una de las bases soportadas.
Para equipos que construyen productos sobre agentes, la propuesta resuelve un problema real, el de mantener una integración distinta por cada motor, y lo hace con un código y una especificación abiertos que se pueden revisar. Su recorrido como estándar dependerá de que otros fabricantes de harnesses lo implementen por su cuenta, algo que por ahora no ha ocurrido de forma verificable. En noticias.ai ya vimos un caso de esa fragmentación con DeepSeek Harness y su puente para Claude Code.
Preguntas frecuentes
¿Qué es UHP, el Unified Harness Protocol?
Es una especificación abierta, con licencia Apache 2.0, que define cómo una aplicación envía tareas a un entorno de agentes y recibe su progreso, archivos, errores y resultado con un formato común. Su versión actual es la 2026-10-19.
¿Quién está detrás de HarnessRouter?
La startup Epsilla, de Y Combinator, con Kuanze Ma y Richard Song como cofundadores. Mantiene tanto el servidor de código abierto como la propia especificación UHP.
¿Qué agentes se pueden usar con HarnessRouter?
Su repositorio enumera 26 bases, entre ellas Codex, Claude Code, Hermes, Pi, DeepSeek Harness, OpenCode, Gemini CLI, Aider, OpenHands y Qoder Cloud Agent. La web del proyecto habla de 30.
¿Cambiar de harness reduce el coste?
En la única prueba publicada por el proyecto, con el mismo modelo, cambiar de harness alteró el coste entre 1,5 y 2,1 veces. El propio HarnessRouter advierte que es un test controlado y no una clasificación universal.
Fuentes:
- HarnessRouter en GitHub
- Unified Harness Protocol: especificación, gobierno y registro de cambios
- HarnessRouter: prueba Care Prep
- Y Combinator: lanzamiento de HarnessRouter
- Fondo: HarnessRouter gives agent backends a shared protocol, with Qoder support (15/10/2026)
- Akshay, «Run Any Agent Harness Under One Interface», artículo en X
