Neste artigo, vou compartilhar minhas impressões sobre o lançamento do GPT-5.5 pela OpenAI e, mais importante, explicar por que os benchmarks tradicionais estão perdendo relevância no dia a dia de quem realmente usa inteligência artificial para trabalhar. Se você acompanha o mercado de IA, sabe que todo lançamento vem acompanhado de uma enxurrada de números, gráficos e comparações. Mas será que isso tudo faz diferença na hora de resolver um problema real no seu código, no seu projeto ou na sua rotina? Minha experiência diz que não. E eu vou explicar por quê. ## O lançamento do GPT-5.5 O GPT-5.5 foi anunciado ontem pela OpenAI. Segundo os primeiros dados divulgados, o modelo supera o Claude Opus 4.7 em alguns benchmarks importantes, incluindo desenvolvimento de software e uso de ferramentas. Vamos aos números: no Terminal Bench 2.0, o GPT-5.5 pontuou 82,7% — um salto significativo frente aos 75,1% do GPT-5.4. O Claude Opus 4.7, para fins de comparação, ficou em 69,4%. Se você já acha o Opus impressionante no dia a dia, teoricamente o GPT-5.5 seria ainda melhor. No entanto, é preciso ter cuidado com esses números. A OpenAI costuma esconder os benchmarks onde o GPT perde para o Claude. Ou seja, a comparação que chega até você é parcial. Mais adiante vou colocar isso em perspectiva. Outro ponto fundamental é o preço. O GPT-5.5 é duas vezes mais caro que o 5.4. A OpenAI justifica dizendo que o modelo é mais eficiente no uso de tokens — ele faz mais com menos. Mas o custo por token subiu. E isso muda a equação. Vale comparar com a abordagem da Anthropic, criadora do Claude. Quando lançou o Opus 4.7, a empresa disse: "ele pensa por mais tempo, gasta mais tokens, mas o custo não é tão alto". São duas filosofias opostas. De um lado, eficiência e token mais caro. Do outro, mais raciocínio, mais tokens e custo controlado. Ainda não consegui testar o GPT-5.5 no meu dia a dia. Farei isso nos próximos dias e trago um relato prático. Mas já posso adiantar: os benchmarks, por si só, não vão me dizer se o modelo é bom de verdade. ## Por que benchmarks não são tudo Existem outros números que merecem atenção. No SWE-bench, um benchmark interno de engenharia de software da OpenAI, o GPT-5.5 marcou 73,1%. Parece bom, certo? O problema é que você não tem a pontuação da Anthropic nesse mesmo teste. Por quê? Porque a Anthropic não permite que seus modelos sejam testados nesses benchmarks internos — o que os torna inerentemente tendenciosos. Outro exemplo é o OS World Verified, um benchmark importante para tarefas do mundo real. Neste teste, o GPT-5.5 não apresentou ganhos significativos frente ao Opus 4.7. Ou seja, dependendo do que você mede, a história muda completamente. Mas o problema principal não é nem esse. O problema é que benchmarks não refletem o uso real. No seu dia a dia, você não roda um teste controlado. Você abre uma ferramenta — Cursor, Codex, Claude Code, seja lá qual for — e pede para resolver um problema real. E aí entram variáveis que nenhum benchmark captura. A principal delas é o que está sendo chamado de AI harness. O harness é todo o sistema operacional que envolve o modelo: cache, lógica de retry (tentar novamente quando algo falha), decisões sobre quando pesquisar na internet, quando usar uma ferramenta, quando delegar para um subagente. É um sistema complexo que vai muito além do modelo bruto. E aqui está o ponto central: você pode usar o GPT-5.2 ou o GPT-5.4 dentro do Cursor, e ele vai desempenhar de um jeito. Se usar o mesmo modelo dentro do Codex, o desempenho pode ser completamente diferente. Porque o harness é diferente. O modelo é o mesmo. O que muda é tudo ao redor dele. Portanto, quando você vê um benchmark dizendo que o modelo X é melhor que o modelo Y, isso não significa nada até você testar esse modelo dentro da ferramenta que você usa, com o harness específico daquela plataforma, resolvendo os problemas que você realmente enfrenta. ## O problema do controle: o caso Anthropic E se eu te dissesse que você pode selecionar o melhor modelo, configurar para ele pensar no nível máximo, e mesmo assim ele não estar obedecendo? Foi exatamente isso que aconteceu com a Anthropic nesta semana. A empresa admitiu publicamente um bug no sistema dela. Desde o dia 4 de março, no Claude Code, quando o usuário configurava "effort high" — ou seja, pedia para o modelo pensar o máximo possível — na verdade ele estava operando em "medium". A interface mostrava "high" configurado, mas por baixo dos panos rodava "medium". Você acreditava estar usando o modelo no auge da sua capacidade, pagando por isso, confiando naquela configuração. Mas na prática, estava recebendo uma versão capada, mais burra, que pensava menos. Isso ilustra perfeitamente o ponto que venho levantando há semanas neste canal: as empresas vão ter que escolher entre "nerfar" os modelos (deixá-los mais burros para economizar computação) ou aumentar a latência (deixar o usuário esperando mais). A Anthropic tentou fazer o usuário acreditar que estava tendo o melhor dos dois mundos, mas na verdade estava entregando menos. E o mais grave: isso não aparece em benchmark nenhum. Você não vai olhar para a tabela comparativa e ver um asterisco dizendo "o modo high na verdade é medium". O benchmark testa o modelo em condições ideais. O seu uso real está sujeito a esses "ajustes" que as plataformas fazem para economizar dinheiro. A conclusão é inevitável: não temos mais controle total sobre o que está rodando. Você seleciona um modelo, mas subagentes podem ser spawnados com outros modelos. Você configura esforço máximo, mas a plataforma pode ignorar. No meu teste recente com o Claude Desktop, selecionei o Opus 4.7 e ele decidiu rodar um subagente usando Haiku 4.5 — um modelo muito menor. Não fui avisado, não autorizei. Simplesmente aconteceu. O que adianta, então, ficar comparando benchmarks? Se você não sabe nem se o modelo que você pediu está sendo usado, se não sabe se o nível de thinking está sendo respeitado, se não sabe se a plataforma está cortando caminhos para economizar... esses números bonitos em uma tabela não significam absolutamente nada para o seu dia a dia. ## O que fazer, então? Diante desse cenário, qual deveria ser a postura de quem realmente usa IA para trabalhar? Eu sugiro três movimentos práticos. Primeiro: testar na prática, não confiar apenas em benchmarks. Pegue um problema real do seu trabalho — aquele bug chato, aquela refatoração complexa, aquela documentação que precisa ser escrita — e teste os modelos lado a lado. Somente assim você vai descobrir qual funciona melhor para o seu contexto específico. Segundo: escolher o modelo certo para cada tarefa. Nem todo modelo precisa ser bom em tudo. O GPT-5.5, por exemplo, parece ser excelente para buscas e para criar planos. Talvez a estratégia inteligente seja usar o GPT-5.5 para planejar e pesquisar, e o Claude Opus 4.7 para executar. São abordagens complementares. Terceiro: testar também as ferramentas, não apenas os modelos. Codex, Claude Code, Cursor — cada uma dessas plataformas tem seu próprio AI harness. Uma pode ser melhor para tarefas longas e complexas, outra pode ser mais rápida para interações curtas. E os preços também variam. Saber qual ferramenta usar em cada situação está se tornando uma habilidade tão importante quanto saber programar. ## O que vem a seguir Na semana que vem, pretendo trazer um review prático do GPT-5.5. Vou pegá-lo em um caso real de debugging — um bug particularmente sinistro que temos no PSUA no Windows. Esse bug tem sido meu benchmark pessoal nos últimos meses porque é genuinamente difícil de resolver. Vou testar o GPT-5.5 lado a lado com o Claude Opus 4.7 e trago um relato honesto sobre qual deles se sai melhor. Não vou me basear em números bonitos divulgados por empresas. Vou me basear no que funciona — ou não — na prática. ## Resumo para quem tem pressa Se você não leu o artigo inteiro, aqui estão os pontos principais: - GPT-5.5 é mais caro e mais eficiente em tokens, mas isso não significa que seja melhor para o seu uso específico. - Benchmarks não contam a história completa. O AI harness — todo o sistema ao redor do modelo — importa tanto quanto o modelo em si. - Empresas estão "nerfando" modelos para economizar dinheiro, como vimos no caso do bug da Anthropic onde "effort high" na verdade era "medium". - Você não tem mais controle total sobre qual modelo está rodando, se subagentes estão sendo usados, ou se a configuração de esforço está sendo respeitada. - O melhor caminho é testar pessoalmente com problemas reais e escolher modelo + ferramenta conforme a necessidade de cada tarefa. ## Consideração final O mercado de inteligência artificial está amadurecendo, e com o amadurecimento vêm as complexidades. Não existe mais um "melhor modelo absoluto". Existe o modelo certo para a sua ferramenta, para o seu problema, para o seu orçamento. Benchmarks são úteis? Sim, como ponto de partida. Mas não pare neles. Teste, quebre, compare. E lembre-se: por trás de cada número bonito, há uma empresa tomando decisões de negócio que podem estar afetando a qualidade do que você está usando — sem que você saiba.