O Niklaus Harness Leaderboard testa Kimi Code, Hermes, Pi, Claude Code e Codex além dos rankings de marca

Joël Niklaus comparou nove harnesses de agentes de programação em 28.849 testes, contestando a ideia de que escolher um modelo resolve a questão do desempenho. O Niklaus harness leaderboard avalia o software que direciona o trabalho de um modelo, mantendo sob controle o modelo subjacente e as configurações de raciocínio. Seus resultados iniciais colocam várias ferramentas reconhecíveis em uma faixa de precisão semelhante, enquanto diferenças de eficiência e repetibilidade complicam a definição de um vencedor.

A comparação inclui Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code e OpenClaw. Um harness é o software que gerencia as instruções, as ferramentas e o ciclo de execução de um modelo de IA. Neste caso, esse software ao redor do modelo se torna a variável examinada.

A tensão central está entre a reputação de um produto e o comportamento de uma configuração específica testada. Esses resultados não estabelecem que Claude Code ou Codex tenha desempenho universalmente melhor com seu modelo padrão. Eles examinam o que acontece quando diferentes harnesses operam modelos abertos selecionados em condições controladas — uma questão mais restrita, com consequências práticas para desenvolvedores.

O que o Niklaus Harness Leaderboard realmente compara

O experimento isola o software do agente ao redor do modelo, em vez de tratar cada produto de programação como um pacote inseparável.

Em sua descrição de lançamento, Niklaus afirma que a comparação mantém fixos o modelo, o provedor e o esforço de raciocínio, enquanto altera o harness. Cada tarefa recebe três tentativas. A avaliação inicial abrange GLM-5.3-Flash, DeepSeek-V4.1-Flash e Flint, usando Terminal-Bench 2.1 e DeepSWE.

Esse desenho importa porque comparações comuns de produtos frequentemente mudam várias variáveis ao mesmo tempo. Um desenvolvedor que troca de assistente de programação pode alterar simultaneamente o modelo, as instruções, as ferramentas disponíveis, as permissões e o comportamento de execução. Uma diferença de desempenho então se torna difícil de atribuir.

A descrição de lançamento informa que o mini-swe-agent alcançou uma taxa média de resolução de 51,4% nos três modelos, em comparação com 27,3% do OpenClaw. Niklaus também afirma que outros quatro harnesses estão estatisticamente empatados com o resultado líder. Esses números descrevem o lançamento inicial, e não um ranking permanente.

Suas conclusões específicas por modelo complicam essa média geral. Segundo Niklaus, o mini-swe-agent lidera no GLM-5.3-Flash, o Hermes Agent no DeepSeek-V4.1-Flash e o Kimi Code no Flint. Portanto, a ordem depende de qual modelo um desenvolvedor pretende executar.

A implicação imediata é limitada, mas relevante. Um harness que funciona bem com um modelo não extrai automaticamente o mesmo desempenho relativo de outro. Uma pontuação geral pode ajudar a identificar candidatos, ao mesmo tempo que oculta o emparelhamento importante para uma implantação real.

O Terminal-Bench avalia agentes que executam tarefas em ambientes de terminal, nos quais o software executa comandos e interage com arquivos. O DeepSWE fornece uma avaliação separada de engenharia de software. Usar ambos amplia a comparação, embora combinar resultados não torne as coleções de tarefas representativas de todos os fluxos de trabalho de desenvolvimento.

O experimento também precisa ter uma data associada às suas conclusões. Quando verificado para este artigo, o aplicativo ao vivo exibiu a versão v0.1.2. Sua descrição atual se refere à verificação de provedores equivalentes, em vez de simplesmente repetir a formulação do lançamento inicial sobre provedores fixos.

Essa distinção merece atenção porque um benchmark pode evoluir após seu primeiro anúncio. Novas versões de harnesses, testes adicionais ou controles revisados podem mudar o significado de uma captura de tela. Os números de lançamento continuam sendo evidências sobre a configuração de lançamento, mesmo quando o painel atual apresenta uma ordenação diferente.

Para leitores que encontrarem a discussão original no Reddit, a correção essencial é, portanto, sobre o escopo. Trata-se de uma comparação de combinações selecionadas de harness e modelo. Não é um teste abrangente de todos os recursos, experiências de assinatura ou configurações padrão associadas aos nomes de produtos listados.

Fornecedores de agentes de programação enfrentam pressão para explicar toda a configuração

Os resultados pressionam alegações que atribuem o desempenho de um agente inteiramente ao seu modelo subjacente.

