Migrar do GPT-6 Astra para outro modelo: o que quebra no meio do projeto?

Modelo novo não é plugue de tomada que você troca sem consequência

O GPT-6 Astra foi apresentado pela OpenAI em 3 de setembro de 2026, com rollout em fases: primeiro organizações limitadas, depois os planos pagos do ChatGPT (Plus, Pro, Business e Enterprise)

Na API ele já aparece com o identificador gpt-6-astra, então muita gente subiu projeto em cima dele nos últimos dias

Aí vem a parte que nenhum anúncio conta: quem amarrou o projeto no Astra e agora quer sair esbarra em atritos bem específicos, tipo formato de saída, tool calling, reasoning persistido, teto de contexto e teto de output

Esse post é de risco, não de propaganda

Bora ver o que quebra de verdade?

O que revisar antes de puxar o plugue

Antes de escrever uma linha nova, tu precisa saber o que no teu projeto está amarrado ao Astra hoje

É um inventário chato, mas é ele que decide se a troca vai ser um susto ou um fim de semana perdido

• Qual endpoint o código usa hoje: o Astra suporta v1/chat/completions, v1/responses e v1/batch, porém tool calling exige a Responses API. Se tu usa ferramentas no Chat Completions, a orientação da própria documentação é seguir o guia de migração para Responses
• Quais recursos tu depende de verdade: streaming, function calling, structured outputs e entrada de imagem estão entre os recursos suportados pelo Astra na API. Marque quais são obrigatórios no teu fluxo e quais são conforto
• Qual reasoning.effort está fixado no código: o Astra aceita low, medium, high, xhigh e max. O valor none não é suportado e devolve HTTP 400, então se tem um none esquecido em algum lugar, ele vai aparecer no pior momento
• Onde o prompt encosta em 272 mil tokens de entrada: acima disso o Astra muda de faixa de preço, com 2x no input e no cache e 1,5x no output, aplicado ao request completo. Não é só a parte que passou, é a requisição inteira
• Quantos pontos de cache o destino permite: a Anthropic aceita até 4 cache breakpoints (cache_control) por requisição. Se a tua estratégia de cache hoje usa mais pontos que isso, ela não atravessa a fronteira

Fechou esse inventário? Aí sim dá pra conversar sobre destino

E se o teu caminho for o contrário (tu entrando no Astra em vez de sair dele), tem um checklist antes de trocar o modelo que cobre esse outro lado

Astra, Fable 5.1 e Gemini 3.1 Pro: a origem e os dois destinos lado a lado

Coloquei os números verificados lado a lado, porque é olhando assim que a dor da migração aparece

A primeira coluna é a origem (o Astra, de onde tu está saindo), as outras duas são os destinos possíveis

O Claude Fable 5.1 chegou em 1 de setembro de 2026, junto com o Mythos 5.1, e o corte de 75% no cache read é o item mais chamativo dele nessa tabela

Mas olha de novo pra linha do teto de saída

Essa é a que mais quebra pipeline pronto: sair de 128.000 tokens de output para 65.536 corta pela metade o que o modelo consegue devolver numa tacada só

Se o teu fluxo gera arquivo grande, relatório longo ou refactor de vários arquivos numa resposta, ele não vai "ficar mais lento", ele simplesmente vai truncar

Como migrar sem quebrar o projeto: passo a passo

1. Congele o comportamento atual antes de mexer em qualquer coisa: registre os prompts que estão em produção, os formatos de saída que tu espera e a lista de ferramentas que o modelo chama hoje. Sem isso tu não tem baseline. O erro comum deste passo é migrar e comparar de cabeça, no "achei que antes tava melhor"

2. Se tu usa ferramentas no Chat Completions, migre para a Responses API primeiro, ainda no Astra: é a própria orientação da documentação do Astra quando tool calling entra na jogada. O erro comum deste passo é trocar de modelo e de endpoint no mesmo commit, porque aí quando quebra tu não sabe qual dos dois foi

3. Limpe do código o que é específico do Astra: os valores próprios de reasoning.effort e a ausência de temperature, top_p e top_logprobs, que estão entre os parâmetros não suportados. O erro comum deste passo é assumir que o destino aceita exatamente os mesmos parâmetros, na base do copiar e colar do cliente

4. Teste o destino pela camada de compatibilidade, mas só como comparação: na Anthropic tu aponta o base_url e continua usando client.chat.completions.create()

from openai import OpenAI

