> 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/pt-br/2026/w30-model-harness-an-intelligent-routing-vision.md).

# W30-Model × Harness: uma proposta de roteamento inteligente

Recentemente, li o artigo da Databricks [Avaliação de agentes de programação em uma base de milhões de linhas de código](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase).

O artigo constrói tarefas de avaliação a partir de PRs já integrados na empresa e compara diferentes modelos e harnesses de agentes de programação em uma base real com milhões de linhas. Sua conclusão mais relevante é que o próprio harness altera muito os resultados. A posição dos modelos no ranking acaba sendo menos importante.

A Databricks executou as tarefas com o mesmo modelo e o mesmo esforço de raciocínio, usando harnesses como Claude Code, Codex e Pi. Em algumas comparações, a qualidade era praticamente igual, mas o custo variava por um fator superior a dois. O Pi enviava cerca de um terço do contexto por rodada e, por isso, concluía as tarefas com um conjunto de trabalho menor e menos rodadas.

Isso mostra que costumamos fazer a pergunta errada.

Sempre perguntamos qual modelo programa melhor. A unidade real de execução já se tornou um conjunto de configurações:

> model × harness × thinking effort × tools × policy

Aqui, harness é o ambiente de execução que sustenta o ciclo do agente. O modelo define o teto de capacidade; o harness define como ele entende a base de código, administra o contexto, chama ferramentas, verifica resultados e encerra o trabalho. O desempenho final vem da configuração inteira.

### Um serviço de roteamento de configurações

Depois de ler o artigo, pensei em um serviço que:

1. Avalie continuamente as combinações mais recentes de model × harness;
2. Identifique o tipo, a complexidade e o risco das tarefas recebidas;
3. Encaminhe cada tarefa automaticamente à configuração ótima de Pareto, respeitando restrições de qualidade, custo, latência e risco.

Ele manteria um mapa de desempenho condicionado ao contexto, atualizado ao longo do tempo, em vez de um ranking estático:

> Para determinado tipo de tarefa, em determinada base de código e sob determinadas restrições, qual configuração é a mais adequada?

A configuração A pode ser a melhor para alterar uma feature flag; a B, para refatorar vários módulos; a C pode elevar a taxa de sucesso em apenas alguns pontos percentuais, custando cinco vezes mais. Não há um campeão global, apenas soluções localmente ótimas para diferentes distribuições de tarefas.

Ao receber uma tarefa, o roteador extrai um conjunto de características: linguagens e diretórios envolvidos, extensão estimada das alterações, existência de testes claros, volume de busca no código, possibilidade de reversão e risco das permissões. Em seguida, escolhe uma configuração na fronteira de Pareto válida naquele momento. Ao final, resultados de testes, retrabalho humano, consumo de tokens, tempo de execução e rastros de uso das ferramentas retornam ao sistema de avaliação.

Forma-se um ciclo fechado:

> Conjunto privado de tarefas → avaliação de combinações → identificação da tarefa → roteamento de configuração → resultado real → atualização da avaliação

### Três peças que já existem

Já há quem avance nessa direção, mas os produtos existentes costumam atuar em camadas diferentes.

A primeira categoria é a dos roteadores de modelos.

