StateM: 95,3% no Terminal-Bench sem tocar em um único peso

Existe um experimento mental que qualquer pessoa que já operou um agente de terminal reconhece. O modelo começa bem: lê o repositório, entende a tarefa, roda o primeiro comando. Trinta passos depois, ele esqueceu o que estava fazendo, refez trabalho já concluído e declarou vitória sobre uma coisa que não terminou. O modelo não ficou pior no meio do caminho. O que se degradou foi a memória do que já havia sido feito.

O StateM — publicado esta semana por Ziheng Qin, Yaxin Lu, Zhangyang "Atlas" Wang e Kai Wang, e o paper mais votado do Hugging Face nos últimos dias com folga — ataca exatamente esse ponto. E ataca de um jeito que desconcerta: sem treinar nada. Nenhum peso é alterado. O que muda é o sistema que roda em volta do modelo.

O que exatamente é um "harness"

No jargão de agentes, harness é o andaime: a camada que decide o que entra no contexto, como as ferramentas são chamadas, o que acontece quando um comando falha e quando a tarefa pode ser considerada encerrada. O modelo gera texto; o harness é quem transforma esse texto em execução.

Isso já era conhecido como fonte de variância — o mesmo modelo tira notas diferentes no Terminal-Bench 2.1 conforme o andaime que o embrulha. O que o StateM propõe é tratar essa camada não como plumbing acessório, mas como o eixo de escala: em vez de gastar computação treinando um modelo maior, gaste-a estruturando a execução.

Três fronteiras, um runbook em YAML

A arquitetura é deliberadamente pouco glamourosa. O agente opera sobre um runbook — um arquivo YAML compartilhado, legível e editável tanto por humanos quanto pelo próprio agente — que descreve as fases da tarefa. Cada fase passa por quatro momentos: planejar (carregar o contexto durável), executar (trabalho aberto, com instruções locais àquela fase), verificar (checar evidência antes de transitar) e entregar (só alcançar um estado terminal quando as condições forem cumpridas).

Sustentando isso, três fronteiras explícitas:

A ideia central é que o estado do trabalho deixe de morar no contexto do modelo — onde ele se dilui, se contradiz e se perde — e passe a morar num artefato externo, durável e auditável. É a diferença entre lembrar de cabeça e anotar num caderno.

Os números, e o asterisco que eles carregam

No Terminal-Bench 2.1 — 89 tarefas realistas de linha de comando, de administração de sistemas a treino de modelo — os autores relatam:

Para dimensionar: no leaderboard independente da Artificial Analysis, o topo do Terminal-Bench v2.1 hoje é o GPT-5.6 Sol (xhigh) com 89,5%, seguido de Claude Opus 5 com 89,1% e Grok 4.6 com 88,4% — todos medidos com o harness Terminus 2, em pass@1 sobre três repetições por tarefa.

Aqui mora o asterisco, e ele importa. "Acurácia bruta" sobre 445 tentativas não é o mesmo protocolo que pass@1 médio, e "todas as tarefas resolvidas ao menos uma vez" é uma afirmação mais fraca do que parece à primeira leitura. Comparar 95,3% com 89,5% diretamente é comparar duas réguas. O ganho relativo à própria linha de base do StateM — 92,1% contra 83,1% no mesmo modelo, mesmo protocolo — é a evidência sólida; o número de manchete é a versão generosa dela.

Os próprios autores dão uma segunda razão para cautela. Num teste complementar em BusinessBench, o ganho foi de +10,04 pontos nos subgrupos em que o mecanismo se aplica — e de apenas +0,55 ponto no agregado. Ou seja: o método não melhora tudo. Ele melhora, e muito, um tipo específico de tarefa — a longa, sequencial, com estado que precisa sobreviver a interrupções. Em tarefas curtas, não há estado a preservar.

Por que isso é mais interessante que mais um recorde

