Chat Completions ou Responses API: onde o GPT-6 Sol roda com todos os recursos?

Você tem uma aplicação inteira em Chat Completions, o GPT-6 Sol saiu e agora a pergunta é uma só: dá pra trocar o nome do modelo e seguir a vida?

Depende do que seu código faz 🙂

O GPT-6 Sol e o GPT-6 Luna foram lançados em 22 de setembro de 2026 e já estão disponíveis na API como gpt-6-sol e gpt-6-luna

Dentro da família GPT-6, o Sol é o modelo do meio: a OpenAI posiciona ele pra equilibrar inteligência e custo

Na ponta de cima fica o GPT-6 Astra, o da linha pra raciocínio e coding complexos, e na ponta de baixo o GPT-6 Luna, pra workloads de alto volume sensíveis a custo

Mesmo sendo o do meio, a página do próprio Sol descreve ele como construído para coding complexo e fluxos agênticos, ou seja, não é modelinho de recado, é um modelo agêntico com preço de meio-termo

E é justamente aí que mora a pegadinha: fluxo agêntico pede ferramenta, e ferramenta é exatamente o ponto onde as duas APIs deixam de ser equivalentes

Chat Completions x Responses API no GPT-6 Sol: o que muda

A página do modelo é curta e grossa: a orientação é usar a Responses API para built-in tools e function calling, e a Chat Completions suporta function calling apenas com reasoning_effort definido como none

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Se liga na comparação linha a linha:

Repara que não é uma lista de firulas

A Responses é agêntica por padrão, a Chat Completions é um endpoint de conversa que ganhou ferramentas depois

Quando a Chat Completions ainda resolve (e quando não resolve)

Primeiro, o alívio: a Chat Completions não está depreciada e segue suportada

Quem foi encerrada foi a Assistants API, em 26 de agosto de 2026

A recomendação oficial é usar a Responses em projetos novos, mas ninguém vai puxar o tapete do seu código que já roda

Casos em que dá pra ficar onde está:

• Endpoint simples de geração de texto, sem nenhuma ferramenta envolvida
• Classificação, resumo, reescrita, aquele monte de chamada burra que só recebe texto e devolve texto
• Job interno que já está estável e você não quer tocar agora

Casos em que dá pra ficar, mas com uma trava:

Se você precisa de function calling e não vai migrar agora, o jeito é fixar reasoning_effort como none

Funciona, porém você está usando um modelo construído pra coding complexo no modo mais raso possível

E aqui vale explicar a escala inteira, porque ela muda o resultado: o reasoning effort do GPT-6 Sol aceita none, low, medium, high, xhigh e max, sendo medium o padrão

Só presta atenção no nome do campo, que muda conforme a API: na Chat Completions ele vai plano, como reasoning_effort, e na Responses ele vai aninhado, como reasoning.effort

Ou seja, ao fixar none você está descendo abaixo do padrão pra conseguir chamar função

Tome cuidado com uma coisa: esse valor none não é universal na família GPT-6

O GPT-6 Astra não suporta reasoning effort none e retorna HTTP 400 quando esse valor é enviado

Então aquele wrapper esperto que você escreveu pra trocar de modelo na variável de ambiente vai explodir no dia que alguém apontar pro Astra 😛 (se a ideia é brincar com ele fora do código, dá pra rodar o GPT-6 Astra no terminal antes de decidir)

Casos em que a Chat Completions trava o projeto:

• Agente com várias ferramentas, onde o modelo precisa encadear chamadas sozinho
• Qualquer coisa que dependa de web search ou file search nativos
• Execução de Python em container sandbox pelo code interpreter
• Integração com servidores MCP

Nesses quatro, não tem jeitinho

É migrar

Como migrar de Chat Completions para a Responses API

O guia oficial de migração resume tudo em três mudanças principais: o endpoint, a leitura da saída e como a aplicação carrega o estado entre turnos

Na prática, quando você abre o código, aparecem mais alguns pontos

Bora por partes

1. Troque o endpoint

As requisições deixam de ir pra /v1/chat/completions e passam a ir pra /v1/responses

POST /v1/chat/completions   (antes)
POST /v1/responses          (depois)

O erro comum aqui: achar que só isso basta e mandar o payload antigo inteiro pro endpoint novo

2. Aponte o modelo e o effort no formato novo

O identificador do modelo continua sendo gpt-6-sol, mas o effort deixa de ser um campo solto

{
  "model": "gpt-6-sol",
  "reasoning": { "effort": "medium" },
  "store": true
}

O erro comum: manter reasoning_effort no formato antigo por copiar e colar do código velho

3. Leia a saída do array output tipado

A resposta não vem mais no formato que você conhece de cor

O SDK da Responses oferece o helper output_text, que não existe na Chat Completions, e ele resolve o caso simples

O erro comum: seu parser antigo continuar cavando o mesmo caminho de chaves e quebrar em produção com um erro de índice

