OpenAI desativa a Assistants API: o guia de migração para quem tinha agentes em produção

Um encerramento que já aconteceu

A Assistants API da OpenAI não é mais uma opção em desuso, é uma API que parou de responder. Segundo o guia oficial de migração publicado na documentação da OpenAI, o desligamento aconteceu em 26 de agosto de 2026: qualquer chamada para openai.beta.threads ou openai.beta.threads.runs a partir dessa data simplesmente não funciona mais. Isso muda o tom do artigo: não é um aviso de que 'vai acabar', é um chamado para quem ainda está com produção quebrada, um mês depois do prazo, tentando entender o que fazer com Threads, Runs, File Search e Code Interpreter que dependiam daquela API.

A substituta indicada é a Responses API, já em uso por boa parte de quem construiu agentes mais recentes. A OpenAI resume a troca numa tabela de equivalências que vale entender item por item, porque nenhuma peça migra 1 para 1.

| Antes (Assistants API) | Agora (Responses API) | Por quê | |---|---|---| | Assistants | Prompts | Configuração fica versionada, fora do código | | Threads | Conversations | Guardam itens, não só mensagens | | Runs | Responses | Loop de ferramentas passa a ser explícito | | Run steps | Items | Objeto genérico: mensagem, tool call ou saída |

De threads para conversations: mensagens deixam de ser a unidade

Na Assistants API, uma thread era uma coleção de mensagens guardada no servidor da OpenAI. Só isso: entrada e saída de texto, associadas a um thread_id. Na Responses API esse contêiner passou a se chamar conversation, e a diferença não é só de nome: uma conversation armazena items, uma categoria mais ampla que inclui mensagens, chamadas de ferramenta e as respostas dessas ferramentas dentro do mesmo histórico.

Na prática, isso significa que o código que só empilhava role e content para reconstruir contexto precisa agora lidar com um histórico heterogêneo. O exemplo da própria documentação mostra a troca:

# Antes
thread = openai.beta.threads.create(
 messages=[{"role": "user", "content": "pergunta"}],
 metadata={"user_id": "peter"},
)

# Agora
conversation = openai.conversations.create(
 items=[{"role": "user", "content": "pergunta"}],
)

Quem tinha lógica de auditoria ou replay de conversa construída em torno de thread.messages.list() vai precisar reescrevê-la para iterar sobre items, e tratar cada tipo (mensagem, tool call, tool output) de forma distinta em vez de assumir que tudo é texto.

De runs para responses: o loop de ferramentas agora é seu

Essa é, na leitura deste guia, a mudança de contrato mais dolorosa para quem tinha agentes com Code Interpreter ou funções customizadas. Um run na Assistants API era um processo assíncrono: o cliente criava o run, entrava num loop de polling checando run.status até virar completed, e a SDK tratava por trás dos panos boa parte da orquestração de required_action quando havia uma tool call pendente.

Na Responses API não existe mais esse status assíncrono por padrão. openai.responses.create() recebe os items de entrada e devolve os items de saída numa única chamada, associada opcionalmente a um conversation_id para manter o histórico (substituindo o antigo hábito de repassar previous_response_id manualmente). O texto da OpenAI é direto sobre isso: as respostas são pensadas para serem usadas isoladamente, mas também aceitam prompt e conversation para guardar configuração e contexto.

O ponto que o guia deixa explícito, e que muda o desenho de qualquer agente com ferramentas, é que "tool call loops are explicitly managed": não existe mais o required_action do run cuidando de pausar e retomar a execução quando uma função precisa ser chamada. Quem tinha um agente de Code Interpreter ou function calling que dependia desse ciclo automático do run precisa reescrever esse loop no próprio código de orquestração, decidindo explicitamente quando reenviar o output de uma ferramenta como novo input.

Assistants somem, prompts entram (só pelo dashboard)

A segunda mudança de contrato é organizacional, não só técnica. Um Assistant era um objeto de API: criado, atualizado e apagado por chamadas POST/PATCH/DELETE, com modelo, instruções e ferramentas embutidos nele. O substituto, o prompt, só pode ser criado pelo dashboard da OpenAI, não pela API. Isso é uma escolha deliberada, segundo a documentação: prompts são pensados para serem versionados, revisados e comparados como um artefato de produto, não gerados programaticamente a cada deploy.

A consequência prática é que times que automatizavam a criação de assistants via CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, por exemplo criando um assistant por tenant ou por experimento, perdem esse caminho. O guia sugere guardar o ID do prompt (ou o spec exportado) em controle de versão, e trocar de prompt via ID para rodar testes A/B, em vez de criar e apagar objetos de assistant em runtime. É uma perda de flexibilidade programática em troca de rastreabilidade: dá para auditar exatamente qual versão do prompt gerou qual resposta, algo que a Assistants API não oferecia de forma nativa.

File Search e Code Interpreter: a lacuna que o guia não fecha

Aqui está o ponto que interessa mais a quem realmente tinha RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → em produção com File Search, ou execução de código com Code Interpreter, e não só um chatbot simples. O guia de migração da OpenAI documenta em detalhe a troca de threads, runs e assistants, com exemplo de código lado a lado em Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → e Go. Mas, na versão consultada da documentação, não há o mesmo tratamento passo a passo para migrar as configurações de File Search e Code Interpreter que existiam dentro de um Assistant.

Ambas as ferramentas continuam existindo como capacidades da plataforma, listadas separadamente na estrutura de documentação sob "Search and retrieval" e "Computer and code", o que sugere que elas foram reorganizadas como tools de propósito geral, plugáveis também em Responses API, MCP e Agents SDK, e não mais amarradas ao objeto Assistant. Só que isso é inferência a partir da estrutura do índice, não uma instrução de migração explícita para índices de arquivo, vector stores e resultados de execução de código que antes viviam dentro de tool_resources de um assistant. Para quem tinha um pipeline de RAG inteiro configurado dessa forma, a recomendação prática é tratar essa parte da migração como reconstrução, não como troca de nome de campo: vale revisitar a configuração de vector store e reimplementá-la olhando a documentação específica de file search e code interpreter dentro da Responses API, em vez de esperar um mapeamento automático.

Roteiro de migração para quem ainda não saiu do lugar

Para quem chega a este ponto com produção ainda dependente da API desligada, um caminho razoável, seguindo a lógica proposta pelo próprio guia, é:

1. Levantar cada Assistant existente e documentar seu par instruções + ferramentas antes que o dashboard antigo saia do ar também.
2. Recriar esse conjunto como um prompt no dashboard atual, guardando o ID em controle de versão junto com o código da aplicação.
3. Trocar a chamada de threads.create + runs.create por responses.create, passando o conversation_id para manter o histórico entre chamadas.
4. Reescrever o polling de run.status como um loop explícito de tool calls, tratando cada item de saída (mensagem, chamada de função, resultado) sem assumir que a SDK vai pausar e retomar por conta própria.
5. Auditar separadamente qualquer configuração de File Search ou Code Interpreter, tratando essa parte como reimplementação e não como find-and-replace de nomes de campo.

O ganho declarado pela OpenAI para quem completa essa migração inclui acesso a recursos que não existiam na Assistants API, como deep research, MCP e computer use, além de gestão de conversa mais direta no lugar do encadeamento manual de previous_response_id. Para times brasileiros com agentes em produção, isso significa que o esforço de reescrever o loop de ferramentas tende a se pagar em funcionalidades novas, mas o custo real está concentrado exatamente onde o guia oficial é mais raso: na reconstrução de RAG e execução de código que antes vinham prontos dentro do Assistant.

Fonte: OpenAI Platform Docs — Assistants API Migration Guide