Para desenvolvedores de harnesses, a comparação torna as escolhas de implementação mais visíveis. Instruções, interfaces de ferramentas, comportamento de repetição e decisões de encerramento moldam o trabalho executado por um modelo. Um modelo forte ainda pode enfrentar atritos causados pelo software responsável por orientá-lo.

Para provedores de modelos, o mesmo experimento introduz um problema de atribuição. Um resultado decepcionante dentro de um agente específico não identifica o modelo como a única causa. Da mesma forma, um resultado forte não estabelece que todos os aplicativos que usam esses pesos reproduzirão esse desempenho.

Para compradores corporativos, isso muda o que uma avaliação significativa precisa descrever. Nomear um modelo e um assistente é insuficiente quando escolhas de configuração influenciam os resultados. Os compradores precisam de informações suficientes para entender a combinação testada e reproduzir o comportamento relevante para seu trabalho.

Uma tarefa hipotética de manutenção torna a distinção concreta. Um agente pode precisar inspecionar um repositório, identificar um teste com falha, modificar uma função e verificar a alteração. Cada etapa depende de como o harness expõe informações e administra a sequência de ações.

Se o agente parar após editar sem executar o teste relevante, uma correção plausível permanecerá sem verificação. Se continuar emitindo comandos improdutivos, a conclusão se torna mais lenta e mais intensiva em recursos. Essas são diferenças operacionais, mesmo quando o modelo subjacente permanece inalterado.

Isso não estabelece qual implementação causou qualquer resultado específico no leaderboard. Isso exige inspecionar os registros de execução e testar uma intervenção. Explica por que a comparação controlada faz uma pergunta útil que um ranking de modelos isoladamente não consegue responder.

As conclusões de lançamento também estabelecem um limite para o conhecido debate Claude Code vs Codex. Esses nomes de produtos frequentemente representam experiências completas construídas em torno de determinadas famílias de modelos. Testar seus harnesses com modelos abertos selecionados faz uma pergunta diferente de comparar essas experiências completas.

Uma posição baixa neste experimento não estabeleceria que o serviço padrão de um produto tem desempenho ruim. Uma posição alta não estabeleceria superioridade em revisão de código, colaboração interativa ou fluxos de trabalho específicos de uma organização. Essas alegações exigem avaliações que meçam diretamente essas atividades.

O resultado do benchmark do Kimi Code traz a mesma limitação. Sua liderança relatada com Flint justifica investigar esse emparelhamento nas condições testadas. Ela não estabelece uma liderança geral em modelos ou repositórios não relacionados.

Para os fornecedores, a resposta construtiva é publicar configurações e explicar mudanças que afetam os resultados. Assim, os compradores podem distinguir uma atualização de modelo de uma melhoria de harness. Isso torna as alegações de desempenho mais fáceis de avaliar e as falhas mais fáceis de investigar.

A pressão é especialmente relevante para equipes que operam modelos abertos por meio de software de agente intercambiável. Sua decisão de compra inclui a camada de execução. Elas precisam de evidências sobre o que essa camada acrescenta, em vez de depender inteiramente de um nome de produto reconhecível.

Precisão semelhante pode ocultar comportamentos operacionais diferentes

Um resultado de precisão próximo ainda deixa espaço para diferenças significativas no uso de recursos, na latência e na consistência.

O painel atual separa várias medições, em vez de apresentar a precisão como uma resposta completa. Seu método de avaliação descreve a medição externa do uso do modelo e distingue o tempo de processamento do modelo do tempo gasto executando o agente. Essas distinções ajudam a explicar por que taxas de resolução semelhantes podem produzir experiências operacionais diferentes.

O painel também relaciona precisão e custo em um gráfico e identifica uma fronteira de Pareto, o conjunto de opções que nenhum concorrente supera em ambas as medidas exibidas. Isso oferece aos leitores uma forma de examinar vantagens concorrentes sem presumir que a maior precisão deve ser sempre preferível.

Esse enquadramento importa quando uma organização tem uma carga de trabalho fixa e recursos limitados. Uma pequena vantagem de precisão pode ser valiosa para uma tarefa difícil que exige supervisão mínima. A mesma vantagem pode ser menos atraente se exigir substancialmente mais tempo de execução em trabalhos rotineiros de manutenção.

Um resultado de eficiência também precisa de interpretação. Gastar menos não significa necessariamente que um agente raciocina de forma mais eficaz. Isso pode refletir menos tentativas, encerramento antecipado, saídas mais curtas ou um padrão diferente de uso de ferramentas. O registro de execução ajuda a distinguir contenção produtiva de falha prematura.

