Stealth Models Benchmark: comparativo de modelos stealth

Este benchmark nasceu para catalogar os modelos stealth que aparecem de graça por uma semana nos harnesses de código e depois somem. Os números das tabelas e gráficos acima vêm de um arquivo de dados atualizado a cada bateria; esta seção explica como eles são produzidos e o que não medem.

Bench de harness: modelo fixo, harness variando

Quase toda comparação de harness mistura duas variáveis: troca o harness e o modelo ao mesmo tempo. Aqui o modelo é fixo e o harness (OpenCode, Cline, Command Code) é a única coisa que muda. O alvo é o pallets/jinja, pinado num commit, com cinco bugs injetados em módulos distintos (sandbox, lexer, runtime, loaders, compiler), escolhidos para que o sintoma fique longe da causa. Bug injetado derrota memorização: o modelo não resolve de cabeça.

Cada rodada recebe uma cópia descartável do repositório, sem histórico git, e um perfil limpo do harness contendo só a credencial: sem MCP, skills, plugins ou memória. A correção é avaliada com a pasta de testes restaurada de uma cópia pristina, e qualquer alteração em testes é detectada. São três repetições por par tarefa × harness, em ordem embaralhada com semente fixa, para que a carga da API ao longo do dia não vire diferença de harness.

A métrica principal não é taxa de acerto, que empata entre agentes convergidos, mas custo e contexto por tarefa resolvida. Modelos stealth custam zero, então os tokens medidos são convertidos pelo preço de um modelo pago de referência (indicado nas notas), para responder “quanto isso custaria num modelo equivalente”. Reportamos contexto total (entrada não cacheada mais leitura de cache) e taxa de cache, nunca tokens de entrada crus: dois harnesses que pareciam diferir 9× mandavam o mesmo contexto, com aproveitamento de cache diferente.

Isolamento e auditoria

Uma primeira bateria foi descartada inteira. Os diretórios das rodadas ficavam dentro do repositório do benchmark, e os agentes subiram dois níveis, leram a definição exata dos bugs injetados e compararam o código com a cópia sem bug. O placar medía a capacidade de achar o gabarito. Desde então cada rodada roda fora da árvore do benchmark, com nome aleatório, e o log bruto é auditado automaticamente: uma rodada que alcança o repositório do benchmark é excluída das métricas e contada à parte.

Suíte de inteligência e coding

Para cobrir outras vertentes, uma suíte reduzida inspirada nos índices do Artificial Analysis roda com os mesmos modelos: AA-Omniscience (conhecimento factual e alucinação), Humanity’s Last Exam (raciocínio acadêmico), SciCode (programação científica), Terminal-Bench 2.1 (uso de terminal) e SWE-bench Verified Mini (correção de bugs em repositórios reais). Os subconjuntos são sorteados uma vez, com semente fixa, e são os mesmos para todos os modelos. Nos testes de perguntas e respostas o modelo não tem acesso a ferramentas; nos testes com agente, cada tarefa roda no próprio container, e no SWE-bench a rede do agente fica restrita ao gateway do modelo, porque a correção de cada tarefa está pública no GitHub. A correção usa um modelo-juiz pago, diferente dos avaliados, no Omniscience e no HLE; nos demais, testes automatizados.

Limitações

• Tempo não é comparável. Cada harness fala com o modelo pelo seu próprio gateway, e houve rodadas com minutos de fila do provedor. Trate o tempo como indicativo.
• Harness limpo não é harness real. Sem MCP e skills, um harness que depende delas joga em desvantagem. O que se mede é o custo de base.
• Tarefas são correção pontual, não feature nova nem requisito ambíguo.
• Preview muda. Stealth em preview é ajustado durante a janela, e alguns saem do ar antes do prazo anunciado. Os números valem para a data indicada em cada seção.
• Subconjuntos pequenos. Na suíte, 100 questões dão uma margem de erro em torno de ±8 pontos; 14 a 20 tarefas com agente, margem maior. Os números separam modelos com diferença clara, não desempatam modelos parecidos, e não são comparáveis aos do Artificial Analysis, que usa outros subconjuntos, harness e juiz.
• Disponibilidade por região. Alguns stealth são bloqueados em certos países; quando um modelo não roda no servidor do benchmark, isso é indicado nas notas da seção.

A metodologia completa, com as armadilhas encontradas e como cada uma foi resolvida, está em duas páginas: a do bench de harness e a da suíte de inteligência e coding. As análises saem como posts no blog; a da suíte é Modelos stealth do OpenCode: testei 3 em 5 benchmarks.