client = OpenAI(
    api_key="SUA_CHAVE",
    base_url="https://api.anthropic.com/v1/"
)

resposta = client.chat.completions.create(
    model="MODELO_DE_DESTINO",
    messages=[{"role": "user", "content": "teste de paridade"}]
)

A própria documentação da Anthropic diz que essa camada serve para testar e comparar capacidades, e que não é solução de longo prazo nem pronta para produção na maioria dos casos. O erro comum deste passo é gostar do resultado e subir a camada de compatibilidade em produção "só por enquanto" (spoiler: o "por enquanto" dura anos)

5. Reescreva o cliente na API nativa do destino: no caso do Gemini, o Google recomenda chamar a API Gemini direto pra quem não está preso ao SDK da OpenAI. O erro comum deste passo é adiar a reescrita até o dia em que um recurso que a camada não cobre vira requisito

6. Se o teu trabalho é dentro do Claude Code, a troca é por comando, flag ou variável de ambiente

# dentro da sessão (vale SÓ para a sessão atual)
/model

# no launch
claude --model NOME_DO_MODELO

# mudando o default
export ANTHROPIC_MODEL=NOME_DO_MODELO

Dá pra mudar o default também pelo campo model nas settings. O erro comum deste passo é trocar via /model, gostar do resultado e achar que o default do projeto mudou: não mudou, aquilo morre com a sessão

Os atritos reais da troca (e como prevenir cada um)

A conversa perde qualidade logo depois da troca:

Sintoma: tu troca o modelo no meio de uma thread longa e a qualidade cai de um jeito estranho, como se ele tivesse esquecido metade do que já foi combinado

Causa: reasoning persistido só é reaproveitado dentro da mesma família de modelo. Quando tu muda de família, a API omite o raciocínio incompatível do contexto, mesmo com reasoning.context em all_turns

Solução: tratar a troca como início de contexto novo, não como continuação

Como prevenir: antes de trocar, materialize em texto tudo que estava implícito no raciocínio (decisões, restrições, formato esperado) e alimente o novo modelo com isso

Erro de validação 4xx nas chamadas de função do Gemini 3:

Sintoma: a primeira chamada de ferramenta funciona, a resposta seguinte volta com erro de validação e tu jura que o payload está certo

Causa: os modelos Gemini 3 exigem que a thought_signature volte nas chamadas de função. Se a resposta traz partes functionCall, a assinatura é obrigatória, e não devolvê-la gera erro 4xx. Em chamadas paralelas só a primeira parte functionCall carrega a assinatura, em chamadas sequenciais cada functionCall carrega a sua

Solução: reenviar a parte exatamente como o modelo devolveu, sem normalizar, sem reordenar, sem "limpar"

Como prevenir: dá uma lida no guia de thought signatures antes de portar a tua camada de tools, porque essa é a pegadinha que mais parece bug de biblioteca e não é

O controle de raciocínio para de responder ao que tu pede:

Sintoma: tu ajusta o nível de esforço e o comportamento praticamente não muda

Causa: na camada de compatibilidade OpenAI do Gemini, os níveis low, medium e high do SDK da OpenAI são mapeados internamente para budgets fixos de 1K, 8K e 24K tokens de thinking. E as ferramentas server-side diferem entre as plataformas

Solução: assumir que tu está mexendo num tradutor, não no controle real do modelo

Como prevenir: se tu não está preso ao SDK da OpenAI, o próprio Google recomenda chamar a API Gemini direto. Tome cuidado aqui: é justamente o tipo de detalhe que passa despercebido em teste rápido e aparece na fatura

Recursos somem sem aviso na camada de compatibilidade da Anthropic:

Sintoma: o código roda, não dá erro, mas coisas que tu configurou simplesmente não acontecem

Causa: na camada de compatibilidade com o SDK da OpenAI, o parâmetro strict de function calling é ignorado, entrada de áudio não é suportada, prompt caching não é suportado, mensagens system e developer são concatenadas no início da conversa (a Anthropic aceita uma única system inicial) e o raciocínio detalhado não é retornado pelo SDK da OpenAI

Solução: listar esses cinco itens e checar um por um contra o teu código antes de confiar no resultado do teste

Como prevenir: usar a camada só pra comparar capacidade, do jeito que a documentação manda, e ir pra API nativa quando o teste virar decisão

O fluxo de segurança ofensiva para de rodar:

Sintoma: prompts que funcionavam no pipeline de segurança começam a voltar recusados

Causa: a versão pública do GPT-6 Astra recusa tarefas ofensivas avançadas de cibersegurança, incluindo geração de exploits de prova de conceito

Solução: não tem contorno bonito aqui, é limite de política do modelo público

Como prevenir: a OpenAI afirma que pretende afrouxar as restrições para defensores verificados por meio do programa Daybreak nas próximas semanas, e que as recusas reduzidas não estão disponíveis no Astra para a maioria dos clientes Daybreak. Ou seja: se o teu produto depende disso, planeje sem contar com essa liberação

Trocar no meio do projeto custa cota: o que aconteceu no meu teste

Aqui entra a parte que ninguém coloca na planilha de migração: o preço de refazer trabalho

No vídeo eu troco o modelo padrão do Claude Code por um modelo de terceiro e mostro o passo a passo dessa configuração, e o mesmo esquema vale pra qualquer software agente que aceite outra IA

Uma coisa que eu fiz e recomendo: em vez de trocar tudo por um modelo só, eu mapeei papéis. O modelo mais forte ficou com as tarefas pesadas e um mais fraco ficou com as tarefas simples, justamente pra não estourar a cota

Optei pelo plano mensal do provedor em vez de pagar por API, porque no uso via API dentro do Claude Code o consumo me pareceu alto quando comparei com Opus. Já tinha testado esse modelo antes e gostei do código entregue, mas a ressalva de custo continuou de pé

Como não era um modelo topo de linha, comecei gerando um PRD e um plano em markdown antes de qualquer código, pra guiar a IA durante o projeto

E olha o que aconteceu na prática:

• ele devolveu o PRD e o plano com 5 pontos em aberto pra eu decidir, e eu respondi cada um antes de liberar a implementação
• logo depois de ajustar os documentos, ele começou a implementar sem eu pedir, e eu cancelei a execução na hora pra não perder o controle das etapas
• depois desse susto eu passei a particionar mais os prompts em etapas menores e bem separadas, e os resultados tendem a ficar melhores assim
• na etapa seguinte ele respeitou o escopo e parou onde eu mandei parar, o que me surpreendeu porque eu esperava que passasse reto
• 16% da cota do plano de 5 horas foram embora só na criação do projeto inicial mais a landing page
• a etapa de autenticação levou 26 minutos pra ser entregue
• depois dessa etapa eu já estava em 40% da cota, com o projeto ainda nem na metade

Pra comparar: minha estimativa é que um scaffolding inicial de projeto costume levar em torno de 10 minutos (estimativa minha, não medição do teste)

A landing page ficou bonita e bem explicada, com cards animados, apesar do visual ter cara de padrão de IA. A autenticação funcionou quando eu criei uma conta de teste

A queixa forte foi a lentidão: qualquer coisa que eu pedia parecia demorar mais do que em outros modelos, percepção que eu já tinha do teste anterior

Agora conecta isso com migração

Quando tu troca de modelo no meio do projeto, tudo que estava implícito no contexto vira retrabalho pago de novo

Os pontos em aberto voltam pra mesa, o modelo novo não herda o raciocínio do antigo e cada etapa que tu já tinha "resolvido na conversa" precisa ser reconstruída em texto

E, apoiada em PRD e planejamento, a IA vai longe independentemente do modelo escolhido. É por isso que esses dois documentos são o teu seguro de migração: eles sobrevivem à troca, o contexto da thread não

No vídeo acima dá pra ver o consumo de cota subindo e o ritmo de entrega de cada etapa na prática, que é exatamente o custo escondido de recomeçar com outro modelo

Vale a pena trocar? Depende do que você já amarrou

A troca raramente quebra tudo de uma vez

Ela quebra em pedaços: o endpoint aqui, as ferramentas ali, o reasoning que não atravessa família, o teto de saída que cai pela metade, a faixa de preço que muda o request inteiro

Por isso o próximo passo concreto não é escolher o modelo destino, é rodar o inventário da seção de pré-requisitos com o teu código aberto na frente

Depois disso: se tu usa ferramentas no Chat Completions, migre pra Responses API antes de trocar de modelo

Teste o destino em paralelo pela camada de compatibilidade, sabendo que ela é bancada de teste e não produção

E só então reescreva o cliente na API nativa

Dá mais trabalho? Dá

Menos do que descobrir em produção que o output trunca na metade… 😀

até o próximo post!