Da mesma forma, uma execução mais longa não estabelece desperdício. Um agente pode dedicar esforço adicional a verificar uma correção ou se recuperar de uma abordagem malsucedida. A questão relevante é se o trabalho extra melhora um resultado que a equipe realmente valoriza.

É por isso que informar o uso de recursos por tentativa e por resultado bem-sucedido responde a perguntas diferentes. Uma tentativa barata que falha continua sendo uma falha. Uma tentativa bem-sucedida mais exigente ainda pode ser a melhor escolha quando a recuperação humana, de outra forma, dominaria o fluxo de trabalho.

Essas são considerações de avaliação, e não explicações estabelecidas para cada harness no painel. Um gráfico pode revelar um padrão que vale investigar. Ele não pode, por si só, identificar o comportamento de instrução ou de ferramenta responsável por esse padrão.

O mecanismo é simples em princípio. Um agente recebe informações, escolhe uma ação, observa o resultado e decide o que fazer em seguida. O harness controla partes importantes desse ciclo, incluindo quais ferramentas estão disponíveis e como suas respostas chegam ao modelo.

Considere um repositório hipotético com uma compilação falhando devido a um problema de ambiente. Um agente que edita repetidamente o código do aplicativo pode consumir recursos sem abordar a causa. Outra configuração pode reconhecer o problema de ambiente e redirecionar sua investigação.

A diferença diria respeito à execução da tarefa, e não ao conhecimento bruto do modelo. Estabelecer essa explicação exigiria relacionar o comportamento observado ao resultado. Sem essa inspeção, afirmar que um determinado harness é “mais inteligente” vai além das evidências.

O Niklaus harness leaderboard, portanto, sustenta uma comparação mais específica do que sugere o rótulo de um único vencedor. Desenvolvedores podem perguntar quais combinações atingem precisão aceitável ao mesmo tempo que usam recursos de uma forma compatível com sua carga de trabalho. A resposta pode diferir entre desenvolvimento interativo e operação sem supervisão.

Ele também muda a forma de interpretar uma manchete sobre o benchmark do Kimi Code. Uma liderança específica de modelo é um sinal útil para avaliações posteriores. Ela continua incompleta sem informações sobre tentativas com falha, duração da execução e o comportamento que produziu a pontuação.

Pelo mesmo motivo, comparações entre Claude Code vs Codex devem preservar o contexto testado. Os nomes fornecem orientação, mas a configuração determina o que o resultado realmente descreve.

Sucesso repetível é um resultado diferente de sucesso ocasional

Um agente que resolve uma tarefa de forma intermitente apresenta uma proposta de implantação diferente daquela de um agente que a resolve de forma consistente.

Niklaus destacou posteriormente a confiabilidade em tentativas repetidas. Segundo sua análise de confiabilidade, o mini-swe-agent resolveu, em média, 51,4% das tarefas por tentativa. Ele resolveu 68,6% pelo menos uma vez em três tentativas, mas 33,0% em todas as tentativas.

Essas medições descrevem questões operacionais diferentes. A média captura o desempenho entre tentativas. O sucesso ao menos uma vez indica se oportunidades repetidas acabam produzindo uma solução. O sucesso em todas as vezes captura a consistência dentro das tentativas medidas.

A distinção se torna importante quando alguém observa o agente trabalhando. Um desenvolvedor pode inspecionar uma tentativa que falhou, alterar uma instrução ou decidir que outra execução vale a pena. A supervisão humana pode tornar útil o sucesso intermitente, embora o tempo gasto supervisionando continue fazendo parte do fluxo de trabalho.

Um processo sem supervisão enfrenta uma restrição diferente. Ele não pode presumir que existe uma tentativa alternativa bem-sucedida, a menos que o sistema ao redor realmente execute alternativas e reconheça sua qualidade. Tentativas repetidas precisam de um método de seleção, um orçamento de execução e uma forma de lidar com falhas não resolvidas.

Isso torna uma pontuação de sucesso ocasional um substituto inadequado para uma medição de consistência. Ela pode mostrar que uma configuração tem acesso a uma solução sob certas condições. Não estabelece que a configuração entregará essa solução de forma confiável quando solicitada.

Niklaus relata que cinco harnesses resolveram entre 32,0% e 33,3% das tarefas em todas as tentativas na comparação citada. Ele descreve esses resultados como próximos demais para definir um vencedor. Isso sustenta a resistência a alegações precisas de vitória dentro do grupo líder.

Os números de confiabilidade também precisam vir acompanhados de limites. Três tentativas fornecem evidências sobre repetibilidade dentro daquele experimento. Elas não estabelecem uma taxa de falha em produção diante de repositórios, dependências, permissões e instruções de usuários em constante mudança.

