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ícitaagentRuntimeou 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_KEYou de um perfil de autenticação por chave de APIopenai. - Configuração legada - as referências
codex/*eopenai-codex/*são corrigidas paraopenai/*, comagentRuntime.id: "codex"com escopo de modelo, poropenclaw doctor --fix.
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_KEYmostra 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_IDrestringe opcionalmente o histórico da Admin API a um único projeto.- O OpenClaw nunca envia
OPENAI_API_KEYnem um perfil de inferênciaopenaiàs APIs da organização; essas credenciais podem pertencer a endpoints personalizados, do Azure ou locais do agente.
Escolha rápida
Mapa de nomes
Runtime implícito do agente
Quando a políticaagentRuntime 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 exatosopenai/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:
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 dememory_search e embeddings de consulta:
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
- Chave de API (OpenAI Platform)
- Assinatura Codex
Ideal para: acesso direto à API e faturamento baseado no uso.Ou forneça a chave diretamente:O ID
1
Obtenha sua chave de API
Crie ou copie uma chave de API no painel da OpenAI Platform.
2
Execute a integração inicial
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
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.Autenticação nativa do app-server do Codex
O harness nativo do app-server do Codex usa referências de modeloopenai/* 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:
- Perfis de autenticação OpenAI ordenados para o agente, de preferência em
auth.order.openai. Executeopenclaw doctor --fixpara migrar IDs de perfil de autenticação legados do Codex e a ordem de autenticação. - 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.
- Somente para inicializações locais do app-server por stdio e apenas quando o app-server
não informar nenhuma conta:
CODEX_API_KEYe depoisOPENAI_API_KEY.
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 integradoopenai 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:
--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:
Geração de vídeos
O plugin integradoopenai 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 provedoropenai (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.
- Configuração
- CLI
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
Síntese de fala (TTS)
Síntese de fala (TTS)
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.Conversão de fala em texto
Conversão de fala em texto
O plugin 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.
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
Transcrição em tempo real
Transcrição em tempo real
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.Voz em tempo real
Voz em tempo real
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 provedoropenai 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.- 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 provedoropenai 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):
*.openai.azure.com*.services.ai.azure.com*.cognitiveservices.azure.com
- Envia o cabeçalho
api-keyem vez deAuthorization: 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
timeoutMspor chamada ainda substituem esse padrão.
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
DefinaAZURE_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:
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 provedoropenai 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:
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 debackground 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 deparams 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.
Transporte (WebSocket versus SSE)
Transporte (WebSocket versus SSE)
O OpenClaw usa WebSocket primeiro, com SSE como alternativa (Documentação relacionada da OpenAI:
"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
Modo rápido
Modo rápido
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
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.
Processamento prioritário (service_tier)
Processamento prioritário (service_tier)
A API da OpenAI disponibiliza processamento prioritário por meio de Valores compatíveis:
service_tier. Defina-o por
modelo no OpenClaw:auto, default, flex, priority.Compaction no lado do servidor (API Responses)
Compaction no lado do servidor (API Responses)
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 definasupportsStore: false) - Injeta
context_management: [{ type: "compaction", compact_threshold: ... }] - Valor padrão de
compact_threshold: 70% decontextWindow(ou80000quando indisponível)
- Ativar explicitamente
- Limite personalizado
- Desativar
Ú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.Modo GPT estritamente agêntico
Modo GPT estritamente agêntico
Para modelos da família GPT-5 do provedor Definir
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:"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_planpara 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
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.
Rotas nativas versus compatíveis com OpenAI
Rotas nativas versus compatíveis com OpenAI
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çononeda 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)
- Usam um comportamento de compatibilidade mais flexível
- Removem
storede Completions de payloadsopenai-completionsnão nativos - Aceitam JSON avançado de passagem direta
params.extra_body/params.extraBodypara proxies de Completions compatíveis com OpenAI - Aceitam
params.chat_template_kwargspara 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.