Built-in tools ou função própria: o que delegar ao GPT-6 Sol na Responses API?

Fala aí, beleza? A OpenAI soltou o GPT-6 Sol e o GPT-6 Luna em 22 de setembro de 2026, e junto veio de novo aquela decisão de arquitetura que todo mundo que monta agente precisa tomar

Usar as ferramentas prontas que a Responses API já entrega, ou escrever suas próprias funções e manter o controle na sua mão?

O Sol é posicionado pela OpenAI como modelo de raciocínio para codificação complexa e fluxos agênticos, ou seja, ele foi feito pra trabalhar COM ferramenta, não pra só cuspir texto bonito

E isso muda o cálculo de quanto trabalho vale a pena você escrever e quanto vale a pena delegar…

O que o GPT-6 Sol traz para fluxos com ferramentas

Antes de decidir arquitetura, bora dimensionar o terreno

O preço de API do GPT-6 Sol em contexto curto é de US$ 2,00 por milhão de tokens de entrada e US$ 10,00 por milhão de tokens de saída

Em prompts longos (long context), sobe pra US$ 4,00 de entrada e US$ 15,00 de saída por milhão de tokens

Pra comparar: o GPT-5.6 Sol custava US$ 4,00 de entrada e US$ 20,00 de saída por milhão de tokens

A OpenAI fala em redução de 50% nos preços de API de Sol e Luna frente ao preço promocional da geração GPT-5.6, e é no contexto curto que essa conta fecha redondinha

No long context a história é outra: a entrada segue em US$ 4,00 e a saída cai de US$ 20,00 pra US$ 15,00, ou seja, o desconto existe mas é bem menor

Então olha SEMPRE em qual faixa de preço o teu prompt vai cair antes de comemorar 🙂

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

A janela é de 1.050.000 tokens de contexto, com até 128.000 tokens de saída, e o corte de conhecimento é 30 de abril de 2026

Por que isso importa aqui? Porque fluxo agêntico é máquina de queimar token

Cada chamada de ferramenta devolve resultado pro contexto, e o contexto volta pro modelo no turno seguinte

Então contexto gigante + preço menor = você pode deixar o modelo fazer mais rodadas de ferramenta antes de a conta doer

Outro parâmetro que entra na conta é o reasoning.effort, que aceita none, low, medium (padrão), high, xhigh e max

E tem um detalhe importante de API: a Responses API é o caminho indicado pra usar built-in tools e function calling com o Sol

O Chat Completions só suporta function calling com reasoning_effort definido como none

Ou seja, se tu quer raciocínio + ferramenta, é Responses API, ponto

No benchmark interno FrontierCode, que avalia se as mudanças feitas por agentes de código estão prontas pra merge, a OpenAI relata melhora substancial sobre o GPT-5.6 Sol e empate com o Claude Fable 5.1 xhigh a custo muito menor

E na avaliação interna de factualidade, cerca de metade dos erros do antecessor, se aproximando da confiabilidade do Astra a custo bem menor

Se tu tá na dúvida sobre onde cada modelo já está disponível, vale lembrar que no dia do lançamento Sol e Luna chegaram no ChatGPT Work e no Codex pra Plus, Pro, Business, Enterprise e Edu, o Luna no app desktop pra Free e Go, e ambos na API

Built-in tools x function calling: comparação lado a lado

A diferença fundamental é UMA: quem executa o código

Na built-in tool, quem roda é a OpenAI, do lado de lá

No function calling, o modelo só te passa os dados e QUEM executa a ação é o teu aplicativo

Repara numa coisa: os tokens usados pelas built-in tools são cobrados pelas tarifas por token do modelo escolhido

Não existe token mágico de graça

O resultado que a ferramenta devolve entra no contexto e você paga por ele igual paga por qualquer outro token de entrada

O catálogo de built-in tools do GPT-6 Sol e o que cada uma resolve

As ferramentas são habilitadas pelo parâmetro tools na requisição da Responses API, e cada uma tem sua própria configuração

O GPT-6 Sol suporta, via Responses API: web search, file search, image generation, code interpreter, hosted shell, apply patch, skills, computer use, MCP, tool search e function calling

Bora passar por grupo e ver o que faz sentido delegar

Informação atualizada: web search e file search

A ferramenta web search permite respostas com informação atualizada da internet e traz citações de fonte

Isso resolve direto o problema do corte de conhecimento em 30 de abril de 2026

Já a file search faz busca semântica E por palavra-chave em arquivos que você enviou antes

Se teu caso é RAG de documentação interna, pensa bem antes de sair montando pipeline de embedding do zero: aqui tem taxa por chamada, mas tu não mantém índice, não mantém reprocessamento, não mantém nada

