Engenharia de prompt no uso real: do NTC ao Prompthen Bench — 28 modelos de IA, 7 engenharias, 2 idiomas

Existe uma frase que virou senso comum e que eu acho errada: a de que, se você quer que a IA acerte mais, precisa de um modelo maior. Trocar de plano, pagar mais caro, esperar a próxima geração. Quase todo mundo que trabalha com isso já engoliu essa lógica em algum momento.

Este texto é sobre o que aconteceu quando eu fui na direção oposta: em vez de trocar o modelo, mudar a forma como a informação chega até ele. A tese, do começo ao fim, é uma só — comunicação vale mais que tamanho de modelo —, e ela aparece de dois jeitos, medidos em dois momentos diferentes.

O artigo tem duas partes. A primeira é o estudo de compreensão de outubro de 2025, que validou uma engenharia de prompt que eu chamo de NTC em 6 modelos e 36 testes. A segunda é o Prompthen Bench: uma semana de testes que eu fechei em 22 de julho de 2026 — mais uma execução retardatária, presa por quota, que completou no dia 27 — foram 18.375 respostas de IA avaliadas uma a uma contra gabarito, somando 35 execuções completas de 525 células cada, com 28 modelos de 6 provedores, 7 engenharias de prompt e 2 idiomas. Até onde eu sei, é o maior estudo aberto de engenharia de prompt já feito no Brasil. A primeira parte já estava publicada; a segunda nasceu de uma pontinha solta da primeira que ficou me incomodando por quase um ano.

O essencial em nove frases

• É o maior estudo aberto de engenharia de prompt já feito no Brasil. Até onde eu sei, nenhum outro benchmark brasileiro publicou tantas medições com dados abertos: 18.375 respostas de IA avaliadas uma a uma contra gabarito.
• O ambiente importa mais que o formato. O mesmo modelo dentro de uma ferramenta CLI ou chamado por API Direta muda de patamar: o Sonnet 5 saltou +20,6 pontos só trocando de ambiente, sem mudar uma vírgula do prompt.
• Thinking importa mais que tudo. Ligar o raciocínio no Gemini 3.5 Flash-Lite levou a acurácia de 6,5% para 48,2% — +41,7 pontos, o maior efeito isolado do estudo inteiro.
• Português venceu o inglês no agregado — 48,56% contra 47,47% —, mas o placar por execução foi 16 a 17, com 2 empates: o PT ganha na soma porque seus ganhos são maiores, não porque acontecem mais vezes. Nos extremos, até +12,9 pontos num único modelo.
• Entre os formatos do topo não houve diferença. O NTC fez 48,99% e o XML-PT 48,69% — oito acertos em 2.625, e o teste de McNemar dá p=0,76. O único contraste de formato que resiste estatisticamente é que o YAML em inglês ficou atrás. O que o NTC entrega de distinto é compactação: no prompt denso em instrução é o menor dos sete, com o XML precisando de até 67% mais caracteres.
• Cinco modelos abertos couberam em 4,3 pontos. Em 2025 era um DeepSeek solitário; em 2026 é um pelotão brigando de igual para igual.
• A alegação de eficiência do Google se confirmou nos nossos dados. O Gemini 3.6 Flash, lançado em 21 de julho e medido no dia 22, entregou +4,2 pontos de acurácia gastando 40% menos.
• A família GPT-5.6 dominou o sistema que ninguém tinha visto antes. No VOLTGRID, um sistema inventado para o estudo, os GPT-5.6 ocuparam as seis primeiras posições — o sinal mais forte contra memorização.
• Engenharia de prompt não morreu. A gente mediu. Trocar de idioma valeu mais do que uma geração inteira de modelo em vários casos.
• Quando o acerto empata, quem decide é o token. Seis das sete engenharias couberam em 0,88 ponto de acurácia — mas o XML-PT precisa de 45% mais tokens que o MD-EN para chegar ao mesmo lugar. Engenharia de prompt é acertar e custar pouco; medir só a pontuação responde metade da pergunta.

Sumário

• O problema de verdade não é o custo. É a comunicação.
• A jornada até o NTC
• O problema que o NTC resolve
  • Quando o system prompt cresce e a janela de contexto vira o gargalo
  • Quando a IA começa a ignorar regras no meio da tarefa
  • Quando a conta da API sobe e o resultado não acompanha
• Como validamos em 2025: 6 modelos, 36 testes
• O que descobrimos em 2025
• Modelo pequeno pode render como um grande?
• Dá para cortar 56% dos tokens sem perder qualidade?
• Como garantir que a compressão não quebre a instrução
• Dá para gerar NTC de forma confiável?
• A ponte: a rodada incompleta que virou o Bench
• Por que criamos nosso próprio teste
• O que o Prompthen Bench tem de diferente
• Os três grupos: GRID, CASCADE, VOLTGRID
• As sete engenharias, lado a lado
• Ranking GRID
• Ranking CASCADE
• Ranking VOLTGRID
• Ranking geral: os 35 runs
• Engenharia de prompt morreu? A gente mediu.
• O NTC no Bench
• Cada modelo, cada engenharia, em cada grupo
  • Grupo GRID — Indução visual em grades
  • Grupo CASCADE — Cascata de três regras
  • Grupo VOLTGRID — O sistema inventado
• O achado do idioma
  • Os três maiores saltos de idioma
  • O controle do 2.5 Pro: o placar variou, a direção não
  • Por que isso é difícil de aceitar — inclusive para a própria IA
• Ambiente: API Direta contra Harness CLI
• O efeito do thinking
• O Google disse melhor e mais econômico. A gente mediu.
• Modelos abertos já servem para produção?
• O Grok
• O retardatário: o Codex Spark
• A crítica à Anthropic
• Dois testes, duas medidas: a ponte do 2.5 Pro
• O que fazer com isso
• Limitações e escopo
• Como citar este estudo

Parte 1 — A origem e o estudo de 2025

O problema de verdade não é o custo. É a comunicação.

Conversar com um modelo de IA em linguagem natural é caro de um jeito que a gente nem percebe. É verboso: você escreve três parágrafos para dizer algo que caberia numa linha. É ambíguo: a mesma frase pode ser lida de duas maneiras, e você só descobre qual delas o modelo escolheu quando a resposta chega torta. E é frágil: um detalhe fora do lugar e a instrução inteira muda de sentido.

O caminho que a maioria segue para lidar com isso é o da compressão. Encurta, resume, poda. O problema é que compressão, feita assim, é subtração. Você tira palavras e reza para que o sentido sobreviva. Às vezes sobrevive. Muitas vezes não — e o modelo passa a responder com base numa versão empobrecida do que você queria dizer.

A pergunta que ficou martelando foi outra. E se o gargalo não fosse a quantidade de palavras, mas a forma como a informação é entregue ao modelo? E se o problema não fosse falar demais, mas falar de um jeito que a IA precisa se esforçar para entender?

O objetivo nunca foi economizar tokens. O objetivo sempre foi fazer o modelo performar melhor. A economia de tokens veio como consequência da eficiência, não como meta — e essa distinção parece pequena, mas não é. Quando sua meta é gastar menos, você mede o sucesso pela conta no fim do mês, e a qualidade vira uma variável que você tenta não estragar. Quando sua meta é o modelo entender melhor, você mede o sucesso pelo acerto — e aí uma informação bem organizada acaba sendo, ao mesmo tempo, mais fácil de entender e mais enxuta. As duas coisas andam juntas quando você mira na compreensão. Só brigam quando você mira no corte.

O sistema que fez isso funcionar se chama NTC. A engenharia de prompt NTC é proprietária, criada por mim — o mesmo caminho que me levou ao método Prompthen. E chamo de engenharia de prompt sabendo que o termo ficou pequeno: na prática ela é tanto engenharia de prompt quanto engenharia de contexto, porque o que ela otimiza não é uma frase isolada — é a camada inteira de instrução que ocupa a janela de contexto do modelo. Por ser proprietária, o que compartilho são os resultados, o desempenho e a metodologia, não os detalhes internos. Mas por ser um estudo de caso, eu vou mais fundo no dado do que num post comum: abro a tabela, nomeio os modelos, mostro de onde veio cada número. Inclusive as limitações.

A jornada até o NTC

O NTC não nasceu pronto num dia, e eu não vou fingir que foi um lampejo. Ele é o fim de uma estrada longa de tentativa e erro — e, para contar direito, preciso voltar ao começo de 2025, quando eu procurava a melhor forma de incorporar a IA moderna aos projetos que eu já desenvolvia.

Na época, o jeito mais fácil de programar com IA eram os forks do VSCode preparados para isso. Os dois mais populares eram o Cursor e o Windsurf. Você assinava o plano menor e num instante já estava desenvolvendo. Era prático — mas, para mim, o desempenho era bom só em coisas pequenas. Em projeto longo, a forma como eles geriam a janela de contexto deteriorava tudo. E é justo dizer: gerir janela de contexto no início de 2025 não era fácil para ninguém; os modelos estavam começando a ficar bons de verdade naquele momento.

