Skip to main content
OpenClaw utilizza un unico id provider, 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 esplicita agentRuntime o 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_KEY o un profilo di autenticazione tramite chiave API openai.
  • Configurazione legacy - i riferimenti codex/* e openai-codex/* vengono corretti in openai/* più agentRuntime.id: "codex" con ambito limitato al modello da openclaw doctor --fix.
OpenAI supporta esplicitamente l’uso di OAuth degli abbonamenti in strumenti esterni e flussi di lavoro come OpenClaw.

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_KEY mostra 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_ID limita facoltativamente la cronologia dell’API di amministrazione a un singolo progetto.
  • OpenClaw non invia mai OPENAI_API_KEY o un profilo di inferenza openai alle API dell’organizzazione; tali credenziali possono appartenere a endpoint personalizzati, Azure o locali dell’agente.
Una chiave di amministrazione esplicita ha la precedenza su OAuth. La cronologia segnalata dal provider non viene unita al costo stimato da OpenClaw in base alle sessioni; può includere attività API di altri client e rettifiche di fatturazione lato provider. La documentazione del dashboard di utilizzo delle API di OpenAI descrive i requisiti relativi al proprietario dell’organizzazione e all’autorizzazione esplicita per il dashboard di utilizzo necessari per accedere ai dati di utilizzo. Provider, modello, runtime e canale sono livelli separati. Se queste etichette vengono confuse, consultare Runtime degli agenti prima di modificare la configurazione.

Scelta rapida

Mappa dei nomi

Runtime implicito dell’agente

Quando il criterio agentRuntime 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 esatti openai/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:
L’accesso all’organizzazione API e all’area di lavoro Codex può essere diverso. Se GPT-5.6 non è disponibile, selezionare esplicitamente GPT-5.5:
OpenClaw mostra l’errore di accesso upstream e non sostituisce silenziosamente una selezione GPT-5.6 con GPT-5.5.
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’indicizzazione memory_search e gli embedding delle query:
Per gli endpoint compatibili con OpenAI che richiedono etichette di embedding asimmetriche, impostare 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

Ideale per: accesso diretto all’API e fatturazione basata sull’utilizzo.
1

Ottenere la chiave API

Creare o copiare una chiave API dalla dashboard OpenAI Platform.
2

Eseguire l'onboarding

In alternativa, passare direttamente la chiave:
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

L’id diretto dell’API senza qualificatori 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.
OpenClaw non espone gpt-5.3-codex-spark sulla route diretta con chiave API OpenAI. È disponibile solo tramite le voci del catalogo dell’abbonamento Codex quando l’account connesso lo espone.

Autenticazione nativa dell’app-server Codex

L’harness app-server Codex nativo usa riferimenti al modello openai/* 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:
  1. Profili di autenticazione OpenAI ordinati per l’agente, preferibilmente in auth.order.openai. Eseguire openclaw doctor --fix per migrare i precedenti ID profilo di autenticazione Codex legacy e il relativo ordine.
  2. 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.
  3. Solo per gli avvii locali dell’app-server tramite stdio e solo quando l’app-server non segnala alcun account: CODEX_API_KEY, quindi OPENAI_API_KEY.
Un accesso locale con abbonamento ChatGPT/Codex non viene sostituito solo perché il processo Gateway dispone anche di 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 plugin openai 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:
Usare gli stessi flag --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 un PNG trasparente:
Modifica:

Generazione di video

Il plugin openai 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 provider openai (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.
Durante il runtime, i valori non distinguono tra maiuscole e minuscole, pertanto sia "Off" sia "off" disabilitano il livello dello stile amichevole.
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

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.
Il Plugin incluso 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
Per imporre l’uso di OpenAI per la trascrizione dell’audio in ingresso:
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.
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.
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 provider openai 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.
Utilizzare Azure OpenAI nei seguenti casi:
  • È 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 provider openai incluso, indirizzare models.providers.openai.baseUrl alla propria risorsa Azure e impostare apiKey sulla chiave Azure OpenAI (non una chiave OpenAI Platform):
OpenClaw riconosce questi suffissi host Azure per il percorso di generazione di immagini Azure:
  • *.openai.azure.com
  • *.services.ai.azure.com
  • *.cognitiveservices.azure.com
Per le richieste di generazione di immagini su un host Azure riconosciuto, OpenClaw:
  • Invia l’header api-key invece di Authorization: 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 timeoutMs per singola chiamata continuano a sostituire questo valore predefinito.
Gli altri URL di base (OpenAI pubblico, proxy compatibili con OpenAI) mantengono il formato standard delle richieste di immagini OpenAI.
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

Impostare AZURE_OPENAI_API_VERSION per fissare una specifica versione di anteprima o GA di Azure per il percorso di generazione di immagini Azure:
Quando la variabile non è impostata, il valore predefinito è 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 provider openai 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:
La stessa regola relativa al nome della distribuzione si applica a qualsiasi chiamata di generazione di immagini instradata tramite il provider openai incluso.

Disponibilità regionale

La generazione di immagini Azure è attualmente disponibile solo in un sottoinsieme di regioni (ad esempio eastus2, 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 valori background 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 esempi params 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.
OpenClaw utilizza prima WebSocket con fallback a SSE ("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
Documentazione OpenAI correlata:
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
Quando è abilitata, OpenClaw associa la modalità rapida all’elaborazione prioritaria di OpenAI (service_tier = "priority"). I valori service_tier esistenti vengono conservati e la modalità rapida non riscrive reasoningtext.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.
L’API di OpenAI espone l’elaborazione prioritaria tramite service_tier. Impostarla per modello in OpenClaw:
Valori supportati: auto, default, flex, priority.
serviceTier viene inoltrato solo agli endpoint OpenAI nativi (api.openai.com) e agli endpoint Codex nativi (chatgpt.com/backend-api). Se uno dei due provider viene instradato tramite un proxy, OpenClaw lascia service_tier invariato.
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 imposti supportsStore: false)
  • Inserisce context_management: [{ type: "compaction", compact_threshold: ... }]
  • Valore predefinito di compact_threshold: 70% di contextWindow (oppure 80000 quando non disponibile)
Ciò si applica al percorso di runtime integrato di OpenClaw e agli hook del provider OpenAI utilizzati dalle esecuzioni incorporate. L’harness app-server nativo di Codex gestisce il proprio contesto tramite Codex e non è interessato da questa impostazione.
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.
Per i modelli della famiglia GPT-5 del provider 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:
L’impostazione esplicita di "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_plan per 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
OpenClaw non classifica il testo dell’assistente per decidere se un turno sia un piano, un aggiornamento sullo stato di avanzamento o una risposta finale.
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.
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 di none di 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)
Percorsi proxy/compatibili:
  • Utilizza un comportamento di compatibilità meno rigoroso
  • Rimuove store di Completions dai payload openai-completions non nativi
  • Accetta JSON pass-through avanzato params.extra_body/params.extraBody per i proxy Completions compatibili con OpenAI
  • Accetta params.chat_template_kwargs per 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.