Terminal-Bench 2.0: O Harness É a Decisão de Compra Que Seu CIO Não Está Tomando

Times de compras que avaliam ferramentas de IA para código fazem a pergunta errada primeiro. Perguntam qual modelo está por dentro. O modelo é a variável que todo mundo sabe comparar: contagem de parâmetros, janela de contexto, posição no leaderboard, ficha técnica do fornecedor. O harness ao redor do modelo é tratado como encanamento, um detalhe de implementação que fica a cargo de quem for fazer o deploy.

A thread Model-Harness-Fit de Nicholas Bustamante, trazida pela TLDR AI nesta semana, torna essa ordem indefensável. O harness não é encanamento. O harness é o produto. E, com o Terminal-Bench 2.0, finalmente existe um benchmark que prova isso com números que um CFO consegue ler.

A Variação de 4,5 Pontos

Segundo a análise de Bustamante, o Terminal-Bench 2.0 rodou o Claude Opus 4.6 contra dois harnesses diferentes. O ForgeCode envolveu o modelo: 79,8 por cento. O Capy envolveu o mesmo modelo: 75,3 por cento. Mesmos pesos. Mesmos prompts. 4,5 pontos de diferença, atribuíveis inteiramente à estrutura ao redor do modelo.

O Cursor, segundo a mesma thread, saltou do “Top 30 para o Top 5” apenas com uma troca de harness.

Quem passou algum tempo em planilhas de compra sabe o que 4,5 pontos significam. É a diferença entre “podemos colocar isso em produção para revisão de código” e “fica em modo consultivo”. É a linha entre uma ferramenta que um CTO defende no comitê de segurança e outra que volta para mais um ciclo de avaliação. Trocar de modelo de fronteira raramente produz variação de 4,5 pontos dentro da mesma geração. O harness, ao que parece, faz isso numa terça-feira qualquer.

Por Que o Harness Mexe no Número

O mecanismo está no pós-treinamento. Pela leitura que Bustamante faz da forma como Codex CLI, Claude Code e GitHub Copilot CLI são construídos, os laboratórios de fronteira não publicam pesos crus para que o harness se adapte depois. Eles pós-treinam o modelo contra um harness específico. Os nomes das ferramentas que o modelo aprende a chamar, o schema dessas chamadas, as tags de citação que ele aprende a emitir, os rituais de memória que ele espera executar, a estrutura do system prompt contra a qual foi otimizado. Tudo isso fica gravado nos pesos.

Troque o harness e você removeu o substrato contra o qual os pesos foram treinados. O modelo continua funcionando. Funciona menos bem. Os 4,5 pontos são o custo do desencaixe.

A implicação para o comprador não é sutil. Quando um fornecedor diz “usamos Claude Opus 4.6 por dentro”, ele está informando o nome do modelo. Não está informando se o harness ao redor é o harness contra o qual aquele modelo foi pós-treinado, um harness concorrente ou um wrapper genérico que um engenheiro júnior montou num fim de semana. Esses três casos produzem três produtos diferentes com o mesmo cartão de modelo.

O Reenquadramento da Compra

Trate o harness como critério de avaliação de primeira classe. A frase soa óbvia. Na prática, quase nenhum processo de compra faz isso. A rubrica padrão cobre nome do modelo, janela de contexto, preço, SOC 2, residência de dados e superfície de integração. O harness aparece como “detalhe de implementação” ou, no pior caso, como “molho secreto do fornecedor que não pode ser divulgado”.

Uma compra consciente de harness faz outras perguntas:

Contra qual harness o modelo foi pós-treinado? Se o fornecedor não sabe responder, essa é a resposta. O ajuste modelo-harness não foi restrição de design.

Em qual benchmark, com qual harness, saiu o número publicado? 79,8 não significa nada sem o harness em que rodou. Exija o par.

Se trocarmos o harness no nosso deploy, a precisão divulgada pelo fornecedor ainda vale? A maior parte dos deploys corporativos embrulha a ferramenta do fornecedor dentro do próprio servidor MCP, do próprio gerenciador de contexto, da própria camada de memória. Cada embrulho é, formalmente, uma troca parcial de harness. O número do fornecedor foi medido contra o harness dele, não contra o seu.

Quem controla o system prompt, o schema das tools e o formato de citação dentro do harness? Se isso é controlado pelo fornecedor e não documentado, você está operando com coeficientes ocultos na sua avaliação.

Qual é a cadência de mudança do harness? Um fornecedor que solta atualizações de harness mensalmente está entregando um produto diferente todo mês. O nome do modelo no contrato não muda. O comportamento muda.

O Caso Cursor

O salto do Cursor “do Top 30 para o Top 5” é a parte mais legível da thread para um comprador não técnico. Um produto único, com a mesma relação com o modelo subjacente, andou 25 posições num benchmark pela troca de harness. Quem comprou o Cursor antes da mudança comprou um produto Top 30. Quem comprou depois comprou um Top 5. O nome do fornecedor era o mesmo. O nome do modelo era o mesmo. O time de compras que leu apenas a ficha do modelo perdeu todo o delta.

A lição não exige tomar partido sobre qual harness é melhor. A lição é que “Cursor”, como objeto de compra, não é um artefato estável. É um modelo mais um harness, e o harness se mexe. Qualquer ferramenta de IA para código que o fornecedor batize é o mesmo tipo de objeto, mesmo que ele não diga isso na ficha técnica.

O Que Isso Significa Para o CIO

Três mudanças concretas para compradores neste trimestre.

Pare de aceitar nome de modelo como nome de produto. Quando o fornecedor diz “powered by GPT-5” ou “usa Claude Opus 4.6”, a sua próxima pergunta é “em qual harness, pós-treinado como, com qual tool schema”. Se o fornecedor não responde no nível do harness, ele não fez do ajuste modelo-harness parte da engenharia. Isso é sinal de risco.

Exija o par de benchmark. Qualquer número de precisão divulgado precisa vir com o harness em que foi medido. “Claude Opus 4.6 a 79,8 por cento no Terminal-Bench 2.0 com ForgeCode” é uma afirmação. “Claude Opus 4.6 a 79,8 por cento” é marketing. Trate o segundo como inverificável até virar par.

Audite o seu próprio harness. Como argumentamos em Auditoria de Harness: a Camada de Governança do Lado do Comprador, a maior parte das empresas já construiu metade de um harness sem perceber. Os servidores MCP, os gerenciadores de contexto, os templates de prompt que o time de plataforma colocou em cima da ferramenta do fornecedor já fazem parte do harness. A sua precisão efetiva é a que o modelo entrega dentro do seu harness composto, não a que o fornecedor mediu. Rode o benchmark no seu stack. O número que voltar é o número que importa.

Os times que vencem o próximo ciclo de compra não são os que escolhem o melhor modelo. São os que entendem que a pergunta “qual modelo” nunca foi a pergunta. A pergunta sempre foi “qual modelo, em qual harness, pós-treinado como, avaliado onde, em produção contra o quê”. Os números do Terminal-Bench 2.0 são a primeira vez em que o coeficiente do harness aparece de forma limpa o bastante para que um executivo não técnico consiga enxergar. Use isso.

Os fornecedores que pós-treinaram para ajuste modelo-harness vão publicar o par. Os que não fizeram vão publicar só o nome do modelo. Essa assimetria, sozinha, já é sinal de compra.

Fontes

Bustamante, Nicholas. “Model-Harness-Fit.” Citado via TLDR AI, Maio de 2026.

A Victorino ajuda times de compras a tratar o harness como critério de avaliação de primeira classe ao lado do modelo: contato@victorino.com.br | www.victorino.com.br