O passo que mudou o meu jeito de trabalhar foi sair do ambiente pronto e ir para o RooCode, direto no VSCode — um derivado do Cline. Foi ali que comecei a usar agentes de IA com o system prompt e as instruções separados por tipo de tarefa: um para planejar, um para desenvolver, um para testar. Eu pegava a base e reescrevia os prompts do meu jeito. Foi trabalhando assim, com tarefas atômicas, que senti na prática algo que carrego até hoje: é muito mais eficiente ter um agente principal, com acesso a toda a janela de contexto, delegando tarefas menores que um outro agente executa numa janela separada, sem entupir a do coordenador. É uma evolução exata disso que eu faço hoje, com coordenadores e sub-agentes especialistas.

Só que junto com a vantagem vinha um problema grande, e é dele que nasce toda esta história. Aquelas instruções separadas por tarefa eram densas de um jeito absurdo. O RooCode exigia uma montanha de texto no system prompt. Usar um modelo com janela abaixo de 200 mil tokens era sofrido: em poucos vai-e-vem a janela já estava no fim. Por isso eu vivia no Gemini, pela janela grande. E o custo doía: teve semana em que gastei uns 10 mil reais só de API do Gemini; no Claude, mais caro ainda. Não existia o plano MAX de hoje; era tudo API, na conta aberta.

Então eu me sentava para entender cada instrução e reescrever, tirando o que não servia, somando regra e protocolo. Virou um vai-e-vem sem fim — eu enxugava, gastava menos, e com o tempo inflava tudo de novo. Uma batalha. Mas foi nessa batalha, repetida centenas de vezes, que fui aprendendo na prática engenharia de prompt e de contexto. Quem começou com os modelos de 2023 lembra: antes de eles terem o "pensamento" integrado, a gente precisava forçar a reflexão na base da instrução.

E aqui entra uma coisa que levo para a vida: a repetição é o que te torna melhor. Aqueles milhares de reais e de tokens me obrigaram a repetir a otimização tantas vezes que virou método. Eu criava o mesmo projeto centenas de vezes, comparando resultado, caçando a melhor forma de instruir — não só no Gemini e no Claude, mas nos gratuitos, nos da China, nos mais baratos. E descobri uma coisa que quase ninguém diz em voz alta:

Se você perguntar a um modelo de IA como instruí-lo melhor, ele vai repetir o que aprendeu a dizer — escreva em inglês, organize em markdown. Mas existem coisas que funcionam na IA que nem ela mesma sabe. A IA não sabe do que ela não sabe. Você só descobre testando à exaustão.

Aqueles system prompts gigantescos foram encolhendo: de 40 mil tokens para 35, para 30. Mas a redução nunca foi o objetivo em si. O objetivo era o modelo entender melhor. Foi essa engenharia em busca de clareza que, no segundo semestre de 2025, deu origem ao NTC.

E o nascimento foi surpreendente. Eu estava trabalhando noite adentro, comparando prompts que criei para gerar páginas web. Tinha umas dez versões do mesmo system prompt na mesa. E uma delas era estranha. Meu agente planejador dizia que não ia funcionar — que eu teria de ensinar o que aquelas coisas esquisitas significavam. Só que nos testes ela sempre performava melhor. Naquela noite eu resolvi dissecar. Quebrei os testes em fragmentos, comparei parte por parte — e foi ali que montei a primeira versão do que o próprio agente ajudou a nomear como NTC. Funcionou tão bem que eu não acreditei; achei que ele tinha pego uma técnica pronta. Foi quando ele me disse, e eu guardo a frase:

"Não, Paulo, o NTC não existe. Foi a partir desses nossos testes exaustivos — você criou isto agora, nesta janela de contexto onde estamos. Não existe NTC nenhum. Foi um nome que inventei a partir do que testamos. É algo que criamos aqui."

Não conto isso para me gabar. Achei uma coisa que, para o meu uso, funcionava — e funcionava especialmente bem nos system prompts longos, que eram justamente a minha dor. Aumentava a clareza a ponto de os modelos entenderem sem treino prévio. E a economia vinha junto: em prompts longos, eu chegava a 70, às vezes 80% de redução de tokens. No estudo controlado que mostro adiante, medido token a token, o número que aparece é uma média de 56%, com o melhor caso em 73,7%. Um é a minha vivência com os prompts mais inchados; o outro é o experimento limpo. Os dois são verdade.

Foi depois de meses usando o NTC no dia a dia que resolvi fazer a bateria de testes que esta primeira parte conta — em outubro de 2025. Não foi o nascimento do NTC; foi a validação do que eu já tinha comprovado na prática. Era para eu ter publicado ainda em outubro, mas a correria fez esse artigo levar quase um ano para sair.

O problema que o NTC resolve

Antes de ir para os números, vale nomear direto as três dores que me levaram até aqui. Se alguma delas é a sua, o resto do artigo faz muito mais sentido.

Quando o system prompt cresce e a janela de contexto vira o gargalo

Você monta um agente sério e a camada de instrução incha: regras, protocolos, definições de papel, exemplos, o que fazer e o que não fazer. No meu caso os system prompts do RooCode chegaram a 40 mil tokens. Com um modelo de janela abaixo de 200 mil, bastavam poucos vai-e-vem para a janela encher — e aí você está pagando para o modelo carregar a própria instrução em vez de trabalhar no problema.

O reflexo natural é cortar texto. E cortar texto é subtrair sentido: você tira palavras e torce para que a intenção sobreviva. Muitas vezes não sobrevive, e o modelo passa a responder com base numa versão empobrecida do que você queria dizer.

O caminho que funcionou para mim foi outro: reorganizar em vez de encurtar. Isso é menos "escrever um prompt melhor" e mais engenharia de contexto: decidir o que entra na janela do modelo, em que ordem e com que estrutura, para que a mesma informação seja entendida com menos esforço — e, como consequência, ocupe menos espaço. Foi assim que aqueles 40 mil tokens viraram 30, depois 20, depois 15, sem perder regra nenhuma.

Quando a IA começa a ignorar regras no meio da tarefa

Essa é a dor que mais irrita, porque parece falha de capacidade do modelo e muitas vezes é falha de comunicação. Você escreveu a regra, ela está lá no prompt, e mesmo assim o agente atropela.

A parte contraintuitiva que os testes mostraram: estrutura não atrapalha, estrutura ajuda. Quando peguei a mesma informação e organizei em camadas — o principal separado do detalhe —, a compreensão média dos modelos saltou de 75% para 95%, um ganho de 20 pontos sem trocar de modelo e sem acrescentar uma palavra de conteúdo. O inimigo da compreensão não é a densidade da informação; é a bagunça.

E há um efeito colateral que me surpreendeu: informação bem estruturada é mais resistente a erro. Injetei 47 erros de propósito numa especificação e a compreensão caiu só 6 pontos — nenhum dos 6 modelos sequer apontou que havia erros. O modelo lê a intenção, não a letra, desde que a intenção esteja organizada.

Quando a conta da API sobe e o resultado não acompanha

Teve semana em que gastei 10 mil reais só de API do Gemini — no Claude, mais caro ainda. Não existia plano de assinatura como hoje; era tudo API, na conta aberta. E o pior não era o valor: era saber que boa parte daquilo estava sendo gasta para o modelo reler instrução, não para produzir trabalho.

Aqui está a distinção que mudou tudo para mim: comprimir é diferente de clarear. Comprimir paga a economia com um pedaço da qualidade. Clarear faz as duas coisas subirem juntas — o modelo entende melhor e o texto ocupa menos. Medido em 93 pares reais de produção, token a token, a redução foi de 56,45% no agregado, chegando a 73,7% no melhor caso, com a compreensão subindo no mesmo movimento.

Não é mágica e tem limite: no Prompthen Bench, que usa prompts curtos e cheios de dado bruto, essa vantagem encolhe — em um dos grupos o NTC chega a custar mais que o Markdown. A compactação cresce com a densidade de instrução, e é por isso que ela brilha em system prompt e some em grade numérica.

Como validamos em 2025: 6 modelos, 36 testes

A montagem do teste foi deliberadamente hostil ao NTC. A ideia era não facilitar.

Pegamos 6 modelos de IA de 3 empresas diferentes — Google, OpenAI e Anthropic — de tamanhos bem variados. Rodamos 5 experimentos de complexidade crescente, mas o quinto teve duas fases (um controle e uma versão com erros injetados), o que dá 6 rodadas no total. Seis rodadas vezes seis modelos são 36 testes.

O detalhe cruel: cada especificação foi enviada sem nenhuma explicação prévia. Zero system prompt. Só a especificação em NTC e uma pergunta seca — o que isso representa? Se o modelo não entendesse de imediato, teríamos que admitir que o NTC só funciona para quem já foi treinado nele.

Um fato que registro de uma vez: a pontuação de compreensão é uma avaliação criteriosa numa escala própria de 0 a 100%, com uma medição por modelo por experimento (n=1 em cada célula), e as transcrições brutas desses 36 testes não foram salvas — ficaram as tabelas-resumo. Levo os números a sério e digo de onde eles vêm.

O primeiro resultado vale como frase solta:

Em 36 testes com 6 modelos de 3 empresas diferentes, sem uma linha de explicação prévia, a compreensão média do NTC ficou em 91%.

Nenhum dos 36 testes precisou de manual. O NTC é entendido de imediato — e isso não é detalhe estético, é a diferença entre uma ferramenta que funciona em qualquer lugar e uma que exige setup toda vez.

São modelos da era 2025, os que estavam disponíveis quando montei o teste. Esta é uma validação de outubro de 2025, com os modelos daquela época. O que não envelhece é o padrão que os números revelam: estrutura sobe a compreensão, e o modelo pequeno se aproxima do grande.

O que descobrimos em 2025

Estrutura não atrapalha. Estrutura ajuda.

Essa foi a descoberta que mais mexeu com a minha cabeça, porque contraria a intuição.

O primeiro experimento testou um formato mais "plano" — a informação toda no mesmo nível. A média dos 6 modelos ficou em 75%, com uma dispersão enorme: o melhor cravou 95%, o pior derrapou em 30%. No segundo experimento, organizamos a mesma informação de forma hierárquica — com camadas, o principal separado do detalhe. E a compreensão média saltou para 95%. Um ganho de +20 pontos, na mesma informação, só arrumando a casa.

A progressão completa das rodadas, sempre pela média dos 6 modelos, foi esta:

• Experimento 1 — formato plano: 75% (variando de 30% a 95%).
• Experimento 2 — a mesma informação, hierárquica: 95% (+20 pontos).
• Experimento 3 — densidade máxima de estrutura: 97%, o pico.
• Experimento 4 — estrutura recursiva: 93%. Aqui já dá para ver o platô.
• Experimento 5A — caso de controle, limpo: 96%.
• Experimento 5B — o mesmo caso, com 47 erros injetados: 90% (a rodada de robustez).

A leitura é dupla. De um lado, derruba a intuição: complexidade bem estruturada não afunda a compreensão, ela sobe. De outro, mostra o limite — do Exp3 para o Exp4 o ganho estabiliza e começa a ceder. O NTC tem um regime onde brilha, e ele não escala para o infinito.

Complexidade bem estruturada ajuda a IA a entender, em vez de atrapalhar. O inimigo da compreensão não é a densidade da informação — é a bagunça.

Robustez: o comportamento de auto-cura

Foi o par 5A/5B. Peguei a especificação limpa do controle (que fez 96%) e introduzi 47 erros propositais espalhados pelo texto. A compreensão média caiu de 96% para 90% — 6 pontos diante de 47 erros deliberados, uma degradação relativa de cerca de 6,5%. E a distribuição por modelo revela o achado: o Haiku 3.5, um dos menores, degradou só 5,6%, enquanto o GPT-4o, um dos grandes, caiu 10,2%. O pequeno aguentou o tranco melhor.

O mais notável é que nenhum dos 6 modelos sequer apontou que havia erros. Todos entenderam o sentido e seguiram em frente — como você lê um texto com erros de digitação sem perceber, porque seu cérebro conserta na hora. O modelo lê a intenção, não a letra.

Modelo pequeno pode render como um grande? O achado que muda o jogo

Se você lê só uma parte desta primeira metade, que seja esta.

Quando quebramos os resultados por modelo, apareceu o padrão que sustenta tudo. Os modelos menores e mais baratos se aproximaram dos grandes quando a informação foi bem estruturada com NTC. Repare na palavra: se aproximaram. Não empataram com o topo — encurtaram a distância, e muito.

O exemplo mais forte tem nome. No primeiro experimento, o Sonnet 4.5 foi o pior de todos: 30% de compreensão. No segundo, com a mesma informação reorganizada com NTC, ele foi a 85%. Um salto de +55 pontos. Não trocamos o modelo. Mudamos só como a informação chegava até ele.

Agora a parte que faço questão de não exagerar. O Sonnet se aproximou do pelotão de cima — mas o topo, o Gemini 2.5 Pro, tinha média 98,5%. O pequeno encurtou a distância; ele não igualou o grande. Essa diferença importa: o NTC não transforma um modelo pequeno num grande. Ele faz o pequeno render muito mais do que rendia — o suficiente, na maior parte do trabalho, para você não precisar do grande.

O NTC não pede um modelo melhor. Ele faz o modelo que você já tem render mais — só mudando a forma como você fala com ele. O pequeno não vira o grande; ele encurta a distância a ponto de dar conta do trabalho.

Dá para cortar 56% dos tokens sem perder qualidade? Medimos em 93 pares reais

Chegamos na parte que todo mundo espera que seja o começo — e que para nós é o fim da história.

A economia não veio de estimativa nem de um caso escolhido a dedo: veio de 93 pares reais de produção — os arquivos que o nosso gateway serve todo dia, cada um numa versão original e numa versão em NTC, contados token a token com o tokenizador cl100k. O enquadramento do corpus: esses 93 pares são system-prompts, descrições de ferramentas e catálogos de skills no estilo Anthropic — instrução técnica densa, o terreno em que o NTC mais brilha.

Os números, com a conta aberta:

• No agregado, os 93 pares somavam 418.158 tokens na versão original e 182.121 tokens em NTC — uma redução de 56,45%.
• Por par, a mediana de redução foi 55,72%. O melhor caso chegou a 73,7%. E o pior foi −3,3%: um único par ficou levemente maior em NTC. Aconteceu, está na conta.
• Por tipo de conteúdo, os catálogos de skills reduziram mais (58,18%) que as descrições de ferramentas (45,32%).
• Dois exemplos concretos: a descrição da ferramenta AskUserQuestion foi de 237 para 186 tokens (21,5% menos); e o melhor par, um catálogo de skills, foi de 7.834 para 2.063 tokens (73,7% menos).

Dá para dizer, sem inflar, que o NTC entrega em torno de 56% de redução agregada, chegando a ~74% no melhor caso, medido num corpus real e verificável.

A economia de tokens do NTC é consequência da eficiência, não o objetivo dela. E ela não custou qualidade: a compreensão subiu e o custo caiu no mesmo movimento.

Como garantir que a compressão não quebre a instrução: o portão que roda em produção

Tem uma diferença enorme entre um número bonito num relatório e um número que precisa se provar todo dia. O NTC é a camada de compressão que roda dentro de dois sistemas que construí: é o cache interno do gateway de IA que uso em produção e a etapa que densifica a memória do Exocortex, a minha memória permanente em camadas. Ele não é uma demonstração — é infraestrutura, acionada centenas de vezes por dia.

E toda compressão que ele serve passa por um portão automático. A regra é dura: a compressão precisa ficar entre 20% e 80% de redução — nem de menos nem de mais — e preservar pelo menos 90% das diretivas do texto original. Se falhar em qualquer um dos dois critérios, é rejeitada.

Dá para gerar NTC de forma confiável?

O primeiro estudo respondeu: a IA entende NTC? Sim. Ficou uma segunda pergunta: dá para a IA gerar NTC de forma confiável? Esse estudo separado teve as transcrições salvas, então é mais reproduzível.

Foram 3 modelos Gemini, 3 casos cada, num total de 9 traduções de linguagem natural para NTC. A qualidade média ficou em 92%, 100% do código Python foi preservado literalmente e houve zero perguntas de esclarecimento. Mas em 22% dos testes (2 dos 9), o modelo inventou propriedades que não estavam no input. Numa tradução, inventar é um defeito grave. Foi ele que me levou a um v2 do prompt do tradutor — o v2 é do prompt que instrui a IA a traduzir, não do NTC. No reteste, a qualidade subiu de 9,2 para 9,4.

Parte 2 — O Prompthen Bench

A ponte: a rodada incompleta que virou o Bench

Na primeira versão deste artigo, publicada em julho de 2026, eu contei que tinha testado o NTC num benchmark de raciocínio puro — o ARC-AGI-2, uma bateria de quebra-cabeças visuais e lógicos — e que nem cheguei a completar a rodada, porque ficou claro cedo que aquele não era o terreno do NTC. Deixei registrado como exploração, sem cravar número.

Aquela rodada incompleta ficou me incomodando. Um teste que eu comecei e não terminei é um pedaço de curiosidade que não descansa. Em julho de 2026 eu voltei a ele — e ele virou o maior estudo que já fiz.

A pergunta que o Prompthen Bench responde é direta: formato de prompt muda o acerto em raciocínio duro? E o que mais muda? Se muda, quanto? Se não muda, o que decide? A primeira parte deste artigo mediu compreensão — se a IA entende. Esta segunda parte mede acerto — se a IA resolve. São coisas diferentes, e essa diferença vai voltar mais de uma vez daqui para frente.

Por que criamos nosso próprio teste

Os benchmarks públicos estão saturados. Modelo nenhum guarda segredo do que vai cair, porque tudo já foi visto no treino. Um teste que o modelo já conhece não mede raciocínio; mede memória. Eu queria o contrário: um teste difícil de propósito, com puzzles que o modelo tivesse de resolver na hora, sem atalho de memorização.

