Mais Um Modelo Essa Semana: A Fadiga De Lançamento Que Ninguém Confessa

Domingo é o dia em que eu costumo limpar a pasta de release notes do e-mail. Hoje fiz a conta de setembro antes de apagar qualquer coisa e fiquei um tempo parado olhando para a lista. Gemini 3.8 Flash no dia 2. GPT-6 Astra no dia 3. Gemini 3.8 Live e a variante com Extended Thinking no dia 15. Claude Opus 5.5 e GPT-6 Sol e Luna, no mesmo dia, 22. E, fechando o mês, a OpenAI anunciando que apresentaria o GPT-6 Cyber na DevDay de 29 de setembro.

Na mesma semana, um colega que lidera um time de produto me mandou uma mensagem curta: "a gente devia migrar pro Opus 5.5 ou pro Sol?". Ele tinha acabado de fechar, em agosto, uma rodada de ajuste de prompts para o modelo que usava. A pergunta era razoável. O que me incomodou foi o tom, meio de obrigação, meio de cansaço. Ninguém ali estava empolgado. Estavam com medo de ficar para trás, e com preguiça de começar tudo de novo. As duas coisas ao mesmo tempo.

Tenho a impressão de que esse sentimento é mais comum do que as pessoas admitem em público. Na timeline, todo lançamento vem acompanhado de thread entusiasmada e gráfico de barras. No Slack interno dos times, a reação mais honesta costuma ser um suspiro. Existe um custo nesse ritmo que não aparece na fatura da API, não aparece em benchmark e não aparece em nenhum dashboard: o custo de atenção e de decisão que cada lançamento cobra de quem precisa manter um produto funcionando.

Este é um post de opinião, de domingo. Não testei nenhum desses modelos lado a lado, e não vou fingir que sim. O que quero fazer é organizar o que setembro mostrou sobre a cadência, nomear o custo escondido que ela gera, explicar por que a manchete é um péssimo gatilho de decisão, propor uma política concreta para times que não querem viver em reavaliação permanente e, por honestidade, mostrar quando pular um lançamento sai caro.

Setembro Em Uma Tabela

Vale começar pelo calendário, porque a sensação de "tem modelo novo toda semana" é, neste caso, quase literal. Juntando os anúncios oficiais e a cobertura que o blog já fez ao longo do mês, setembro de 2026 fica mais ou menos assim para quem constrói em cima das três maiores APIs:

Uma matéria da shattered.io sobre o tema contou oito modelos relevantes em setembro, com Anthropic, Google, Meta e OpenAI soltando modelos de topo praticamente juntos nos primeiros dias do mês — Claude Fable 5.1 no dia 1º, Gemini 3.8 Flash e Muse Spark 1.3 no dia 2, GPT-6 Astra no dia 3. A leitura do texto é que o setor passou de ciclos anuais, em 2023, para ciclos trimestrais ou semestrais em 2024 e 2025, e para algo entre mensal e semanal em 2026. A mesma matéria reúne duas frases que resumem bem o clima: Zhen Lu, CEO da Runpod, dizendo à CNBC que "model fatigue is a real thing", e Sam Altman comentando que cada lançamento é tão bom que fica difícil perceber um salto de verdade.

Essa segunda frase é mais reveladora do que parece. Se até quem lança tem dificuldade de dizer qual versão representa um salto, o time que consome a API tem ainda menos condição de saber, olhando só o anúncio, se vale a pena mexer em alguma coisa. Quando escrevi sobre o Gemini 3.8 Flash como o terceiro lançamento em seis semanas, a hipótese era que a cadência na linha barata sinalizava uma aposta do Google na camada de roteamento. Três semanas depois, a cadência não parece mais particularidade de um fornecedor. Parece o ambiente.

O Custo Que Não Aparece Na Fatura

Quando um modelo novo sai, o debate público gira em torno de duas variáveis: quanto ele pontua e quanto ele custa por token. As duas são visíveis, comparáveis e fáceis de colocar num slide. O que quase nunca entra na conta é o custo de mudar, e principalmente o custo de ficar decidindo se vai mudar.

Pense num time hipotético com três fluxos de IA em produção. Cada lançamento relevante dispara, no mínimo, uma conversa: alguém compartilha o anúncio no canal, outra pessoa pergunta se vale testar, um terceiro lembra que o último teste levou uma semana. Mesmo que a decisão final seja "não agora", a pergunta já consumiu atenção de três pessoas sêniores. Multiplique por seis lançamentos num mês e o time gastou horas relevantes discutindo trocas que não fez.

