Você não precisa escolher entre Claude Code e Codex: HarnessRouter executa os dois, e mais oito harnesses, atrás de uma única API em um contêiner Docker com suas próprias chaves. É software livre sob Apache 2.0 e roda na sua infraestrutura.
Já vi muita infraestrutura sendo vendida como „padrão aberto‟. O reflexo que isso me provocou me parece digno de explicar, porque aqui a engenharia é melhor que a governança, e um CIO precisa avaliar as duas coisas separadamente.
Claude Code ou Codex?
A pergunta está mal colocada, e essa é precisamente a tese do produto.
Claude Code e Codex não são intercambiáveis. Cada um tem seu loop de execução, suas ferramentas, sua semântica de erros e seu calendário de versões. Se seu produto incorpora um, você herda tudo isso. A resposta habitual é escolher o melhor e viver com a decisão por anos.
HarnessRouter propõe o contrário: executa os dois e muda conforme a tarefa. O projeto publica uma comparativa de oito combinações de harness e modelo sobre uma mesma tarefa gravada, com uma economia de até 99,8% em custo e uma melhoria de 3,2× em velocidade.
Convém ler essas cifras com cuidado, e o próprio projeto avisa: são dados autorrelatados, provêm de uma única tarefa gravada, e os dois números são comparações separadas entre extremos, não um mesmo resultado. O que demonstram não é que mudar de harness vai economizar 99,8%. O que demonstram é que a diferença entre a forma mais barata e a mais cara de executar uma mesma tarefa é enorme, e que hoje você toma essa decisão às cegas.
Esse é o argumento real. Não „qual é melhor‟, mas „por que você está pagando o preço de uma escolha que nunca mediu‟.
O que é HarnessRouter?
Um harness é a camada ao redor do modelo que o converte em agente: o loop, as ferramentas, o espaço de trabalho e o estado da sessão. Claude Code é um harness. Codex é outro.
HarnessRouter coloca uma única interface na frente de todos eles. A Community Edition empacota o Console, o Gateway e o Runner em uma única implantação Docker e implementa o Unified Harness Protocol (UHP), cuja superfície de tarefas é deliberadamente compatível com a API de Responses do OpenAI. Isso significa que os SDKs, os parsers de streaming e os componentes de interface que você já usa com Responses funcionam contra ele.
Vem de Epsilla (YC S23) e foi lançado publicamente em 17 de agosto de 2026.
Como se instala?
Você precisa de Docker, uns 4 GB de disco e uma chave de API de algum provedor de modelos. Não vem com modelo incluído nem chave de teste.
docker run -d --name harnessrouter \
-p 127.0.0.1:3000:3000 \
-v harnessrouter:/data \
harnessrouter/harnessrouter
Na primeira inicialização, instala os CLIs dos harnesses no volume. Aguarde ver [harnessrouter] ready on :3000 em docker logs -f harnessrouter, abra http://localhost:3000 e faça login com harnessrouter / harnessrouter.
Essas credenciais padrão são reais, e o contêiner registra um aviso enquanto permanecerem ativas. Altere-as em Profile, ou defina-as ao iniciar:
docker run -e HR_AUTH_USER=seu-usuario -e HR_AUTH_PASSWORD=a-chave-que-escolher ...
Mantenha o link para loopback (127.0.0.1:3000:3000) até ter feito isso. Um detalhe documentado que convém conhecer antes de escrever um manifesto de implantação: não adicione --user. O entrypoint e o Runner precisam de root para gerenciar os usuários de cada sessão.
Quais harnesses ele realmente executa?
O conjunto padrão são dez:
docker run -e HR_BACKENDS=claude,codex,hermes,pi,dsh,opencode,qwen,gemini,cline,omp ...
Os backends são instalados no volume de dados e não na imagem, então isso é um ajuste em tempo de execução: -e HR_BACKENDS=opencode deixa você com uma instância mínima. Se um backend falhar ao ser instalado, não é fatal, simplesmente não aparece no catálogo do console.
Os CLIs de cada agente são instalados sob suas licenças originais respectivas e não são redistribuídos dentro da imagem.
Como você o conecta ao seu próprio backend?
Esta é a parte que importa se você está construindo um produto e não apenas avaliando uma ferramenta. Crie uma chave de API em /keys e chame o endpoint compatível com Responses, selecionando o harness com 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
}'
As continuações mantêm a sessão com previous_response_id, e "stream": true retorna server-sent events.
Aqui há três credenciais com três funções distintas, e confundi-las é o primeiro erro que todo mundo vai cometer: a senha do Console é para a pessoa que usa o navegador, a chave do provedor é a que HarnessRouter usa para chamar o modelo, e a chave de API de HarnessRouter é a que seu backend apresenta.
Quanto custa?
HarnessRouter Community Edition não custa nada: é Apache 2.0 e você o executa em sua própria máquina.
O que você pagará são os modelos, e os paga diretamente ao provedor com sua própria chave, por uso. Não há intermediação, não há créditos, não há assinatura do produto. Isso muda a estrutura do gasto mais do que parece: você passa de uma taxa fixa por assento para um custo variável que pode medir por tarefa, e que pode otimizar escolhendo a combinação correta de harness e modelo para cada trabalho.
É aí que a comparativa de que falávamos no início deixa de ser marketing e começa a ser orçamento.
É realmente código aberto?
Em sua maior parte sim, e as exceções merecem ser mencionadas.
A Community Edition é Apache 2.0, e isso cobre a implementação de referência, os esquemas legíveis por máquina e a suite de conformidade. Os Starter Kits — Slides, Sheets, Dashboards e Videos — vivem em um repositório separado com termos de licença diferentes. HarnessRouter Cloud é a oferta comercial gerenciada, que executa o mesmo contrato de API em sandboxes serverless isoladas.
E depois está a cláusula que eu gostaria que todo arquiteto lesse antes de padronizar sobre isso: Apache 2.0 concede direitos sobre o código e sobre a especificação, mas explicitamente não sobre o nome do protocolo. „Unified Harness Protocol‟ e „UHP‟ são marcas registradas de HarnessRouter. Você pode dizer que seu produto „funciona com‟ UHP; você só pode afirmar que o implementa se passar sua suite de conformidade.
UHP é um padrão ou o protocolo de uma empresa?
A resposta honesta, no momento da publicação desta nota, é que é o segundo, governado com uma disciplina pouco comum.
A governança é liderada por mantenedores e sempre parte de uma proposta. As mudanças entram como UHP Enhancement Proposals, os mantenedores respondem em um prazo de dez dias úteis com aceito / precisa de trabalho / rejeitado com motivos, e nada é integrado se a especificação, a implementação de referência e um teste de conformidade não avançarem no mesmo pull request. Essa última regra — „uma frase da especificação que nada faz cumprir é um desejo‟ — é melhor disciplina que a de muitos organismos de padronização corporativos.
Também não há órgão certificador, nem taxa, nem programa de logos. A suite está no repositório e qualquer um pode executá-la contra o servidor de qualquer um, incluindo o seu:
pip install -e protocol/conformance
uhp-conformance --base-url https://seu-servidor --api-key "$KEY" --class full
A execução de conformidade registrada pela própria implementação de referência, datada de 4 de setembro de 2026, passou nas 64 verificações em classe Full sem falhas nem omissões, contra a suite 2026.8.11.post1 e a versão de protocolo 2026-08-11. O projeto esclarece sem rodeios que se trata de uma medição datada e não de uma reexecução a cada versão posterior.Resumindo: manutenção de um único provedor, nome registrado como marca e ausência de órgão independente, mas com uma especificação pública e versionada, um conjunto de conformidade executável e uma declaração explícita de que o padrão pode ser implementado sem HarnessRouter Cloud, porque é um contrato HTTP e nada nele requer um serviço gerenciado.
Essa combinação é defensável. Não é o mesmo que um padrão multiator, e eu gostaria de vê-lo escrito assim em qualquer registro de decisão de arquitetura que o adote.
O que realmente isola o self-hosting?
Leia isto antes de concluir que auto-hospedado significa contenção.
As sessões obtêm espaços de trabalho separados e usuários do sistema operacional separados, não contêineres separados. O Console é a única porta publicada; o Gateway (8080) e o Runner (8081) escutam no loopback dentro do contêiner. O entrypoint define HR_SANDBOX_TRUST=owner, cuja justificativa documentada é que você é dono da máquina, do agente e da chave, então a chave é entregue diretamente ao agente em vez de ser intermediada.
É um design coerente para uma máquina própria e uma carga de trabalho em que você confia. Não é um limite de isolamento multilocatário, e você não deveria tratá-lo como tal.
Consequências práticas:
- Define
HR_SECRET_KEYpara que as cadeias de conexão salvas sejam criptografadas em repouso, e mantenha a mesma chave entre reinicializações. - Use uma conta de banco de dados somente leitura para o kit de Dashboards.
- Coloque TLS na frente via proxy reverso antes de expô-lo em uma URL pública.
- Os espaços de trabalho inativos são recuperados de acordo com
HR_WORKSPACE_TTL_HOURS, 72 por padrão, e são reidratados a partir do seu checkpoint.0os preserva para sempre.
A CE além disso desativa completamente a telemetria de produto do Console, o que é uma concessão real e incomum.
Você deveria adotá-lo?
Se você está lançando recursos de agente dentro de um produto e não quer vincular seu backend ao CLI de um único provedor, essa é a abstração mais credível que vi até agora, e o custo de avaliá-la é um docker run.
Se você é um desenvolvedor individual escolhendo um agente de código para si, resolve um problema que você não tem. Os próprios fundadores disseram no Hacker News quando lhes perguntaram por que alguém rotearia entre vários harnesses: o valor aparece quando você empacota agentes como infraestrutura de produto para seus usuários finais. Aquele thread, no momento de escrever esta nota, acumulava uns discretos 10 pontos e 14 comentários: o tração está no GitHub e no lançamento de YC, ainda não em um arraste orgânico de comunidade.
O que eu observaria é a fronteira do open core. Uma empresa jovem, com um tier cloud comercial, um nome de protocolo registrado e manutenção em solitário tem todos os incentivos para mover essa linha mais adiante. Nada em sua conduta até agora sugere que pretenda fazê-lo. Ainda assim, deixe por escrito de que lado da linha cada dependência cai.
Relacionado: Como conectar todos seus coding agents com OmniRoute