Difícil de verdade. O puzzle mais duro do estudo — uma cascata de regras que eu batizo abaixo — teve 0% de acerto em 35 execuções: ninguém, nenhum modelo, em nenhum formato, acertou uma vez sequer. E o teto do estudo inteiro, o melhor modelo na melhor configuração, ficou em 77,5%. Quando o topo não passa de 77,5% e o fundo é zero absoluto, você sabe que o teste tem espaço para separar quem raciocina de quem chuta.

A escala fechou assim: 35 execuções de 525 células cada — 18.375 respostas avaliadas —, 28 modelos distintos, 6 provedores, custo total de cerca de $900, uma semana de execução, concluída em 22 de julho de 2026 — com uma execução retardatária, presa por quota, completando em 27 de julho.

O que o Prompthen Bench tem de diferente

Quatro escolhas separam esse estudo de um benchmark comum.

Verificação determinística. Cada resposta é comparada, caractere a caractere, contra um gabarito calculado por código. Não há juiz-modelo, não há avaliação subjetiva, não há "quase certo". Ou o modelo produziu a sequência exata, ou errou. Isso mata a discussão sobre critério.

Um sistema que nenhum modelo pode ter visto no treino. Um dos três grupos de tarefas é o VOLTGRID — um sistema que eu inventei para o estudo, com uma regra oculta que não existia em lugar nenhum da internet antes desta publicação. É o desenho que minimiza contaminação por dados de treino, e os resultados dele são os que mais confio.

Os mesmos dados em 7 engenharias × 2 idiomas. O mesmo puzzle foi entregue em sete embalagens diferentes — MD, YAML e XML em inglês e português, mais o NTC — com os dados numéricos byte-idênticos em todas e as instruções semanticamente equivalentes em cada idioma. A única coisa que muda entre uma variante e outra é a forma. Assim, qualquer diferença de acerto é do formato ou do idioma, não do conteúdo.

Os mesmos modelos em API Direta e em Harness CLI. Vários modelos foram testados por duas vias: chamados diretamente pela API do provedor e rodando dentro de uma ferramenta de linha de comando (Claude Code, Codex CLI, grok CLI, qwen CLI). Isso mede o efeito do ambiente como pacote completo — system prompt, ferramentas e configurações que cada CLI traz —, que é exatamente como as pessoas usam esses modelos no dia a dia. E o efeito foi grande.

Os 90 prompts das engenharias abertas e os resultados estão públicos no GitHub: github.com/pauloctxr/prompthen-bench — incluindo o per_cell.csv com as 18.375 células individuais (execução × grupo × puzzle × engenharia × idioma × repetição × acerto), que permite a qualquer pessoa recomputar cada número deste artigo e rodar as próprias análises estatísticas. Vai também o ablation.csv, com os quatro runs do experimento de thinking (os dois modelos Lite, com raciocínio ligado e desligado), separado do ranking porque configuração não é competidor. As seis engenharias abertas estão inteiras lá; o NTC, por ser proprietário, aparece pelos resultados, não pela notação. Os gabaritos ficam retidos para o benchmark continuar utilizável com modelos futuros.

Os três grupos: GRID, CASCADE, VOLTGRID

O estudo tem três famílias de tarefas de raciocínio indutivo. Cada uma testa um músculo diferente, e a dificuldade é do puzzle, não do grupo — há puzzles fáceis e impossíveis dentro de cada um.

GRID é indução visual em grades, no estilo do ARC-AGI-2: o modelo vê alguns pares de grade-de-entrada para grade-de-saída, precisa inferir a regra oculta que transforma uma na outra e aplicá-la a um caso novo. É pattern-matching visual sob pressão.

CASCADE é cascata de regras: três transformações ocultas — Alpha, Beta, Gamma — cada uma convertendo uma sequência de inteiros em outra. O modelo induz as três regras a partir de exemplos e as compõe em cadeia. Foi aqui que mora o puzzle de 0%.

VOLTGRID é o sistema inventado: uma especificação de um sistema fictício com uma regra oculta, alguns traces de execução e a tarefa de ler tudo, inferir a regra e simular o resultado. É o grupo que nenhum modelo pode ter memorizado — e, não por acaso, o que mais separou os modelos.

A dificuldade real de cada puzzle só aparece quando você olha a média de todas as 1.225 respostas que ele recebeu (35 execuções × 7 engenharias × 5 repetições). O intervalo vai de 83,8% a zero absoluto:

Repare que os três grupos aparecem espalhados por toda a tabela: o CASCADE tem o puzzle mais fácil (p0, 83,8%) e o único impossível (p2, 0%). Dificuldade é propriedade do puzzle, não do grupo — e é por isso que eu não trato "GRID" como sinônimo de difícil ou fácil.

As sete engenharias, lado a lado

Falar em "sete formatos" fica abstrato até você ver a mesma tarefa nas embalagens diferentes. Aqui está o começo do mesmo puzzle CASCADE, o mais fácil do grupo, em três engenharias. O conteúdo — as regras, os exemplos, a entrada de teste — é byte a byte o mesmo. Só a estrutura muda.

Em MD (markdown, inglês), a tarefa vira um documento com títulos e listas:

# Task
Three hidden transformation rules — Alpha, Beta, Gamma — each turn a
sequence of integers into another sequence. Infer each rule from its examples.
## Rule examples
### Alpha
- `[8,3,9] -> [11,12,9]`
- `[9,4,5,3,1,4] -> [13,9,8,4,5,4]`

Em YAML (inglês), a mesma tarefa vira uma estrutura de chaves e listas aninhadas, mais compacta:

task: Infer three hidden rules (Alpha, Beta, Gamma) from their examples,
  then apply them in chain to the test input.
rule_examples:
  Alpha:
    - "[8,3,9] -> [11,12,9]"
    - "[9,4,5,3,1,4] -> [13,9,8,4,5,4]"

Em XML (português), a mesma tarefa vira uma árvore de tags nomeadas — a mais verbosa das três:

<tarefa>Infira tres regras ocultas (Alpha, Beta, Gamma) a partir de seus
exemplos, depois aplique-as em cadeia a entrada de teste.</tarefa>
<exemplos_das_regras>
  <regra nome="Alpha">
    <exemplo>[8,3,9] -> [11,12,9]</exemplo>
    <exemplo>[9,4,5,3,1,4] -> [13,9,8,4,5,4]</exemplo>

Repare no que muda só de olhar: a mesma regra Alpha, o mesmo exemplo [8,3,9] -> [11,12,9], ocupa uma linha de lista no MD, uma linha entre aspas no YAML e uma tag <exemplo> inteira no XML. A informação é idêntica; o volume de estrutura ao redor dela, não. O NTC é a sétima embalagem — a que carrega a mesma informação com a menor quantidade de estrutura ao redor, especialmente quando a densidade de instrução cresce. Ele entra nos rankings como qualquer outra, medido pelo acerto.

Ranking GRID

Indução visual em grades. Os dez primeiros, por acurácia no grupo:

As 35 execuções completas no GRID:

A leitura mais interessante aqui é o Gemini 3.5 Flash-Lite empatado em segundo com o Gemini 3 Flash, ambos com 66,3% — e o Lite é um modelo minúsculo de custo baixíssimo. A indução visual não escala com o tamanho do modelo do jeito que a gente esperaria: um Lite bem configurado (com thinking, como veremos adiante) segurou o topo de um grupo que muita gente grande não dominou. Repare também que cinco das dez posições são da família Gemini. GRID recompensa o padrão certo, não a força bruta.

Ranking CASCADE

Cascata de regras compostas em cadeia. Os dez primeiros:

As 35 execuções completas no CASCADE:

O Gemini 3.1 Pro lidera com 80,0%, e o grupo muda a hierarquia: o Grok 4.5 sobe ao pódio (77,1%, empatado com o sol) e os Gemini Flash aparecem fortes no meio da tabela. CASCADE premia raciocínio composicional — segurar três regras na cabeça e encaixá-las na ordem certa — e aí modelos que não lideram os outros grupos ganham posição. É também o grupo onde vive o puzzle de 0%: uma cascata específica que nenhum modelo, em nenhuma configuração, resolveu.

Ranking VOLTGRID

O sistema inventado, que nenhum modelo pode ter visto no treino. Os dez primeiros:

As 35 execuções completas no VOLTGRID:

Aqui está o resultado que mais me chama atenção. A família GPT-5.6 ocupou as seis primeiras posições, com o sol chegando a 89,7% — o pico de qualquer grupo no estudo inteiro. E isso num sistema que ninguém pôde ter memorizado, porque ele não existia antes deste estudo. Quando você tira a memorização da jogada e sobra raciocínio puro sobre um sistema novo, aparece um degrau real: os GPT-5.6 leem uma especificação inédita, inferem a regra e simulam o resultado melhor que todo o resto. Esse é o sinal de capacidade mais limpo que eu tenho.

Ranking geral: os 35 runs

A média das três famílias, por execução. A coluna Ambiente separa o que rodou via API Direta do que rodou dentro de um Harness CLI — porque, como você vai ver, isso muda tudo.

* O 59,6% do Fable 5 é o dado oficial: célula que ele não respondeu conta como erro, sem dedução. Há uma história inteira por trás desse número — está na seção da crítica à Anthropic, mais abaixo, com todos os detalhes.