4. Migre as definições de função e o call_id

O formato de function calling muda nos dois lados: na definição da função e no retorno da chamada

É preciso migrar as definições e garantir que os outputs de function call incluam o call_id correto

O erro comum: o modelo chama a função, sua aplicação executa direitinho, devolve o resultado sem o call_id certo e a conversa fica de pernas pro ar

5. Mova os schemas de Structured Outputs

Os schemas saem de response_format e passam para text.format

{
  "text": {
    "format": { "comentario": "seu schema de structured output vai aqui" }
  }
}

O erro comum: mandar response_format no payload novo e ficar achando que o modelo "parou de respeitar o schema"

6. Atualize quem consome streaming

A Responses trabalha com eventos tipados, então os consumidores de streaming precisam ser atualizados pra tratar esses eventos

O erro comum: o front continuar concatenando delta de texto igual antes e a UI virar um Frankenstein

7. Decida como sua aplicação carrega o estado

Aqui você escolhe: previous_response_id pra encadear respostas, compatibilidade com a Conversations API pra conversas persistentes, ou store: true pra manter estado de turno em turno

Na Chat Completions esse trabalho era manual, todo no seu código

O erro comum: migrar tudo e continuar remontando o histórico na mão, jogando fora o ganho de cache que era metade do motivo da mudança

Reasoning items: o detalhe que quebra a migração pela metade

Esse é o ponto que costuma passar batido e depois vira aquele bug estranho de "o modelo ficou burro no segundo turno"

Para melhores resultados com reasoning items, a documentação recomenda usar a Responses API com store definido como true e reenviar os reasoning items das requisições anteriores

Ou seja, não é só guardar a mensagem final, é devolver o raciocínio anterior pro modelo continuar de onde parou

E se você não pode armazenar nada?

Tem saída

Quando store é false ou a organização usa Zero Data Retention, os reasoning items do array output incluem a propriedade encrypted_content por padrão

Esse conteúdo criptografado pode ser devolvido em requisições futuras, então dá pra manter a continuidade do raciocínio sem abrir mão do modo stateless

Muito massa esse detalhe, e é exatamente o tipo de coisa que ninguém lembra de checar antes de subir pra produção…

Quanto custa rodar o GPT-6 Sol na API

Agora a parte que o financeiro pergunta

Repara na terceira linha da tabela: input cacheado sai por um décimo do input normal

Agora junta isso com o fato de que a Responses API reporta melhora de 40% a 80% na utilização de cache comparada à Chat Completions

A migração não é só sobre recurso, é sobre quanto do seu prompt fixo (system, instruções, definições de ferramenta) está batendo no cache em vez de ser cobrado cheio

E presta atenção naquele corte de 272 mil tokens: passou disso, a tabela muda pra requisição inteira, não só pro excedente

Com 1.050.000 tokens de janela, é bem fácil cruzar essa linha sem perceber quando você joga um repositório inteiro no contexto

Veredito: qual API escolher para o GPT-6 Sol

Vamos ao que interessa, por perfil:

Projeto novo: vai de Responses API, sem pensar muito

É a recomendação da própria documentação pra projetos novos, é onde as built-in tools moram e é onde o function calling funciona sem amarras

Código legado sem tools: pode ficar onde está

A Chat Completions segue suportada, então não existe urgência artificial aqui

Migra quando fizer sentido, não porque alguém no Twitter disse que é obrigatório

Precisa de function calling e não vai migrar agora: você fica preso a reasoning_effort = none

Funciona, mas é o Sol andando de muletas

E se o seu caso é agente de verdade, com várias ferramentas e várias chamadas por requisição, essa muleta cai rápido

Duas coisas pra fechar a decisão

A primeira: snapshots existem pra travar uma versão específica do modelo, mantendo performance e comportamento consistentes

Se seu sistema é sensível a mudança de comportamento, fixa a versão antes de migrar, não durante

A segunda: no anúncio de lançamento, a OpenAI divulgou 68,8% no DeepSWE v1.1 para o GPT-6 Sol com reasoning effort max

Esse é o teto do modelo

E dá pra olhar esse número e perguntar: faz sentido pagar por um modelo desse porte pra rodar ele fixado em effort none só pra não mexer no endpoint? 🤔

Conclusão

A escolha entre Responses API ou Chat Completions no GPT-6 Sol não é questão de gosto: com ferramentas no jogo, a Responses é o único lugar onde o modelo entrega tudo, e a Chat Completions só faz function calling com reasoning_effort = none

Quem tem código antigo sem tools não precisa correr, porque a Chat Completions segue suportada, mas quem vai construir agente já começa do lado certo

Próximo passo concreto: escolhe um endpoint pequeno do seu projeto, migra ele pra /v1/responses, valida se o function calling volta com o call_id certo e observa o que acontece com o input cacheado na fatura

Deu certo nesse, aí sim você move o resto

Até o próximo post! =)