Em 26 de agosto de 2026, os endpoints /v1/assistants, /v1/threads e /v1/runs vão retornar erro. Não aviso, não fallback: erro 404 em produção. Se você tem agentes rodando com a Assistants API da OpenAI, tem menos de 100 dias para migrar ou perder a operação.
O Que Vai Parar de Funcionar em Agosto?
A OpenAI anunciou a descontinuação da Assistants API em agosto de 2025, com um ano de prazo. O comunicado foi direto: todos os endpoints são removidos permanentemente em 26/08/2026. Nenhuma extensão foi sinalizada desde então.
O que para de funcionar no dia do corte:
/v1/assistants: criação e gerenciamento de assistants/v1/threads: abertura e manutenção de threads de conversa/v1/threads/{thread_id}/runs: execução de runs- File Search e Code Interpreter vinculados à Assistants API
O detalhe que muda o tamanho do trabalho: a OpenAI não vai fornecer ferramenta automática para migrar Threads para Conversations. Todo o histórico armazenado em Threads precisa ser migrado manualmente ou descartado. A documentação oficial é explícita sobre isso. (Fonte: OpenAI Developer Community)
Por Que a Migração Para a Responses API Não é Simples?
A thread mais votada da developer community OpenAI sobre o assunto tem um título revelador: "Assistants API to Responses API: this is not a 1:1 migration." O problema não é sintaxe. É arquitetura.
Na Assistants API, a OpenAI gerenciava o estado da conversa. Você criava um Thread, adicionava mensagens, disparava um Run e coletava o output. O armazenamento ficava nos servidores da OpenAI. Para multi-turn, você continuava o mesmo Thread. Para recuperar histórico, consultava o Thread. Estado zero do seu lado.
Na Responses API, você gerencia o estado. Duas abordagens possíveis:
- Client-managed: você armazena o
previous_response_ide envia de volta a cada chamada. Simples para conversas curtas, problemático para sessões longas com muitos usuários simultâneos. - Server-managed via Conversations API: equivalente ao Thread, mas API nova, estrutura nova e sem migração automática dos dados existentes.
Dado-chave: A OpenAI confirmou que não haverá ferramenta automática de migração de Threads para Conversations. A recomendação oficial é migrar novas conversas para a Conversations API e fazer backfill das antigas conforme necessário. Para sistemas com histórico extenso de threads, isso representa trabalho manual significativo de migração de dados. (Fonte: OpenAI Migration Guide)
A mudança para Responses API é arquiteturalmente mais sólida: API stateless é mais previsível, mais testável e mais barata de operar. Mas coloca a responsabilidade de gestão de estado de volta no dev. Para agentes simples, é um refactor de horas. Para agentes com histórico longo, múltiplos usuários simultâneos e File Search extensivo, é uma reescrita de componentes centrais.
3 Rotas de Migração Para Antes de Agosto
Rota 1: Responses API + Conversations API (OpenAI Nativo)
A rota oficial da OpenAI. O código muda assim na prática:
# Assistants API (para de funcionar em 26/08/2026)
thread = client.beta.threads.create(
messages=[{"role": "user", "content": "Como rastrear meu pedido?"}],
metadata={"user_id": "user_123"}
)
run = client.beta.threads.runs.create_and_poll(
thread_id=thread.id,
assistant_id=assistant_id
)
# Responses API (substituto atual)
conversation = client.conversations.create(
items=[{"role": "user", "content": "Como rastrear meu pedido?"}],
metadata={"user_id": "user_123"}
)
response = client.responses.create(
model="gpt-5",
conversation_id=conversation.id,
instructions="Você é o assistente de atendimento da Loja X."
)
Para agentes simples com poucas mensagens por sessão: refactor de 1 a 3 dias. Para agentes com File Search extensivo, Code Interpreter ou threads com histórico longo de múltiplos usuários, o trabalho sobe para semanas, incluindo infraestrutura de armazenamento de estado.
Um detalhe de custo que muda a conta: na Assistants API, o armazenamento de Threads era gerenciado pela OpenAI por um período e depois descartado automaticamente. Na Conversations API, você controla o ciclo de vida. O custo de storage de conversas longas é seu.
Rota 2: LangGraph + LLM Direto (Sair do Lock-in OpenAI)
Aproveitar a migração forçada para construir em cima de LangGraph com chamadas diretas às APIs de LLM. Você escolhe o modelo, gerencia estado com os checkpointers nativos do LangGraph e não depende de nenhuma abstração proprietária.
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver
from typing import TypedDict, Annotated
import operator
class ConvState(TypedDict):
messages: Annotated[list, operator.add]
user_id: str
def agente(state: ConvState):
# troca de modelo sem reescrever a lógica
response = llm.invoke(state["messages"])
return {"messages": [response]}
memory = SqliteSaver.from_conn_string("conversas.db")
workflow = StateGraph(ConvState)
workflow.add_node("agente", agente)
workflow.set_entry_point("agente")
workflow.add_edge("agente", END)
app = workflow.compile(checkpointer=memory)
O ganho concreto: independência de fornecedor. Com LangGraph, trocar de GPT-5.4 (US$ 2,50/M tokens de input) para Claude Sonnet 4.6 (US$ 3/M com contexto de 1M) ou DeepSeek V3.2 (US$ 0,14/M) é um import. Para operações com alto volume, a diferença de custo entre modelos pode ultrapassar 10x.
O custo dessa rota: você constrói e mantém a camada de persistência. Redis ou Postgres para checkpoints em produção. Se o agente vai operar no WhatsApp, você ainda precisa de webhook, sessões por número de telefone, tratamento de mídia e aprovação na Cloud API do Meta. São semanas de infra antes de escrever a primeira linha de lógica do negócio.
Rota 3: Plataforma Gerenciada (Zero Infra, Deploy em Horas)
A Assistants API resolvia um problema real: persistência de estado sem banco de dados próprio. A Responses API devolve esse problema para o dev. Para equipes focadas em produto, essa é a parte mais custosa da migração.
Uma terceira rota é usar plataforma que já resolve estado, memória, RAG e canal nativamente. O Assistente na Verboo opera exatamente assim. Instrução com contexto do negócio, Base de Conhecimento com RAG e re-ranking, memória persistente entre sessões por usuário, Gatilhos para fluxos automáticos e WhatsApp nativo. Você configura a lógica do agente, não a infra por baixo.
O paralelo com o que a Assistants API prometia:
| Assistants API | Verboo (equivalente nativo) |
|---|---|
| Assistant + Instructions | Assistente + Instrução |
| Threads (estado da conversa) | Memória nativa por usuário |
| File Search (RAG sobre documentos) | Base de Conhecimento com RAG + re-ranking |
| Code Interpreter | MCP Servers e integrações customizadas |
| Canal de entrega: você implementa | WhatsApp nativo integrado |
Qual Rota Tem o Menor Custo Real de Migração?
Custo real não é só tempo de desenvolvimento. É tempo de desenvolvimento mais manutenção mais risco de downtime em agosto se a migração atrasar.
| Rota | Tempo de Setup | Migração de Histórico | Manutenção de Infra | Melhor Para |
|---|---|---|---|---|
| Responses API | 1-3 dias (simples) / 2-4 semanas (complexo) | Manual, sem ferramenta automática | Você gerencia estado e storage | Agentes com lógica complexa já em produção |
| LangGraph direto | 2-4 semanas (infra completa) | Reimplementação completa | Redis/Postgres + deploy | Times com capacidade de infra e foco em independência de LLM |
| Verboo | Horas | Não necessário | Zero | Atendimento, vendas e automação em WhatsApp |
O Que Fazer Esta Semana?
Independentemente da rota escolhida, três ações práticas antes de entrar em junho:
- Audite o uso atual: liste todos os assistants e threads ativos. A OpenAI tem exportação de dados via API, mas não migração automática. Exporte o histórico relevante enquanto os endpoints ainda funcionam.
- Decida a rota agora: deixar para julho é tarde. Com testes e validação em produção, você precisa de pelo menos 4 a 6 semanas de margem para não chegar em agosto correndo.
- Suba o novo ambiente em paralelo: nunca migre direto em produção. Suba o ambiente novo (Responses API, LangGraph ou plataforma alternativa) e migre gradualmente por caso de uso com rollback disponível.
A Verboo opera 390 empresas com mais de 27 milhões de mensagens processadas e latência abaixo de 500ms. Para agentes de atendimento e vendas que precisam sair da Assistants API sem construir infra do zero, é o caminho mais direto disponível agora. Conheça a plataforma.