O Gemini 2.5 Pro aparece duas vezes de propósito (34,9% e 33,0%): são duas rodadas independentes do mesmo modelo, e eu deixei as duas no ranking porque a proximidade entre elas — menos de dois pontos — é a prova de que o método é estável, não um best-of viciado.

E como cada execução se comportou nos três grupos, lado a lado — é aqui que dá para ver quem é regular e quem é especialista:

Leia na horizontal e os perfis saltam. O Gemini 3.1 Pro é o caso mais extremo: lidera o CASCADE com 80,0% e despenca para 52,0% no VOLTGRID — forte em compor regras dadas, fraco em inferir a regra que ninguém contou. O GPT-5.6 sol faz o oposto: 89,7% no VOLTGRID, seu pior grupo é o GRID. Um ranking único esconde isso; três colunas mostram. Volto ao 2.5 Pro numa seção própria, porque o número dele conta uma história que só faz sentido com as duas partes deste artigo lado a lado.

Engenharia de prompt morreu? A gente mediu.

Existe uma frase circulando de que engenharia de prompt acabou — de que os modelos ficaram tão bons que a forma de falar com eles não importa mais. Eu tenho dados sobre isso. Vamos comparar duas coisas: o que uma geração nova de modelo entrega, e o que uma alavanca de engenharia entrega no mesmo modelo.

Primeiro, os saltos de geração, medidos no mesmo ambiente:

• Gemini 3.5 Flash → 3.6 Flash: +4,2 pontos.
• Gemini 3 Flash → 3.5 Flash: +4,9 pontos.
• Kimi K2.6 → K3: −0,5 ponto (geração nova nem sempre melhora).
• Opus 4.6 → 4.8, em API Direta: +21,5 pontos.
• Gemini 2.5 Pro → 3.1 Pro: +30,1 pontos (um salto de duas gerações inteiras).

Agora, as alavancas de engenharia, no mesmo modelo:

• Idioma: o Sonnet 5, de inglês para português, ganhou +12,9 pontos.
• Formato: a diferença entre a melhor e a pior engenharia, dentro de um mesmo modelo, variou de 1,3 a 21,3 pontos, com mediana de 12.
• Ambiente: o Sonnet 5, de API Direta para Claude Code, ganhou +20,6 pontos.
• Thinking: ligar o raciocínio no Gemini 3.5 Flash-Lite valeu +41,7 pontos.

Ponha os dois lado a lado:

O salto de geração do Gemini Flash deste mês valeu +4,2 pontos. Escolher o idioma certo no Sonnet 5 valeu +12,9. Quem diz que engenharia de prompt morreu está repetindo uma frase que nunca testou.

A nuance honesta, e ela é importante: das quatro alavancas, três passam no teste estatístico e uma não. Thinking, ambiente e idioma têm efeito comprovado — thinking com uma margem esmagadora. Já o formato, no agregado, quase não separou: entre as engenharias do topo a diferença é indistinguível de zero. Procurei também se os modelos mais fracos seriam mais sensíveis à embalagem e não encontrei essa relação. Então a conclusão fica assim: engenharia de prompt não morreu de jeito nenhum — mas ela deixou de ser sobre "escolher markdown ou XML" e passou a ser sobre ligar o raciocínio, escolher o ambiente e testar o idioma. É aí que estão os pontos que se movem.

O NTC no Bench

Na média entre todos os modelos, o topo terminou em empate técnico entre o NTC (48,99%) e o XML-PT (48,69%) — oito acertos de diferença em 2.625 células, ou seja, ruído. A tabela completa das sete engenharias, cada uma medida sobre as mesmas 2.625 células:

Tokens medidos com o tokenizador cl100k, média dos 15 puzzles do estudo.

Acerto empatado? Então a conta passa a ser o token

Seis das sete engenharias couberam em 0,88 ponto de acurácia. Se você parar aqui, a conclusão é "tanto faz o formato". É a leitura errada — e a coluna de tokens mostra por quê.

Engenharia de prompt tem duas métricas, não uma: acertar e custar pouco. A tabela de acurácia sozinha só responde metade da pergunta. Com as duas colunas lado a lado, a decisão fica direta:

• NTC e XML-PT estão a 0,30 ponto de acurácia — o mesmo resultado, na prática. Só que o XML-PT consome 35% mais tokens para chegar lá.
• XML-EN é dominado por completo: perde em acurácia para NTC, MD-PT e YAML-PT e custa 28% mais que o MD-EN. Não há cenário neste teste em que ele seja a escolha certa.
• YAML-EN também é dominado: é o pior em acerto (46,02%, e essa diferença resiste a teste estatístico, p=0,0004) por praticamente o mesmo custo do MD-EN.
• Sobram dois na fronteira de eficiência: o NTC, que tem a maior acurácia por 507 tokens, e o MD-EN, que é o mais barato (473) pagando 0,88 ponto de acerto. Todo o resto é dominado por um dos dois.

A regra de bolso que sai daqui: acerto maior com menos token, use. Acerto igual, use o que gasta menos. Neste estudo, tudo que é XML paga um pedágio de 28% a 45% em tokens sem comprar acurácia nenhuma.

E o efeito é maior justamente onde a instrução domina. Olhe o VOLTGRID, o grupo mais denso em especificação:

Aqui o NTC entrega a melhor acurácia praticamente pelo menor custo — 2 tokens acima do YAML-EN, que é o pior em acerto. O XML-PT precisa de 50% mais tokens para acertar 2 pontos a menos. É exatamente o terreno para o qual o NTC foi feito: instrução densa, muita regra, pouco dado bruto.

E onde ele não compensa: no GRID, que é 85% de grade numérica, o NTC gasta 594 tokens contra 471 do MD-EN — 26% a mais, sem vantagem de acerto que justifique. Sem instrução para compactar, ele paga o custo da própria estrutura. Está na conta, e eu não vou esconder.

O mesmo raciocínio vale para o idioma: se duas versões acertam igual, escolha a mais curta; se uma acerta mais, veja o que ela custa. O português tende a ocupar mais tokens que o inglês no mesmo formato (o MD-PT gasta 13,5% mais que o MD-EN), então "português é melhor" só se sustenta quando o ganho de acerto paga esse custo — e no Sonnet 5, que ganhou 12,9 pontos, paga com folga.

Uma ressalva de honestidade sobre a acurácia. As diferenças de acerto entre as engenharias do topo são pequenas demais para o tamanho da amostra: NTC contra XML-PT dá p=0,76 no teste de McNemar; NTC contra MD-PT, p=0,69. Dentro de cada execução a distância entre a melhor e a pior chega a 12 pontos na mediana, mas com 75 respostas por engenharia parte disso é ruído — trate como indício de onde investigar, não como veredito. A diferença de tokens, essa não tem ruído nenhum: contar tokens é determinístico, e 45% a mais é 45% a mais em toda chamada, todo dia, para sempre.

O placar de vitórias reforça o mesmo: as sete engenharias venceram em pelo menos quatro execuções cada (NTC 9, MD-PT 7, XML-EN 7, XML-PT 7, MD-EN 5, YAML-EN 5, YAML-PT 4, contando os empates no topo para todas as empatadas), num resultado que o acaso sozinho já explicaria. Não há formato campeão universal — há o que funciona no seu modelo e o que custa menos para chegar lá. As duas perguntas juntas, sempre.

Quatro casos onde a engenharia decidiu a partida (cada engenharia medida sobre 75 respostas):

Repare na última linha: no Gemini 2.5 Pro o NTC é a pior das sete. Não é um estudo que só mostra a própria aposta ganhando — o mesmo formato que dá 65,3% ao Opus dá 26,7% ao 2.5 Pro. Isso é exatamente o ponto: modelos diferentes respondem de formas diferentes, e um ranking somado esconde essa informação, que é a mais útil de todas.

E o idioma sozinho, mantendo a engenharia fixa (mesmo formato, mesmos dados, só a língua da instrução muda):

Vinte pontos de diferença só por trocar o idioma do mesmo formato — e em direções opostas conforme o modelo. No agregado geral, o português aparece 1,09 ponto à frente do inglês. Esse 1,09 é o resíduo de ganhos de +20 e perdas de −13 se cancelando. A média não mede o efeito; ela mede o que sobra depois que os efeitos se anulam.

Por isso as tabelas por modelo, mais adiante, importam mais que esta. Nelas o efeito aparece inteiro — e é lá que está a informação acionável: qual formato e qual idioma usar no seu modelo.

Contando quantas vezes cada engenharia foi a campeã dentro de um modelo, o NTC aparece em primeiro com 9 vitórias nos 35 runs, à frente do MD-PT, do XML-EN e do XML-PT (7 cada). Não vou vender isso como troféu: com sete formatos e 35 execuções, o esperado por acaso é cerca de 5 vitórias por formato. Nove não se distingue de sete. Por família, o NTC ficou em segundo no grupo Claude e no DeepSeek, e em terceiro entre os abertos.