Se o resultado se sustentar em avaliação independente, a consequência prática não é "o GPT-5.6 é melhor do que se pensava". É que a fronteira de custo se moveu. Um modelo aberto e barato, com o andaime certo, alcançou 88% — território que até ontem exigia o modelo de fronteira mais caro do mercado, a um custo 37 vezes maior.

Isso reorganiza a decisão de quem constrói. Durante dois anos, a resposta padrão para "meu agente falha em tarefas longas" foi esperar o próximo modelo. O StateM sugere uma resposta diferente e desconfortavelmente mundana: talvez o problema não fosse o raciocínio, e sim a ausência de um registro confiável do que já foi feito. Não é uma descoberta sobre inteligência. É uma descoberta sobre contabilidade.

Há também um efeito colateral que os benchmarks não medem. Um runbook em YAML é legível. Quando o agente falha, dá para abrir o arquivo e ver em que fase ele parou, qual verificação não passou, o que ele achava que já tinha entregue. Comparado com auditar 40 mil tokens de transcript, é uma melhoria de engenharia que vale por si — independentemente de quantos pontos ela some no benchmark.

O que ainda não sabemos

O código está publicado no GitHub, o que é a condição mínima para verificação — e a comunidade vai reproduzir isso nas próximas semanas. Três perguntas ficam abertas até lá.

A primeira é quanto do ganho sobrevive fora do Terminal-Bench. Tarefas de benchmark têm começo, meio e critério de sucesso explícito; o trabalho real raramente tem. A segunda é quem escreve o runbook: se cada domínio novo exigir um desenhado à mão por um especialista, o método escala menos do que promete. A terceira é a mais interessante — se a estrutura ajuda tanto assim, ela deveria ser destilada de volta para dentro dos pesos, ou é melhor que fique fora, editável e auditável?

A resposta a essa última pergunta vale mais que os 95,3%. Ela decide se os próximos dois anos de progresso em agentes vão vir de modelos maiores ou de andaimes melhores — e essas duas trajetórias custam ordens de grandeza diferentes.

Perguntas Frequentes

O que é o Terminal-Bench 2.1?

É um benchmark aberto com 89 tarefas realistas executadas dentro de um terminal isolado, cobrindo desde administração de sistemas até treino de modelos. O agente recebe uma tarefa em linguagem natural e precisa concluí-la rodando comandos de verdade — não respondendo perguntas sobre eles. É considerado difícil justamente porque as tarefas são longas e o erro se acumula.

O StateM funciona com qualquer modelo?

Nos testes reportados, sim: o mesmo runbook foi aplicado a modelos da OpenAI e ao DeepSeek-V4 Flash, atravessando gerações diferentes sem reescrita. Como nada é treinado, o requisito é o modelo saber seguir instruções estruturadas e usar ferramentas de forma confiável — o que exclui modelos pequenos demais.

Qual a diferença entre isso e simplesmente dar um prompt melhor?

Um prompt melhor vive dentro da janela de contexto e se degrada junto com ela. O runbook do StateM é um arquivo externo com transições verificadas: o agente não avança de fase sem passar numa checagem, e se o processo cair, ele retoma do estado gravado em disco, não da própria lembrança. É engenharia de estado, não engenharia de texto.

Por que a comparação com o leaderboard público não é direta?

Porque as métricas diferem. O leaderboard da Artificial Analysis reporta pass@1 médio sobre três repetições por tarefa; o StateM reporta acurácia bruta sobre 445 tentativas, mais a afirmação de que toda tarefa foi resolvida ao menos uma vez. São medidas legítimas, mas não intercambiáveis — e o ganho mais confiável do trabalho é o comparativo interno, com o mesmo protocolo dos dois lados.

Vale a pena adotar hoje?

Se o seu caso de uso é agente de tarefa longa com estado — migração, refatoração ampla, pipeline de dados —, o código está aberto e o mecanismo é simples o suficiente para testar num fim de semana. Se são tarefas curtas de uma ou duas chamadas, o resultado do BusinessBench sugere que o ganho será próximo de zero.