Tome cuidado com um detalhe: a cobrança de chamada do file search vale apenas para a Responses API

Execução de código: code interpreter e hosted shell

O Code Interpreter roda código Python em ambiente isolado, um container, que é uma máquina virtual em sandbox podendo conter arquivos enviados ou gerados

É a ferramenta pra análise de dados, código e matemática

O hosted shell entra quando o trabalho é explorar um ambiente: listar diretório, ler arquivo, rodar grep

E aqui vai o alerta de custo: sessões de container (hosted shell e Code Interpreter) são cobradas por minuto, com mínimo de 5 minutos por sessão

Agente que abre container pra fazer uma continha de 3 segundos tá pagando 5 minutos. Pensa nisso antes de deixar solto 🙂

Edição de arquivo: apply patch

Essa é a mais direta de todas

Tu habilita declarando o tipo no array de tools:

{
  "tools": [
    { "type": "apply_patch" }
  ]
}

A saída traz objetos apply_patch_call com operações create, update ou delete por arquivo

Combinada com a ferramenta shell, a apply patch permite ao modelo explorar diretórios, ler arquivos e fazer grep antes de editar, ou seja, descoberta e edição de forma agêntica

Se você já escreveu seu próprio parser de diff na mão, sabe exatamente o tamanho da dor que isso economiza

Skills no hosted shell

Skills podem ser montadas no ambiente de hosted shell, anexadas via tools[].environment.skills na chamada da ferramenta shell

Uma skill é um diretório com manifesto SKILL.md

Ponto de atenção que já derruba gente: skills hospedadas seguem o ciclo de vida do container

Arquivos e skills montados ficam disponíveis enquanto o container está ativo e são DESCARTADOS quando ele expira ou é deletado

Então não trate container como disco permanente, beleza?

Quando a função própria é a escolha certa

Uma function é uma ferramenta definida por um JSON schema, e ela serve pro modelo passar dados ao seu aplicativo, que executa a ação

Leia de novo: o modelo não executa nada, ele preenche os argumentos e devolve

Isso é exatamente o que você quer quando a ação é:

• escrita no seu banco de dados
• regra de negócio (cálculo de frete, desconto, limite de crédito)
• integração com sistema interno que nunca vai ser exposto pra fora
• qualquer coisa que precise de log e auditoria linha a linha

Em nenhum desses casos faz sentido tentar aproximar com built-in tool

A OpenAI recomenda sempre habilitar o modo strict, que usa structured outputs e garante aderência ao schema da função

Com strict: true você precisa de additionalProperties: false em cada objeto de parameters

{
  "type": "function",
  "name": "cancelar_pedido",
  "description": "Cancela um pedido do cliente e registra o motivo",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "pedido_id": { "type": "string" },
      "motivo": { "type": "string" }
    },
    "required": ["pedido_id", "motivo"],
    "additionalProperties": false
  }
}

O erro comum aqui é esquecer o additionalProperties: false em um objeto aninhado e ficar tentando entender por que o strict reclama

Outro controle que vale ouro em ação destrutiva: o modelo pode chamar várias funções no mesmo turno, e isso dá pra desligar

Com parallel_tool_calls: false você garante zero ou uma chamada por turno

Num fluxo de cancelamento, estorno ou os rm -rf da vida, isso não é frescura, é guardrail

E quando o argumento não cabe em JSON?

Aí entram as custom tools, que aceitam texto livre na entrada e na saída, sem empacotar em JSON

Custom tools recebem payloads de texto bruto: script Python, SQL, arquivo de config

É MUITO mais limpo do que ficar escapando um script inteiro dentro de uma string de JSON

Detalhe importante: custom tools não suportam chamadas paralelas

O meio-termo: MCP, connectors, tool search e Programmatic Tool Calling

A decisão não é binária, e é aqui que a maioria das arquiteturas boas mora

Segundo o guia oficial Using tools, as formas de estender as capacidades do modelo são: built-in tools, function calling, Programmatic Tool Calling, tool search e servidores MCP remotos

MCP e connectors

Servidores MCP remotos conectam o modelo a serviços externos pela Responses API

Connectors são wrappers MCP mantidos pela própria OpenAI pra serviços populares, como Google Workspace e Dropbox

Por padrão a OpenAI pede aprovação antes de compartilhar dados com um conector ou servidor MCP remoto, e o require_approval aceita política única pra todas as ferramentas: always ou never

Outro parâmetro que economiza dinheiro de verdade é o allowed_tools, que restringe o que vem de mcp_list_tools, reduzindo tokens e latência

Servidor MCP com 40 ferramentas jogando descrição no contexto a cada turno é conta caindo sem você fazer nada 😛