E onde ele não brilhou: no Gemini 2.5 Pro, o NTC foi o último dos sete, com 26,7%. O 2.5 Pro preferiu dados espalhados em grade a instrução densa — e isso é coerente com a natureza dele, um ponto que retomo na próxima seção. Estudo bom mostra também onde a própria aposta perde.

O achado mais interessante do NTC no Bench, porém, é a compactação por grupo. Lembre que o conteúdo é byte-idêntico entre formatos; o que muda é o volume de estrutura ao redor. Medindo o tamanho do prompt em cada grupo:

A tese que isso confirma: a compactação do NTC cresce com a densidade de instrução. No VOLTGRID, que é quase só instrução, o NTC é o menor dos sete formatos — o XML precisa de até 67% mais caracteres para carregar a mesma informação — e ainda assim os dois empatam em acerto. No GRID, que é 85% dados brutos de grade, ele não tem o que compactar, e o MD fica menor. Isso importa porque o terreno onde o NTC nasceu — system prompts de 10 a 40 mil tokens, quase todos instrução — é justamente onde ele mais comprime e mais clareia. O Bench usa prompts curtos; o efeito real do NTC aparece com força onde a instrução domina.

Cada modelo, cada engenharia, em cada grupo

Até aqui os números de engenharia foram médias. Média esconde o que interessa: o mesmo formato que salva um modelo afunda outro. Então aqui está o dado sem intermediário — as sete engenharias, modelo por modelo, dentro de cada grupo de teste. Cada célula é uma acurácia sobre 25 respostas (os 5 puzzles do grupo × 5 repetições), e a última coluna mostra a amplitude: a distância entre a melhor e a pior engenharia daquele modelo naquele grupo.

Um aviso obrigatório antes de você mergulhar, e ele vale para qualquer tabela deste tipo: com 25 células, um acerto vale 4 pontos percentuais. Simulei o cenário em que o formato não tem efeito nenhum e, mesmo assim, a distância entre a melhor e a pior de sete medições desse tamanho fica em torno de 28 pontos só por acaso. Ou seja: não leia estas tabelas como prova de que um formato ganhou — leia como um mapa de onde vale a pena investigar no seu próprio caso. O que aparece aqui é indício, e indício vira evidência quando você repete o teste e o padrão se mantém.

Grupo GRID — Indução visual em grades

Aqui a tarefa é inferir a regra que transforma uma grade em outra e aplicá-la a um caso novo. Cada célula = 25 respostas (5 puzzles × 5 repetições). Em verde a melhor engenharia de cada modelo, em vermelho a pior, em azul a amplitude entre as duas.

Grupo CASCADE — Cascata de três regras

Aqui a tarefa é induzir Alpha, Beta e Gamma dos exemplos e compô-las em cadeia. Cada célula = 25 respostas (5 puzzles × 5 repetições). Em verde a melhor engenharia de cada modelo, em vermelho a pior, em azul a amplitude entre as duas.

Grupo VOLTGRID — O sistema inventado

Aqui a tarefa é ler a especificação, inferir a regra oculta a partir dos traces e simular o resultado. Cada célula = 25 respostas (5 puzzles × 5 repetições). Em verde a melhor engenharia de cada modelo, em vermelho a pior, em azul a amplitude entre as duas.

O que essas três tabelas mostram e nenhuma média mostraria:

• A amplitude varia muito entre modelos — mas não do jeito que eu esperava. O Gemini 3.6 Flash varia 4 pontos entre a melhor e a pior engenharia no GRID; o Sonnet 5, no mesmo grupo, varia 52. Fui procurar se os modelos mais fracos eram sistematicamente mais sensíveis ao formato e não encontrei essa relação (a correlação entre acerto e amplitude é praticamente zero). Com 25 respostas por célula, boa parte dessa variação é ruído de amostragem. Fica o registro do que foi medido, sem a conclusão que eu queria tirar dele.
• O caso mais brutal do estudo: o Sonnet 5, no GRID, faz 76,0% em YAML-PT e 24,0% em YAML-EN. Mesmo formato, mesmo modelo, mesmos puzzles — só o idioma muda, e são 52 pontos de diferença.
• Não existe engenharia campeã. Percorra a coluna em negrito de cada tabela: a vencedora muda de linha para linha, e muda também de grupo para grupo dentro do mesmo modelo. Quem procura "o melhor formato" está fazendo a pergunta errada. A pergunta certa é "o melhor formato para o meu modelo, na minha tarefa" — e ela custa um teste de meia hora para responder.

O achado do idioma

Um dos resultados que mais me surpreendeu: no agregado, o português venceu o inglês. 48,56% contra 47,47%, com o PT à frente nas três engenharias abertas — MD +0,50, YAML +2,36, XML +0,42. Consistente, ainda que por margens curtas.

Nos extremos, a diferença explode. O Sonnet 5 ganhou +12,9 pontos só passando de inglês para português; o GPT-5.5, +11,1; o GLM, +7,1. Mas — e aqui está a lição — a vitória do português no agregado esconde um placar muito mais dividido: 16 dos 35 runs foram melhor em português, 17 foram melhor em inglês e 2 empataram. O PT vence na soma porque os ganhos dele são maiores, não porque acontecem mais vezes. Entre os pró-inglês estão nomes que surpreendem: Gemini 3.5 Flash-Lite (−6,7), GPT-5.6 luna (−5,3), Grok 4.3 (−5,3), além de Fable 5, Opus 4.8 e GPT-5.6 sol. Não existe idioma universalmente melhor — existe o idioma certo para o seu modelo.

Os três maiores saltos de idioma

Vale olhar de perto quem mais ganhou só por trocar a língua da instrução:

• Sonnet 5, no Claude Code: 40,9% → 53,8%, um salto de +12,9 pontos. O mesmo modelo, no mesmo ambiente, com os mesmos puzzles. Só o idioma da instrução mudou.
• GPT-5.5, no codex CLI: 43,1% → 54,2%, +11,1 pontos. Um modelo da OpenAI indo melhor em português — o oposto do que quase todo mundo assume.
• GLM 5.2, via API Direta: 49,3% → 56,4%, +7,1 pontos. Um modelo chinês que também rendeu mais em português do que em inglês.

Ponha esses números em perspectiva. Uma geração nova de modelo costuma ser lançada prometendo um salto de 4, 5, 8 pontos — e foi mais ou menos isso que medi entre o Gemini 3.5 Flash e o 3.6 Flash (+4,2). Trocar o idioma do prompt entregou mais do que uma geração inteira de modelo em três casos deste estudo. Sem esperar lançamento, sem trocar de plano, sem pagar mais caro.

O controle do 2.5 Pro: o placar variou, a direção não

O Gemini 2.5 Pro é o único modelo que rodei duas vezes, e ele acabou entregando uma prova que eu não tinha planejado.

O score geral oscilou 1,9 ponto entre as duas rodadas — é o ruído normal do método, e foi assim que estabeleci a régua de ±1,9 que uso no resto do artigo. Mas repare no que não oscilou: o português venceu nas duas vezes. A magnitude mudou (+6,7 e depois +3,1); a direção, não. Nas engenharias MD e YAML o português ganhou nas duas rodadas; só no XML a coisa inverteu.

Isso é exatamente o tipo de leitura que um número solto não permite: existe uma faixa de variação, e existe um sinal que sobrevive a ela. O ruído mexe no quanto; a preferência de idioma decide para que lado.

Por que isso é difícil de aceitar — inclusive para a própria IA

Tem uma coisa que eu preciso dizer aqui, porque é a lição que mais carrego destes testes.

Se você perguntar a um modelo de IA em que idioma deve escrever seu prompt, ele vai responder "inglês" com muita segurança. É o que ele aprendeu a dizer. E a resposta parece razoável: a maior parte do material de treino é em inglês, logo o inglês deveria funcionar melhor. É uma dedução limpa — e, em metade dos casos que medi, errada.

A IA tem dificuldade com aquilo que ela não sabe que não sabe. Ela repete o consenso do material em que foi treinada, e o consenso nem sempre sobrevive ao teste. É por isso que eu prefiro medir a perguntar: em 16 das 35 execuções o português ganhou, em 17 o inglês ganhou, e em 2 deu empate. Nenhum modelo teria me dito isso.

E vale para além do idioma. É a mesma armadilha de achar que só um modelo maior resolve, que só a próxima geração melhora, que formato não importa. São ideias que se repetem até virarem verdade por repetição, não por evidência. Testar é o que quebra o ciclo — e testar em escala, com verificação determinística e dados abertos, é o que transforma intuição em número que qualquer um pode conferir.

O placar completo, execução por execução — 225 células em português contra 225 em inglês, dados idênticos:

Teste na sua família de modelo antes de decidir o idioma. Traduzir por superstição — "IA entende inglês melhor" — pode estar custando pontos que você nem sabe que está perdendo.

Ambiente: API Direta contra Harness CLI

Esse foi um dos efeitos mais fortes e menos discutidos por aí. O mesmo modelo, com os mesmos prompts, muda de patamar dependendo de estar sendo chamado por API direta ou rodando dentro de uma ferramenta de linha de comando. Os pares completos:

O padrão é claro: os modelos da Anthropic rendem muito mais dentro do Claude Code do que chamados por API Direta — o Sonnet 5 ganha +20,6 pontos —, enquanto nos da OpenAI o efeito é menor e muda de lado conforme o modelo (o sol rendeu mais no Codex CLI; terra e luna, mais na API Direta). E o efeito também aparece na direção oposta: numa fase anterior do estudo, sobre células idênticas recuperadas de logs, o DeepSeek mostrou o maior efeito de ambiente medido — +26,8 pontos no flash e +7,6 no pro rodando pela API direta contra o Claude Code. Ou seja: não existe ambiente universalmente melhor; existe o habitat certo de cada modelo.

Juntando tudo, dá para desenhar a hierarquia dos efeitos medida no estudo, do maior para o menor: thinking (mais de 40 pontos) > ambiente (7 a 27 pontos) > formato (mediana de 12 pontos, indo de 1,3 a 21,3) > idioma (de 1 a 13 pontos conforme a execução, mas só 1,09 no agregado). Quem quer melhorar o acerto de um modelo deveria mexer nessa ordem.

O efeito do thinking

O experimento mais limpo do estudo inteiro: o mesmo modelo, os mesmos 525 prompts byte-idênticos, a mesma verificação — a única diferença sendo o raciocínio ligado ou desligado.

O Gemini 3.5 Flash-Lite saltou de 6,5% para 48,2% ao ligar o thinking — +41,7 pontos, um fator de 7,4×. Mas o achado fica mais interessante no par de baixo: o Gemini 2.5 Flash-Lite, com thinking ligado, subiu apenas de 0 para 7,8% — e olha que ele pensou mais que o 3.5 (10,9 milhões de tokens de raciocínio contra 6,2 milhões). Pensou mais e resgatou quase nada.

Thinking amplifica o que existe; não cria o que não existe. O 3.5 Lite tinha capacidade latente de indução e o raciocínio a destravou. O 2.5 Lite pensou muito mais e resgatou quase nada, porque não havia o que destravar.

Isso vira um alerta metodológico para qualquer benchmark público: resultados de modelos "lite" e "mini" via APIs em lote podem estar medindo o modo reflexo, com o thinking desligado por default. Sem o ajuste que garante o raciocínio ativo, o 3.5 Flash-Lite apareceria como "6,5%" — um erro de caracterização de 7,4× causado por configuração, não por capacidade.

Os quatro runs desse experimento — os dois modelos, cada um com raciocínio ligado e desligado — estão no ablation.csv do repositório, célula a célula. Eles ficam fora do ranking de propósito: a versão sem thinking do mesmo modelo não é um competidor, é uma configuração. Colocá-la na tabela seria listar o mesmo modelo duas vezes por um ajuste, não por capacidade. Mas o dado está aberto para quem quiser recontar o +41,7.

O Google disse melhor e mais econômico. A gente mediu.

O Gemini 3.6 Flash foi lançado em 21 de julho de 2026 com a promessa usual: mais capaz e mais eficiente que o anterior. Eu o medi no dia seguinte, 22 de julho, dentro do mesmo teste. E a alegação se confirmou nos meus dados: +4,2 pontos de acurácia sobre o 3.5 Flash (60,0% contra 55,8%), com 29% menos tokens de raciocínio e custo de $19,18 contra $32,21 — 40% mais barato para fazer mais.

É uma medição de n=1, e digo isso sem cerimônia. Um run, um dia, um teste. Mas é a alegação do fornecedor batida contra dados independentes com verificação determinística — e ela passou.

Modelos abertos já servem para produção? O pelotão de 2026

Essa é a parte que mais mudou de 2025 para 2026. Na primeira parte deste artigo, o único modelo aberto forte era um DeepSeek solitário. Hoje é um pelotão inteiro separado por 4,3 pontos:

Cinco desses cabem em 4,3 pontos — do Kimi K2.6 (55,2%) ao Qwen3.8-max (50,9%). Isso é um pelotão, não um solista. E o nível deles hoje é o dos modelos fechados de cerca de seis meses atrás — a distância entre aberto e fechado encolheu de forma visível. E olha o tamanho da corrida: o Kimi K3, lançado em 16/07 com 2,8 trilhões de parâmetros, é o maior modelo aberto da história — um lançamento que abalou o mercado —, e três dias depois veio o Qwen3.8-max, de 2,4 trilhões, com pesos abertos prometidos. Eu testei os dois poucos dias após o lançamento, o Qwen ainda em preview. O ecossistema aberto deixou de ser um experimento acadêmico e virou uma opção real de produção.

O Grok

O Grok teve dois papéis no estudo. O Grok 4.5, rodando via grok CLI, entrou no pelotão forte com 59,6% de acurácia geral, brilhando especialmente no CASCADE (77,1%, terceiro do grupo). É um modelo competitivo no topo do meio da tabela.

O Grok 4.3 foi o melhor custo do estudo inteiro: o run completo de 525 células custou $4,70. Para comparação, ele pontuou 40,4% — acima do Gemini 2.5 Pro, que fez 34,9% e custou $38,09 naquele run. Oito vezes mais barato e com mais acerto. Quando o assunto é custo-benefício bruto, o Grok 4.3 foi imbatível aqui.

Vale um elogio técnico à grok CLI: é uma das poucas ferramentas de linha de comando hoje que aceita outros provedores e oferece controle real do system prompt único. Isso importa para quem quer testar com rigor, porque é o que permite garantir que o modelo recebeu exatamente o prompt que você mandou, sem camada surpresa por cima.

O retardatário: o Codex Spark

Uma execução deste estudo fechou cinco dias depois das outras, e a história de como ela fechou diz tanto quanto o número dela.

O GPT-5.3 Codex Spark é o modelo de velocidade da OpenAI para o Codex — feito para responder rápido dentro da ferramenta, não para vencer benchmark de raciocínio. No meio da semana de testes ele esbarrou na quota semanal com 297 das 525 células feitas, e eu deixei o runner esperando. Quando a quota renovou, em 27 de julho, ele retomou sozinho e fechou as 228 células restantes em cerca de uma hora e meia. Mesma bateria, mesmos prompts, mesma verificação — só a data mudou.

O resultado: 35,4%, 26º lugar entre as 35 execuções — abaixo do Grok 4.3, logo acima do Gemini 2.5 Pro. E é aqui que mora a curiosidade: o Spark roda exatamente no mesmo Codex CLI que carrega o GPT-5.6 sol ao topo do estudo, com 77,5%. Mesmo harness, mesma empresa, 42 pontos de distância. Depois de tantas seções mostrando o quanto o ambiente move o resultado, o Spark é o contraexemplo que fecha o raciocínio: o ambiente amplifica o que o modelo tem — ele não cria o que o modelo não tem. É o mesmo padrão do thinking nos modelos Lite, aparecendo por outra porta.

O que o Spark tem, e tem de verdade, é constância de velocidade: mediana de 43 segundos por célula e nenhuma resposta acima de 10 minutos — o teto mais baixo entre todas as execuções em que medi a latência célula a célula, num teste em que outros modelos chegaram a passar de 50 minutos numa célula só. Ele foi construído para latência, entrega latência, e paga a conta em raciocínio duro. Não é um defeito; é um nicho. Só não confunda o nicho com a régua: se a sua tarefa é inferir regra oculta, o modelo de velocidade da família não substitui o irmão maior — nem rodando na mesma ferramenta.

A crítica à Anthropic

Aqui eu troco de registro. O que vem agora é opinião — declarada como opinião —, sustentada por dados que qualquer um pode conferir no GitHub. E é dura.

O Fable 5, o modelo mais avançado da Anthropic, ajudou a criar a maior parte destes testes — e não conseguiu completá-los. Deixa isso assentar. Eu usei o Fable no desenvolvimento do próprio estudo, e na hora de rodá-lo como sujeito do experimento, ele travou nas tarefas que ajudou a construir.

Por dois caminhos. Em API Direta, o Fable 5 foi inviável: uma recusa determinística em famílias inteiras de puzzles numéricos completamente benignos — sequências de inteiros, sem nada sensível. Em Claude Code, precisei de 4 rodadas para contornar o bloqueio, e mesmo assim 43 células ficaram permanentemente bloqueadas antes de o modelo sequer ver a tarefa: o classificador de política cortava em 5 a 14 segundos, com a mensagem idêntica nas 43 de 43. E o detalhe que me tirou do sério: o puzzle mais fácil de todo o estudo — CASCADE/p0, aquele mesmo das regras Alpha/Beta/Gamma, com 83,9% de média entre todos os modelos — foi o mais bloqueado. O classificador barrou justamente o mais inofensivo.

O risco disso, para quem desenvolve, é concreto: você monta um projeto em cima de um modelo e, no meio do caminho, é obrigado a trocar de modelo — não por escolha técnica, mas porque o modelo passou a recusar tarefas legítimas. A calibração de política torna o modelo ruim para o dia a dia do desenvolvimento, mesmo sendo tecnicamente excelente.