Quando a decisão é "sim, vamos testar", o custo cresce de forma pouco linear. Prompts afinados para um modelo raramente se transferem intactos para outro, mesmo dentro do mesmo fornecedor. Um modelo mais conciso, como a Anthropic diz que o Opus 5.5 é — ela fala em menos tokens, e a Box, num depoimento publicado pela própria Anthropic, fala em respostas 40% menos verbosas — pode quebrar um parser que dependia de certa estrutura de resposta. Um modelo que usa menos turnos para fechar uma tarefa agêntica muda o perfil de chamadas de ferramenta, o que pode mexer em timeouts, em logs, em alertas. Nada disso é defeito do modelo novo; o sistema ao redor é que foi calibrado para o antigo.

Existe ainda o problema da migração que não termina. Um cenário comum: o time começa a migrar o fluxo de sumarização para o modelo A, chega a 60% do tráfego, e aí sai o modelo B, mais barato. A migração para, alguém abre uma investigação sobre o B, e o sistema passa semanas rodando com dois modelos em produção sem que isso tenha sido uma decisão de arquitetura. Foi só um acúmulo de meias decisões. Com a cadência de setembro, é perfeitamente possível que um time tenha três migrações parciais abertas ao mesmo tempo, cada uma começada por um motivo que já nem vale mais.

E há o custo mais sutil de todos: a avaliação que envelhece. Um time que montou, com cuidado, uma comparação entre três modelos em julho tem nas mãos, em outubro, um documento que compara modelos que em parte já foram substituídos. Se cada rodada de avaliação é feita à mão, a cadência de lançamentos transforma avaliação em trabalho contínuo, sem que ninguém tenha contratado alguém para isso.

Somando tudo, aparece um imposto de atenção sobre as pessoas mais experientes do time, pago em interrupções e em sensação de nunca estar em dia. Não à toa ele conversa com o que discuti sobre o burnout de quem supervisiona agentes de IA em paralelo: o problema lá era gestão de agentes, aqui é gestão de fornecedores, mas o mecanismo de desgaste é parecido. A ferramenta não cansa entre um problema e outro. A pessoa cansa.

Por Que A Manchete É Um Péssimo Gatilho De Decisão

A maior parte dos times que conheço decide reavaliar modelo de um jeito que, dito em voz alta, soa estranho: alguém lê um anúncio e o anúncio parece bom. O gatilho é a manchete. E a manchete é, por construção, o pior sinal disponível para esse tipo de decisão.

Primeiro, porque os números de lançamento são números do fornecedor. Os benchmarks que a Anthropic publicou para o Opus 5.5 — 66,4% no Terminal-Bench 4.0, contra 52,3% do Opus 5 e 57,9% do GPT-6 Astra — são medidos pela Anthropic. Os que a OpenAI publicou para o GPT-6 Sol — 33,2% no AutomationBench com esforço xhigh, 68,8% no DeepSWE v1.1 com esforço máximo — são medidos pela OpenAI. O único benchmark que aparece nos dois anúncios é o AutomationBench, com 40,0% para o Opus 5.5 segundo a Anthropic e 33,2% para o Sol segundo a OpenAI. Parece uma comparação direta, mas não é: são fornecedores diferentes rodando com configurações possivelmente diferentes. Colocar esses dois números lado a lado numa reunião como se fossem uma disputa auditada é um erro que eu vejo acontecer com frequência.

Segundo, porque mesmo benchmark independente mede outra coisa que não o seu produto. Já escrevi sobre isso olhando o leaderboard do SWE-bench Pro e as dúvidas sobre o que ele realmente mede: há auditoria apontando tarefas quebradas no split público e pesquisa sugerindo que modelos de fronteira lembram respostas em vez de raciocinar. E o caso do Astra, que discuti em o que o GPT-6 Astra muda para quem constrói em cima da OpenAI, é o exemplo mais extremo do ano: 99,9% no ARC-AGI-3 no anúncio, 62,7% no teste independente da ARC Prize. Trinta e sete pontos entre o comunicado e a medição neutra.

Terceiro, e mais importante, porque a pergunta que a manchete responde não é a sua. O anúncio responde "esse modelo é melhor em média, nas tarefas que o fornecedor escolheu mostrar?". O seu time precisa saber "esse modelo é melhor nas tarefas que o meu produto executa, com os meus dados, dentro do meu orçamento de latência e custo?". Dez pontos a mais em Terminal-Bench podem não mudar nada num fluxo de extração de campos de nota fiscal.

Uma Política Em Quatro Peças

