Skip to main content
OpenClaw usa um único id de provedor, openai, tanto para autenticação direta por chave de API quanto para autenticação de assinatura do ChatGPT/Codex. openai/* é a rota de modelo canônica. Para turnos de agentes incorporados com a política de runtime não definida ou definida como auto, os dados da rota da OpenAI determinam se o OpenClaw pode selecionar implicitamente o runtime incluído do servidor de aplicativo Codex. O prefixo openai/*, por si só, não seleciona um runtime.
  • Modelos de agente - openai/* por meio do runtime selecionado pela configuração explícita agentRuntime ou pela política de rota implícita da OpenAI. Entre com a autenticação do Codex para usar uma assinatura do ChatGPT/Codex ou configure um perfil de autenticação por chave de API quando quiser cobrança baseada em chave.
  • APIs da OpenAI não relacionadas a agentes - acesso direto à OpenAI Platform, com cobrança por uso, por meio de OPENAI_API_KEY ou de um perfil de autenticação por chave de API openai.
  • Configuração legada - as referências codex/* e openai-codex/* são corrigidas para openai/*, com agentRuntime.id: "codex" com escopo de modelo, por openclaw doctor --fix.
A OpenAI oferece suporte explícito ao uso de OAuth de assinatura em ferramentas e fluxos de trabalho externos, como o OpenClaw.

Acompanhamento de uso e custos

O OpenClaw mantém separadas a cota da assinatura e a cobrança da API da Platform:
  • O OAuth do ChatGPT/Codex mostra o plano de assinatura, as janelas de cota e o saldo de créditos.
  • OPENAI_ADMIN_KEY mostra 30 dias de custos da organização e uso de conclusões informados pelo provedor na seção Uso da Control UI, incluindo gastos diários, totais de solicitações/tokens, principais modelos e categorias de custos.
  • OPENAI_PROJECT_ID restringe opcionalmente o histórico da Admin API a um único projeto.
  • O OpenClaw nunca envia OPENAI_API_KEY nem um perfil de inferência openai às APIs da organização; essas credenciais podem pertencer a endpoints personalizados, do Azure ou locais do agente.
Uma chave de administrador explícita tem precedência sobre o OAuth. O histórico informado pelo provedor não é mesclado ao custo estimado pelo OpenClaw com base nas sessões; ele pode incluir atividades da API de outros clientes e ajustes de cobrança feitos pelo provedor. A documentação do Painel de uso da API da OpenAI descreve os requisitos de proprietário da organização e de permissão explícita no Painel de uso para acessar dados de uso. Provedor, modelo, runtime e canal são camadas separadas. Se esses rótulos estiverem sendo confundidos, leia Runtimes de agentes antes de alterar a configuração.

Escolha rápida

Mapa de nomes

Runtime implícito do agente

Quando a política agentRuntime do provedor/modelo não está definida ou é auto, a política de rota pertencente ao provedor da OpenAI escolhe o runtime implícito com base no endpoint e no adaptador efetivos: Uma configuração explícita e não padrão de agentRuntime.id do provedor/modelo continua sendo autoritativa. Por exemplo, agentRuntime.id: "openclaw" mantém no OpenClaw uma rota que, de outro modo, seria elegível para o Codex, enquanto agentRuntime.id: "codex" exige o Codex e falha de forma fechada quando a rota efetiva não é declarada compatível com o Codex. A seleção do runtime não altera o tipo de credencial nem a cobrança: a autenticação por chave de API da Platform e a autenticação por assinatura do ChatGPT/Codex permanecem distintas. openclaw doctor --fix migra referências de modelo legadas codex/* e openai-codex/*, ids legados de perfis de autenticação do Codex e entradas legadas de ordem de autenticação do Codex para a rota canônica openai. As referências de modelo migradas recebem agentRuntime.id: "codex" com escopo de modelo; use auth.order.openai para novas configurações de ordem de autenticação.
Uma nova configuração da OpenAI aplica um modelo principal GPT-5.6 somente quando nenhum modelo principal está configurado. Adicionar ou atualizar a autenticação da OpenAI preserva uma seleção explícita existente, incluindo openai/gpt-5.5, a menos que você use explicitamente models auth login --set-default ou models set. Use um perfil de autenticação por chave de API somente quando quiser autenticação por chave de API para um modelo de agente.

Prévia limitada do GPT-5.6

O OpenClaw reconhece os ids de modelo exatos openai/gpt-5.6-sol, openai/gpt-5.6-terra e openai/gpt-5.6-luna. Os três oferecem raciocínio xhigh e max no catálogo atual. A OpenAI descreve o Sol como a categoria principal, o Terra como a categoria equilibrada e o Luna como a categoria rápida e de menor custo. Consulte o anúncio de lançamento do GPT-5.6 e o guia de acesso. Com autenticação direta por chave de API da OpenAI, o id openai/gpt-5.6 sem qualificador é um alias do Sol e o padrão para novas configurações. O catálogo nativo do Codex não aplica esse alias da API direta no lado do cliente; dependendo do acesso ao workspace, ele pode mostrar os ids exatos de Sol, Terra e Luna. Portanto, uma nova configuração de OAuth do ChatGPT/Codex usa openai/gpt-5.6-sol. Verifique a conta atual com:
O acesso da organização da API e do workspace do Codex pode ser diferente. Se o GPT-5.6 não estiver disponível, selecione explicitamente o GPT-5.5:
O OpenClaw exibe o erro de acesso do serviço upstream e não substitui silenciosamente uma seleção do GPT-5.6 pelo GPT-5.5.
Rotas HTTPS oficiais exatas e elegíveis podem selecionar o Plugin incluído do servidor de aplicativo Codex quando a política de runtime não está definida ou é auto; rotas de Completions definidas pelo autor, endpoints personalizados e substituições de transporte de solicitações permanecem no OpenClaw. Endpoints HTTP oficiais em texto simples são rejeitados. A configuração explícita do runtime do provedor/modelo continua sendo autoritativa. Execute openclaw doctor --fix para corrigir referências legadas e obsoletas do modelo Codex, referências codex-cli/* ou fixações antigas de sessões de runtime que não foram definidas por uma configuração explícita de runtime.

Cobertura de recursos do OpenClaw

A voz em tempo real da OpenAI passa pela API Realtime pública da OpenAI Platform e exige uma chave de API da Platform. Os tokens OAuth do Codex autenticam o backend ChatGPT Codex; eles não são intercambiáveis com chaves de API da Platform para os endpoints Realtime públicos.Se a autenticação por chave de API informar que não há faturamento, adicione créditos da Platform em platform.openai.com/account/billing para a organização associada às suas credenciais de tempo real ao usar autenticação por chave de API. A voz em tempo real aceita o perfil de autenticação por chave de API openai criado por openclaw onboard --auth-choice openai-api-key, uma chave de API da Platform definida por meio de talk.realtime.providers.openai.apiKey para a Conversa da Control UI, ou plugins.entries.voice-call.config.realtime.providers.openai.apiKey para Voice Call, ou a variável de ambiente OPENAI_API_KEY.

Embeddings de memória

O OpenClaw pode usar a OpenAI, ou um endpoint de embeddings compatível com a OpenAI, para indexação de memory_search e embeddings de consulta:
Para endpoints compatíveis com a OpenAI que exigem rótulos de embeddings assimétricos, defina queryInputType e documentInputType em memorySearch. O OpenClaw os encaminha como campos de solicitação input_type específicos do provedor: os embeddings de consulta usam queryInputType; os fragmentos de memória indexados e a indexação em lote usam documentInputType. Consulte a referência de configuração de memória para ver o exemplo completo.

Introdução

Ideal para: acesso direto à API e faturamento baseado no uso.
1

Obtenha sua chave de API

Crie ou copie uma chave de API no painel da OpenAI Platform.
2

Execute a integração inicial

Ou forneça a chave diretamente:
3

Verifique se o modelo está disponível

Resumo das rotas

Com o runtime não definido ou auto, somente uma rota HTTPS nativa oficial exata e qualificada pode selecionar implicitamente o harness do app-server Codex. Para autenticação por chave de API em um modelo de agente, crie um perfil de autenticação por chave de API openai e ordene-o com auth.order.openai; OPENAI_API_KEY permanece como fallback direto para superfícies não relacionadas a agentes da API da OpenAI. Execute openclaw doctor --fix para migrar entradas antigas da ordem de autenticação legada do Codex.

Exemplo de configuração

O ID gpt-5.6 básico da API direta é resolvido para o nível Sol. Se esta organização da API não disponibilizar o GPT-5.6, defina explicitamente o modelo primário como openai/gpt-5.5.Para experimentar o modelo Instant atual do ChatGPT por meio da API da OpenAI, defina o modelo como openai/chat-latest:
chat-latest é um alias variável. Em vez disso, uma nova configuração com chave de API da OpenAI usa openai/gpt-5.6, cujo ID básico da API direta é resolvido para Sol. Modelos primários explícitos existentes, incluindo openai/gpt-5.5, permanecem inalterados. O alias chat-latest aceita apenas a verbosidade de texto medium; o OpenClaw força qualquer outra verbosidade solicitada para medium nesse modelo.
O OpenClaw não disponibiliza gpt-5.3-codex-spark na rota direta com chave de API da OpenAI. Ele está disponível apenas por meio das entradas do catálogo da assinatura Codex quando sua conta conectada o disponibiliza.

Autenticação nativa do app-server do Codex

O harness nativo do app-server do Codex usa referências de modelo openai/* quando uma rota HTTPS oficial exata e qualificada o seleciona implicitamente ou quando agentRuntime.id: "codex" do provedor/modelo o seleciona explicitamente. Sua autenticação ainda é baseada em conta. O OpenClaw seleciona a autenticação nesta ordem:
  1. Perfis de autenticação OpenAI ordenados para o agente, de preferência em auth.order.openai. Execute openclaw doctor --fix para migrar IDs de perfil de autenticação legados do Codex e a ordem de autenticação.
  2. A conta existente do app-server, como um login local do ChatGPT na CLI do Codex. Para o diretório inicial isolado padrão do agente, o OpenClaw conecta essa conta nativa da CLI ao app-server por meio do RPC de login; ele não compartilha a configuração, os plugins nem o armazenamento de threads da CLI.
  3. Somente para inicializações locais do app-server por stdio e apenas quando o app-server não informar nenhuma conta: CODEX_API_KEY e depois OPENAI_API_KEY.
Um login local de assinatura do ChatGPT/Codex não é substituído apenas porque o processo do Gateway também tem OPENAI_API_KEY para modelos diretos da OpenAI ou embeddings. O fallback de chave de API do ambiente se aplica somente ao caminho local por stdio sem conta; ele nunca é enviado por conexões WebSocket do app-server. Quando um perfil do Codex baseado em assinatura é selecionado, o OpenClaw também mantém CODEX_API_KEY e OPENAI_API_KEY fora do processo filho do app-server por stdio e envia as credenciais selecionadas por meio do RPC de login do app-server. Quando esse perfil de assinatura é bloqueado por um limite de uso do Codex, o OpenClaw marca o perfil como bloqueado até o horário de redefinição anunciado pelo Codex e permite que a ordem de autenticação alterne para o próximo perfil openai:*, sem mudar o modelo selecionado nem sair do harness do Codex. Depois que o horário de redefinição passa, o perfil de assinatura volta a ser elegível.

Geração de imagens

O plugin integrado openai registra a geração de imagens por meio da ferramenta image_generate. Ele oferece geração de imagens tanto por chave de API da OpenAI quanto por OAuth do Codex usando a mesma referência de modelo openai/gpt-image-2.
Consulte Geração de imagens para conhecer os parâmetros compartilhados da ferramenta, a seleção de provedor e o comportamento de failover.
gpt-image-2 é o padrão para geração de texto para imagem e edição de imagens da OpenAI. gpt-image-1.5, gpt-image-1 e gpt-image-1-mini permanecem utilizáveis como substituições explícitas de modelo. Use openai/gpt-image-1.5 para saída PNG/WebP com fundo transparente; a API gpt-image-2 atual rejeita background: "transparent". Para uma solicitação de fundo transparente, chame image_generate com model: "openai/gpt-image-1.5", outputFormat: "png" ou "webp" e background: "transparent"; a opção mais antiga do provedor openai.background ainda é aceita. O OpenClaw também protege as rotas públicas da OpenAI e do OAuth do OpenAI Codex reescrevendo solicitações transparentes padrão de openai/gpt-image-2 como gpt-image-1.5; o Azure e endpoints personalizados compatíveis com a OpenAI mantêm os nomes de implantação/modelo configurados. A mesma configuração é exposta para execuções da CLI sem interface:
Use as mesmas flags --output-format e --background com openclaw infer image edit ao começar com um arquivo de entrada. --openai-background permanece disponível como um alias específico da OpenAI. Use --quality low|medium|high|auto para controlar a qualidade e o custo das imagens da OpenAI. Use --openai-moderation low|auto para passar a indicação de moderação da OpenAI a partir de image generate ou image edit. Para instalações com OAuth do ChatGPT/Codex, mantenha a mesma referência openai/gpt-image-2. Quando um perfil OAuth openai estiver configurado, o OpenClaw resolve esse token de acesso OAuth armazenado e envia solicitações de imagem por meio do backend Responses do Codex; ele não tenta primeiro OPENAI_API_KEY nem faz fallback silencioso para uma chave de API. Configure models.providers.openai explicitamente com uma chave de API, URL-base personalizada ou endpoint do Azure quando quiser usar a rota direta da API de imagens da OpenAI. Se esse endpoint de imagens personalizado estiver em um endereço confiável de LAN/privado, defina também browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true; o OpenClaw mantém endpoints de imagem privados/internos compatíveis com a OpenAI bloqueados, a menos que essa ativação explícita esteja presente. Gerar:
Gerar um PNG transparente:
Editar:

Geração de vídeos

O plugin integrado openai registra a geração de vídeos por meio da ferramenta video_generate. As solicitações de imagem para vídeo da OpenAI usam POST /v1/videos com uma imagem input_reference. Edições de um único vídeo usam POST /v1/videos/edits com o vídeo enviado no campo video.
Consulte Geração de vídeo para ver os parâmetros compartilhados da ferramenta, a seleção de provedor e o comportamento de failover.O provedor OpenAI declara supportsSize, mas não supportsAspectRatio nem supportsResolution. A camada compartilhada de normalização do OpenClaw converte uma aspectRatio solicitada na size da OpenAI correspondente mais próxima antes que a solicitação chegue ao provedor; portanto, solicitações de proporção de tela geralmente ainda funcionam. resolution não tem fallback de tamanho e é descartado, sendo apresentado ao chamador como Ignored unsupported overrides for openai/<model>: resolution=<value>.

Contribuição de prompt do GPT-5

O OpenClaw adiciona uma contribuição compartilhada de prompt do GPT-5 para modelos da família GPT-5 no provedor openai (incluindo referências legadas do Codex anteriores ao reparo que são normalizadas para openai/*). Outros provedores que também oferecem IDs de modelos da família GPT-5, como rotas do OpenRouter ou opencode, não recebem essa sobreposição; ela é condicionada ao ID de provedor openai, e não apenas ao ID do modelo. Modelos GPT-4.x mais antigos nunca a recebem. O harness nativo do app-server do Codex não recebe o contrato de comportamento de persona e disciplina de ferramentas nem a sobreposição de estilo de interação amigável por meio de instruções do desenvolvedor; o Codex nativo mantém os comportamentos de base, de modelo e de documentação do projeto controlados pelo Codex, e o OpenClaw desativa a personalidade integrada do Codex em threads nativas para que os arquivos de personalidade do workspace do agente permaneçam autoritativos. O OpenClaw fornece apenas contexto de runtime às threads nativas do Codex: entrega por canal, ferramentas dinâmicas do OpenClaw, delegação ACP, contexto do workspace e Skills do OpenClaw. O texto de orientação de Heartbeat dessa mesma contribuição é a única exceção: turnos de Heartbeat do Codex nativo o recebem, injetado como instruções de colaboração dedicadas, e não por meio do hook compartilhado de contribuição de prompt. A contribuição do GPT-5 adiciona um contrato de comportamento com tags para persistência de persona, segurança de execução, disciplina de ferramentas, formato de saída, verificações de conclusão e validação em prompts correspondentes montados pelo OpenClaw. O comportamento de resposta específico do canal e de mensagens silenciosas permanece no prompt de sistema compartilhado do OpenClaw e na política de entrega de saída. A camada de estilo de interação amigável é separada e configurável.
Os valores não diferenciam maiúsculas de minúsculas durante o runtime; portanto, "Off" e "off" desativam a camada de estilo amigável.
O plugins.entries.openai.config.personality legado ainda é lido como fallback de compatibilidade quando a configuração compartilhada agents.defaults.promptOverlays.gpt5.personality não está definida.

Voz e fala

O plugin openai incluído registra a síntese de fala para a superfície messages.tts.Modelos disponíveis: gpt-4o-mini-tts, tts-1, tts-1-hd. Vozes disponíveis: alloy, ash, ballad, cedar, coral, echo, fable, juniper, marin, onyx, nova, sage, shimmer, verse.extraBody é mesclado ao JSON da solicitação /audio/speech após os campos gerados pelo OpenClaw; portanto, use-o para endpoints compatíveis com a OpenAI que exigem chaves adicionais, como lang. Chaves de protótipo são ignoradas.
Defina OPENAI_TTS_BASE_URL para substituir a URL base do TTS sem afetar o endpoint da API de chat. Tanto o TTS quanto a voz Realtime da OpenAI são configurados por meio de uma chave de API da OpenAI Platform; instalações que usam somente OAuth ainda podem utilizar modelos de chat baseados no Codex, mas não a conversação ao vivo da OpenAI.
O plugin openai incluído registra a conversão de fala em texto em lote por meio da superfície de transcrição de compreensão de mídia do OpenClaw.
  • Modelo padrão: gpt-4o-transcribe
  • Endpoint: REST da OpenAI /v1/audio/transcriptions
  • Caminho de entrada: upload de arquivo de áudio multipart
  • Usado sempre que a transcrição de áudio de entrada lê tools.media.audio, incluindo segmentos de canais de voz do Discord e anexos de áudio dos canais
Para forçar o uso da OpenAI na transcrição de áudio de entrada:
As dicas de idioma e de prompt são encaminhadas à OpenAI quando fornecidas pela configuração compartilhada de mídia de áudio ou pela solicitação de transcrição por chamada.
O plugin openai incluído registra a transcrição em tempo real para o plugin Voice Call.
Usa uma conexão WebSocket com wss://api.openai.com/v1/realtime e áudio G.711 u-law (g711_ulaw / audio/pcmu). Para um perfil de chave de API openai, o Gateway gera um segredo efêmero do cliente de transcrição Realtime antes de abrir o WebSocket. Esse provedor de streaming destina-se ao caminho de transcrição em tempo real do Voice Call; atualmente, a voz do Discord grava segmentos curtos e usa o caminho de transcrição em lote tools.media.audio em vez disso.
O plugin openai incluído registra voz em tempo real para o plugin Voice Call.Vozes Realtime integradas disponíveis para gpt-realtime-2.1: alloy, ash, ballad, coral, echo, sage, shimmer, verse, marin, cedar. A OpenAI recomenda marin e cedar para obter a melhor qualidade Realtime. Esse é um conjunto distinto das vozes de conversão de texto em fala acima; uma voz exclusiva de TTS, como fable, nova ou onyx, não é válida para sessões Realtime. Defina explicitamente o modelo como gpt-realtime-2.1-mini quando preferir a variante Realtime 2.1 menor e de custo mais baixo.
GPT-Live (em breve). Os modelos full-duplex gpt-live-1 e gpt-live-1-mini da OpenAI substituíram o modo de voz do ChatGPT em julho de 2026; a API para desenvolvedores está sendo disponibilizada para organizações com acesso antecipado. O OpenClaw reconhece a família de modelos, mas ainda não a executa: as sessões GPT-Live usam somente WebRTC, controlam a própria alternância de turnos (sem VAD) e delegam o trabalho do agente por meio de um protocolo de eventos de transferência que os transportes em tempo real do OpenClaw ainda não implementam. A configuração de um modelo gpt-live-* falha de modo fechado, com orientações sobre a ponte WebSocket e as sessões Talk no navegador, em vez de conectar silenciosamente o áudio sem acesso ao agente. O acesso à API também é restrito por organização da OpenAI durante o acesso antecipado. Mantenha gpt-realtime-2.1 (o padrão) até que o suporte ao GPT-Live seja disponibilizado.
As pontes de backend em tempo real da OpenAI usam o formato de sessão WebSocket Realtime GA, que não aceita session.temperature. As implantações do Azure OpenAI continuam disponíveis por meio de azureEndpoint e azureDeployment e mantêm o formato de sessão compatível com a implantação (incluindo temperature). Compatível com chamadas bidirecionais de ferramentas e áudio G.711 u-law.
A voz em tempo real é selecionada quando a sessão é criada. A OpenAI permite que a maioria dos campos da sessão seja alterada posteriormente, mas a voz não pode ser alterada depois que o modelo tiver emitido áudio nessa sessão. Atualmente, o OpenClaw expõe os IDs das vozes integradas de tempo real como strings.
O Talk da Control UI usa sessões em tempo real da OpenAI no navegador com um segredo de cliente efêmero emitido pelo Gateway e uma troca direta de SDP do WebRTC pelo navegador com a API Realtime da OpenAI. O Gateway emite esse segredo de cliente com a credencial openai selecionada. Chaves configuradas, perfis de chave de API e OPENAI_API_KEY têm precedência; um perfil OAuth openai ou login externo do Codex é a alternativa. As pontes WebSocket em tempo real do relay do Gateway e do backend de Voice Call usam a mesma ordem de credenciais para endpoints nativos da OpenAI. A verificação ao vivo para mantenedores está disponível com OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts; as etapas da OpenAI verificam tanto a ponte WebSocket do backend quanto a troca de SDP do WebRTC pelo navegador sem registrar segredos. Passe --openai-only para executar essas duas etapas sem credenciais do Google.

Endpoints do Azure OpenAI

O provedor openai incluído pode direcionar a geração de imagens para um recurso do Azure OpenAI substituindo a URL base. No caminho de geração de imagens, o OpenClaw detecta nomes de host do Azure em models.providers.openai.baseUrl e muda automaticamente para o formato de solicitação do Azure.
A voz em tempo real usa um caminho de configuração separado (plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint) e não é afetada por models.providers.openai.baseUrl. Consulte o acordeão Voz em tempo real em Voz e fala para ver suas configurações do Azure.
Use o Azure OpenAI quando:
  • Você já tiver uma assinatura, cota ou contrato empresarial do Azure OpenAI
  • Você precisar dos controles de residência regional de dados ou conformidade fornecidos pelo Azure
  • Você quiser manter o tráfego dentro de uma locação existente do Azure

Configuração

Para gerar imagens no Azure por meio do provedor openai incluído, direcione models.providers.openai.baseUrl para seu recurso do Azure e defina apiKey como a chave do Azure OpenAI (não uma chave da OpenAI Platform):
O OpenClaw reconhece estes sufixos de host do Azure para a rota de geração de imagens do Azure:
  • *.openai.azure.com
  • *.services.ai.azure.com
  • *.cognitiveservices.azure.com
Para solicitações de geração de imagens em um host do Azure reconhecido, o OpenClaw:
  • Envia o cabeçalho api-key em vez de Authorization: Bearer
  • Usa caminhos específicos da implantação (/openai/deployments/{deployment}/...)
  • Acrescenta ?api-version=... a cada solicitação
  • Usa um tempo limite padrão de solicitação de 600s para chamadas de geração de imagens do Azure. Os valores de timeoutMs por chamada ainda substituem esse padrão.
Outras URLs base (OpenAI pública, proxies compatíveis com OpenAI) mantêm o formato padrão de solicitação de imagens da OpenAI.
O roteamento do Azure para o caminho de geração de imagens do provedor openai exige o OpenClaw 2026.4.22 ou posterior. Versões anteriores tratam qualquer openai.baseUrl personalizado como o endpoint público da OpenAI e falham com implantações de imagens do Azure.

Versão da API

Defina AZURE_OPENAI_API_VERSION para fixar uma versão específica de prévia ou GA do Azure para o caminho de geração de imagens do Azure:
O padrão é 2024-12-01-preview quando a variável não está definida.

Os nomes dos modelos são nomes de implantação

O Azure OpenAI associa modelos a implantações. Para solicitações de geração de imagens do Azure roteadas pelo provedor openai incluído, o campo model no OpenClaw deve ser o nome da implantação do Azure configurado no portal do Azure, não o ID público do modelo da OpenAI. Se você criar uma implantação chamada gpt-image-2-prod que disponibiliza gpt-image-2:
A mesma regra de nome de implantação se aplica a qualquer chamada de geração de imagens roteada pelo provedor openai incluído.

Disponibilidade regional

Atualmente, a geração de imagens do Azure está disponível apenas em um subconjunto de regiões (por exemplo, eastus2, swedencentral, polandcentral, westus3, uaenorth). Consulte a lista atual de regiões da Microsoft antes de criar uma implantação e confirme se o modelo específico é oferecido em sua região.

Diferenças de parâmetros

O Azure OpenAI e a OpenAI pública nem sempre aceitam os mesmos parâmetros de imagem. O Azure pode rejeitar opções permitidas pela OpenAI pública (por exemplo, determinados valores de background em gpt-image-2) ou disponibilizá-las apenas em versões específicas do modelo. Essas diferenças são provenientes do Azure e do modelo subjacente, não do OpenClaw. Se uma solicitação do Azure falhar com um erro de validação, consulte no portal do Azure o conjunto de parâmetros compatível com sua implantação e versão da API específicas.
O Azure OpenAI usa transporte nativo e comportamento de compatibilidade, mas não recebe os cabeçalhos ocultos de atribuição do OpenClaw — consulte o acordeão Rotas nativas versus compatíveis com OpenAI em Configuração avançada.Para tráfego de chat ou Responses no Azure (além da geração de imagens), use o fluxo de integração ou uma configuração dedicada do provedor Azure; openai.baseUrl por si só não adota o formato de API/autenticação do Azure. Existe um provedor azure-openai-responses/* separado; consulte o acordeão Compaction no lado do servidor abaixo.

Configuração avançada

Os exemplos de params por modelo abaixo definem o formato da solicitação do provedor incorporado do OpenClaw. Configurá-los constitui um comportamento de solicitação definido pelo autor, portanto, uma rota auto que seria elegível permanece no OpenClaw, em vez de selecionar implicitamente o Codex. O harness nativo do servidor de aplicativo Codex controla seu próprio transporte e suas configurações de solicitação; agentRuntime.id: "codex" explícito falha de forma fechada quando a rota efetiva não está declarada como compatível com Codex.
O OpenClaw usa WebSocket primeiro, com SSE como alternativa ("auto") para openai/*.No modo "auto", o OpenClaw:
  • Tenta novamente após uma falha inicial do WebSocket antes de recorrer ao SSE
  • Após uma falha, marca o WebSocket como degradado por 60 segundos e usa SSE durante o período de espera
  • Anexa cabeçalhos estáveis de identidade da sessão e do turno para novas tentativas e reconexões
  • Normaliza contadores de uso (input_tokens / prompt_tokens) entre variantes de transporte
Documentação relacionada da OpenAI:
O OpenClaw disponibiliza uma alternância compartilhada de modo rápido para openai/*:
  • Chat/UI: /fast status|auto|on|off
  • Configuração: agents.defaults.models["<provider>/<model>"].params.fastMode
Quando ativado, o OpenClaw mapeia o modo rápido para o processamento prioritário da OpenAI (service_tier = "priority"). Os valores existentes de service_tier são preservados, e o modo rápido não reescreve reasoning nem text.verbosity. fastMode: "auto" inicia novas chamadas de modelo no modo rápido até o limite automático e, depois, inicia chamadas posteriores de nova tentativa, alternativa, resultado de ferramenta ou continuação sem o modo rápido. O limite padrão é 60 segundos; defina params.fastAutoOnSeconds no modelo ativo para alterá-lo.
As substituições da sessão têm precedência sobre a configuração. Limpar a substituição da sessão na UI Sessions restaura a sessão ao padrão configurado.
A API da OpenAI disponibiliza processamento prioritário por meio de service_tier. Defina-o por modelo no OpenClaw:
Valores compatíveis: auto, default, flex, priority.
serviceTier é encaminhado apenas para endpoints nativos da OpenAI (api.openai.com) e endpoints nativos do Codex (chatgpt.com/backend-api). Se qualquer um dos provedores for roteado por um proxy, o OpenClaw mantém service_tier inalterado.
Para modelos Responses diretos da OpenAI (openai/* em api.openai.com), o wrapper de stream do OpenClaw do Plugin da OpenAI ativa automaticamente a Compaction no lado do servidor:
  • Força store: true (a menos que a compatibilidade do modelo defina supportsStore: false)
  • Injeta context_management: [{ type: "compaction", compact_threshold: ... }]
  • Valor padrão de compact_threshold: 70% de contextWindow (ou 80000 quando indisponível)
Isso se aplica ao caminho de runtime integrado do OpenClaw e aos hooks do provedor OpenAI usados por execuções incorporadas. O harness nativo do servidor de aplicativo Codex gerencia seu próprio contexto por meio do Codex e não é afetado por essa configuração.
Útil para endpoints compatíveis, como o Azure OpenAI Responses:
responsesServerCompaction controla apenas a injeção de context_management. Os modelos Responses diretos da OpenAI ainda forçam store: true, a menos que a compatibilidade defina supportsStore: false.
Para modelos da família GPT-5 do provedor openai executados pelo runtime incorporado do OpenClaw, o OpenClaw já usa por padrão um contrato de execução mais estrito chamado strict-agentic. Ele é ativado automaticamente sempre que o provedor resolvido é openai e o ID do modelo corresponde à família GPT-5, a menos que a configuração desative-o explicitamente:
Definir "strict-agentic" explicitamente não produz efeito em uma rota compatível (ele já é o padrão) e fica inerte em pares de provedor/modelo incompatíveis.Com strict-agentic ativo, o OpenClaw:
  • Ativa automaticamente update_plan para trabalhos substanciais
  • Tenta novamente turnos estruturalmente vazios ou somente com raciocínio com uma continuação de resposta visível
  • Usa eventos explícitos de plano do harness quando o harness selecionado os fornece
O OpenClaw não classifica o texto do assistente para decidir se um turno é um plano, uma atualização de progresso ou uma resposta final.
Esse contrato reside inteiramente no executor de agente incorporado do OpenClaw. Ele não se aplica ao harness nativo do app-server do Codex, que gerencia seu próprio comportamento de turnos e planos; a seleção do harness é mais importante do que a configuração do contrato de execução para execuções nativas do Codex.
O OpenClaw trata endpoints diretos da OpenAI, do Codex e do Azure OpenAI de forma diferente dos proxies /v1 genéricos compatíveis com OpenAI:Rotas nativas (openai/*, Azure OpenAI):
  • Mantêm reasoning: { effort: "none" } somente para modelos compatíveis com o esforço none da OpenAI
  • Omitem o raciocínio desativado para modelos ou proxies que rejeitam reasoning.effort: "none"
  • Usam por padrão o modo estrito nos esquemas de ferramentas
  • Anexam cabeçalhos ocultos de atribuição somente em hosts nativos verificados (o Azure OpenAI não recebe esses cabeçalhos, embora seja uma rota nativa)
  • Mantêm a formatação de solicitações exclusiva da OpenAI (service_tier, store, compatibilidade de raciocínio, dicas de cache de prompt)
Rotas proxy/compatíveis:
  • Usam um comportamento de compatibilidade mais flexível
  • Removem store de Completions de payloads openai-completions não nativos
  • Aceitam JSON avançado de passagem direta params.extra_body/params.extraBody para proxies de Completions compatíveis com OpenAI
  • Aceitam params.chat_template_kwargs para proxies de Completions compatíveis com OpenAI, como o vLLM
  • Não impõem esquemas estritos de ferramentas nem cabeçalhos exclusivos de rotas nativas

Relacionados

Seleção de modelos

Como escolher provedores, referências de modelos e comportamento de failover.

Geração de imagens

Parâmetros compartilhados da ferramenta de imagens e seleção de provedores.

Geração de vídeos

Parâmetros compartilhados da ferramenta de vídeos e seleção de provedores.

OAuth e autenticação

Detalhes de autenticação e regras de reutilização de credenciais.