E aqui vai a minha opinião, sem meio-termo: a Anthropic sabota o próprio modelo. Isso me parece um reflexo do medo que a empresa usou como marketing no lançamento do Mythos — o mesmo medo que agora calibra o Fable 5 e impossibilita tarefas genuínas. Enquanto isso, a OpenAI vai na direção contrária: se esforça para popularizar, remove barreiras, torna o uso mais intuitivo. Parte do motivo de o GPT-5.6 sol brilhar sozinho no topo deste estudo é exatamente essa: ele estava livre para trabalhar, sem uma corda amarrada nos braços.

Se eu, que uso IA diariamente em escala, não consegui concluir etapas do estudo com o Fable, como fica quem está começando?

Um dado descritivo, que não é ranking e por isso fica fora dele: das células que o Fable de fato respondeu, ele acertou 64,9% — taxa de pelotão de cima, à frente de vários modelos que ficaram acima dele no ranking. O que o derruba para o 59,6% oficial não é o modelo; é a corda. As 43 células bloqueadas contam como erro porque, na prática, foram: o usuário não recebeu a resposta.

Para fechar com justiça: o Fable 5 é tecnicamente um modelo excelente, e a contraprova está no próprio estudo — quando respondeu, respondeu bem. O problema não é o limite do modelo; é a calibração de política, uma decisão de empresa. Fora desta seção, eu não tenho reparo a fazer a nenhum provedor. Este aqui eu tenho, e com os dados na mão.

Dois testes, duas medidas: a ponte do 2.5 Pro

Talvez você tenha reparado numa aparente contradição entre as duas partes deste artigo. Na primeira, o Gemini 2.5 Pro foi o campeão absoluto, com 98,5% de compreensão. Na segunda, ele aparece lá embaixo, com 34,9%. O mesmo modelo. Como assim?

Porque são dois testes que medem coisas diferentes. Em 2025, o estudo mediu compreensão — se a IA entende uma especificação. Nisso, o 2.5 Pro foi campeão, e segue campeão daquele teste. Em 2026, o Prompthen Bench mede descobrir-e-resolver — inferir uma regra oculta e simular o resultado, um teste deliberadamente muito mais duro. Nisso, o 2.5 Pro fez 34,9%, e o 3.1 Pro, uma geração depois, fez 65,0%.

Não é o modelo que piorou. É o teste que subiu de nível. E a distância entre os dois — 34,9% para 65,0% — mostra o quanto a geração 3.x avançou em raciocínio duro. A escada Google completa, medida toda no mesmo teste de 2026, deixa isso visível:

Um modelo campeão de compreensão pode ser mediano em raciocínio indutivo puro. As duas coisas não andam necessariamente juntas — e é por isso que eu meço as duas separadas, em vez de fingir que uma métrica resume tudo.

Parte 3 — O que fazer com isso

O que fazer com isso

Tirando a moldura de estudo, sobram cinco decisões práticas:

• Antes de trocar de modelo, mexa nas alavancas. Thinking, ambiente e idioma muitas vezes entregam tanto quanto ou mais que a próxima geração — e custam menos. (Salto geracional grande existe: medimos +21,5 e +30,1 em dois casos. A questão é que a alavanca é grátis e a geração nova não.)
• Ligue o thinking nos modelos pequenos. Um Lite com raciocínio ativo pode multiplicar o acerto por sete. Sem ele, você está medindo o modo reflexo.
• Teste o idioma na sua família de modelo. Não traduza por superstição. O português venceu no agregado, mas o placar por execução foi 16 a 17. Meça antes de decidir.
• Escolha o ambiente com intenção. Modelos Anthropic rendem muito mais dentro de um Harness CLI; alguns modelos OpenAI rendem parecido na API Direta; o DeepSeek rendeu muito mais na API Direta. O ambiente é uma alavanca, não um detalhe — e o habitat certo varia por família.
• Decida pelo par acerto + token, nunca só pelo acerto. Se um formato acerta mais gastando menos, é escolha óbvia. Se dois empatam em acerto, fique com o mais curto — no Bench, o XML custa de 28% a 45% mais em tokens sem comprar acurácia. A mesma conta vale para o idioma: o português custa cerca de 13% mais tokens que o inglês no mesmo formato, então ele compensa quando o ganho de acerto paga esse pedágio (no Sonnet 5, com +12,9 pontos, paga com folga). E é em prompt denso em instrução que a compactação rende mais: no VOLTGRID o NTC entregou a melhor acurácia praticamente pelo menor custo do estudo.

Limitações e escopo

O mesmo cuidado dos números bons vale para os limites.

Os prompts do Bench são curtos — entre 200 e 460 tokens, com 85% de dados brutos e só 15% de instrução. É o cenário menos favorável para uma engenharia de compactação. Instruções longas, de 20 mil tokens para cima, são o próximo capítulo — e são justamente onde o NTC opera em produção. Este estudo mede raciocínio em prompt curto; não mede o terreno de instrução densa onde o NTC nasceu.

A maioria das execuções é n=1. Uma medição por célula. A exceção é o Gemini 2.5 Pro, que rodei duas vezes de propósito porque a pontuação parecia baixa demais: 34,9% e 33,0% — manteve, com cerca de ±1,9 ponto de ruído entre rodadas idênticas. Esse controle importa por dois motivos: confirma que o número baixo dele é real, e dá a régua de ruído do método inteiro.

Cuidado com o denominador nas tabelas mais granulares. No recorte por modelo × engenharia × grupo, cada célula vem de 25 respostas — um único acerto vale 4 pontos percentuais. Diferenças pequenas ali são ruído; o que sustenta leitura é a amplitude e o padrão repetido. Os recortes agregados (175 células por grupo, 525 por execução) são bem mais estáveis.

São 15 puzzles distintos. As 525 células por execução vêm de 15 puzzles × 7 engenharias × 5 repetições — as repetições medem estabilidade, não ampliam o domínio. É um benchmark exploratório profundo nesses 15 problemas, não uma amostra de todos os tipos de raciocínio.

O que passa no teste estatístico — e o que não passa. Não vou deixar isso no convite: eu mesmo rodei o teste de McNemar pareado sobre as 18.375 células e publico o resultado, inclusive quando ele contraria o que eu gostaria de afirmar.

A leitura honesta: os efeitos de thinking e de ambiente são enormes e inquestionáveis; o de idioma é real, porém pequeno no agregado e grande só em modelos específicos; e entre os formatos do topo não há diferença — o único contraste de formato que resiste é que o YAML em inglês ficou atrás.

Uma régua que vale para este e para qualquer outro benchmark. Com 525 células por execução, a margem de erro do ranking geral é de cerca de ±6 pontos. Isso significa que os primeiros colocados — GPT-5.6 sol (77,5%), terra (73,0%) e sol via API (71,2%) — estão estatisticamente empatados, e eu não vou fingir o contrário. O ranking separa bem faixas de capacidade (77% contra 17% é indiscutível); ele não crava o primeiro contra o segundo. Vale registrar que isso não é um defeito deste estudo: um benchmark público de 120 ou 500 tarefas tem margem ainda maior, e quase nenhum publica esse número. Aqui você tem as 18.375 células para conferir cada conta — inclusive as que me contrariam.

O Kimi K2.7 ficou de fora por limite de quota durante a semana de testes; fica como atualização futura. O Codex Spark também tinha ficado — e é por isso que ele fechou em 27 de julho, cinco dias depois do resto do estudo, quando a quota semanal dele renovou. Mesma bateria, mesmos prompts, mesma verificação; só a data mudou.

O domínio é raciocínio indutivo. Este estudo não mede código, escrita, agentes ou uso geral. Ele mede uma coisa específica — inferir regras ocultas e aplicá-las — e os números valem para isso. Extrapolar para "modelo X é melhor que Y em tudo" seria trapaça.

E fica um limite conceitual, o mais importante: uma engenharia de prompt afia a comunicação, não substitui o julgamento. Se a regra por trás está errada, ela será comunicada com clareza impecável. Revisão humana continua parte do processo.

Como citar este estudo

Teixeira, Paulo. "Prompthen Bench: 18.375 respostas avaliadas, 28 modelos de IA, 7 engenharias de prompt, 2 idiomas, verificação determinística." Fica a Dica, julho de 2026. Dados e prompts: github.com/pauloctxr/prompthen-bench.

Deixa eu fechar com a parte que mais me importa, porque ela não é sobre número — é sobre você. Nada do que eu contei aqui veio de talento ou de sorte. Veio de repetição: de criar o mesmo projeto centenas de vezes, de gastar dinheiro e token errando, de testar até o que a própria IA dizia que não ia funcionar. Se um prompt estranho no meio da madrugada virou uma engenharia que hoje roda em tudo que faço, e se uma rodada de teste que eu não terminei virou o maior estudo da minha vida, foi porque eu insisti — não porque eu era especial. A vontade de compartilhar isso é enorme. Não dá para tirar um chip da cabeça e entregar a cada pessoa o que aprendi sobre IA, mas dá para fazer com um texto como este. Então fica o recado, do jeito mais direto que eu sei dar:

Todo mundo pode criar coisas incríveis com a IA. Estude, teste, crie, repita. Se eu consegui, você também consegue. Se multipliquem com a IA.