Radar Tech: o modelo 'bom o bastante' chegou — e o problema deixou de ser qual usar para ser como rotear

O que apareceu nas últimas 24 horas

Dois sinais do mesmo movimento dominaram as discussões de tecnologia hoje.

O primeiro veio de um relato de uso: um desenvolvedor diz que passou um mês usando um modelo destilado chinês, o DeepSeek 4.1 Flash, em uma dúzia de projetos, e que — sem olhar o nome do modelo — não consegue mais distinguir a qualidade de um modelo de fronteira. O detalhe que muda tudo não é a capacidade, e sim o custo: com assinatura de US$ 10/mês, sessões de um dia inteiro ficam abaixo de US$ 1, em parte porque o cache de contexto encolheu centenas de vezes em relação às gerações anteriores. Tarefas "mentais" (testar UI no susto, reorganizar arquivos, exploração de código) passam a custar quase nada.

O segundo sinal é econômico: noticiou-se que a receita anualizada da OpenAI ficou cerca de US$ 20 bilhões abaixo do que havia sido sinalizado. Se os modelos baratos são "bons o bastante" e a conta de quem paga topo de linha não fecha tão fácil, a pressão não é sobre capacidade — é sobre onde o dinheiro inteligente é gasto.

Por que isso é uma mudança de arquitetura, não de ferramenta

Durante dois anos, a pergunta padrão de um time era: qual é o melhor modelo? Hoje a pergunta certa é outra: qual tarefa pode ir para um modelo barato, e qual precisa do caro — e como isso é decidido no código, não no gosto de cada dev?

Isso tem consequências concretas para quem projeta sistemas:

• Um modelo só é uma aposta em um ponto único de falha. Quando preço, latência ou política de um fornecedor mudam — e mudam rápido —, quem espalhou as chamadas pelo código não tem alavanca. Quem põe um ponto único de troca tem.
• "Bom o bastante" depende da tarefa, não do benchmark. O mesmo modelo barato que faz triagem, resumo e reescrita de teste com folga pode falhar na classificação que libera um pagamento. A fronteira de qualidade é por tarefa.
• Custo por token não é custo por resultado. Um modelo barato que erra mais gera retry, revisão humana e retrabalho. A conta que importa é a do resultado concluído, não a do token.
• Roteamento é decisão de arquitetura. Rotear por tipo de tarefa, com orçamento e limiar de escalonamento para o modelo caro, é o mesmo tipo de decisão que escolher onde fica o banco de dados — merece registro, dono e revisão.

O padrão que se desenha

Os times que estão indo bem nesse ciclo não ficam escolhendo "o melhor modelo". Eles montam um gateway de modelos: um ponto único onde a aplicação pede a tarefa, e o gateway decide o modelo, aplica limite de custo, e escala para o caro quando o barato não bate o limiar. A qualidade deixa de ser fé no marketing e passa a ser medida no domínio — com um conjunto de avaliação próprio, versionado, que roda nos dois modelos antes de qualquer mudança de rota.

O ganho dessa arquitetura é duplo: você captura a economia do modelo barato sem apostar a tarefa crítica nele — e troca de fornecedor sem reescrever a aplicação.

A leitura do dia

O modelo barato venceu a corrida onde quase ninguém estava olhando: o trabalho do dia a dia. E, quando a capacidade se torna commodity, o diferencial de arquitetura se desloca para o controle: quem decide onde cada tarefa roda, com que orçamento, e com qual evidência de que a troca não quebrou nada.

Quem trata o roteamento como configuração dispersa vai sentir a próxima mudança de preço no orçamento. Quem o trata como uma camada projetada — com gateway, orçamento, avaliação por domínio e caminho de escalonamento — transforma a queda de preço em margem, não em incidente.

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