openai, sia per l’autenticazione diretta tramite chiave API sia per
l’autenticazione tramite abbonamento ChatGPT/Codex. openai/* è la route canonica del modello.
Per i turni dell’agente incorporato con il criterio di runtime non impostato o impostato su auto, i dati
della route di OpenAI determinano se OpenClaw può selezionare implicitamente il runtime app-server Codex incluso.
Il solo prefisso openai/* non seleziona un runtime.
- Modelli dell’agente -
openai/*tramite il runtime selezionato dalla configurazione esplicitaagentRuntimeo dal criterio implicito della route di OpenAI. Accedere con l’autenticazione Codex per utilizzare l’abbonamento ChatGPT/Codex oppure configurare un profilo di autenticazione tramite chiave API quando si desidera la fatturazione basata sulla chiave. - API OpenAI non destinate agli agenti - accesso diretto alla piattaforma OpenAI, con fatturazione in base all’uso,
tramite
OPENAI_API_KEYo un profilo di autenticazione tramite chiave APIopenai. - Configurazione legacy - i riferimenti
codex/*eopenai-codex/*vengono corretti inopenai/*piùagentRuntime.id: "codex"con ambito limitato al modello daopenclaw doctor --fix.
Monitoraggio dell’utilizzo e dei costi
OpenClaw mantiene distinti la quota dell’abbonamento e la fatturazione delle API della piattaforma:- OAuth ChatGPT/Codex mostra il piano di abbonamento, le finestre delle quote e il saldo dei crediti.
OPENAI_ADMIN_KEYmostra 30 giorni di costi dell’organizzazione e utilizzo dei completamenti segnalati dal provider nella sezione Utilizzo dell’interfaccia di controllo, inclusi spesa giornaliera, totali di richieste/token, modelli principali e categorie di costo.OPENAI_PROJECT_IDlimita facoltativamente la cronologia dell’API di amministrazione a un singolo progetto.- OpenClaw non invia mai
OPENAI_API_KEYo un profilo di inferenzaopenaialle API dell’organizzazione; tali credenziali possono appartenere a endpoint personalizzati, Azure o locali dell’agente.
Scelta rapida
Mappa dei nomi
Runtime implicito dell’agente
Quando il criterioagentRuntime del provider/modello non è impostato o è impostato su auto, il criterio
della route appartenente al provider OpenAI sceglie il runtime implicito in base
all’endpoint e all’adattatore effettivi:
Un valore
agentRuntime.id esplicito e non predefinito del provider/modello rimane determinante.
Ad esempio, agentRuntime.id: "openclaw" mantiene su OpenClaw una route che altrimenti
sarebbe idonea per Codex, mentre agentRuntime.id: "codex" richiede Codex e genera un errore
in modalità fail-closed quando la route effettiva non è dichiarata compatibile con Codex.
La selezione del runtime non modifica il tipo di credenziale o la fatturazione: l’autenticazione
tramite chiave API della piattaforma e l’autenticazione tramite abbonamento ChatGPT/Codex rimangono distinte.
openclaw doctor --fix migra i riferimenti legacy ai modelli codex/* e openai-codex/*,
gli id legacy dei profili di autenticazione Codex e le voci legacy dell’ordine di autenticazione Codex
alla route canonica openai. I riferimenti ai modelli migrati ricevono
agentRuntime.id: "codex" con ambito limitato al modello; utilizzare auth.order.openai per la nuova configurazione dell’ordine di autenticazione.
Una nuova configurazione OpenAI applica un modello primario GPT-5.6 solo quando non è
configurato alcun modello primario. L’aggiunta o l’aggiornamento dell’autenticazione OpenAI mantiene una selezione
esplicita esistente, incluso
openai/gpt-5.5, a meno che non si utilizzi esplicitamente
models auth login --set-default o models set. Utilizzare un profilo di autenticazione tramite chiave API
solo quando si desidera l’autenticazione tramite chiave API per un modello dell’agente.Anteprima limitata di GPT-5.6
OpenClaw riconosce gli id modello esattiopenai/gpt-5.6-sol,
openai/gpt-5.6-terra e openai/gpt-5.6-luna. Tutti e tre espongono i livelli di ragionamento
xhigh e max nel catalogo attuale. OpenAI descrive Sol come
il livello di punta, Terra come il livello bilanciato e Luna come il livello rapido
e meno costoso. Consultare
l’annuncio del lancio di GPT-5.6
e la guida all’accesso.
Con l’autenticazione OpenAI diretta tramite chiave API, l’id openai/gpt-5.6 senza qualificatori è un alias di
Sol ed è l’impostazione predefinita per le nuove configurazioni. Il catalogo Codex nativo non applica
lato client tale alias dell’API diretta; a seconda dell’accesso all’area di lavoro, può mostrare
gli id esatti di Sol, Terra e Luna. Di conseguenza, una nuova configurazione OAuth ChatGPT/Codex
utilizza openai/gpt-5.6-sol. Controllare l’account corrente con:
Le route HTTPS ufficiali esatte idonee possono selezionare il Plugin app-server
Codex incluso quando il criterio di runtime non è impostato o è impostato su
auto; le route Completions definite,
gli endpoint personalizzati e le sostituzioni del trasporto delle richieste rimangono su OpenClaw. Gli endpoint
HTTP ufficiali non crittografati vengono rifiutati. La configurazione esplicita del runtime del provider/modello rimane
determinante. Eseguire openclaw doctor --fix per correggere i riferimenti legacy obsoleti ai modelli Codex,
i riferimenti codex-cli/* o i vecchi vincoli delle sessioni di runtime non impostati da una
configurazione esplicita del runtime.Copertura delle funzionalità di OpenClaw
La voce in tempo reale di OpenAI passa attraverso l’OpenAI Platform Realtime
API pubblica e richiede una chiave API Platform. I token OAuth Codex autenticano
invece il backend ChatGPT Codex; non sono intercambiabili con le chiavi API
Platform per gli endpoint Realtime pubblici.Se l’autenticazione tramite chiave API segnala l’assenza di fatturazione, ricaricare i crediti Platform su
platform.openai.com/account/billing
per l’organizzazione associata alle credenziali in tempo reale quando si utilizza
l’autenticazione tramite chiave API. La voce in tempo reale accetta il profilo di autenticazione con chiave API
openai creato da
openclaw onboard --auth-choice openai-api-key, una chiave API Platform impostata tramite
talk.realtime.providers.openai.apiKey per Control UI Talk, oppure
plugins.entries.voice-call.config.realtime.providers.openai.apiKey per Voice
Call, oppure la variabile di ambiente OPENAI_API_KEY.Embedding della memoria
OpenClaw può utilizzare OpenAI, o un endpoint di embedding compatibile con OpenAI, per l’indicizzazionememory_search e gli embedding delle query:
queryInputType e documentInputType in memorySearch. OpenClaw
le inoltra come campi della richiesta input_type specifici del provider: gli embedding
delle query utilizzano queryInputType; i frammenti di memoria indicizzati e l’indicizzazione in batch utilizzano
documentInputType. Consultare il
Riferimento per la configurazione della memoria
per l’esempio completo.
Introduzione
- Chiave API (OpenAI Platform)
- Abbonamento Codex
Ideale per: accesso diretto all’API e fatturazione basata sull’utilizzo.In alternativa, passare direttamente la chiave:L’id diretto dell’API senza qualificatori
1
Ottenere la chiave API
Creare o copiare una chiave API dalla dashboard OpenAI Platform.
2
Eseguire l'onboarding
3
Verificare che il modello sia disponibile
Riepilogo delle route
Con il runtime non impostato o
auto, solo una route nativa HTTPS ufficiale
esatta e idonea può selezionare implicitamente l’harness app-server Codex. Per l’autenticazione
tramite chiave API sul modello di un agente, creare un profilo di autenticazione con chiave API openai e ordinarlo con
auth.order.openai; OPENAI_API_KEY rimane il fallback diretto per
le superfici API OpenAI non relative agli agenti. Eseguire openclaw doctor --fix per migrare le precedenti
voci legacy dell’ordine di autenticazione Codex.Esempio di configurazione
gpt-5.6 viene risolto nel livello Sol. Se questa
organizzazione API non espone GPT-5.6, impostare esplicitamente il modello principale su
openai/gpt-5.5.Per provare il modello Instant attuale di ChatGPT dall’API OpenAI, impostare il modello
su openai/chat-latest:chat-latest è un alias dinamico. Le nuove configurazioni con chiave API OpenAI utilizzano invece
openai/gpt-5.6, il cui id diretto dell’API senza qualificatori viene risolto in Sol. I modelli
principali espliciti esistenti, incluso openai/gpt-5.5, rimangono invariati. L’alias
chat-latest accetta solo il livello di dettaglio del testo medium; per questo modello OpenClaw forza
qualsiasi altro livello di dettaglio richiesto su medium.Autenticazione nativa dell’app-server Codex
L’harness app-server Codex nativo usa riferimenti al modelloopenai/* quando viene selezionato implicitamente da una
route HTTPS ufficiale esatta e idonea oppure esplicitamente da
agentRuntime.id: "codex" del provider/modello. L’autenticazione rimane
basata sull’account. OpenClaw seleziona l’autenticazione nel seguente ordine:
- Profili di autenticazione OpenAI ordinati per l’agente, preferibilmente in
auth.order.openai. Eseguireopenclaw doctor --fixper migrare i precedenti ID profilo di autenticazione Codex legacy e il relativo ordine. - L’account esistente dell’app-server, ad esempio un accesso ChatGPT della CLI Codex locale. Per la home isolata predefinita dell’agente, OpenClaw collega tale account CLI nativo all’app-server tramite la relativa RPC di accesso; non condivide la configurazione, i plugin o l’archivio dei thread della CLI.
- Solo per gli avvii locali dell’app-server tramite stdio e solo quando l’app-server
non segnala alcun account:
CODEX_API_KEY, quindiOPENAI_API_KEY.
OPENAI_API_KEY per i modelli OpenAI diretti o
gli embedding. Il fallback tramite chiave API di ambiente si applica esclusivamente al percorso locale stdio senza account;
non viene mai inviato tramite connessioni WebSocket dell’app-server. Quando viene selezionato un
profilo Codex basato su abbonamento, OpenClaw esclude inoltre
CODEX_API_KEY e OPENAI_API_KEY dal processo figlio app-server stdio avviato
e invia invece le credenziali selezionate tramite la RPC di accesso dell’app-server.
Quando tale profilo di abbonamento viene bloccato da un limite di utilizzo Codex, OpenClaw
contrassegna il profilo come bloccato fino all’ora di ripristino indicata da Codex e consente all’ordine di
autenticazione di passare al profilo openai:* successivo, senza modificare il modello selezionato
né uscire dall’harness Codex. Dopo l’ora di ripristino, il
profilo di abbonamento torna idoneo.
Generazione di immagini
Il pluginopenai incluso registra la generazione di immagini tramite lo
strumento image_generate. Supporta sia la generazione di immagini tramite chiave API OpenAI sia quella tramite OAuth Codex
con lo stesso riferimento al modello openai/gpt-image-2.
Consultare Generazione di immagini per i parametri condivisi dello strumento,
la selezione del provider e il comportamento di failover.
gpt-image-2 è il valore predefinito per la generazione di immagini da testo e la modifica di immagini con OpenAI.
gpt-image-1.5, gpt-image-1 e gpt-image-1-mini restano utilizzabili
come sostituzioni esplicite del modello. Usare openai/gpt-image-1.5 per
un output PNG/WebP con sfondo trasparente; l’API gpt-image-2 corrente rifiuta
background: "transparent".
Per una richiesta con sfondo trasparente, chiamare image_generate con
model: "openai/gpt-image-1.5", outputFormat: "png" o "webp" e
background: "transparent"; la precedente opzione del provider openai.background è
ancora accettata. OpenClaw protegge inoltre le route pubbliche OpenAI e OAuth OpenAI Codex
riscrivendo le richieste trasparenti predefinite openai/gpt-image-2 come
gpt-image-1.5; Azure e gli endpoint personalizzati compatibili con OpenAI mantengono i
nomi di distribuzione/modello configurati.
La stessa impostazione è disponibile per le esecuzioni CLI headless:
--output-format e --background con
openclaw infer image edit quando si parte da un file di input.
--openai-background resta disponibile come alias specifico di OpenAI. Usare
--quality low|medium|high|auto per controllare la qualità e il costo di OpenAI Images.
Usare --openai-moderation low|auto per passare il suggerimento di moderazione di OpenAI da
image generate o image edit.
Per le installazioni OAuth ChatGPT/Codex, mantenere lo stesso riferimento openai/gpt-image-2. Quando
è configurato un profilo OAuth openai, OpenClaw risolve il token di accesso OAuth
archiviato e invia le richieste di immagini tramite il backend Codex Responses; non
prova prima OPENAI_API_KEY né esegue silenziosamente il fallback a una chiave API.
Configurare esplicitamente models.providers.openai con una chiave API, un URL di base
personalizzato o un endpoint Azure per usare invece la route diretta dell’API OpenAI Images.
Se tale endpoint personalizzato per le immagini si trova su una LAN o un indirizzo privato attendibile,
impostare anche browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true; OpenClaw
mantiene bloccati gli endpoint privati/interni per immagini compatibili con OpenAI, a meno che non sia presente questa
abilitazione esplicita.
Generazione:
Generazione di video
Il pluginopenai incluso registra la generazione di video tramite lo
strumento video_generate.
Le richieste OpenAI da immagine a video usano
POST /v1/videos con un’immagine
input_reference. Le modifiche di un singolo video usano POST /v1/videos/edits con il
video caricato nel campo video.
Consultare Generazione video per i parametri condivisi dello strumento,
la selezione del provider e il comportamento di failover.Il provider OpenAI dichiara
supportsSize, ma non supportsAspectRatio o
supportsResolution. Il livello di normalizzazione condiviso di OpenClaw converte un
aspectRatio richiesto nel valore OpenAI size corrispondente più vicino prima che la
richiesta raggiunga il provider, pertanto le richieste relative alle proporzioni in genere continuano a funzionare.
resolution non dispone di un fallback per le dimensioni e viene ignorato, con segnalazione al chiamante come
Ignored unsupported overrides for openai/<model>: resolution=<value>.Contributo al prompt GPT-5
OpenClaw aggiunge un contributo condiviso al prompt GPT-5 per i modelli della famiglia GPT-5 sul provideropenai (inclusi i riferimenti Codex precedenti alla riparazione che vengono normalizzati
in openai/*). Gli altri provider che distribuiscono anche ID di modelli della famiglia GPT-5, come
OpenRouter o le route opencode, non ricevono questo overlay; viene abilitato in base
all’ID provider openai, non al solo ID modello. I modelli GPT-4.x precedenti non
lo ricevono mai.
L’harness nativo dell’app server Codex non riceve il contratto di comportamento relativo alla persona e alla
disciplina degli strumenti né l’overlay dello stile di interazione amichevole tramite
le istruzioni dello sviluppatore; Codex nativo mantiene il comportamento di base, del modello e
dei documenti di progetto gestito da Codex, mentre OpenClaw disabilita la personalità integrata di Codex per
i thread nativi, affinché i file della personalità dell’area di lavoro dell’agente rimangano autorevoli.
OpenClaw fornisce ai thread Codex nativi solo il contesto di runtime: distribuzione
al canale, strumenti dinamici di OpenClaw, delega ACP, contesto dell’area di lavoro e
Skills di OpenClaw. Il testo guida relativo all’Heartbeat proveniente dallo stesso contributo è
l’unica eccezione: le esecuzioni Heartbeat di Codex nativo lo ricevono, inserito come
istruzioni di collaborazione dedicate anziché tramite l’hook condiviso per il contributo
al prompt.
Il contributo GPT-5 aggiunge un contratto di comportamento con tag per la persistenza della persona,
la sicurezza dell’esecuzione, la disciplina degli strumenti, la struttura dell’output, i controlli
di completamento e la verifica nei prompt corrispondenti assemblati da OpenClaw. Il comportamento
specifico del canale per le risposte e i messaggi silenziosi rimane nel prompt di sistema condiviso di OpenClaw
e nei criteri di distribuzione in uscita. Il livello dello stile di interazione amichevole è
separato e configurabile.
- Configurazione
- CLI
Il valore precedente
plugins.entries.openai.config.personality viene ancora letto come
fallback di compatibilità quando l’impostazione condivisa
agents.defaults.promptOverlays.gpt5.personality non è impostata.Voce e parlato
Sintesi vocale (TTS)
Sintesi vocale (TTS)
Il Plugin incluso
openai registra la sintesi vocale per la
superficie messages.tts.Modelli disponibili:
gpt-4o-mini-tts, tts-1, tts-1-hd. Voci disponibili:
alloy, ash, ballad, cedar, coral, echo, fable, juniper,
marin, onyx, nova, sage, shimmer, verse.extraBody viene unito al JSON della richiesta /audio/speech dopo i
campi generati da OpenClaw; usarlo quindi per gli endpoint compatibili con OpenAI che richiedono
chiavi aggiuntive come lang. Le chiavi del prototipo vengono ignorate.Impostare
OPENAI_TTS_BASE_URL per sostituire l’URL di base TTS senza influire
sull’endpoint API della chat. Sia OpenAI TTS sia la voce Realtime vengono configurati
tramite una chiave API di OpenAI Platform; le installazioni che usano esclusivamente OAuth possono comunque utilizzare
modelli di chat basati su Codex, ma non la risposta vocale in tempo reale di OpenAI.Da parlato a testo
Da parlato a testo
Il Plugin incluso Quando forniti dalla configurazione condivisa dei contenuti multimediali audio o dalla richiesta di trascrizione
della singola chiamata, i suggerimenti relativi alla lingua e al prompt vengono inoltrati a OpenAI.
openai registra la conversione batch da parlato a testo tramite
la superficie di trascrizione per la comprensione dei contenuti multimediali di OpenClaw.- Modello predefinito:
gpt-4o-transcribe - Endpoint: OpenAI REST
/v1/audio/transcriptions - Percorso di input: caricamento di un file audio multipart
- Utilizzato ovunque la trascrizione dell’audio in ingresso legga
tools.media.audio, inclusi i segmenti dei canali vocali Discord e gli allegati audio dei canali
Trascrizione in tempo reale
Trascrizione in tempo reale
Il Plugin incluso
openai registra la trascrizione in tempo reale per il
Plugin Voice Call.Utilizza una connessione WebSocket a
wss://api.openai.com/v1/realtime con audio
G.711 u-law (g711_ulaw / audio/pcmu). Per un profilo con chiave API openai,
il Gateway genera un segreto client temporaneo per la trascrizione Realtime
prima di aprire il WebSocket. Questo provider di streaming è destinato al percorso di trascrizione
in tempo reale di Voice Call; attualmente la voce Discord registra brevi
segmenti e utilizza invece il percorso di trascrizione batch tools.media.audio.Voce in tempo reale
Voce in tempo reale
Il Plugin incluso
openai registra la voce in tempo reale per il Plugin
Voice Call.Voci Realtime integrate disponibili per
gpt-realtime-2.1: alloy, ash,
ballad, coral, echo, sage, shimmer, verse, marin, cedar.
OpenAI consiglia marin e cedar per ottenere la migliore qualità Realtime. Questo
insieme è distinto dalle voci di sintesi vocale indicate sopra; una voce riservata alla TTS
come fable, nova o onyx non è valida per le sessioni Realtime.
Impostare esplicitamente il modello su gpt-realtime-2.1-mini se si preferisce la
variante Realtime 2.1 più piccola e meno costosa.GPT-Live (di prossima disponibilità). I modelli full-duplex
gpt-live-1 e
gpt-live-1-mini di OpenAI hanno sostituito la modalità vocale di ChatGPT a luglio 2026; l’
API per sviluppatori è in fase di distribuzione alle organizzazioni con accesso anticipato. OpenClaw
riconosce la famiglia di modelli, ma non la esegue ancora: le sessioni GPT-Live sono
esclusivamente WebRTC, gestiscono autonomamente l’alternanza dei turni (senza VAD) e delegano il lavoro dell’agente
tramite un protocollo di eventi di passaggio che i trasporti in tempo reale di OpenClaw
non implementano ancora. La configurazione di un modello gpt-live-* non riesce in modo sicuro e fornisce
indicazioni sia sul bridge WebSocket sia sulle sessioni browser Talk, anziché
connettere silenziosamente l’audio senza accesso all’agente. Durante l’accesso anticipato, anche l’accesso
all’API è limitato per organizzazione OpenAI. Mantenere gpt-realtime-2.1 (il
valore predefinito) finché non sarà disponibile il supporto per GPT-Live.I bridge backend in tempo reale di OpenAI utilizzano la struttura della sessione WebSocket Realtime
GA, che non accetta
session.temperature. Le distribuzioni di Azure OpenAI
rimangono disponibili tramite azureEndpoint e azureDeployment e
mantengono la struttura della sessione compatibile con la distribuzione (incluso temperature).
Supporta la chiamata bidirezionale degli strumenti e l’audio G.711 u-law.La voce in tempo reale viene selezionata al momento della creazione della sessione. OpenAI consente di modificare in seguito la maggior parte
dei campi della sessione, ma la voce non può essere cambiata dopo che il
modello ha emesso audio in quella sessione. Attualmente OpenClaw espone gli
ID delle voci Realtime integrate come stringhe.
La funzione Talk della Control UI utilizza sessioni in tempo reale OpenAI nel browser con un segreto client
temporaneo coniato dal Gateway e uno scambio SDP WebRTC diretto dal browser
con l’API Realtime di OpenAI. Il Gateway conia tale segreto client con
la credenziale
openai selezionata. Le chiavi configurate, i profili con chiave API e
OPENAI_API_KEY hanno la precedenza; un profilo OAuth openai o un accesso
Codex esterno costituisce il fallback. Il relay del Gateway e i bridge WebSocket in tempo reale
del backend Voice Call usano lo stesso ordine delle credenziali per gli endpoint OpenAI nativi.
La verifica live per i manutentori è disponibile con
OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts;
i passaggi OpenAI verificano sia il bridge WebSocket del backend sia lo scambio SDP
WebRTC del browser senza registrare segreti.
Passare --openai-only per eseguire questi due passaggi senza credenziali Google.Endpoint Azure OpenAI
Il provideropenai incluso può indirizzare una risorsa Azure OpenAI per la generazione
di immagini sovrascrivendo l’URL di base. Nel percorso di generazione delle immagini, OpenClaw
rileva i nomi host Azure in models.providers.openai.baseUrl e passa
automaticamente al formato di richiesta di Azure.
La voce in tempo reale utilizza un percorso di configurazione separato
(
plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint)
e non è interessata da models.providers.openai.baseUrl. Consultare il pannello Voce in tempo
reale in Voce e sintesi vocale per le relative impostazioni
Azure.- È già disponibile una sottoscrizione, una quota o un contratto aziendale Azure OpenAI
- Sono necessari la residenza regionale dei dati o i controlli di conformità forniti da Azure
- Si desidera mantenere il traffico all’interno di un tenant Azure esistente
Configurazione
Per la generazione di immagini Azure tramite il provideropenai incluso, indirizzare
models.providers.openai.baseUrl alla propria risorsa Azure e impostare apiKey sulla
chiave Azure OpenAI (non una chiave OpenAI Platform):
*.openai.azure.com*.services.ai.azure.com*.cognitiveservices.azure.com
- Invia l’header
api-keyinvece diAuthorization: Bearer - Utilizza percorsi specifici per la distribuzione (
/openai/deployments/{deployment}/...) - Aggiunge
?api-version=...a ogni richiesta - Utilizza un timeout predefinito di 600s per le richieste di generazione di immagini Azure.
I valori
timeoutMsper singola chiamata continuano a sostituire questo valore predefinito.
L’instradamento Azure per il percorso di generazione di immagini del provider
openai richiede
OpenClaw 2026.4.22 o versione successiva. Le versioni precedenti trattano qualsiasi
openai.baseUrl personalizzato come l’endpoint OpenAI pubblico e non funzionano con le distribuzioni di immagini
Azure.Versione API
ImpostareAZURE_OPENAI_API_VERSION per fissare una specifica versione di anteprima o GA di Azure
per il percorso di generazione di immagini Azure:
2024-12-01-preview.
I nomi dei modelli sono nomi di distribuzione
Azure OpenAI associa i modelli alle distribuzioni. Per le richieste di generazione di immagini Azure instradate tramite il provideropenai incluso, il campo model in OpenClaw
deve essere il nome della distribuzione Azure configurato nel portale Azure, non
l’ID pubblico del modello OpenAI.
Se si crea una distribuzione denominata gpt-image-2-prod che serve gpt-image-2:
openai incluso.
Disponibilità regionale
La generazione di immagini Azure è attualmente disponibile solo in un sottoinsieme di regioni (ad esempioeastus2, swedencentral, polandcentral, westus3,
uaenorth). Consultare l’elenco aggiornato delle regioni di Microsoft prima di creare una
distribuzione e verificare che il modello specifico sia disponibile nella propria regione.
Differenze nei parametri
Azure OpenAI e OpenAI pubblico non accettano sempre gli stessi parametri per le immagini. Azure potrebbe rifiutare opzioni consentite da OpenAI pubblico (ad esempio determinati valoribackground in gpt-image-2) o renderle disponibili solo per versioni specifiche
del modello. Queste differenze derivano da Azure e dal modello sottostante, non da
OpenClaw. Se una richiesta Azure non riesce a causa di un errore di convalida, verificare nel
portale Azure l’insieme di parametri supportato dalla distribuzione e dalla versione API
specifiche.
Azure OpenAI utilizza il trasporto nativo e il comportamento di compatibilità, ma non riceve
gli header di attribuzione nascosti di OpenClaw: consultare il pannello Percorsi nativi e compatibili
con OpenAI in Configurazione avanzata.Per il traffico di chat o Responses su Azure (oltre alla generazione di immagini), utilizzare il
flusso di onboarding o una configurazione dedicata del provider Azure;
openai.baseUrl da solo
non adotta il formato API/autenticazione di Azure. Esiste un provider
azure-openai-responses/* separato; consultare il pannello Compaction
lato server di seguito.Configurazione avanzata
Gli esempiparams per modello riportati di seguito definiscono la richiesta del provider incorporato
di OpenClaw. La loro configurazione costituisce un comportamento di richiesta definito esplicitamente, quindi un percorso
auto altrimenti idoneo rimane su OpenClaw anziché selezionare implicitamente Codex. L’harness
app-server nativo di Codex gestisce il proprio trasporto e le proprie impostazioni di richiesta; un valore
agentRuntime.id: "codex" esplicito non riesce in modo sicuro quando il percorso effettivo non è dichiarato
compatibile con Codex.
Trasporto (WebSocket o SSE)
Trasporto (WebSocket o SSE)
OpenClaw utilizza prima WebSocket con fallback a SSE (Documentazione OpenAI correlata:
"auto") per openai/*.In modalità "auto", OpenClaw:- Riprova una volta dopo un errore WebSocket iniziale prima di passare a SSE
- Dopo un errore, contrassegna WebSocket come degradato per 60 secondi e utilizza SSE durante il periodo di attesa
- Allega header stabili di identità della sessione e del turno per i nuovi tentativi e le riconnessioni
- Normalizza i contatori di utilizzo (
input_tokens/prompt_tokens) tra le varianti di trasporto
Modalità rapida
Modalità rapida
OpenClaw espone un interruttore condiviso per la modalità rapida per
openai/*:- Chat/UI:
/fast status|auto|on|off - Configurazione:
agents.defaults.models["<provider>/<model>"].params.fastMode
service_tier = "priority"). I valori service_tier esistenti vengono
conservati e la modalità rapida non riscrive reasoning né
text.verbosity. fastMode: "auto" avvia rapidamente le nuove chiamate al modello fino alla
soglia automatica, quindi avvia le successive chiamate di nuovo tentativo, fallback, risultato dello strumento o
continuazione senza modalità rapida. La soglia predefinita è 60 secondi;
impostare params.fastAutoOnSeconds sul modello attivo per modificarla.Le sostituzioni della sessione hanno la precedenza sulla configurazione. La rimozione della sostituzione della sessione
nell’interfaccia Sessions riporta la sessione al valore predefinito configurato.
Elaborazione prioritaria (service_tier)
Elaborazione prioritaria (service_tier)
L’API di OpenAI espone l’elaborazione prioritaria tramite Valori supportati:
service_tier. Impostarla per
modello in OpenClaw:auto, default, flex, priority.Compaction lato server (API Responses)
Compaction lato server (API Responses)
Per i modelli Responses OpenAI diretti (
openai/* in api.openai.com), il
wrapper di flusso OpenClaw del Plugin OpenAI abilita automaticamente la Compaction
lato server:- Forza
store: true(a meno che la compatibilità del modello non impostisupportsStore: false) - Inserisce
context_management: [{ type: "compaction", compact_threshold: ... }] - Valore predefinito di
compact_threshold: 70% dicontextWindow(oppure80000quando non disponibile)
- Abilita esplicitamente
- Soglia personalizzata
- Disabilita
Utile per endpoint compatibili come Azure OpenAI Responses:
responsesServerCompaction controlla solo l’inserimento di context_management.
I modelli Responses OpenAI diretti continuano a forzare store: true, a meno che la compatibilità
non imposti supportsStore: false.Modalità GPT agentica rigorosa
Modalità GPT agentica rigorosa
Per i modelli della famiglia GPT-5 del provider L’impostazione esplicita di
openai eseguiti tramite il runtime incorporato
di OpenClaw, OpenClaw utilizza già per impostazione predefinita un contratto di esecuzione più rigoroso denominato
strict-agentic. Si attiva automaticamente ogni volta che il provider risolto è
openai e l’ID del modello corrisponde alla famiglia GPT-5, a meno che la configurazione
non lo disabiliti esplicitamente:"strict-agentic" non produce alcun effetto in un percorso supportato (è
già il valore predefinito) ed è inerte per le coppie provider/modello non supportate.Con strict-agentic attivo, OpenClaw:- Abilita automaticamente
update_planper attività sostanziali - Riprova i turni strutturalmente vuoti o contenenti solo ragionamento con una continuazione che fornisce una risposta visibile
- Utilizza eventi espliciti del piano dell’harness quando l’harness selezionato li fornisce
Questo contratto risiede interamente nell’esecutore dell’agente incorporato di OpenClaw. Non si
applica all’harness nativo app-server di Codex, che gestisce autonomamente
il comportamento dei turni e dei piani; per le esecuzioni native di Codex, la selezione dell’harness conta più
dell’impostazione del contratto di esecuzione.
Percorsi nativi e compatibili con OpenAI
Percorsi nativi e compatibili con OpenAI
OpenClaw gestisce gli endpoint diretti OpenAI, Codex e Azure OpenAI
in modo diverso dai proxy generici
/v1 compatibili con OpenAI:Percorsi nativi (openai/*, Azure OpenAI):- Mantiene
reasoning: { effort: "none" }solo per i modelli che supportano il livello dinonedi OpenAI - Omette il ragionamento disabilitato per i modelli o i proxy che rifiutano
reasoning.effort: "none" - Imposta per impostazione predefinita gli schemi degli strumenti in modalità rigorosa
- Aggiunge intestazioni di attribuzione nascoste solo sugli host nativi verificati (Azure OpenAI non riceve queste intestazioni, sebbene sia un percorso nativo)
- Mantiene la strutturazione delle richieste specifica di OpenAI (
service_tier,store, compatibilità del ragionamento, suggerimenti per la cache dei prompt)
- Utilizza un comportamento di compatibilità meno rigoroso
- Rimuove
storedi Completions dai payloadopenai-completionsnon nativi - Accetta JSON pass-through avanzato
params.extra_body/params.extraBodyper i proxy Completions compatibili con OpenAI - Accetta
params.chat_template_kwargsper i proxy Completions compatibili con OpenAI, come vLLM - Non impone schemi degli strumenti rigorosi né intestazioni riservate ai percorsi nativi
Argomenti correlati
Selezione del modello
Scelta dei provider, dei riferimenti ai modelli e del comportamento di failover.
Generazione di immagini
Parametri condivisi dello strumento per le immagini e selezione del provider.
Generazione di video
Parametri condivisi dello strumento per i video e selezione del provider.
OAuth e autenticazione
Dettagli sull’autenticazione e regole per il riutilizzo delle credenziali.