Nota do autor: se o seu agente ainda usa client.chat.completions.create com tools, ao migrar para o GPT-6.1 você vai esbarrar numa bifurcação bem específica: o texto continua funcionando, mas a chamada de ferramentas exige trocar de endpoint.
Por que a chamada de ferramentas fica travada no endpoint ao migrar para o GPT-6.1
Primeiro, a conclusão: GPT-6 Astra, GPT-6.1 Sol e GPT-6.1 Terra suportam Chat Completions, mas a chamada de ferramentas precisa passar pela Responses API. Ou seja, dentro do mesmo código, a conversa em texto puro pode continuar no Chat. Mas, assim que você precisar registrar funções, ler o retorno de uma ferramenta ou rodar um loop de ferramentas com várias rodadas, a requisição tem que ir para o endpoint Responses.
Isso não é um problema de compatibilidade que dá para contornar mexendo em parâmetros. Mudar a forma de escrever tools não resolve, e adicionar tool_choice também não: para esses três modelos, o Chat Completions simplesmente não oferece chamada de ferramentas. O que você precisa mudar é o próprio endpoint e toda a estrutura de requisição/resposta em volta dele. Se quiser comparar os dois endpoints com a sua própria chave, use a entrada unificada da APIYI (apiyi.com): aponte o base_url para https://api.apiyi.com/v1 e troque só o ID do modelo para alternar.
Outra pegadinha é o caso do GPT-6 Sol e do GPT-6 Luna. Esses dois conseguem fazer chamada de função no Chat Completions, mas só quando reasoning_effort é none. Em outras palavras, dá para chamar ferramentas pelo Chat, mas ao custo de desligar a intensidade de raciocínio. Se você precisa manter o raciocínio, também vai ter que voltar para a Responses. Esse detalhe costuma passar batido, e o resultado é um código que roda, mas entrega um resultado pior do que o esperado.
Valor central: ao terminar este artigo, você vai conseguir identificar a que categoria pertence a sua cadeia de chamada de ferramentas e migrar a requisição do endpoint Chat para o Responses sem derrubar a arquitetura inteira.
Pontos-chave da invocação de ferramentas no GPT-6.1
A tabela abaixo mostra a qual endpoint cada um dos três modelos (mais dois modelos antigos) pertence. Vale conferir primeiro onde o seu modelo se encaixa e só depois seguir para os passos de migração.
| Modelo | Chat Completions só texto | Chat Completions com ferramentas | Endpoint recomendado para ferramentas |
|---|---|---|---|
| gpt-6.1-sol | Suportado | Não suportado | Responses |
| gpt-6.1-terra | Suportado | Não suportado | Responses |
| gpt-6-astra | Suportado | Não suportado | Responses |
| gpt-6-sol | Suportado | Só quando reasoning_effort é none |
Responses (se for preciso manter o raciocínio) |
| gpt-6-luna | Suportado | Só quando reasoning_effort é none |
Responses (se for preciso manter o raciocínio) |
Divisão de tarefas entre os endpoints: Chat cuida do texto, Responses cuida das ferramentas
Resumindo a tabela numa frase: na família GPT-6, o Chat Completions virou um canal só de texto, e o canal de ferramentas foi separado e passou para o Responses. O impacto nos projetos antigos acontece em camadas. Serviços que só fazem perguntas e respostas, resumos ou classificação quase não precisam mudar nada. Já os serviços que trabalham com Agent, function calling ou orquestração de ferramentas em várias etapas precisam migrar.
Para quem já encapsulou o SDK numa camada própria, a notícia boa é que a migração é menor do que parece. O ID do modelo continua o mesmo, a autenticação também, e o base_url não muda. O que muda é a estrutura do corpo da requisição e a forma de devolver os resultados das ferramentas ao modelo. Ou seja, o trabalho de verdade não está em “trocar de modelo”, e sim em “trocar a forma de chamar”.
Como escolher entre os três modelos principais
O GPT-6.1 Sol e o GPT-6.1 Terra são a dupla principal desta geração, e a diferença entre eles está sobretudo no posicionamento e no custo. O GPT-6 Astra é o carro-chefe da geração anterior: ele continua suportando texto puro no Chat e invocação de ferramentas no Responses, o que o torna uma boa opção para projetos que já estão estáveis e que você não quer mexer muito. Na hora de escolher, olhe primeiro a frequência de chamadas de ferramentas, depois o tamanho do contexto de cada requisição e, por último, o preço unitário. Isso porque a invocação de ferramentas costuma envolver várias idas e vindas, o que multiplica o consumo de tokens.
Para os valores exatos, consulte a tabela de preços mais adiante ou confira direto na documentação do APIYI (apiyi.com) qual critério de cobrança está valendo hoje, para não montar orçamento com preço desatualizado.
O que mudar na invocação de ferramentas do GPT-6.1: 5 pontos
Esta é a seção mais prática do artigo. Se você ajustar os 5 pontos abaixo, um loop típico de invocação de ferramentas passa do endpoint Chat para o endpoint Responses.
| Nº | Ponto de mudança | Como é no Chat Completions | Como é no Responses |
|---|---|---|---|
| 1 | Método de chamada | client.chat.completions.create |
client.responses.create |
| 2 | Onde vai a entrada | array messages |
parâmetro input |
| 3 | Declaração das ferramentas | tools (mantido) |
tools (estrutura praticamente igual) |
| 4 | Devolução do resultado da ferramenta | mensagem com role: "tool" |
item do tipo function_call_output |
| 5 | Contexto multi-turno | montar o messages completo na mão |
encadear com previous_response_id |
Os pontos 1 e 2 são os mais fáceis de esquecer. Muita gente ajusta a estrutura de tools, acha que a migração terminou e só depois percebe que o método do SDK continua o mesmo, ou seja, as requisições ainda vão para chat.completions. Quem define o endpoint é o método: se você não troca o método, o endpoint não muda.
O ponto 4 é onde a migração mais costuma travar. No Chat, o resultado da execução da ferramenta volta para o messages como uma mensagem com role: "tool". No Responses, você precisa devolver, do jeito que vieram, os itens de chamada retornados pelo modelo e depois acrescentar um item function_call_output. Se faltar um item ou a ordem estiver errada por uma posição, o modelo pode disparar a mesma chamada de novo.
O ponto 5 é do tipo “dá para não mexer, mas vale a pena mexer”. O Responses aceita previous_response_id para continuar a partir do turno anterior, o que elimina o custo de reenviar todo o histórico de mensagens a cada requisição. Para Agents com muitos turnos de ferramentas, isso pesa mais no custo do que trocar de modelo.
🎯 Dica técnica: a forma mais tranquila de validar durante a migração é rodar os dois caminhos, o antigo e o novo, em paralelo com o mesmo lote de requisições, e comparar a taxa de acerto das ferramentas e a estrutura do retorno. Usando a interface unificada do APIYI (apiyi.com), você não precisa gerenciar chaves de várias plataformas: com uma única configuração já dá para comparar as respostas reais do Responses e do Chat.
GPT-6.1: início rápido com chamada de ferramentas
Um exemplo mínimo que chama uma ferramenta
Suponha que você tenha uma função-ferramenta para consultar o status de um pedido, chamada get_order_status, que recebe o número do pedido como parâmetro. Só dois pontos precisam mudar: o método de chamada e o retorno do resultado ao modelo.
- A inicialização do cliente continua igual: use a sua própria chave em
api_keye definabase_urlcomohttps://api.apiyi.com/v1. Assim, qualquer modelo compatível com a interface da OpenAI pode ser chamado diretamente. - No ID do modelo, use
gpt-6.1-sol(ougpt-6.1-terra,gpt-6-astra). Os três usam a Responses API para chamada de ferramentas. - Troque o antigo
client.chat.completions.create(...)porclient.responses.create(...), e o parâmetromessagesporinput. - Continue passando
toolscomo antes: a descrição da ferramenta e o schema dos parâmetros não precisam ser reescritos. - No
outputretornado, procure o item do tipofunction_call, extraia o nome da ferramenta e os argumentos, e execute localmente a sua função de consulta de pedidos. - Adicione o resultado da execução de volta como
function_call_outpute faça uma segunda requisição para obter a resposta final.
Desses 6 passos, os que realmente são “obrigatórios” são o 3 e o 6. Os passos 1 e 2 são configuração, e os passos 4 e 5 são só uma questão de ler as informações em outro lugar, em vez do jeito que você estava acostumado na época do Chat.
🚀 Início rápido: se você não quer montar um ambiente de testes por conta própria, pode pegar créditos de teste gratuitos no APIYI (apiyi.com) e rodar esse exemplo de consulta de pedidos uma vez antes de mexer no código de produção. É o caminho de menor risco.
Uma forma ainda mais prática é desacoplar primeiro a camada de ferramentas da camada do modelo: concentre as definições das ferramentas em um só lugar e encapsule o ponto de entrada da chamada em uma função que decide internamente: “texto puro vai para o Chat, com tools vai para a Responses”. Assim, a migração acontece só na camada de encapsulamento, e o código de negócio não precisa mudar nenhuma linha.
Preços e escolha de modelo do GPT-6.1 (12/11/2026)
A tabela abaixo segue os valores em vigor a partir de 12/11/2026, sempre em dólares por 1M de tokens.
| Modelo | Entrada | Saída | Leitura de cache | Endpoint recomendado |
|---|---|---|---|---|
| gpt-6.1-sol | $2 | $10 | $0.1 | responses |
| gpt-6.1-terra | $1 | $5 | $0.05 | responses |
| gpt-6-luna | $0.1 | $0.5 | $0.01 | chat (reasoning_effort como none) ou responses |
Dá para tirar uma conclusão bem prática dessa tabela: os preços de entrada e saída do GPT-6.1 Terra são exatamente metade dos do Sol. Em cenários com muitas rodadas de ferramentas e alta taxa de repetição de contexto, o Terra costuma ser a melhor opção padrão. Já o GPT-6 Luna custa uma ordem de grandeza a menos, então vale usá-lo para tarefas leves, como classificação e extração, deixando o Sol ou o Terra para a orquestração de ferramentas, que realmente exige raciocínio.
A coluna de leitura de cache merece uma olhada à parte. Chamadas de ferramentas geram naturalmente muitos prefixos repetidos (prompt de sistema, definições de ferramentas, histórico da conversa), e, quando essa parte acerta o cache, o preço unitário fica em cerca de um vigésimo do preço de entrada. Por isso, ao usar previous_response_id na Responses para carregar o contexto, você economiza não só tráfego, mas dinheiro de verdade.
💰 Dica de custo: se você precisa dividir o orçamento por projeto, chamar os modelos com uma chave única pelo APIYI (apiyi.com) permite concentrar o consumo de vários modelos em um só lugar. Junto com a cobrança por uso, fica mais fácil calcular o custo real das chamadas de ferramentas.
Perguntas frequentes (FAQ) sobre chamada de ferramentas no GPT-6.1
P1: O que é o GPT-6.1 e qual a relação dele com o GPT-6?
O GPT-6.1 é uma versão iterativa da série GPT-6 e hoje tem dois modelos: GPT-6.1 Sol e GPT-6.1 Terra. Já a série GPT-6 inclui GPT-6 Astra, GPT-6 Sol e GPT-6 Luna. Todos compartilham o mesmo canal de chamada de ferramentas da Responses API, e a diferença está principalmente no posicionamento de capacidade e no preço.
P2: Por que não consigo chamar ferramentas pela Chat Completions? Escrevi algum parâmetro errado?
Não é problema de parâmetro. No GPT-6 Astra, no GPT-6.1 Sol e no GPT-6.1 Terra, a Chat Completions oferece só texto puro, e a chamada de ferramentas fica restrita à Responses API. Mexer em `tools` ou em `tool_choice` não adianta: você precisa trocar o método do SDK de `chat.completions.create` para `responses.create`.
P3: O GPT-6 Sol e o GPT-6 Luna conseguem fazer chamada de função no Chat?
Conseguem, mas só quando `reasoning_effort` está definido como `none`. Se você precisa manter a intensidade de raciocínio, esses dois modelos também têm que passar pela Responses. Essa restrição é a mais fácil de passar batida na migração, porque ela não gera erro: só faz o resultado ficar diferente do esperado.
P4: Preciso mudar o ID do modelo ao migrar para a Responses?
Não. Os IDs continuam sendo `gpt-6.1-sol`, `gpt-6.1-terra` e `gpt-6-astra`, e o `base_url` e a forma de autenticação também não mudam. O que você realmente precisa alterar é o método de chamada, o formato de entrada e a estrutura usada para devolver o resultado da ferramenta.
P5: Como validar rapidamente se a chamada de ferramentas está funcionando depois da migração?
Recomendo um smoke test com uma ferramenta simples de consulta de pedidos. Primeiro, confirme que a requisição realmente chegou ao endpoint da Responses. Depois, verifique se o `output` retornado tem um item `function_call`. Por fim, confira se, depois de devolver o `function_call_output`, o modelo deu a resposta final. Se os três passos passarem, o fluxo está funcionando. Com uma chave API de teste do APIYI (apiyi.com), dá para fazer toda essa validação.
P6: Os serviços de texto puro também precisam migrar para a Responses?
Não precisam. A Chat Completions continua disponível para texto puro nos três modelos principais, então serviços que só fazem perguntas e respostas, resumos ou traduções podem ficar como estão. Só as requisições que envolvem `tools` precisam sair de lá, e é por isso que o impacto da mudança é dividido em camadas.
P7: Como controlar o custo de contexto em chamadas de ferramentas com várias rodadas?
Prefira usar `previous_response_id` para continuar a partir da rodada anterior, em vez de reenviar o histórico completo a cada vez. Assim, o prefixo repetido tem mais chance de acertar o cache, e o preço de leitura de cache é bem menor que o de entrada. Com o `gpt-6.1-sol`, por exemplo, a entrada custa US$ 2 e a leitura de cache, US$ 0,1, uma diferença bem expressiva.
P8: Existem armadilhas conhecidas na migração para a Responses?
Dois erros são os mais típicos. O primeiro é mudar só a estrutura de `tools` sem mudar o método de chamada, e a requisição continua caindo no endpoint de Chat. O segundo é devolver o resultado da ferramenta com o formato antigo `role: “tool”`, o que faz o modelo não receber a saída e disparar a mesma chamada de novo. Além disso, se a sua equipe mistura modelos como o GPT-6 Sol, que exigem `reasoning_effort` igual a `none`, o ideal é aplicar essa restrição de forma unificada na camada de encapsulamento. Assim você evita o cenário em que “a mesma ferramenta funciona em alguns modelos e em outros não”.
Principais pontos sobre chamada de ferramentas no GPT-6.1 (Key Takeaways)
- Os endpoints se separaram: no GPT-6.1 Sol, no Terra e no GPT-6 Astra, o texto vai pelo Chat, mas as ferramentas precisam passar pelo Responses.
- Uma exceção: o GPT-6 Sol e o GPT-6 Luna permitem chamada de funções no Chat, desde que
reasoning_effortsejanone. - Cinco mudanças: método de chamada, o conteúdo de
input, a declaração detools, o retorno viafunction_call_outpute o encadeamento comprevious_response_id. - O ID do modelo continua o mesmo: nem o
base_urlnem a chave API mudam, e a migração acontece só na camada de encapsulamento. - O custo depende do cache: o prefixo das chamadas de ferramenta se repete muito, e o preço de leitura do cache é cerca de um vigésimo do preço de entrada.
- Validação em três passos: confirme o endpoint, confirme que há um
function_callemoutpute confirme que você recebe a resposta final depois de devolver o resultado. - Por onde começar: use o crédito gratuito do APIYI (apiyi.com) para rodar primeiro uma pequena ferramenta de consulta de pedidos e só depois refatore o fluxo de produção.
Resumo
A mudança central se resume a uma frase: o GPT-6.1 tirou a chamada de ferramentas do Chat Completions e a levou para o Responses, enquanto a capacidade de texto puro continua onde estava. Disso saem três pontos que vale guardar:
- Classifique antes de migrar: serviços que só trabalham com texto não precisam mudar. Requisições com
toolsprecisam trocar de endpoint. - Mude o método, não só os parâmetros: o que realmente “liga a chave” do novo endpoint é o
client.responses.create. A estrutura detoolsé só um complemento. - O retorno dos resultados é onde mais se erra: o
function_call_outputsubstitui orole: "tool", e tanto a ordem quanto a completude precisam estar corretas.
Se o seu projeto já roda chamadas de ferramentas em produção, o ideal é escolher uma ferramenta mínima para um rollout gradual e só fazer a troca total depois de confirmar que o fluxo funciona. Para poupar o trabalho de gerenciar várias chaves e configurações de ambiente em diferentes plataformas, você pode usar a APIYI (apiyi.com) com uma única chave e comparar o retorno real do Responses com o do Chat. Basta apontar o base_url para https://api.apiyi.com/v1.
Referências
- Documentação oficial de modelos da OpenAI: explica as capacidades de endpoint das séries GPT-6 e GPT-6.1, incluindo a restrição de que a chamada de ferramentas precisa passar pelo Responses
- Link:
developers.openai.com/api/docs/guides/latest-model -
Descrição: fonte primária para saber se um modelo consegue fazer function calling no Chat Completions
-
Documentação de modelos e preços da APIYI: preços de entrada, saída e leitura de cache de cada modelo, além do endpoint recomendado
- Link:
docs.apiyi.com/models - Descrição: para conferir os critérios de cobrança em vigor desde 2026-11-12 e as recomendações de endpoint
Autor: equipe técnica da APIYI
Fale com a gente: entre em contato pela página inicial da APIYI (apiyi.com). Para mais detalhes sobre as interfaces, acesse a central de documentação em docs.apiyi.com
