Radar Tech: o modelo mais barato chegou — e a decisão de trocar não se resolve no benchmark

O que aconteceu hoje

O dia foi movimentado no mercado de modelos de linguagem. A Anthropic apresentou o Claude Haiku 5.5, um modelo de classe pequena que a empresa descreve como o mais barato e rápido da sua linha, com cerca de 75% de redução de custo em relação à geração anterior, um ajuste de "effort" para trocar custo por profundidade de raciocínio, e número de destaque em tarefas de uso de computador e trabalho de escritório. No mesmo dia, a OpenAI anunciou o GPT-6, e veículos de tecnologia relataram que Meta e Microsoft estão tomando medidas para reduzir o uso de ferramentas de IA de terceiros entre funcionários.

Três eventos diferentes, um mesmo sinal: o modelo que você escolheu há seis meses não é mais o mesmo produto. O que era a melhor relação custo-qualidade pode ter virado caro da noite para o dia — ou estar a caminho da deprecação.

Por que isso é um problema de arquitetura, não de benchmark

Quando um modelo novo chega mais barato, a reação natural do time é trocar. É uma reação perigosa, por três motivos:

• Benchmark público não é o seu domínio. Os números de destaque são medidos em tarefas genéricas. A sua tarefa crítica — a sugestão de resposta que o cliente lê, a classificação que libera um pagamento, o alerta que evita fraude — não aparece em nenhum gráfico de marketing.
• "Mais barato por token" não é "mais barato por tarefa concluída". Um modelo que erra mais gera retries, escalonamento humano e retrabalho. A conta que importa inclui tudo isso, não só o preço da API.
• A troca é uma decisão irreversível se você não a projetou para ser reversível. Se o modelo está espalhado pelo código em vez de atrás de um ponto único de troca, voltar atrás vira um incidente.

Some a isso a pressão de prazo: quando um fornecedor anuncia que vai descontinuar um modelo, a decisão deixa de ser "qual é o melhor" e passa a ser "como eu continuo funcionando", nesta ordem.

O que uma decisão decente precisa ter

A troca de modelo é, na prática, uma decisão arquitetural — e merece o mesmo tratamento que você dá a trocar um banco de dados. Na prática, o pacote de decisão precisa conter:

• A tarefa crítica identificada. Aquela cujo erro dói mais. A troca se julga por ela, não pela média.
• No mínimo três alternativas, incluindo "não fazer nada agora" e "trocar só parte do tráfego".
• Uma matriz de decisão com pesos explícitos — qualidade, custo por tarefa, latência, esforço, reversibilidade, lock-in — e o cálculo visível.
• Um plano de avaliação com golden set próprio, antes de qualquer adoção. Sem isso, não é decisão, é aposta.
• Rollout por fatias de tráfego, nunca 100% de uma vez, com rollback automático por limiar numérico.
• Um plano de reversão com tempo-alvo, tão detalhado quanto o rollout.

E, quando o gatilho é um aviso de deprecação com data, a ordem se inverte: primeiro a continuidade — o pior cenário é ficar sem modelo —, depois a otimização.

A leitura do dia

Modelos vão continuar chegando mais baratos e mais capazes, e isso é ótimo. Mas a facilidade do teste grátis esconde o custo real da troca: a regressão silenciosa na tarefa que o benchmark não mede. Os times que vão se sair bem nesse ciclo não são os que trocam mais rápido — são os que conseguem provar que a troca não quebrou nada, e voltar atrás em minutos quando quebra.

Quem trata a troca de modelo como uma ADR rastreável — com alternativas, pesos, golden set e reversão — para de jogar dados com a produção. Quem usa o benchmark como bússola continua descobrindo a regressão do jeito caro: no suporte.

Nota: toda decisão de troca de modelo deve ser revisada por quem a assume. Uma saída de IA organiza a decisão e aponta as lacunas — não substitui o julgamento de quem responde pelo sistema.