Caiu ou Não?Pesquisar serviço
PT
Agentes e APIs

Snapshots GPT-4o e GPT-4.1 sairão da API: como migrar

Cinco snapshots da família GPT-4 serão removidos da API em 14 de janeiro de 2027. Veja como inventariar o uso, adaptar chamadas e validar a troca.

Computador exibindo a migração de snapshots GPT-4o e GPT-4.1 para GPT-6 Luna na API da OpenAI

Resposta rápida

A OpenAI removerá da API em 14 de janeiro de 2027 os snapshots gpt-4o-2024-08-06, gpt-4o-2024-11-20, gpt-4o-mini-2024-07-18, gpt-4.1-2025-04-14 e gpt-4.1-mini-2025-04-14. Versões ajustadas a partir desses modelos seguem o mesmo prazo. O substituto recomendado para todos eles é gpt-6-luna.

Não troque apenas o nome do modelo em produção. Primeiro inventarie chamadas diretas, variáveis de ambiente, filas Batch, configurações salvas e IDs de fine-tuning; depois crie uma rota de teste com GPT-6 Luna, execute avaliações representativas e faça rollout gradual. Use GET /v1/models para monitorar o campo shutdown_date e confirme a migração antes do prazo.

Quais modelos serão desligados

O aviso oficial de 14 de outubro de 2026 cobre dois snapshots GPT-4o, um GPT-4o mini, um GPT-4.1 e um GPT-4.1 mini. A data de desligamento é a mesma para os cinco identificadores: 14 de janeiro de 2027. A descontinuação já foi anunciada, mas o desligamento é o momento em que esses modelos deixam de ficar acessíveis pela API.

O comunicado não afirma que todo identificador contendo GPT-4 será removido nessa data. Compare o ID usado pela aplicação com a lista oficial, sem concluir pelo nome exibido em um painel ou por um alias. Se houver um modelo ajustado, localize o modelo-base; versões ajustadas derivadas dos modelos listados também seguem o cronograma de janeiro.

  • gpt-4o-2024-08-06 e gpt-4o-2024-11-20: migrar para gpt-6-luna.
  • gpt-4o-mini-2024-07-18: migrar para gpt-6-luna.
  • gpt-4.1-2025-04-14: migrar para gpt-6-luna.
  • gpt-4.1-mini-2025-04-14: migrar para gpt-6-luna.
  • Fine-tunes baseados nesses modelos: concluir a substituição antes da mesma data.

Encontre dependências que uma busca simples não mostra

Procure os IDs no código, arquivos de configuração, segredos, variáveis de ambiente, infraestrutura como código, jobs agendados e exemplos copiados para notebooks. Revise também bancos que guardam a escolha de modelo por cliente, painéis administrativos, plataformas low-code e serviços intermediários que recebem o nome dinamicamente.

Inclua Batch API, rotas de fallback, avaliações, tarefas assíncronas e modelos ajustados. Um endpoint pouco usado pode passar semanas sem aparecer nos logs e ainda quebrar depois do desligamento. Registre para cada ocorrência o proprietário, o volume, os recursos usados, a tolerância a erro e a data planejada de migração.

  • Busque os cinco IDs exatos em todos os repositórios e ambientes.
  • Liste configurações armazenadas fora do Git, inclusive painéis e bancos de dados.
  • Consulte métricas de uso e filas pendentes para encontrar caminhos raros.
  • Mapeie fine-tunes para o respectivo modelo-base.
  • Atribua um responsável e uma data de corte a cada integração.

Monitore shutdown_date pela API

O endpoint GET /v1/models agora informa o campo opcional shutdown_date. Quando houver data anunciada, o valor usa o formato YYYY-MM-DD; quando não houver, ele pode ser null. Faça uma consulta autenticada, filtre os modelos permitidos pela aplicação e gere alerta quando a data estiver próxima.

Não registre a chave da API nem a resposta integral em um local público. O endpoint mostra os modelos disponíveis para aquela credencial e organização, por isso dois ambientes podem ter catálogos diferentes. Uma checagem diária ou semanal é suficiente para governança; ela não substitui a página de descontinuações nem os testes de produção.

  • Chame GET https://api.openai.com/v1/models com a credencial do ambiente correto.
  • Selecione os IDs realmente aceitos pela aplicação.
  • Leia shutdown_date e trate null como ausência de data anunciada, não como garantia permanente.
  • Abra um alerta com antecedência e vincule-o ao responsável pelo serviço.
  • Repita a verificação após mudanças de projeto, conta ou provedor.