Tampouco uma falha em um benchmark se traduz automaticamente em uma ação prejudicial em produção. O avaliador mede se a tarefa atende aos seus critérios de sucesso. As consequências operacionais dependem do que o agente pode acessar e de quais aprovações ou verificações cercam seu trabalho.

Para gestores de engenharia, a implicação é separar capacidade de entrega confiável. Uma configuração pode ser capaz o suficiente para produzir ocasionalmente um patch correto e ainda assim permanecer inadequada para um fluxo de trabalho sem supervisão. Essa lacuna exige verificação adicional, e não um rótulo de marketing mais forte.

Uma atualização hipotética de dependência ilustra a diferença. Um agente pode atualizar o pacote com sucesso e passar nos testes em uma execução, mas deixar de fazer uma alteração relacionada de configuração em outra. O sucesso ocasional diz menos sobre a prontidão para trabalho sem supervisão do que a porcentagem de destaque pode sugerir.

Uma equipe que avalia esse fluxo de trabalho se preocuparia com conclusão reproduzível e tratamento claro de falhas. Também se preocuparia em saber se a alteração resultante é compreensível para um revisor. Essas dimensões continuam distintas de saber se o verificador do benchmark aceita o estado final.

A visão de tentativas repetidas do leaderboard traz essa distinção para a comparação pública. Ela incentiva os leitores a perguntar o que acontece quando o agente precisa trabalhar novamente, em vez de tratar uma trajetória bem-sucedida como uma descrição completa do produto.

Versões de Benchmarks e Registros Públicos Limitam as Alegações de Vitória

Os resultados publicados são evidências inspecionáveis, mas continuam limitados pelas versões dos benchmarks, configurações e pela abrangência da verificação.

O próprio Terminal-Bench fornece um exemplo claro de por que os rótulos de versão importam. Sua revisão 2.1 corrigiu problemas em 28 das 89 tarefas da edição anterior. Os mantenedores relataram mudanças nas pontuações de agentes-modelos representativos após esses reparos.

Esse histórico faz da versão do benchmark parte da alegação. Uma pontuação do Terminal-Bench 2.0 não pode ser tratada simplesmente como intercambiável com uma da versão 2.1. As tarefas e as condições de avaliação mudaram, mesmo quando a métrica exibida mantém o mesmo nome.

O mesmo princípio se aplica ao harness. Um resultado pertence à versão e às configurações do software testado. Se uma atualização altera instruções, execução de ferramentas ou comportamento de encerramento, a pontuação anterior descreve a implementação anterior.

Isso cria um desafio para discussões públicas em rápida evolução. Um gráfico pode circular após o painel mudar, enquanto os comentários continuam tratando o gráfico como atual. Os leitores precisam da configuração original e da data da medição para determinar o que a imagem ainda demonstra.

Os registros públicos de execuções do projeto oferecem um caminho para verificar esses detalhes. A disponibilidade dos registros é um benefício de transparência. Sua publicação não significa que cada resultado já tenha recebido reprodução independente ou revisão manual completa.

A reprodução independente exigiria executar as configurações especificadas e verificar se os padrões relevantes persistem. Ler os registros pode apoiar uma auditoria dos cálculos relatados ou de comportamentos individuais. Essas atividades fornecem tipos diferentes de evidência.

A questão causal permanece especialmente exigente. Uma diferença de pontuação pode identificar uma associação entre configuração e resultado sob condições controladas. Explicar a diferença exige examinar falhas e testar se uma mudança proposta as altera.

Por exemplo, um suposto problema de timeout deve ser testado alterando o timeout e preservando outras condições relevantes. Um suposto problema de perda de informação exige inspecionar quais informações desapareceram e se preservá-las melhora os resultados. Nenhuma das explicações decorre automaticamente de uma posição baixa.

A familiaridade com o benchmark introduz outra preocupação que vale investigar sem presumir má conduta. Um sistema otimizado com base em tarefas públicas pode melhorar nessa distribuição de tarefas sem melhorar de maneira equivalente em outros contextos. Evidências de tarefas desconhecidas ajudariam a estabelecer quão amplamente o ganho é transferido.

A cobertura de tarefas apresenta uma limitação separada. A manutenção de repositórios envolve convenções organizacionais, solicitações ambíguas e expectativas de revisão humana que um benchmark fixo não consegue capturar completamente. Um benchmark ainda pode ser útil, deixando essas questões de implantação sem resolução.

A resposta prática é manter a evidência proporcional à decisão. Um resultado público pode justificar uma lista curta ou um teste direcionado. Substituir o fluxo de desenvolvimento de uma equipe exige evidências adicionais de trabalho semelhante às responsabilidades reais dessa equipe.

