For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegação principal

Lista de verificação de implantação da API

Guia objetivo com escolhas de design valiosas e frequentemente subutilizadas que podem fazer uma diferença real na qualidade, velocidade, custo e confiabilidade da implantação.

ConteúdoImpacto esperado
Use a API ResponsesQualidade, custo, latência, confiabilidade
Escolha um modelo GPT-5.6Qualidade, custo, latência
Configure reasoning.effortQualidade, custo, latência
Configure text.verbosityQualidade, custo, latência
Configure o parâmetro phase do assistenteQualidade, custo
Use tool_searchCusto, latência
Use a chamada programática de ferramentasQualidade, custo, latência
Use múltiplos agentes para trabalhar em paraleloQualidade, custo, latência
Aproveite as ferramentas integradasQualidade
Aproveite a compactaçãoCusto
Otimize o cache de promptsLatência, custo
Use reasoning.encrypted_contentQualidade, latência
Escolha o nível de detalhe das imagens com critérioQualidade, custo, latência
Envie um identificador de segurançaSegurança, confiabilidade
Use background=TrueRetomada do trabalho
Use o modo WebSocketLatência

Use a API Responses

Comece sempre pela API Responses. Ela é a principal API da OpenAI e o melhor lugar para acessar os comportamentos mais recentes dos modelos, ferramentas integradas, fluxos de trabalho com estado e recursos de agentes.

Escolha um modelo GPT-5.6

Escolha um modelo GPT-5.6 adequado à carga de trabalho em vez de encaminhar todas as solicitações ao nível mais capaz. Use gpt-5.6 ou gpt-5.6-sol para obter a capacidade dos modelos principais, gpt-5.6-terra para um ótimo desempenho a um preço menor e gpt-5.6-luna para processar cargas de trabalho de alto volume com eficiência.

Ao migrar, preserve o papel do modelo atual na carga de trabalho e o esforço de raciocínio efetivo na primeira comparação. Execute avaliações representativas antes de alterar prompts ou adicionar novas capacidades. Compare o sucesso nas tarefas, a latência, os tokens de entrada, saída, raciocínio e gravação em cache e o custo por tarefa concluída com sucesso.

Configure reasoning.effort

Use reasoning.effort para definir quanto o modelo deve raciocinar antes de responder.

Para os modelos GPT-5.6, os valores aceitos são none, low, medium, high, xhigh e max. O padrão é medium. Um esforço menor é mais rápido e usa menos tokens de raciocínio. Um esforço maior dá ao modelo mais tempo para planejamento, depuração, síntese e ponderação de vantagens e desvantagens em várias etapas.

Use low quando a tarefa envolver principalmente extração, roteamento, classificação ou uma reescrita rotineira. Use medium ou high quando o modelo precisar diagnosticar um problema, comparar opções, elaborar um plano ou raciocinar sobre código. Use xhigh ou max somente quando avaliações representativas mostrarem que o ganho de qualidade justifica a latência e o custo adicionais. Ao migrar do GPT-5.5 ou GPT-5.4, comece com o esforço atual e compare essa configuração com um nível abaixo. O GPT-5.6 muitas vezes consegue manter ou melhorar a qualidade com menos tokens de raciocínio, então a configuração de menor esforço também pode reduzir a latência e o custo.

Para as cargas de trabalho mais difíceis que priorizam a qualidade, compare também reasoning.mode: "pro" com o modo padrão no mesmo nível de esforço. O modo e o esforço de raciocínio são independentes. O modo Pro pode melhorar a confiabilidade ao fazer o modelo trabalhar mais antes de retornar uma única resposta final, mas aumenta a latência e o uso de tokens.

Ajuste o esforço de raciocínio à tarefa
from openai import OpenAI

client = OpenAI()

