Achei que estava sendo esperto. Escrevi uma função auxiliar que reservava exatamente trinta por cento da janela de contexto como um

Eu achei que estava sendo esperto. Escrevi uma função auxiliar que reservava exatamente trinta por cento da janela de contexto como um orçamento de raciocínio para o nosso pipeline de IA. Era limpo, previsível e funcionava maravilhosamente no Opus 4.5. Então, mudei para o Opus 4.8 e cada uma das requisições morreu com um erro 400. Minha matemática de tokens cuidadosamente elaborada tornou-se lixo da noite para o dia.

O padrão antigo era simples. Você definia um valor de budget_tokens e o modelo racionava seu pensamento para caber dentro desse limite. Se eu entregasse um contexto de 128K, meu código reservaria aproximadamente 38.000 tokens para raciocínio e deixaria o resto para a resposta. Parecia responsável. Como manter um carro abaixo do limite de velocidade.

Esse modelo acabou. Lançamentos mais recentes, como o Opus 4.7 e 4.8, usam pensamento adaptativo. Você não escolhe mais um número. Em vez disso, você passa um controle de esforço. Isso parece apenas uma mudança de nome, mas os dois controles não poderiam ser mais diferentes. budget_tokens estabelecia um teto rígido sobre o quanto o modelo tinha permissão para pensar. O esforço controla como o modelo pensa e age, para começo de conversa. Um é um medidor de bomba de combustível. O outro é o mapa do motor.

Mapeando o Esforço para o Trabalho Real

Quando o controle mudou, minha intuição antiga parou de funcionar. Tive que reaprender o que cada configuração realmente proporciona. Realizei testes em nosso tráfego interno para descobrir onde cada nível de esforço se posiciona na prática.

Classificação e roteamento devem quase sempre usar esforço low. Esses trabalhos são decisões rápidas. Isso é um pedido de reembolso ou uma pergunta de vendas? Esta entrada de log precisa de escalonamento? Você não precisa de um monólogo. O esforço low mantém a latência baixa e o custo insignificante.

A maior parte do tráfego de aplicativos, o trabalho diário de resumos, reescritas, respostas de suporte e extração de conteúdo, se encaixa em esforço de medium a high. Este é o ponto de equilíbrio. O modelo tem espaço suficiente para resolver ambiguidades reais sem queimar tokens em uma tarefa que não precisa de uma cadeia de pensamento estendida.

Codificação e loops de agentes precisam de esforço xhigh. É aqui que os erros se acumulam. Se o modelo escrever um plano ruim na primeira rodada de um loop de chamadas de ferramentas, ele passará as próximas três etapas reparando o dano. Ou pior, ele chamará as ferramentas erradas, alucinará parâmetros e deixará o usuário encarando um fluxo de trabalho quebrado. Um raciocínio melhor desde o início evita esse ciclo vicioso.

Tarefas críticas devem receber esforço max. Não use isso para tudo. Reserve para os momentos em que uma resposta errada custa mais do que qualquer conta de tokens. Reconciliações financeiras, verificações de segurança, decisões de arquitetura e triagem médica são os casos ideais. Se um erro significa que um humano terá que desembaraçar a bagunça por horas, pague pelo raciocínio extra.

A Surpresa nos Custos

Aqui está a parte que quebrou meu modelo mental. Eu assumi que o esforço max sempre faria meus custos dispararem. Em uma única etapa, ele faz. O rastro de raciocínio é mais longo. Mas em tarefas agênticas de múltiplas etapas, a conta total muitas vezes diminuiu.

O modelo planeja melhor na primeira tentativa. Ele faz menos chamadas de ferramentas. Ele evita entrar em becos sem saída. Eu observei um agente de extração de dados que normalmente precisava de cinco idas e vindas terminar em duas, porque o modelo teve espaço de raciocínio suficiente para analisar o schema corretamente no início. Ao medir o custo, olhe para a conclusão do trabalho, não para a requisição. Um orçamento de raciocínio maior por etapa pode significar menos etapas no total.

Como Migrar Sem Quebrar Todo o Resto

Se você ainda tem budget_tokens espalhados pelo seu código, aqui está o caminho exato para sair disso. Não pule os passos três e cinco. Eu pulei, e isso me custou uma tarde de depuração.

Procure por budget_tokens no seu código. Cada instância precisa ser removida. Este parâmetro está morto em modelos mais novos e causará um erro 400.

Substitua o objeto de orçamento por um bloco de pensamento adaptativo. Use thinking: { type: "adaptive" }.

Adicione output_config com um nível de esforço explícito para cada chamada. Não deixe isso para um padrão global se o seu tráfego for misto. Seu endpoint de classificação leve não deve herdar acidentalmente a mesma configuração de esforço do seu agente de codificação. Seja explícito no local da chamada.

Delete seu helper de cálculo de orçamento. Eu sei. Provavelmente ele tem testes unitários. O meu tinha. Mas agora ele é um peso morto. A plataforma não quer a sua matemática de tokens. O modelo gerencia seu próprio ritmo.

Remova temperature, top_p e top_k. No Opus 4.7 e 4.8, esses parâmetros de amostragem causarão erros 400. A plataforma os removeu desta geração. Seus antigos truques de ajuste de temperatura não se aplicam aqui, e deixá-los presentes quebrará silenciosamente sua migração.

Teste cada modelo individualmente. Opus 4.5 e 4.8 são mundos completamente diferentes. Uma configuração que funciona em um não funcionará necessariamente no outro. Se você suportar múltiplas versões, ramifique sua lógica ou trate-as como backends separados.

Corrigindo o congelamento da UI

Existe um comportamento de streaming que confundirá seus usuários se você não o tratar. Nos novos modelos, os blocos de pensamento (thinking blocks) são transmitidos, mas o texto vem vazio por padrão. Em sua interface, isso parece uma pausa longa e estranha, sem progresso visível. Os usuários assumirão que o aplicativo travou.

Para corrigir isso, passe thinking: { type: "adaptive", display: "summarized" }. Isso lhe proporciona um indicador de progresso visível sem despejar o fluxo bruto de pensamento na janela de chat. Seu frontend permanece responsivo e seus usuários sabem que algo está acontecendo nos bastidores.

A Lição Real

Eu construí uma camada de abstração inteira sobre um parâmetro que o fornecedor nunca pretendeu que durasse. Eu envolvi as configurações deles em minha própria lógica porque achei que entendia o tradeoff melhor do que a plataforma. Eu não entendia. O pensamento adaptativo (adaptive thinking) é uma opção melhor porque o modelo decide de fato quando precisa raciocinar intensamente e quando pode ir no automático. Minha base de código está menor agora. Os resultados ficaram mais precisos. Às vezes, a decisão de engenharia correta é deletar o código "esperto" e deixar a plataforma fazer o seu trabalho.

Se você quiser ler as notas de migração originais, pode encontrá-las aqui. Para mais discussões práticas como esta, junte-se à comunidade GyaanSetu AI no Telegram.