Manter juntas as configurações, os exemplos de falhas e as decisões de revisão torna essas comparações mais fáceis de revisitar. Uma base de conhecimento pesquisável pode ajudar a preservar esse histórico de avaliação junto dos documentos técnicos usados durante os testes.

A lacuna de verificação não elimina o valor do experimento. Ela define o que os resultados atualmente sustentam e qual trabalho adicional os fortaleceria. Essa é uma leitura mais útil do que aceitar literalmente cada posição ou descartar inteiramente a comparação.

Os Próximos Testes Devem Acompanhar Atualizações, Reprodução e Trabalho Sem Supervisão

As evidências de acompanhamento mais robustas conectarão mudanças de versão a melhorias reproduzíveis em trabalhos que vão além da comparação inicial.

O primeiro sinal a observar é o desempenho atualizado dos harnesses com um histórico claro de versões. Quando um desenvolvedor altera o software de execução, uma nova execução comparável pode mostrar se a precisão, a eficiência ou a consistência muda. Preservar a configuração anterior torna essa comparação significativa.

Uma melhoria em medições repetidas fortaleceria o argumento de que a engenharia de harnesses afeta materialmente os resultados. Um resultado que desaparece em novas execuções comparáveis enfraqueceria a confiança no ganho alegado. Qualquer um dos desfechos fornece mais informação do que um selo atualizado de vencedor.

Isso também oferece aos fornecedores uma maneira construtiva de responder. Eles podem identificar um padrão de falha, explicar a alteração relevante na implementação e publicar evidências sobre o resultado. Os leitores podem então avaliar uma alegação concreta de engenharia, em vez de inferir qualidade a partir da reputação de um produto.

O segundo sinal é a reprodução independente com controles correspondentes. Um avaliador separado deve documentar o modelo, as condições do provedor, as configurações de raciocínio, a versão da tarefa e a versão do harness. As diferenças precisam permanecer visíveis, em vez de serem incorporadas a uma pontuação aparentemente idêntica.

Se os resultados independentes preservarem a ordenação geral ou os padrões específicos de modelo, a confiança na comparação aumenta. Se os resultados divergirem, isso aponta para condições que exigem análise mais detalhada. O comportamento do provedor, as configurações de execução e os detalhes de medição tornam-se questões de pesquisa, e não explicações convenientes.

A reprodução não exige que todos os números coincidam exatamente. A questão relevante é se a conclusão resiste a medições repetidas razoáveis. Resultados próximos devem continuar próximos, a menos que evidências adicionais sustentem diferenciá-los.

O terceiro sinal é o desempenho em trabalhos desconhecidos com critérios explícitos de sucesso sem supervisão. Isso significa verificar se o agente conclui a tarefa solicitada, verifica o resultado e lida adequadamente com falhas. A intervenção humana deve ser registrada porque ela altera o significado de “conclusão autônoma”.

Melhorias consistentes nesse trabalho fortaleceriam a importância prática das descobertas do leaderboard. Ganhos restritos a tarefas conhecidas de benchmark reduziriam sua relevância. A distinção importa mais para a implantação do que outro pequeno movimento em uma média geral.

Para equipes que escolhem software agora, as evidências sustentam a comparação no nível do pareamento real. Kimi Code, Hermes Agent, Pi, Claude Code, Codex e mini-swe-agent merecem avaliação nas configurações que uma equipe pretende usar. Seus nomes sozinhos não podem determinar o resultado.

O leaderboard de harnesses de Niklaus oferece a essa avaliação um ponto de partida público, com resultados de lançamento, tentativas repetidas e registros acessíveis. Sua contribuição duradoura dependerá de essas medições ajudarem a explicar e melhorar o comportamento dos agentes.

Antes de alterar seu fluxo de trabalho de programação, compare um pareamento pré-selecionado com a configuração em que você já confia usando trabalho de manutenção representativo. Registre a configuração exata, as evidências de conclusão, o esforço do revisor e as falhas que exigem intervenção. Inclua tarefas em que um patch plausível é insuficiente sem uma etapa de verificação bem-sucedida. Retome a comparação após uma atualização significativa do harness, preservando os resultados anteriores para que as mudanças permaneçam compreensíveis. Trate o painel público como evidência para essa decisão, mas dê ao seu próprio fluxo de trabalho a palavra final. A pergunta que vale responder é concreta: qual combinação testada entrega um trabalho que sua equipe pode verificar, repetir e aceitar com a supervisão que vocês realmente podem fornecer?