prompt = """
Our CI job started failing after a dependency bump.

Error:
TypeError: Timeout.__init__() got an unexpected keyword argument 'connect'

Identify the likeliest root cause and the smallest safe fix.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "xhigh", "mode": "pro"},
    input=prompt,
)

print(response.output_text)

Configure text.verbosity

text.verbosity é o principal controle para equilibrar concisão e completude. Use um nível de detalhamento menor quando o produto precisar de uma resposta rápida e compacta, e um nível maior quando a resposta precisar de uma explicação mais detalhada, uma estrutura mais clara ou contexto completo. Menos detalhamento significa menos tokens de saída, então o modelo gera menos conteúdo e retorna a saída mais rápido.

Para programação, medium e high tendem a produzir saídas mais longas e organizadas, com uma estrutura mais clara. low mantém a resposta mais enxuta e restrita ao essencial.

O GPT-5.6 tende a ser mais conciso por padrão do que o GPT-5.5. Ao migrar, verifique se instruções genéricas como "Seja conciso" ainda ajudam. Em alguns casos, elas podem deixar as respostas breves demais. Mantenha essas instruções apenas quando ainda ajudarem e prefira usar text.verbosity para controlar o nível de detalhamento padrão; depois, use o prompt para especificar o conteúdo obrigatório, a estrutura e uma extensão mais específica, se aplicável.

Defina um nível de detalhamento menor para obter saídas compactas
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    text={"verbosity": "low"},
    input="""
    Summarize this incident for the next on-call engineer.
    - checkout latency spiked from 220 ms to 4.8 s
    - only us-east-1 was affected
    - rollback is complete
    - likely trigger: cache stampede after deploy
    """,
)

print(response.output_text)

Configure o parâmetro phase do assistente

phase é um rótulo nas mensagens do assistente no histórico da conversa. Ele indica ao modelo se uma mensagem anterior do assistente era um comentário intermediário sobre o trabalho em andamento ou a resposta final. Use phase: "commentary" para atualizações de progresso, observações antes de chamadas de ferramentas e outras mensagens intermediárias. Use phase: "final_answer" para a resposta concluída.

O assistente pode dizer algo como:

Mensagem de comentário do assistente
{
  "role": "assistant",
  "phase": "commentary",
  "content": "I'm checking the logs and comparing them to the last successful deploy."
}

Essa não é a resposta. É uma atualização de progresso. Mais tarde, o assistente pode dizer:

Mensagem de resposta final do assistente
{
  "role": "assistant",
  "phase": "final_answer",
  "content": "The deploy failed because the migration referenced a column that does not exist in production."
}

Isso é útil em fluxos de trabalho de longa duração ou com uso intensivo de ferramentas, nos quais o assistente pode gerar atualizações visíveis de progresso antes de terminar. Ao reenviar esse histórico em solicitações subsequentes para gpt-5.3-codex e modelos posteriores, preserve e reenvie phase nas mensagens do assistente para que o modelo possa distinguir as atualizações de progresso do resultado final. Isso ajuda a reduzir o encerramento prematuro, aumentando a probabilidade de o agente continuar até chegar à resposta final.

Em vez de carregar o catálogo completo de ferramentas em cada solicitação, use a pesquisa de ferramentas: adicione {"type": "tool_search"} e marque as definições de ferramentas de alto custo com defer_loading: true. Assim, o modelo pode carregar apenas o subconjunto necessário durante a execução. No início da solicitação, o modelo vê apenas o nome e a descrição da ferramenta de pesquisa. Se decidir que precisa de uma ferramenta com carregamento adiado, ele executa a pesquisa de ferramentas, e só então as definições dessas ferramentas são carregadas no contexto. Somente depois disso o modelo as chama. Isso economiza tokens e preserva o desempenho do cache.

A pesquisa de ferramentas tem dois modos:

  • A pesquisa de ferramentas hospedada é a opção mais simples. Use-a quando você já souber quais ferramentas podem estar disponíveis para a solicitação.
  • A pesquisa de ferramentas executada pelo cliente serve para casos em que seu aplicativo precisa decidir quais ferramentas estão disponíveis, por exemplo, com base no locatário, no projeto, nas permissões ou no registro interno do usuário.

Comece pela pesquisa de ferramentas hospedada , a menos que seu aplicativo realmente precise controlar a descoberta por conta própria.

Agrupe suas ferramentas pela intenção do usuário. Use espaços de nomes ou servidores MCP sempre que possível. É mais fácil para o modelo escolher entre alguns grupos bem definidos do que entre as funções de uma longa lista sem agrupamento. Recomendamos manter cada espaço de nomes com menos de cerca de 10 funções para otimizar a eficiência no uso de tokens e o desempenho do modelo.

Mantenha as descrições dos espaços de nomes curtas e deixe claras as diferenças entre eles. Coloque as instruções detalhadas nas definições das ferramentas com carregamento adiado. Evite criar um único espaço de nomes enorme para tudo.

Use a pesquisa de ferramentas hospedada com ferramentas de carregamento adiado
from openai import OpenAI

client = OpenAI()

billing_namespace = {
    "type": "namespace",
    "name": "billing",
    "description": "Billing tools for invoices, payments, taxes, and credits.",
    "tools": [
        {
            "type": "function",
            "name": "lookup_invoice",
            "description": "Look up invoice state, taxes, credits, and payment attempts.",
            "parameters": {
                "type": "object",
                "properties": {
                    "invoice_id": {"type": "string"},
                },
                "required": ["invoice_id"],
                "additionalProperties": False,
            },
            "strict": True,
            "defer_loading": True,
        }
    ],
}

crm_namespace = {
    "type": "namespace",
    "name": "crm",
    "description": "CRM tools for account ownership, plans, health, and payment history.",
    "tools": [
        {
            "type": "function",
            "name": "get_account",
            "description": "Fetch account owner, plan, health, and payment history.",
            "parameters": {
                "type": "object",
                "properties": {
                    "account_id": {"type": "string"},
                },
                "required": ["account_id"],
                "additionalProperties": False,
            },
            "strict": True,
            "defer_loading": True,
        }
    ],
}

response = client.responses.create(
    model="gpt-6-astra",
    input=(
        "Find the right billing tool and explain why invoice INV-1043 still "
        "shows overdue after a payment yesterday."
    ),
    tools=[billing_namespace, crm_namespace, {"type": "tool_search"}],
)

print(response.output)

Use a chamada programática de ferramentas

A chamada programática de ferramentas permite que o GPT-5.6 escreva JavaScript que chama ferramentas elegíveis e reduz seus resultados intermediários em um ambiente de execução hospedado. Use-a em etapas de escopo delimitado nas quais o código possa filtrar, cruzar, classificar, remover duplicatas, combinar ou verificar resultados volumosos de ferramentas antes de retornar um resultado estruturado menor ao modelo.

Adicione a ferramenta programmatic_tool_calling e habilite cada ferramenta elegível. Use allowed_callers: ["programmatic"] para ferramentas que só podem ser chamadas por programas, ou use allowed_callers: ["direct", "programmatic"] quando o modelo também puder chamar a ferramenta diretamente. Mantenha as chamadas diretas quando cada resultado puder mudar a próxima decisão do modelo, uma ação exigir aprovação ou a resposta final precisar preservar citações ou artefatos nativos. Documente os campos de retorno das ferramentas e o comportamento em caso de erro para que o modelo possa escrever um programa correto sem precisar inspecionar um resultado primeiro.

Seu ciclo de chamadas de ferramentas deve lidar com itens program e program_output, assim como itens function_call emitidos pelo programa e seus itens function_call_output. Preserve cada call_id e copie o caller da chamada de função para a saída dela, para que o serviço possa retomar o programa correto.

Teste tanto o program_output quanto a mensagem final do assistente. Um resultado correto do programa ainda pode levar a uma resposta final incompleta. Compare o sucesso da tarefa, as evidências exigidas, o total de tokens, a latência e o custo com os do mesmo fluxo de trabalho usando chamadas diretas de ferramentas.

Use múltiplos agentes para trabalhar em paralelo

O recurso de múltiplos agentes do GPT-5.6 permite que um agente principal delegue frentes de trabalho independentes a subagentes e sintetize seus resultados. Use-o quando puder dividir a pesquisa, a análise ou a implementação em tarefas concretas, de escopo delimitado, que usem contextos separados e sejam executadas em paralelo.

Defina multi_agent.enabled como true na solicitação. Para HTTP, use o SDK beta da API Responses com client.beta.responses e passe responses_multi_agent=v1 em betas. Para conexões HTTP diretas ou WebSocket, envie OpenAI-Beta: responses_multi_agent=v1. Os esquemas dos itens podem mudar enquanto o recurso de múltiplos agentes estiver em beta.

Prefira um único agente para tarefas curtas, sequências em que cada etapa depende da anterior ou trabalhos que gravam no mesmo recurso mutável. Subagentes podem aumentar o uso de tokens, então comece com o valor padrão de max_concurrent_subagents, que é 3, e meça a qualidade, a latência e o custo de ponta a ponta. Para fluxos de trabalho com múltiplos agentes de longa duração ou com uso intensivo de ferramentas, o modo WebSocket pode reduzir a sobrecarga de continuação.

Antes de habilitar múltiplos agentes, considere as limitações atuais do recurso: /responses/compact, reasoning.summary e max_tool_calls não têm suporte. O servidor compacta automaticamente o contexto do agente principal e o contexto de cada subagente.

Aproveite as ferramentas integradas

As ferramentas integradas são capacidades nativas da API. Em vez de criar cada ferramenta por conta própria, você pode dar ao modelo acesso a ferramentas que já funcionam dentro da API Responses. Assim, o modelo pode decidir quando usá-las.

A OpenAI continua adicionando ferramentas nativas, então comece pelas ferramentas integradas quando elas atenderem ao seu fluxo de trabalho. Crie ferramentas personalizadas quando as opções nativas não atenderem à tarefa. As ferramentas integradas e as opções de ferramentas relacionadas disponíveis atualmente incluem:

  • Pesquisa na Web: Pesquise na Web para obter informações atualizadas
  • Pesquisa de arquivos: Pesquise em arquivos enviados ou armazenamentos vetoriais
  • Code Interpreter: Execute Python para análises, cálculos, gráficos e processamento de arquivos
  • Shell: Execute comandos de shell em um contêiner hospedado ou no seu próprio ambiente de execução
  • Uso do computador: Opere uma interface por meio de capturas de tela, cliques, digitação e rolagem
  • Geração de imagens: Gere ou edite imagens
  • MCP/conectores: Conecte o modelo a serviços e ferramentas externos
  • Habilidades: Anexe pacotes reutilizáveis de instruções e arquivos de fluxo de trabalho
  • Aplicar patch: Faça edições estruturadas no código

A qualidade do modelo é outro motivo para preferir essas ferramentas. As ferramentas integradas fazem parte da distribuição usada no nosso pós-treinamento, ou seja, os modelos são treinados e avaliados com base nos formatos, comportamentos e saídas dessas ferramentas. Com ferramentas integradas, os modelos da OpenAI selecionam melhor as ferramentas, executam as chamadas de forma mais consistente e apresentam menos falhas do que com ferramentas novas.

Aproveite a compactação

A compactação é uma ferramenta de engenharia de contexto: ela decide quais informações o modelo mantém ao longo de vários turnos. Em agentes de longa duração, o problema não é apenas: "Vou atingir o limite de contexto?" Mensagens antigas, logs de ferramentas, novas tentativas e detalhes desatualizados também acabam tomando o espaço do estado de que o modelo precisa.

A compactação permite reduzir o tamanho do contexto de forma controlada, preservando o estado necessário para os turnos seguintes. Após um marco significativo, como concluir uma etapa de depuração ou delimitar uma causa raiz, você pode compactar a janela anterior e continuar a partir da saída compactada. Isso mantém o modelo focado, pois o próximo turno se baseia no estado importante, e não em cada raciocínio intermediário, comando que falhou e linha de raciocínio obsoleta.

Você pode usar a compactação de duas formas:

  • Deixe o servidor cuidar disso: se você usa previous_response_id, ative context_management com um compact_threshold. O servidor compactará automaticamente a conversa quando ela ficar grande demais. Você continua enviando apenas a mensagem mais recente do usuário.
  • Faça por conta própria: se você gerencia todo o array de entrada, chame client.responses.compact(). Essa chamada retorna uma janela de contexto menor. Use a saída retornada diretamente na próxima chamada de responses.create().

Não edite a saída compactada. Ela não é um resumo para leitura humana, mas o estado da máquina que ajuda o modelo a continuar. Passe-a adiante sem alterações e depois adicione a próxima mensagem do usuário.

Continue a partir do estado compactado da resposta
from openai import OpenAI

client = OpenAI()

# Full window collected from a long debugging session:
# user messages, assistant outputs, tool calls, and tool outputs.
long_window = session_items

compacted = client.responses.compact(
    model="gpt-6-astra",
    input=long_window,
)

next_response = client.responses.create(
    model="gpt-6-astra",
    store=False,
    input=[
        *compacted.output,  # Use compact output as-is.
        {
            "type": "message",
            "role": "user",
            "content": (
                "We found the bad cache invalidation path. Write the fix plan "
                "and the verification checklist."
            ),
        },
    ],
)

print(next_response.output_text)

Otimize o cache de prompts

O cache de prompts reduz automaticamente a latência e o custo quando as solicitações reutilizam o mesmo prefixo longo. Coloque instruções estáveis, exemplos e material de referência primeiro, seguidos pelo conteúdo dinâmico específico do usuário. Mantenha as definições e a ordem das ferramentas estáveis e acrescente novos turnos à conversa sem reescrever o contexto anterior.

O GPT-5.6 introduziu o cache explícito de prompts. O cache implícito continua sendo o padrão, mas os modelos GPT-5.6 e as famílias de modelos posteriores também oferecem suporte a pontos de corte explícitos de cache e a uma política de cache para toda a solicitação. Se um sufixo variável vier após um prefixo estável, adicione um prompt_cache_breakpoint explícito no limite do trecho reutilizável. Defina prompt_cache_options.mode como explicit somente quando a solicitação deva usar apenas os pontos de corte que você fornecer, sem nenhum ponto de corte implícito. Os modelos anteriores continuam usando apenas o cache automático de prompts.

Nos modelos GPT-5.6 e nas famílias de modelos posteriores, as gravações em cache custam 1,25× o preço dos tokens de entrada sem cache. Registre cached_tokens e cache_write_tokens e, depois, compare o volume de gravações com as leituras posteriores do cache para medir o custo líquido e ajustar a posição dos pontos de corte.

Use um valor estável de prompt_cache_key nas solicitações que compartilham um prefixo reutilizável para ajudar a direcionar solicitações relacionadas ao mesmo cache e otimizar as taxas de acerto de cache nos modelos anteriores ao GPT-5.6. Para grupos com tráfego intenso, siga as orientações para distribuir o tráfego entre mais chaves.

No GPT-5.6 e nos modelos posteriores, prompt_cache_key é opcional: você pode alcançar taxas ideais de acerto de cache sem essa chave. Você pode usá-la para manter a contabilização do cache separada por cliente, usuário ou workspace. Isso pode facilitar a explicação do uso de tokens em cache e da cobrança para cada grupo. Atribua uma chave distinta a cada cliente e mantenha-a estável nas solicitações relacionadas desse cliente. Chaves separadas também ajudam a impedir a sondagem de acertos de cache entre clientes. Consulte Separe a contabilização do cache com chaves.

Mantenha a contabilização do cache separada para um cliente
from openai import OpenAI

client = OpenAI()

instructions = """
You are the support agent for Acme.
Follow the Acme support policy and escalation rubric.
Use the same tone, safety rules, and tool plan for each ticket.
"""

response = client.responses.create(
    model="gpt-6-astra",
    prompt_cache_key="tenant-acme-support-agent",
    instructions=instructions,
    input="Summarize the current escalation for the on-call lead.",
)

print(response.output_text)

Use reasoning.encrypted_content

O GPT-5.6 pode preservar o raciocínio entre chamadas. Use reasoning.context: "all_turns" quando as metas, as premissas e as prioridades da tarefa permanecerem estáveis. Use current_turn quando o raciocínio anterior já não for relevante e puder prender o modelo a uma abordagem desatualizada. Se você omitir reasoning.context ou definir seu valor como auto, inspecione o campo reasoning.context da resposta para confirmar o modo efetivo.

O raciocínio persistido só funciona quando os itens de raciocínio anteriores estão disponíveis. Use previous_response_id para respostas armazenadas. Se seus requisitos de zero retenção de dados (ZDR) não permitirem armazenar dados de resposta, o conteúdo de raciocínio criptografado permite uma transferência sem estado.

Os itens de raciocínio na saída da resposta incluem conteúdo de raciocínio criptografado por padrão. Você pode acessar esse conteúdo pela propriedade encrypted_content de cada item de raciocínio. Seu aplicativo não precisa entender esse valor. Basta manter cada item de raciocínio exatamente como foi retornado e reenviá-lo no próximo turno, para que o modelo possa usá-lo para continuar o fluxo de trabalho.

Passe o raciocínio criptografado entre turnos sem estado
from openai import OpenAI

client = OpenAI()

history = [
    {
        "role": "user",
        "content": "Investigate why invoice INV-1043 has mismatched tax totals.",
    }
]

first = client.responses.create(
    model="gpt-6-astra",
    store=False,
    reasoning={"effort": "medium", "context": "current_turn"},
    input=history,
)

history.extend(item.model_dump(exclude={"status"}) for item in first.output)
history.append(
    {
        "role": "user",
        "content": "Now write the customer-facing explanation in plain English.",
    }
)

second = client.responses.create(
    model="gpt-6-astra",
    store=False,
    reasoning={"effort": "medium", "context": "all_turns"},
    input=history,
)

print(second.output_text)

Defina o nível de detalhe da imagem de forma intencional

Nos modelos GPT-5.6, omitir detail da imagem ou usar detail: "auto" resulta no mesmo comportamento de dimensionamento de original. O serviço preserva as dimensões de entrada, exceto quando a imagem ultrapassa 65.535 pixels em qualquer um dos lados; nesse caso, ela é reduzida para respeitar esse limite. A API rejeita imagens que ainda excedam o limite de 30.000 patches, em vez de redimensioná-las para atender a esse limite. Imagens grandes podem consumir mais tokens de entrada e, por isso, aumentar a latência.

Escolha detail de acordo com a tarefa. Redimensione a imagem, use low quando detalhes visuais finos não forem importantes ou use high para a compreensão padrão de imagens com alta fidelidade. Reserve original para tarefas com imagens grandes ou densas, sensíveis a coordenadas, de OCR, localização ou inspeção visual nas quais o detalhe adicional melhora a qualidade. Meça o consumo de tokens de imagem e a latência no pior caso antes da implantação.

Envie um identificador de segurança

Se seu aplicativo atende usuários finais individuais, envie um identificador safety_identifier estável e que preserve a privacidade em cada requisição. Ele ajuda a OpenAI a detectar uso indevido e oferece à sua equipe uma forma consistente de rastrear violações de políticas. Também reduz a chance de que o uso indevido por um usuário prejudique o acesso de toda a organização.

Gere um hash do nome de usuário ou do endereço de e-mail em vez de enviar informações que identifiquem a pessoa. Para experiências sem login, use um ID de sessão estável.

Use background=True

Use background=True para requisições que possam levar muito tempo. Em vez de manter a conexão do cliente aberta, a API inicia uma tarefa e retorna um ID. Seu aplicativo pode consultar periodicamente essa tarefa até que ela termine, falhe ou seja cancelada. Use esse recurso para análises extensas, execuções demoradas de ferramentas ou trabalhos que precisem de acompanhamento de status e novas tentativas.

Execute uma resposta em segundo plano e consulte seu status periodicamente
# Replace the illustrative IDs and URLs below with your own resource values.
from openai import OpenAI
import time

client = OpenAI()
log_bundle_file_id = "file_123"

job = client.responses.create(
    model="gpt-6-astra",
    background=True,
    store=False,
    input="Analyze this large log bundle and cluster the primary failure modes.",
    tools=[
        {
            "type": "code_interpreter",
            "container": {
                "type": "auto",
                "file_ids": [log_bundle_file_id],
            },
        }
    ],
)

while job.status in {"queued", "in_progress"}:
    time.sleep(2)
    job = client.responses.retrieve(job.id)

print(job.output_text)

Você pode combinar esse recurso com stream=True para receber eventos de progresso, mas o primeiro evento pode demorar mais do que em uma requisição normal.

Do ponto de vista da interface, o modo em segundo plano indica: "Está em execução; este é o status; o resultado aparecerá aqui quando estiver pronto."

Use o modo WebSocket

O modo WebSocket foi desenvolvido para fluxos de trabalho de longa duração com muitas chamadas de ferramentas, nos quais você mantém uma conexão persistente aberta e continua enviando apenas novos itens de entrada junto com previous_response_id. Para execuções com 20 ou mais chamadas de ferramentas, essa abordagem é cerca de 40% mais rápida de ponta a ponta.

Como funciona: a primeira mensagem será semelhante a uma requisição normal à API Responses: modelo, instruções, ferramentas e entrada do usuário. O servidor retorna eventos por streaming. Se o modelo solicitar uma ferramenta, seu aplicativo a executa. Em seguida, em vez de enviar uma nova requisição HTTP, você envia outro evento response.create pelo mesmo socket com o previous_response_id anterior e o novo item. É daí que vem a redução de latência. No HTTP convencional, cada continuação é uma nova requisição. No modo WebSocket, a conexão permanece aberta, e o estado da resposta mais recente fica pronto para reutilização na memória dessa conexão. Quando o próximo turno continua a partir dessa resposta, o backend precisa fazer menos trabalho de preparação.

Se seu fluxo de trabalho consiste em uma requisição e uma resposta, continue usando HTTP. Se seu fluxo de trabalho se comporta como um agente de longa duração, experimente o modo WebSocket.

Uma única conexão WebSocket processa uma resposta em andamento por vez, portanto o trabalho em paralelo exige várias conexões. Atualmente, as conexões têm duração máxima de 60 minutos. A continuação usa a mesma semântica de previous_response_id do modo HTTP, com um cache local da conexão para a resposta mais recente.

Observação: o modo WebSocket funciona com ZDR porque seus dados não são armazenados em disco, apenas na memória.

O exemplo em Python usa pip install "openai[realtime]>=3.8.0". O exemplo em JavaScript usa npm install openai@^7.10.0 ws. O exemplo em Ruby usa gem install openai async-websocket.

Inicie uma sessão WebSocket da API Responses
from openai import OpenAI

client = OpenAI()

with client.responses.connect() as connection:
    # Use the same typed parameters as client.responses.create(...).
    connection.response.create(
        model="gpt-6-astra",
        store=False,
        input=[
            {
                "type": "message",
                "role": "user",
                "content": [
                    {
                        "type": "input_text",
                        "text": (
                            "Find the flaky test in this run, call the tools "
                            "you need, and keep going until you can explain "
                            "the root cause."
                        ),
                    }
                ],
            }
        ],
        tools=[test_log_tool, code_search_tool],
    )
    first_event = connection.recv()
    print(first_event.type)

Conclusão

A API Responses é a base para criar aplicativos mais inteligentes e capazes com a OpenAI. A principal vantagem é permitir que desenvolvedores passem de prompts isolados para fluxos de trabalho duradouros, que usam ferramentas, levam o contexto em conta e se adaptam à complexidade da tarefa. Siga este guia para obter melhor desempenho em implantações reais.