Adapte a chamada para GPT-6 Luna

GPT-6 Luna aceita texto e imagem como entrada e está disponível na Responses API e em Chat Completions. Para uma migração simples, coloque o identificador do modelo em uma configuração reversível e teste gpt-6-luna em um ambiente separado. A OpenAI recomenda a Responses API para ferramentas integradas e chamadas de função com raciocínio.

Em Chat Completions, GPT-6 Luna oferece function calling somente com reasoning_effort definido como none. Quando o esforço de raciocínio não for none, remova temperature, top_p e top_logprobs; remova também logprobs e inclusões equivalentes que a configuração não suporta. Preserve os esquemas de saída e as permissões de ferramentas enquanto compara o comportamento.

  • Crie uma flag ou configuração que permita alternar o modelo sem novo deploy emergencial.
  • Reproduza primeiro a chamada sem ferramentas e valide o formato de saída.
  • Adicione ferramentas, Structured Outputs, streaming e contexto persistente um recurso por vez.
  • Confirme reasoning_effort e retire parâmetros incompatíveis.
  • Mantenha uma rota de reversão somente enquanto o modelo antigo ainda estiver disponível.

Teste qualidade, custo e latência por tarefa concluída

Uma avaliação de migração deve usar entradas reais e casos difíceis, não apenas prompts curtos escolhidos para demonstração. Separe conjuntos para respostas factuais, classificação, extração, JSON estruturado, visão e tool calling conforme o produto. Defina antes o que conta como sucesso e inclua revisão humana nos casos em que uma resposta plausível pode causar dano.

Compare taxa de sucesso, recusas, formato, chamadas de ferramenta, tempo total, tokens de entrada, saída, raciocínio e gravação de cache. O preço de tabela ajuda no orçamento, mas a métrica mais útil é custo por tarefa correta: uma resposta barata que exige repetição pode sair mais cara. Refaça limites de gasto e rate limits com o tráfego observado.

  • Congele um conjunto de casos representativos e critérios de aprovação.
  • Execute o modelo antigo e o novo com o mesmo contexto e ferramentas.
  • Classifique regressões por impacto, frequência e possibilidade de correção no prompt.
  • Calcule custo e latência por tarefa aprovada, incluindo tentativas.
  • Promova por canário e acompanhe erros antes de aumentar o tráfego.

Fine-tuning exige um plano próprio

Trocar o ID de um modelo ajustado pelo nome GPT-6 Luna não transfere os pesos nem o comportamento aprendido. Como os fine-tunes baseados nos modelos afetados também serão desligados em 14 de janeiro, exporte o conjunto de avaliação, documente o prompt e identifique quais ganhos dependiam do ajuste.

Teste primeiro o modelo-base recomendado com um prompt atualizado e exemplos representativos. Se a qualidade ainda não atingir o requisito, avalie as opções de otimização atualmente disponíveis para a organização. Não espere o último mês: reproduzir critérios, dados e integrações costuma levar mais tempo que mudar uma linha de código.

Limitações e próxima ação útil

Este guia foi verificado em 15 de outubro de 2026. Ele cobre somente os cinco snapshots anunciados no dia anterior e seus fine-tunes. Preços, rate limits, recursos, substitutos recomendados e datas de outros modelos podem mudar; revalide a página oficial antes do corte. A página de status informa incidentes operacionais, mas não reativa um modelo desligado nem confirma compatibilidade do seu código.

Faça agora a primeira verificação objetiva: pesquise os cinco IDs, consulte GET /v1/models no projeto de produção e registre cada shutdown_date encontrado. Em seguida, migre uma rota de baixo risco para gpt-6-luna, rode o conjunto de avaliações e só amplie o tráfego quando qualidade, custo, latência e ferramentas passarem pelos critérios definidos.

Faça o próximo teste

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

Outros guias ligados ao mesmo tipo de problema.