OpenAI
A OpenAI fornece APIs para desenvolvedores dos modelos GPT. O Codex oferece suporte a login com ChatGPT para acesso por assinatura ou login com chave de API para acesso baseado em uso. O Codex cloud exige login com ChatGPT. A OpenAI oferece suporte explícito ao uso de OAuth por assinatura em ferramentas/fluxos externos como o OpenClaw.Estilo de interação padrão
O OpenClaw adiciona por padrão uma pequena sobreposição de prompt específica da OpenAI para execuçõesopenai/* e openai-codex/*. A sobreposição mantém o assistente receptivo,
colaborativo, conciso e direto sem substituir o prompt base do sistema
do OpenClaw.
Chave de configuração:
plugins.entries.openai.config.personalityOverlay
Valores permitidos:
"friendly": padrão; ativa a sobreposição específica da OpenAI."off": desativa a sobreposição e usa apenas o prompt base do OpenClaw.
- Aplica-se a modelos
openai/*. - Aplica-se a modelos
openai-codex/*. - Não afeta outros providers.
Desativar a sobreposição de prompt da OpenAI
Se você preferir o prompt base do OpenClaw sem modificações, desative a sobreposição:Opção A: chave de API da OpenAI (OpenAI Platform)
Melhor para: acesso direto à API e cobrança baseada em uso. Obtenha sua chave de API no painel da OpenAI.Configuração da CLI
Trecho de configuração
gpt-5.4 e gpt-5.4-pro para uso direto
da API da OpenAI. O OpenClaw encaminha ambos pelo caminho openai/* Responses.
O OpenClaw intencionalmente suprime a linha desatualizada openai/gpt-5.3-codex-spark,
porque chamadas diretas à API da OpenAI a rejeitam em tráfego real.
O OpenClaw não expõe openai/gpt-5.3-codex-spark no caminho direto da API da OpenAI.
O pi-ai ainda inclui uma linha integrada para esse modelo, mas requisições reais à API da OpenAI
atualmente o rejeitam. No OpenClaw, o Spark é tratado como exclusivo do Codex.
Opção B: assinatura do OpenAI Code (Codex)
Melhor para: usar acesso por assinatura do ChatGPT/Codex em vez de uma chave de API. O Codex cloud exige login com ChatGPT, enquanto o Codex CLI oferece suporte a login com ChatGPT ou chave de API.Configuração da CLI (Codex OAuth)
Trecho de configuração (assinatura Codex)
gpt-5.4 como o modelo atual do Codex. O OpenClaw
mapeia isso para openai-codex/gpt-5.4 para uso de OAuth do ChatGPT/Codex.
Se o onboarding reutilizar um login existente do Codex CLI, essas credenciais continuarão
gerenciadas pelo Codex CLI. Ao expirar, o OpenClaw relê primeiro a fonte externa do Codex
e, quando o provider consegue atualizá-la, grava a credencial atualizada
de volta no armazenamento do Codex em vez de assumir a posse em uma cópia separada
somente do OpenClaw.
Se sua conta Codex tiver direito ao Codex Spark, o OpenClaw também oferece suporte a:
openai-codex/gpt-5.3-codex-spark
openai/gpt-5.3-codex-spark.
O OpenClaw também preserva openai-codex/gpt-5.3-codex-spark quando o pi-ai
o detecta. Trate-o como dependente de entitlement e experimental: o Codex Spark é
separado do /fast do GPT-5.4, e a disponibilidade depende da conta Codex / ChatGPT conectada.
Limite da janela de contexto do Codex
O OpenClaw trata os metadados do modelo Codex e o limite de contexto em runtime como valores separados. Paraopenai-codex/gpt-5.4:
contextWindownativo:1050000- limite
contextTokenspadrão em runtime:272000
models.providers.<provider>.models[].contextTokens:
contextWindow apenas quando estiver declarando ou substituindo metadados nativos do
modelo. Use contextTokens quando quiser limitar o orçamento de contexto em runtime.
Transporte padrão
O OpenClaw usapi-ai para streaming de modelos. Para openai/* e
openai-codex/*, o transporte padrão é "auto" (WebSocket primeiro, depois
fallback para SSE).
No modo "auto", o OpenClaw também tenta novamente uma falha inicial de WebSocket que possa ser repetida
antes de recorrer ao SSE. O modo "websocket" forçado ainda expõe erros de transporte
diretamente em vez de escondê-los atrás do fallback.
Após uma falha de conexão ou de início de turno do WebSocket no modo "auto", o OpenClaw marca
o caminho WebSocket dessa sessão como degradado por cerca de 60 segundos e envia
os turnos seguintes por SSE durante esse período de espera, em vez de alternar
repetidamente entre transportes.
Para endpoints nativos da família OpenAI (openai/*, openai-codex/* e Azure
OpenAI Responses), o OpenClaw também anexa estado estável de identidade de sessão e turno
às requisições para que tentativas, reconexões e fallback para SSE permaneçam alinhados à mesma
identidade de conversa. Nas rotas nativas da família OpenAI isso inclui cabeçalhos estáveis de identidade
de requisição de sessão/turno, além de metadados de transporte correspondentes.
O OpenClaw também normaliza contadores de uso da OpenAI entre variantes de transporte antes que eles
cheguem às superfícies de sessão/status. O tráfego nativo OpenAI/Codex Responses pode
reportar uso como input_tokens / output_tokens ou
prompt_tokens / completion_tokens; o OpenClaw trata ambos como os mesmos contadores de entrada
e saída para /status, /usage e logs de sessão. Quando o tráfego WebSocket nativo
omite total_tokens (ou reporta 0), o OpenClaw usa como fallback o total normalizado de entrada + saída
para que as exibições de sessão/status continuem preenchidas.
Você pode definir agents.defaults.models.<provider/model>.params.transport:
"sse": força SSE"websocket": força WebSocket"auto": tenta WebSocket e depois recorre ao SSE
openai/* (API Responses), o OpenClaw também ativa por padrão o aquecimento de WebSocket
(openaiWsWarmup: true) quando o transporte WebSocket é usado.
Documentação relacionada da OpenAI:
Aquecimento de WebSocket da OpenAI
A documentação da OpenAI descreve o aquecimento como opcional. O OpenClaw o ativa por padrão paraopenai/* para reduzir a latência do primeiro turno ao usar transporte WebSocket.
Desativar o aquecimento
Ativar o aquecimento explicitamente
Processamento prioritário da OpenAI e do Codex
A API da OpenAI expõe processamento prioritário por meio deservice_tier=priority. No
OpenClaw, defina agents.defaults.models["<provider>/<model>"].params.serviceTier
para repassar esse campo em endpoints nativos OpenAI/Codex Responses.
auto, default, flex e priority.
O OpenClaw encaminha params.serviceTier tanto para requisições diretas openai/* Responses
quanto para requisições openai-codex/* Codex Responses quando esses modelos apontam
para os endpoints nativos OpenAI/Codex.
Comportamento importante:
openai/*direto deve apontar paraapi.openai.comopenai-codex/*deve apontar parachatgpt.com/backend-api- se você rotear qualquer um dos providers por outra URL base ou proxy, o OpenClaw deixará
service_tierinalterado
Modo rápido da OpenAI
O OpenClaw expõe um alternador compartilhado de modo rápido para sessõesopenai/* e
openai-codex/*:
- Chat/UI:
/fast status|on|off - Configuração:
agents.defaults.models["<provider>/<model>"].params.fastMode
- chamadas diretas
openai/*Responses paraapi.openai.comenviamservice_tier = "priority" - chamadas
openai-codex/*Responses parachatgpt.com/backend-apitambém enviamservice_tier = "priority" - valores existentes de
service_tierno payload são preservados - o modo rápido não reescreve
reasoningnemtext.verbosity
Rotas nativas OpenAI versus rotas compatíveis com OpenAI
O OpenClaw trata endpoints diretos OpenAI, Codex e Azure OpenAI de forma diferente de proxies genéricos compatíveis com OpenAI em/v1:
- rotas nativas
openai/*,openai-codex/*e Azure OpenAI mantêmreasoning: { effort: "none" }intacto quando você desativa explicitamente o reasoning - rotas nativas da família OpenAI usam por padrão schemas de ferramenta em modo estrito
- cabeçalhos ocultos de atribuição do OpenClaw (
originator,versioneUser-Agent) são anexados apenas em hosts nativos OpenAI verificados (api.openai.com) e hosts nativos Codex (chatgpt.com/backend-api) - rotas nativas OpenAI/Codex mantêm modelagem de requisição exclusiva da OpenAI, como
service_tier,storedo Responses, payloads de compatibilidade de reasoning da OpenAI e dicas de cache de prompt - rotas compatíveis com OpenAI no estilo proxy mantêm o comportamento de compatibilidade mais flexível e não forçam schemas de ferramenta estritos, modelagem de requisição exclusiva nativa nem cabeçalhos ocultos de atribuição OpenAI/Codex
/v1 de terceiros.
Compactação no servidor do OpenAI Responses
Para modelos diretos OpenAI Responses (openai/* usando api: "openai-responses" com
baseUrl em api.openai.com), o OpenClaw agora ativa automaticamente
dicas de payload de compactação no servidor da OpenAI:
- Força
store: true(a menos que a compatibilidade do modelo definasupportsStore: false) - Injeta
context_management: [{ type: "compaction", compact_threshold: ... }]
compact_threshold é 70% do contextWindow do modelo (ou 80000
quando indisponível).
Ativar explicitamente a compactação no servidor
Use isso quando quiser forçar a injeção decontext_management em modelos
Responses compatíveis (por exemplo, Azure OpenAI Responses):
Ativar com um limite personalizado
Desativar a compactação no servidor
responsesServerCompaction controla apenas a injeção de context_management.
Modelos diretos OpenAI Responses ainda forçam store: true, a menos que a compatibilidade defina
supportsStore: false.
Observações
- Refs de modelo sempre usam
provider/model(consulte /concepts/models). - Detalhes de autenticação + regras de reutilização estão em /concepts/oauth.