Tool search

O tool search adia definições de ferramentas até o modelo precisar delas

Você adiciona tool_search no array tools e marca as funções a adiar com defer_loading: true

{
  "tools": [
    { "type": "tool_search" },
    {
      "type": "function",
      "name": "consultar_nota_fiscal",
      "defer_loading": true,
      "parameters": { "type": "object", "properties": {}, "additionalProperties": false }
    }
  ]
}

Existem duas estratégias: a hosted, em que a OpenAI busca entre as ferramentas adiadas e devolve o subconjunto na mesma resposta, e a client-executed, em que o modelo emite tool_search_call e sua aplicação responde com tool_search_output

A recomendação oficial de organização é agrupar as funções adiadas em namespaces ou servidores MCP com descrições claras, mantendo menos de 10 funções por namespace

E atenção no requisito: apenas modelos gpt-5.4 e posteriores suportam tool_search

Programmatic Tool Calling

Esse aqui é insano

O Programmatic Tool Calling permite ao modelo escrever e executar JavaScript que orquestra as próprias ferramentas

O programa pode chamar ferramentas em paralelo, usar loops e condições e guardar resultados intermediários no runtime hospedado

Cada programa roda em um runtime V8 isolado e novo

Na prática, em vez de 30 idas e voltas enchendo o contexto com resultado intermediário, o modelo escreve o loop UMA vez e só o resultado final volta pra conversa

Controlando o comportamento: tool_choice e nível de raciocínio

Declarar a ferramenta é metade do trabalho, a outra metade é dizer QUANDO ela pode ser usada

O tool_choice controla se e qual ferramenta o modelo chama:

• none: não chama ferramenta
• auto: o modelo escolhe
• required: obriga pelo menos uma chamada

Casa isso com o reasoning.effort (none, low, medium, high, xhigh, max) e tu tem duas alavancas de custo bem diretas

Esforço alto pensa mais, gera mais token de saída e a saída é a parte cara da conta (US$ 10,00 por milhão em contexto curto, contra US$ 2,00 na entrada)

E tem a alavanca mais óbvia de todas, que quase todo mundo esquece: trocar de modelo

O GPT-6 Luna custa US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de tokens de saída

Pra classificação, roteamento, extração simples e tarefa de alto volume, jogar tudo no Sol é desperdício

Essa lógica de medir custo por tarefa resolvida em vez de olhar só o preço da tabela vale igual aqui

Veredito: a régua para decidir em cada ferramenta

Em vez de decorar lista, usa três perguntas em ordem

1. Essa capacidade é genérica e chata de manter? Buscar na web com citação, rodar Python em sandbox, aplicar patch em arquivo, indexar documento pra busca semântica

Se é isso, delega pra built-in tool. Você não vai escrever nada melhor do que já está pronto, e o que você escrever vira manutenção eterna

2. A ação é do SEU domínio? Toca seu banco, sua regra de negócio, seu sistema interno, precisa de log auditável

Então é function calling, com strict: true e, em ação destrutiva, parallel_tool_calls: false

3. O número de ferramentas está crescendo? Aí é MCP (com allowed_tools apertado) ou tool search com defer_loading: true, senão o contexto vira um catálogo de descrição que você paga a cada turno

Agora o lado honesto da história

Built-in tool não é grátis e nem sempre é mais barata: além dos tokens na tarifa do modelo, tem taxa por chamada em ferramentas específicas como busca e computer use, e container cobrado por minuto com mínimo de 5 minutos por sessão

Se teu agente abre container o tempo todo pra tarefa curta, a conveniência sai cara

E tem o custo que não aparece em fatura: previsibilidade. Com função própria, você sabe exatamente o que rodou, quando e com qual argumento

Não existe resposta certa universal, existe régua aplicada ferramenta por ferramenta

Conclusão

A decisão de built-in tool x função própria no GPT-6 Sol não é ideológica, é econômica e de controle

Delega o genérico, escreve o que é teu, e quando a lista de ferramentas engordar, parte pra MCP ou tool search antes de o contexto virar um monstro

Próximo passo concreto: monta um array tools MÍNIMO na Responses API, só com o que a tarefa realmente exige, roda um lote de casos reais, mede o custo por tarefa (lembrando de contar os tokens que as ferramentas devolvem pro contexto) e só então expande

Começar com 12 ferramentas declaradas e ir cortando é muito mais doloroso que começar com 2 e ir somando, acredita

O modelo é novo, o preço caiu frente ao promocional da geração anterior (pela metade no contexto curto) e o catálogo de ferramentas tá completão

Dá pra fazer coisa muito massa com isso, só não sai clicando next, next e finish na arquitetura 😀

até o próximo post!