O [Not Diamond](https://docs.notdiamond.ai/docs/key-concepts) analisa a entrada e faz uma otimização de Pareto entre modelos candidatos por qualidade, custo ou latência. O [OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router) também escolhe modelos conforme o tipo e a complexidade da tarefa. O Not Diamond ainda permite treinar roteadores personalizados com dados de avaliação do usuário e já anunciou um Code Router para agentes de programação.

A decisão nativa desses produtos ainda gira principalmente em torno do modelo. O Not Diamond pode empacotar um modelo personalizado ou um fluxo com agentes como endpoint candidato, o que permite, tecnicamente, chegar ao roteamento de combinações. Mas ele ainda não trata o harness como uma dimensão de primeira classe, independente, observável e sujeita a avaliação contínua.

O OpenRouter também vai além de um gateway comum de modelos. O Pareto Code Router atualiza os níveis de qualidade a partir de benchmarks externos de programação, enquanto o Auto Exacto ajusta a ordem dos provedores com base em vazão em tempo real, sucesso das chamadas de ferramentas e avaliações internas. Eles já demonstraram que avaliações e sinais de produção podem alimentar o roteamento. Ainda não conhecem, porém, a base de código e o harness do próprio cliente.

A segunda categoria reúne plataformas de avaliação e observabilidade.

O posicionamento público do [Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026) já integra gateway, experimentos, pontuação em produção, rastros de produção e roteamento em um mesmo fluxo. Equipes podem comparar modelos no tráfego real e ajustar a política de roteamento segundo precisão, custo e latência.

Isso se aproxima bastante de um roteamento orientado por avaliações contínuas, mas a apresentação pública do produto ainda se concentra em modelos e seus endpoints. Permitir que avaliações influenciem o roteamento não significa que o sistema já atualize automaticamente suas políticas no espaço de combinações model × harness.

A terceira categoria é a camada de controle de harnesses.

O [Omnigent](https://omnigent.ai/docs/build/harnesses) oferece uma camada comum sobre Claude Code, Codex, Cursor, Pi e outros harnesses. Mantendo modelo, ferramentas e políticas, basta alterar uma linha de configuração para trocar o harness. Também é possível substituir separadamente o harness e o modelo durante a execução. Ele já tem hooks de política que restringem modelos caros conforme a complexidade da tarefa. A versão v0.5.0, lançada em julho de 2026, acrescentou roteamento inteligente em que um routing judge escolhe o modelo por tarefa.

Por isso, o Omnigent é o mais próximo dessa proposta. Ele já torna o harness substituível, combinável e governável. A Databricks também dispõe de um conjunto de avaliações baseado em PRs internos e de dados reais de chamadas coletados pelo Unity AI Gateway. No fim do artigo, a empresa anuncia explicitamente que abordará, em uma próxima publicação, o roteamento inteligente no Unity AI Gateway e no Omnigent.

Até agora, porém, o roteamento inteligente implementado publicamente no Omnigent ainda escolhe o modelo dentro de um harness já selecionado. A documentação pública não mostra uma seleção automática, por tarefa, entre Claude Code, Codex, Pi e outros harnesses, muito menos uma seleção atualizada continuamente por benchmarks de PRs. Os produtos existentes demonstram avaliação de combinações, abstração de harnesses, identificação de complexidade, roteamento de modelos e gateways. Ainda não encontrei um serviço independente, oferecido ao mercado, que transforme avaliações contínuas de combinações em tarefas privadas de empresas diretamente em políticas de roteamento automático de harnesses e modelos.

Ainda há espaço, mas seus limites são mais estreitos do que pareciam à primeira vista.

### A verdadeira dificuldade está no sistema de avaliação

O algoritmo de roteamento em si talvez não seja a principal barreira competitiva. A dificuldade está em obter, continuamente, comparações confiáveis.

#### 1. A avaliação precisa pertencer a uma base de código concreta

Benchmarks públicos fornecem apenas uma estimativa inicial. Não podem tomar a decisão final pela empresa.

A Databricks não usou diretamente o SWE-bench porque as questões públicas podem ter entrado nos dados de treinamento e não representam sua base interna, que inclui Scala, Go, Rust, Java, Python, Bazel e Protobuf. A equipe extraiu tarefas de PRs humanos integrados recentemente, ocultou a implementação original e usou os testes existentes para verificar os resultados dos agentes.

Um roteador realmente valioso, portanto, não pode vender apenas um ranking de todo o setor. Ele precisa construir um mapa privado de desempenho sobre o código, os testes, as normas de engenharia e a distribuição de tarefas de cada empresa.

#### 2. O espaço de combinações cresce depressa

Dez modelos, cinco harnesses e três níveis de esforço de raciocínio já produzem 150 configurações. Acrescente diferentes conjuntos de ferramentas, políticas de contexto e permissões, e a busca exaustiva logo se torna inviável.

O sistema precisa avaliar em etapas: eliminar configurações claramente inferiores com uma pequena amostra, depois concentrar o orçamento nas proximidades da fronteira de Pareto. Quando surgir um modelo ou harness novo, poucas tarefas de sondagem podem estimar sua faixa de capacidade. Isso se aproxima mais de desenho experimental e contextual bandits do que de um ranking simples.

#### 3. Complexidade não é um rótulo no prompt

Uma alteração aparentemente simples pode virar uma tarefa de alto risco por causa da propriedade do código, das dependências ou da falta de testes. A complexidade também muda durante a execução: o agente começa precisando alterar um arquivo e, ao investigar, descobre que terá de ajustar um protocolo e migrar dados.

O roteamento não pode classificar a tarefa uma única vez, na entrada. Precisa ler os metadados do repositório e permitir configurações mais capazes durante a execução. Um modelo barato explora primeiro e, ao descobrir efeitos entre módulos, entrega a tarefa a um modelo mais forte. Um harness leve localiza o problema e, quando a alteração se torna longa, dá lugar a outro mais adequado à gestão de contexto.

Isso traz outra questão: como preservar o estado útil durante a troca sem carregar junto o ruído do contexto do harness anterior?

#### 4. Uma política ótima exige pagar pela exploração

Se todas as tarefas de produção forem enviadas ao atual campeão, o sistema logo perderá seus dados comparativos. Atualizações de modelos, mudanças de preço e novas versões de harnesses também tornam antigas conclusões obsoletas.

O roteamento contínuo precisa, portanto, reservar uma pequena parcela do tráfego para exploração, testando novas combinações com tarefas canário ou reexecuções offline. Também precisa distinguir causas de falha: capacidade insuficiente do modelo, falha do harness na gestão de contexto, ferramenta indisponível ou ambiente de testes instável. Esses problemas não podem ser condensados em uma única nota.

Executar benchmarks periodicamente é apenas uma parte da avaliação contínua. O sistema também precisa manter os dados atuais, atribuir causas às falhas e controlar o risco da exploração.

### Onde estaria a vantagem defensável desse produto?

Gateways e APIs unificadas se tornam semelhantes com facilidade. O valor duradouro provavelmente virá de três tipos de dados.

Primeiro, a distribuição de tarefas da própria empresa: quais são frequentes, quais são caras e quais falhas provocam perdas reais.

Segundo, os rastros de execução de cada combinação: como o mesmo modelo, em diferentes harnesses, lê o contexto, chama ferramentas, consome tokens e corrige erros.

Terceiro, os resultados finais: os testes passaram? O PR foi aceito? Quanto uma pessoa precisou alterar? Houve reversão depois da entrada em produção?

Só ao conectar esses três tipos de dados o roteador entenderá o sentido real de barato e eficaz. Ele otimiza o custo total entre a entrada da tarefa e sua aceitação. O preço de uma chamada de API é apenas um componente.

Isso também cria um ciclo de melhoria baseado em dados. Quanto mais tempo o sistema é usado, melhor entende o código e os hábitos de engenharia da empresa. Quanto mais preciso o roteamento, mais tarefas a equipe aceita delegar. Mais resultados reais continuam melhorando o roteamento. Modelos e harnesses podem ser trocados; os ativos de avaliação e o histórico de decisões da empresa permanecem na camada de controle.

### Um ponto de partida mais realista

A primeira versão não deveria assumir de imediato todo o tráfego de agentes de programação. Um caminho mais sólido seria começar por um sistema de decisão offline:

1. Conectar repositórios e PRs integrados recentemente;
2. Gerar automaticamente um conjunto privado de tarefas verificáveis;
3. Reexecutar periodicamente um pequeno número de configurações model × harness;
4. Produzir uma fronteira de custo e qualidade por tipo de tarefa;
5. Primeiro recomendar configurações, depois ativar o roteamento automático para tarefas de baixo risco;
6. Calibrar o classificador e o conjunto de avaliações com resultados reais.

Assim, seria possível demonstrar primeiro duas coisas: que existem diferenças estáveis entre as combinações e que a economia do roteamento cobre o custo das avaliações.

Se essas condições não se confirmarem, o roteamento automático apenas acrescentará complexidade. Se forem confirmadas, o sistema poderá passar gradualmente de ferramenta de recomendação a plano de controle.

### Minha avaliação

Há uma demanda real nessa direção. O número de modelos cresce, as diferenças entre harnesses começam a afetar diretamente custo e qualidade, e as empresas ainda costumam definir um único modelo e um único agente de programação padrão para todas as tarefas. Essa configuração estática provavelmente desperdiça capacidade computacional e mantém parte das tarefas no nível errado de capacidade.

A Databricks é, hoje, quem mais se aproxima do ciclo completo. O Omnigent fornece a abstração de harnesses; o Unity AI Gateway, a entrada unificada e os dados de chamadas; os PRs internos, o conjunto privado de avaliações. O próximo passo anunciado no artigo talvez seja justamente conectar avaliação e roteamento.

A oportunidade de uma empresa independente não está em criar antes dos outros um ranking maior de modelos. Uma posição mais valiosa seria uma camada de controle de configurações de agentes, neutra em relação a fornecedores: avaliar continuamente as tarefas próprias de cada empresa, tratar o harness como dimensão roteável e fazer escolhas explicáveis entre qualidade, custo, latência e risco.

A janela existe, mas não ficará aberta por muito tempo. O Not Diamond pode avançar para fluxos com agentes; o Braintrust pode automatizar mais a conexão entre avaliações e gateway; a Databricks pode transformar seu sistema interno em produto. Um novo produto precisa demonstrar rapidamente algo mais concreto:

> Em bases reais de código empresarial, rotear configurações custa menos do que usar sempre o modelo mais forte e o harness padrão, sem reduzir a qualidade final da entrega.

Se isso puder ser demonstrado de forma consistente, a unidade de competição entre agentes de programação subirá mais uma camada. Modelos e harnesses continuarão importantes, mas uma parcela maior do valor ficará no sistema que escolhe continuamente a melhor combinação.

### Referências

* [Avaliação de agentes de programação na base de milhões de linhas da 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: conceitos fundamentais](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond: treinamento de um roteador 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: melhores roteadores de LLMs e plataformas de roteamento de modelos em 2026](https://www.braintrust.dev/articles/best-llm-routers-2026)