No tienes que elegir entre Claude Code y Codex: HarnessRouter ejecuta los dos, y ocho harnesses más, detrás de una sola API en un contenedor Docker con tus propias claves. Es software libre bajo Apache 2.0 y corre en tu infraestructura.
He visto mucha infraestructura venderse como “estándar abierto”. El reflejo que me provocó esta me parece digno de explicar, porque aquí la ingeniería es mejor que la gobernanza, y un CIO necesita evaluar las dos cosas por separado.
¿Claude Code o Codex?
La pregunta está mal planteada, y esa es precisamente la tesis del producto.
Claude Code y Codex no son intercambiables. Cada uno tiene su bucle de ejecución, sus herramientas, su semántica de errores y su calendario de versiones. Si tu producto incorpora uno, heredas todo eso. La respuesta habitual es elegir el mejor y vivir con la decisión durante años.
HarnessRouter propone lo contrario: ejecuta ambos y cambia según la tarea. El proyecto publica una comparativa de ocho combinaciones de harness y modelo sobre una misma tarea grabada, con un ahorro de hasta 99,8 % en costo y una mejora de 3,2× en velocidad.
Conviene leer esas cifras con cuidado, y el propio proyecto lo advierte: son datos autorreportados, provienen de una sola tarea grabada, y las dos cifras son comparaciones separadas entre extremos, no un mismo resultado. Lo que demuestran no es que cambiar de harness te ahorre un 99,8 %. Lo que demuestran es que la diferencia entre la forma más barata y la más cara de ejecutar una misma tarea es enorme, y que hoy esa decisión la tomas a ciegas.
Ese es el argumento real. No “cuál es mejor”, sino “por qué estás pagando el precio de una elección que nunca mediste”.
¿Qué es HarnessRouter?
Un harness es la capa alrededor del modelo que lo convierte en agente: el bucle, las herramientas, el espacio de trabajo y el estado de la sesión. Claude Code es un harness. Codex es otro.
HarnessRouter pone una sola interfaz delante de todos ellos. La Community Edition empaqueta la Consola, el Gateway y el Runner en un único despliegue Docker e implementa el Unified Harness Protocol (UHP), cuya superficie de tareas es deliberadamente compatible con la API de Responses de OpenAI. Eso significa que los SDK, los parsers de streaming y los componentes de interfaz que ya usas con Responses funcionan contra él.
Viene de Epsilla (YC S23) y se lanzó públicamente el 17 de agosto de 2026.
¿Cómo se instala?
Necesitas Docker, unos 4 GB de disco y una clave de API de algún proveedor de modelos. No trae modelo incluido ni clave de prueba.
docker run -d --name harnessrouter \
-p 127.0.0.1:3000:3000 \
-v harnessrouter:/data \
harnessrouter/harnessrouter
El primer arranque instala los CLI de los harnesses en el volumen. Espera a ver [harnessrouter] ready on :3000 en docker logs -f harnessrouter, abre http://localhost:3000 e inicia sesión con harnessrouter / harnessrouter.
Esas credenciales por defecto son reales, y el contenedor registra una advertencia mientras sigan activas. Cámbialas desde Profile, o defínelas al arrancar:
docker run -e HR_AUTH_USER=tu-usuario -e HR_AUTH_PASSWORD=la-clave-que-elijas ...
Mantén el enlace a loopback (127.0.0.1:3000:3000) hasta que lo hayas hecho. Un detalle documentado que conviene conocer antes de escribir un manifiesto de despliegue: no añadas --user. El entrypoint y el Runner necesitan root para gestionar los usuarios de cada sesión.
¿Qué harnesses ejecuta realmente?
El conjunto por defecto son diez:
docker run -e HR_BACKENDS=claude,codex,hermes,pi,dsh,opencode,qwen,gemini,cline,omp ...
Los backends se instalan en el volumen de datos y no en la imagen, así que esto es un ajuste en tiempo de ejecución: -e HR_BACKENDS=opencode te deja una instancia mínima. Que un backend falle al instalarse no es fatal, simplemente no aparece en el catálogo de la consola.
Los CLI de cada agente se instalan bajo sus propias licencias originales y no se redistribuyen dentro de la imagen.
¿Cómo lo conectas a tu propio backend?
Esta es la parte que importa si estás construyendo un producto y no solo evaluando una herramienta. Crea una clave de API en /keys y llama al endpoint compatible con Responses, seleccionando el harness con metadata.harness_id:
export HARNESSROUTER_BASE_URL=http://localhost:3000/api/harness
curl --fail-with-body -sS "$HARNESSROUTER_BASE_URL/v1/responses" \
-H "Authorization: Bearer ${HARNESSROUTER_API_KEY:?}" \
-H 'content-type: application/json' \
-d '{
"input":"Reply with exactly: it works.",
"metadata":{"harness_id":"codex"},
"model":"gpt-5.4-mini",
"stream":false
}'
Las continuaciones mantienen la sesión con previous_response_id, y "stream": true te devuelve server-sent events.
Aquí hay tres credenciales con tres funciones distintas, y confundirlas es el primer error que va a cometer todo el mundo: la contraseña de la Consola es para la persona que usa el navegador, la clave del proveedor es la que HarnessRouter usa para llamar al modelo, y la clave de API de HarnessRouter es la que presenta tu backend.
¿Cuánto cuesta?
HarnessRouter Community Edition no cuesta nada: es Apache 2.0 y lo ejecutas en tu propia máquina.
Lo que sí pagas son los modelos, y los pagas directamente al proveedor con tu propia clave, por uso. No hay intermediación, no hay créditos, no hay suscripción al producto. Esto cambia la estructura del gasto más de lo que parece: pasas de una cuota fija por asiento a un costo variable que puedes medir por tarea, y que puedes optimizar eligiendo la combinación de harness y modelo adecuada para cada trabajo.
Ahí es donde la comparativa de la que hablábamos al principio deja de ser marketing y empieza a ser presupuesto.
¿Es realmente open source?
En su mayor parte sí, y las excepciones merecen nombrarse.
La Community Edition es Apache 2.0, y eso cubre la implementación de referencia, los esquemas legibles por máquina y la suite de conformidad. Los Starter Kits —Slides, Sheets, Dashboards y Videos— viven en un repositorio aparte con términos de licencia distintos. HarnessRouter Cloud es la oferta comercial gestionada, que ejecuta el mismo contrato de API en sandboxes serverless aisladas.
Y después está la cláusula que yo querría que leyera cualquier arquitecto antes de estandarizar sobre esto: Apache 2.0 concede derechos sobre el código y sobre la especificación, pero explícitamente no sobre el nombre del protocolo. “Unified Harness Protocol” y “UHP” son marcas de HarnessRouter. Puedes decir que tu producto “funciona con” UHP; solo puedes afirmar que lo implementa si pasas su suite de conformidad.
¿UHP es un estándar o el protocolo de una empresa?
La respuesta honesta, al momento de publicar esta nota, es que es lo segundo, gobernado con una disciplina poco común.
La gobernanza es liderada por mantenedores y parte siempre de una propuesta. Los cambios entran como UHP Enhancement Proposals, los mantenedores responden en un plazo de diez días hábiles con aceptado / necesita trabajo / rechazado con motivos, y nada se integra si la especificación, la implementación de referencia y un test de conformidad no avanzan en el mismo pull request. Esa última regla —“una frase de la especificación que nada hace cumplir es un deseo”— es mejor disciplina que la de muchos organismos de estandarización corporativos.
Tampoco hay organismo certificador, ni cuota, ni programa de logos. La suite está en el repositorio y cualquiera puede ejecutarla contra el servidor de cualquiera, incluido el tuyo:
pip install -e protocol/conformance
uhp-conformance --base-url https://tu-servidor --api-key "$KEY" --class full
La ejecución de conformidad registrada por la propia implementación de referencia, fechada el 4 de septiembre de 2026, pasó las 64 comprobaciones en clase Full sin fallos ni omisiones, contra la suite 2026.8.11.post1 y la versión de protocolo 2026-08-11. El proyecto aclara sin rodeos que se trata de una medición fechada y no de una reejecución por cada versión posterior.
Resumiendo: mantenimiento de un solo proveedor, nombre registrado como marca y ausencia de organismo independiente, pero con una especificación pública y versionada, una suite de conformidad ejecutable y una declaración explícita de que el estándar puede implementarse sin HarnessRouter Cloud, porque es un contrato HTTP y nada en él exige un servicio gestionado.
Esa combinación es defendible. No es lo mismo que un estándar multiactor, y yo querría verlo escrito así en cualquier registro de decisión de arquitectura que lo adopte.
¿Qué aísla realmente el self-hosting?
Lee esto antes de concluir que autoalojado significa contenido.
Las sesiones obtienen espacios de trabajo separados y usuarios del sistema operativo separados, no contenedores separados. La Consola es el único puerto publicado; el Gateway (8080) y el Runner (8081) escuchan en loopback dentro del contenedor. El entrypoint fija HR_SANDBOX_TRUST=owner, cuya justificación documentada es que tú eres dueño de la máquina, del agente y de la clave, así que la clave se entrega directamente al agente en vez de intermediarse.
Es un diseño coherente para una máquina propia y una carga de trabajo en la que confías. No es una frontera de aislamiento multiinquilino, y no deberías tratarla como tal.
Consecuencias prácticas:
- Define
HR_SECRET_KEYpara que las cadenas de conexión guardadas se cifren en reposo, y mantén la misma clave entre reinicios. - Usa una cuenta de base de datos de solo lectura para el kit de Dashboards.
- Pon TLS delante mediante proxy inverso antes de exponerlo en una URL pública.
- Los espacios de trabajo inactivos se reclaman según
HR_WORKSPACE_TTL_HOURS, 72 por defecto, y se rehidratan desde su checkpoint.0los conserva para siempre.
La CE además desactiva por completo la telemetría de producto de la Consola, que es una concesión real y poco habitual.
¿Deberías adoptarlo?
Si estás lanzando funciones de agente dentro de un producto y no quieres casar tu backend con el CLI de un solo proveedor, esta es la abstracción más creíble que he visto hasta ahora, y el costo de evaluarla es un docker run.
Si eres un desarrollador individual eligiendo un agente de código para ti, resuelve un problema que no tienes. Los propios fundadores lo dijeron en Hacker News cuando les preguntaron por qué alguien enrutaría entre varios harnesses: el valor aparece cuando empaquetas agentes como infraestructura de producto para tus usuarios finales. Ese hilo, al momento de escribir esta nota, acumulaba unos discretos 10 puntos y 14 comentarios: la tracción está en GitHub y en el lanzamiento de YC, todavía no en un arrastre orgánico de comunidad.
Lo que yo vigilaría es la frontera del open core. Una empresa joven, con un tier cloud comercial, un nombre de protocolo registrado y mantenimiento en solitario tiene todos los incentivos para mover esa línea más adelante. Nada en su conducta hasta ahora sugiere que pretenda hacerlo. Aun así, deja por escrito de qué lado de la línea cae cada dependencia.
Relacionado: Cómo conectar todos tus coding agents con OmniRoute