Para identificar mudanças incompatíveis da OpenAI, acompanhe três fontes oficiais com papéis diferentes: o changelog da API (o que mudou na plataforma), a página de deprecations (o que vai deixar de funcionar e quando) e as notas de versão do ChatGPT e dos modelos na central de ajuda (o que mudou para quem usa o produto). Em cada entrada, procure os nomes de modelo e endpoints que você usa, verbos como “retire”, “shut down”, “deprecated” e “does not support”, e datas de desligamento.
Uma mudança incompatível (breaking change) é qualquer alteração que faz um sistema que funcionava parar ou mudar de comportamento sem você mexer no código: um modelo desligado, um parâmetro que deixa de ser aceito, um endpoint encerrado.
Resumo rápido
- O changelog da API fica em developers.openai.com/api/docs/changelog e marca cada entrada com tipo (Feature, Update, Fix) e com os modelos e endpoints afetados.
- A página de deprecations lista desligamentos com data e substituto recomendado; o mesmo dado aparece no campo
shutdown_datedo endpointGET /v1/models.- Mudanças no ChatGPT (aposentadoria de modelos no app, novos padrões por plano) ficam nas notas de versão do ChatGPT e nas notas de modelos da central de ajuda, e muitas vezes não afetam a API.
- Use o aviso específico de retirada para planejar prazos, em vez de depender apenas de uma política geral.
- Toda entrada relevante vira uma linha no inventário: o que usamos, o que muda, data, dono, teste de regressão.
Onde a OpenAI publica cada tipo de mudança
Cada página cobre um público e um tipo de mudança, e um anúncio pode aparecer em mais de uma delas.
| Fonte | Endereço | O que registra | Quem precisa ler |
|---|---|---|---|
| Changelog da API | developers.openai.com/api/docs/changelog | Lançamentos de modelos, novos parâmetros, mudanças de preço, correções e anúncios de deprecation, com data e itens afetados | Desenvolvedores e quem paga a conta da API |
| Deprecations | developers.openai.com/api/docs/deprecations | Modelos e endpoints em descontinuação, data de desligamento e substituto recomendado | Desenvolvedores, operações, gestão de produto |
| Notas de versão do ChatGPT | help.openai.com, artigo “ChatGPT release notes” | Novos recursos e mudanças no app, por plano e plataforma | Usuários, administradores de workspace, treinamento |
| Notas de versão dos modelos | help.openai.com, artigo “Model Release Notes” | Lançamentos, atualizações e aposentadorias de modelos no ChatGPT | Usuários avançados e administradores |
| Changelog do Codex | learn.chatgpt.com/docs/changelog | Versões do Codex, troca de modelos padrão e aposentadorias no Codex | Equipes de desenvolvimento que usam o Codex |
A página de deprecations afirma que clientes afetados são avisados por e-mail e na documentação, com posts no blog para mudanças maiores. O e-mail chega para quem está usando o modelo; use uma caixa compartilhada como contato da organização.
Confira o produto antes de interpretar a mudança
Não deduza que uma mudança no aplicativo vale para a API. Leia o escopo do aviso: produto, cliente, forma de autenticação e público afetado. Se a fonte não esclarecer seu caso, registre a dúvida. A pergunta inicial é qual parte da sua operação depende exatamente do item citado.
Monte um inventário com aplicação, responsável, modelo completo, endpoint e local da configuração. Inclua ferramentas sem código e serviços de terceiros. Uma dependência pode estar num painel de automação ou variável de ambiente, sem aparecer no repositório principal. Quando um fornecedor não informa a configuração, registre a limitação e peça esclarecimento antes de concluir que não existe impacto.
Como ler o changelog da API
Cada entrada do changelog tem data, um tipo (Feature, Update ou Fix) e uma lista de etiquetas com os modelos e endpoints envolvidos, como o identificador completo do modelo e o endpoint utilizado. As etiquetas são o atalho: se nenhuma delas aparece no seu código, a entrada provavelmente não é urgente para você. A própria página informa, no topo, que as descontinuações futuras ficam na página de deprecations.
Ao ler uma entrada de lançamento de modelo, separe três blocos de informação:
- Restrições do modelo novo. Antes de adotar um lançamento, compare os parâmetros aceitos com os enviados pela aplicação. Verifique também a API exigida e os formatos de entrada e saída.
- Condições operacionais. Separe mudanças de cobrança ou acesso de mudanças no contrato técnico. Uma aplicação pode continuar funcionando e ainda exigir uma revisão de orçamento.
- Correções de comportamento. Uma correção pode afetar um processo que passou a depender do comportamento anterior. Encaminhe os casos relevantes para avaliação, sem presumir equivalência.
Leia cada entrada em duas passagens. Primeiro localize os identificadores e termos de retirada ou incompatibilidade. Depois releia as condições completas e registre a conclusão. Não use apenas o trecho mostrado no resultado de busca: ele pode omitir a ressalva que decide se a mudança vale para o seu sistema.
Como ler a página de deprecations
A página de deprecations usa um vocabulário preciso, e vale conhecê-lo antes de ler as tabelas:
- Deprecated (descontinuado): o modelo ou endpoint entrou em processo de retirada no momento do anúncio. Ainda funciona, mas já tem data de desligamento.
- Shut down ou sunset (desligado): a partir da data, o modelo ou endpoint deixa de responder.
- Legacy (legado): não recebe mais atualizações e deve ser descontinuado em algum momento, mas ainda sem data.
Na tabela de retirada, copie o identificador completo, a data publicada e o substituto indicado para uma ficha de acompanhamento. Acrescente a URL e a data da consulta. Se a entrada mudar depois, preserve a conclusão anterior e registre uma revisão. Assim a equipe consegue distinguir uma alteração do fornecedor de um erro de leitura interno.
Planeje pelo aviso específico
Não transforme a política geral de aviso em prazo garantido para sua aplicação. Leia a entrada concreta, registre a data e atribua uma pessoa responsável. Defina um prazo interno que deixe espaço para dúvidas, testes e correções. Se a dependência for crítica, acompanhe a fonte com frequência maior e mantenha a equipe operacional informada.
Monitorar datas sem depender de leitura manual
A consulta à API pode complementar o acompanhamento das fontes. O endpoint GET /v1/models (e o de consulta de um modelo específico) pode retornar o campo opcional shutdown_date, no formato AAAA-MM-DD, ou null quando não há data anunciada. Um script diário que cruza esse campo com os modelos do seu código e alerta quando surge uma data complementa a revisão. Trate campo ausente e falha na consulta explicitamente; o silêncio do monitor não deve parecer ausência de mudanças.
Transforme nomes e configurações em evidência
Registre o identificador efetivamente enviado pela aplicação, não apenas o nome comercial que aparece na conversa com o fornecedor. Se o acesso usar um nome que aponta para outra versão, confira na documentação como esse apontamento funciona. Não presuma comportamento imutável pelo formato do nome.
Uma ficha de revisão útil contém aplicação, produto, identificador, configuração relevante e conclusão. Diferencie “não usamos”, “usamos e precisamos avaliar” e “não foi possível confirmar”. Essa terceira situação exige responsável e próximo passo; ausência de evidência não é prova de compatibilidade.
A revisão documental precisa terminar em perguntas verificáveis: a chamada continua aceita? Os campos retornados continuam legíveis? O comportamento segue adequado para a tarefa? Uma resposta bem-sucedida da API não confirma sozinha a qualidade do processo. Compare também casos em português e critérios de aceitação da operação, conforme o guia sobre registro de configurações para comparar versões.
Checklist de impacto para cada aviso
Para cada entrada relevante, responda:
- Usamos isso? Procure o ID do modelo, o endpoint ou o parâmetro no código, nas variáveis de ambiente, em arquivos de configuração e em ferramentas sem código (automações, agentes, tarefas agendadas).
- É produto ou API? Confirme se a mudança vale para ChatGPT, API, Codex ou para mais de um.
- Qual a data? Anote a data de desligamento e coloque um lembrete com folga, por exemplo 60 dias antes.
- Qual o substituto? Use o recomendado pela página de deprecations como primeiro candidato, não como decisão final.
- O substituto tem restrições? Leia o guia de migração do modelo novo: parâmetros não aceitos, API exigida, residência de dados e preço.
- O que depende disso por baixo? Modelos com ajuste fino, prompts salvos, avaliações e integrações de terceiros que fixam o modelo.
- Quem é o dono? Uma pessoa responsável e um prazo interno.
Inclua dependências de apoio, como ambientes de teste, bibliotecas e serviços intermediários. Uma mudança pode afetar a forma de validar a integração, mesmo quando a chamada principal permanece disponível. Encaminhe cada dúvida para quem consegue conferir a configuração real.
Testes de regressão antes da data
A leitura só vale se terminar num teste:
- Conjunto fixo de casos reais, anonimizados, com a resposta esperada ou critérios objetivos (campo correto, JSON válido, tom adequado).
- Linha de base com o modelo atual e execução no substituto com o mínimo de mudanças exigidas pelo guia; ajustes de prompt só depois.
- Comparação de acerto, formato, custo por tarefa e latência, com um limite claro do que é aceitável piorar.
- Liberação gradual, com caminho de volta enquanto o modelo antigo ainda responde.
Para agentes com ferramentas, o teste precisa olhar também quais ferramentas foram chamadas e em que ordem. O passo a passo está em testes de regressão para agentes. Se a mudança envolve endpoints e webhooks, veja descontinuações na OpenAI API: migrar endpoints sem perder eventos.
Exemplo: escritório contábil em Curitiba organiza a revisão semanal
Imagine um escritório de contabilidade em Curitiba que usa a API da OpenAI em três pontos: transcrição de reuniões com clientes, classificação de documentos recebidos por e-mail e um assistente interno que responde dúvidas sobre prazos fiscais. Os sócios também usam o aplicativo ChatGPT.
Toda segunda-feira, a pessoa responsável abre as fontes pertinentes e cruza as entradas com o inventário. O caso é ilustrativo. Ao encontrar uma nota que cita o modelo do classificador, ela consulta a configuração real, salva a fonte e registra qual parâmetro precisa ser conferido pela pessoa que mantém o sistema.
A ficha não afirma que a integração quebrou antes da verificação. Ela descreve a hipótese, o responsável e o próximo passo. O classificador recebe documentos anonimizados já classificados por pessoas para comparação. Enquanto isso, a operação define quais divergências impedem uma liberação. A decisão fica vinculada ao resultado dos testes.
Um aviso sobre produto que o escritório não utiliza também recebe uma conclusão curta: fora do inventário, sem intervenção identificada. Registrar esse descarte evita repetir a investigação na semana seguinte. Quando uma mudança relevante estiver resolvida, a ficha só é encerrada com evidência do ajuste e da validação.
Erros comuns
- Ler só o blog. Posts cobrem as grandes mudanças; desligamentos de snapshots antigos aparecem na página de deprecations e no e-mail.
- Confundir ChatGPT com API. A aposentadoria de um modelo no app não significa que ele saiu da API, e vice-versa.
- Esquecer dependências indiretas. Confira também serviços de terceiros e configurações fora do código principal.
- Ignorar como o identificador funciona. Confira na documentação se ele aponta para uma versão ou acompanha atualizações.
- Trocar o nome do modelo e publicar. O substituto pode rejeitar parâmetros ou exigir outra API; sem teste de regressão, o erro aparece com o cliente.
- Deixar o e-mail da organização numa caixa pessoal. O aviso oficial chega e ninguém lê.
Perguntas frequentes
Qual a diferença entre deprecated e legacy na OpenAI?
Deprecated significa que a retirada foi anunciada e já existe data de desligamento. Legacy indica que o modelo ou endpoint não recebe mais atualizações e deve ser descontinuado no futuro, ainda sem data.
Como definir o prazo para agir?
Consulte a data da entrada específica e estabeleça um prazo interno que permita revisão e testes. A política geral ajuda a entender o processo, mas a decisão deve usar o aviso aplicável à sua dependência e suas condições.
Existe um jeito automático de saber a data de desligamento?
Sim. O endpoint GET /v1/models documenta o campo opcional shutdown_date, com a data no formato AAAA-MM-DD ou null se não houver data anunciada.
Uma mudança no ChatGPT pode quebrar minha integração com a API?
Não deduza o impacto apenas pelo nome do produto. Confira o escopo do aviso e a forma de acesso da sua aplicação. Se a condição continuar ambígua, registre a pergunta como pendente e confirme com o responsável pela integração.
Fontes e leitura recomendada
- OpenAI API: changelog
- OpenAI API: deprecations
- OpenAI API: List models (campo shutdown_date)
- Central de ajuda: ChatGPT release notes
- Central de ajuda: Model Release Notes
- Codex: changelog
Veja também a página de integrações da OpenAI e do ChatGPT no IA Mágica.