Se o problema é decidir o tempo todo, a saída é decidir menos vezes, com mais critério. Não tenho a pretensão de que isso sirva para qualquer contexto, mas a política que eu defenderia para um time de produto típico tem quatro peças que se reforçam.

A primeira é um ciclo fixo de reavaliação. Trimestral me parece o ponto de equilíbrio para a maioria: longo o bastante para que um lançamento tenha tempo de estabilizar — preço, rate limit, bugs de primeira semana, depoimentos que não são do próprio fornecedor —, curto o bastante para não deixar dinheiro relevante na mesa por muito tempo. Entre um ciclo e outro, lançamento novo entra numa fila, não numa conversa. Alguém registra o modelo, o preço anunciado e o link, e o assunto volta na janela seguinte. "Está na fila do próximo ciclo" encerra a discussão no canal sem soar negligente.

A segunda peça é uma avaliação própria como gatilho, no lugar da manchete. Um eval set pequeno e representativo do seu workload — algumas centenas de casos reais, anonimizados, com critério de acerto definido — vale mais do que qualquer tabela de benchmark público para decidir se um modelo serve para você. O investimento inicial é real, mas ele se paga justamente no cenário de cadência alta: quando o eval está automatizado, testar um modelo novo deixa de ser um projeto e vira uma execução. O ciclo trimestral roda o eval contra os candidatos da fila, compara com o modelo atual em qualidade, custo e latência, e produz uma recomendação com número do seu produto, não do anúncio.

A terceira é uma camada de roteamento ou abstração entre o produto e o modelo. Se trocar de modelo exige mexer em código de produto, cada troca é um projeto. Se o modelo é um parâmetro de configuração por fluxo, com prompts versionados junto e fallback definido, a troca é um deploy. Essa camada não precisa ser sofisticada; o essencial é que o nome do modelo não esteja espalhado pelo código e que cada fluxo tenha dono, eval e orçamento próprios.

Na prática, algo tão simples quanto um arquivo de política por fluxo já resolve boa parte do problema. Um exemplo ilustrativo, não de nenhum time real:

# politica-modelos.yaml — exemplo ilustrativo
ciclo_reavaliacao: trimestral        # próxima janela: janeiro
fila_candidatos:
  - modelo: claude-opus-5-5
    anunciado: 2026-09-22
    motivo: "Anthropic diz ~40% mais barato em workloads típicos"
  - modelo: gpt-6-sol
    anunciado: 2026-09-22
    motivo: "OpenAI diz 50% mais barato que GPT-5.6 Sol"

fluxos:
  classificacao_tickets:
    modelo_atual: modelo-barato-estavel
    eval: evals/tickets_v4.jsonl     # 400 casos reais anonimizados
    criterio_troca:
      qualidade_minima: "igual ou melhor que o atual no eval"
      custo: "pelo menos 25% menor por 1k tickets"
    fallback: modelo-anterior

gatilho_fora_de_ciclo:
  - "queda de preço >= 40% em modelo equivalente já aprovado no eval"
  - "descontinuação anunciada do modelo atual"
  - "incidente de segurança ou qualidade no modelo atual"

A quarta peça é a mais contraintuitiva: aceitar ficar um modelo atrás de propósito. Em vez de adotar o lançamento da semana, adotar o anterior, que já foi batido por outros clientes, já teve o preço estabilizado e já tem documentação de problemas conhecidos. Para muitos fluxos, a diferença de qualidade entre o topo e o penúltimo é pequena, e a diferença de risco operacional é grande. Ficar um modelo atrás não é preguiça; é escolher conscientemente trocar alguns pontos de benchmark por previsibilidade. Onde a qualidade de fronteira realmente importa, a política pode abrir exceção — desde que seja uma decisão, não o padrão.

O Outro Lado: Quando Pular O Lançamento Custa Caro

Seria desonesto defender a política acima sem mostrar onde ela machuca. Setembro de 2026 tem pelo menos um exemplo claro de que ignorar lançamento pode sair caro, e ele não tem nada a ver com benchmark. Tem a ver com preço.

No mesmo dia 22, a OpenAI anunciou o GPT-6 Sol a US$2 por milhão de tokens de entrada e US$10 de saída, e o Luna a US$0,10 e US$0,50, dizendo que são 50% mais baratos que as versões GPT-5.6 equivalentes, com 90% de desconto em leituras de cache. A Anthropic, por sua vez, baixou o preço de tabela do Opus 5.5 para US$4 de entrada e US$20 de saída, contra US$5 e US$25 do Opus 5, e o cache read de US$0,50 para US$0,20. Nos depoimentos que a própria Anthropic publicou, a Optiver fala em qualidade equivalente à do Opus 5 com cerca de metade dos turnos e custo 40 a 50% menor. São números de fornecedor e de clientes escolhidos pelo fornecedor, então vale a cautela de sempre. Mas, se algo nessa ordem de grandeza se confirmar no seu eval, um time com gasto relevante de inferência que espera três meses pela próxima janela está deixando metade da fatura na mesa durante esse período.

É por isso que a política precisa de um gatilho fora de ciclo, e por isso ele aparece no exemplo de configuração. Uma queda de preço grande em um modelo que já passou no seu eval, ou num sucessor direto do modelo que você usa, é o tipo de evento que justifica furar a fila. Note a diferença: o gatilho não é "saiu modelo novo e parece melhor", é "saiu uma versão mais barata de algo que eu já sei que funciona". O primeiro exige avaliação completa. O segundo exige só confirmar que o comportamento não mudou o suficiente para quebrar o fluxo.

Existe também o movimento contrário, que a política ajuda a enxergar. O Gemini 3.8 Flash saiu com preço promocional que já tem data para dobrar, em 1º de janeiro de 2027. Um time que migrou em setembro só pelo preço vai descobrir, na virada do ano, que a conta mudou. Um time com ciclo trimestral e eval com critério de custo explícito faria essa pergunta antes de migrar: o fluxo ainda compensa no preço cheio? Nesse caso, a disciplina protege contra a pressa, não contra a lentidão.

O Que Isso Pede De Quem Lidera

Grande parte do que descrevi é processo, mas a parte difícil é cultural. Adotar ciclo fixo significa que o tech lead vai, várias vezes por mês, responder "isso entra no próximo ciclo" para alguém empolgado com um anúncio. Isso tem custo social. Explicar o porquê uma vez, com clareza, e depois ser consistente, costuma funcionar melhor do que abrir exceção caso a caso.

Também pede uma mudança no que o time considera trabalho legítimo. Montar e manter um eval set é um trabalho pouco glamouroso, que não aparece em demo e raramente entra em OKR. Mas é exatamente o ativo que transforma a cadência de lançamentos de ameaça em oportunidade: quanto melhor o eval, mais barato fica testar, e mais rápido o time consegue capturar uma queda de preço real sem pagar o imposto de atenção inteiro. Quem lidera precisa proteger esse trabalho explicitamente, com dono e tempo reservado.

A comparação mais detalhada entre os dois lançamentos do dia 22 fica para o comparativo entre Opus 5.5 e GPT-6 Sol e Luna para escolha de modelo. O que eu quis fazer aqui foi dar um passo para trás e perguntar como decidir, antes de perguntar o que decidir.

Conclusão

Setembro de 2026 foi, provavelmente, o mês com mais lançamentos relevantes de modelo que eu já acompanhei de perto. Não acho que outubro vá ser muito diferente, e não acho que os fornecedores tenham qualquer incentivo para desacelerar, apesar de toda a conversa pública sobre desaceleração. O ritmo é parte da estratégia comercial deles. O que está sob controle de um time é o ritmo com que responde a isso.

A política que defendo — ciclo fixo, eval próprio como gatilho, camada de abstração, um modelo atrás de propósito, e gatilho fora de ciclo para queda de preço grande — não é a única possível, e certamente não é ótima para todo contexto. Um time muito pequeno talvez não tenha fôlego para manter eval; um time cujo produto é, ele mesmo, uma ferramenta de IA de fronteira talvez precise estar sempre no topo. Mas para a maioria dos times de produto que usam IA como componente, e não como o produto em si, ela troca um custo invisível e contínuo por um custo visível e periódico. Essa troca, na minha leitura, costuma valer.

O que eu ainda não sei responder é quanto tempo essa cadência se sustenta, nem se a fadiga que vejo nos times vai eventualmente virar pressão sobre os próprios fornecedores. Talvez a resposta do mercado seja justamente mais roteamento automático, mais contratos de estabilidade, mais snapshots com prazo de suporte longo. Enquanto isso não chega, a melhor defesa que conheço é parar de deixar a manchete decidir a agenda da semana. O modelo novo vai continuar saindo. A pergunta é se o seu time precisa parar tudo toda vez que ele sair.

Fontes:

• shattered.io — Modelos de IA: fadiga de lançamentos em setembro de 2026
• Anthropic — Claude Opus 5.5
• OpenAI — Introducing GPT-6 Sol and Luna
• Google — Gemini 3.8 Live e Gemini 3.8 Live Extended Thinking
• Fortune — OpenAI launching GPT-6 Cyber model and security product at DevDay