openai, pour l’authentification directe par clé d’API et
l’authentification par abonnement ChatGPT/Codex. openai/* est la route de modèle canonique.
Pour les tours d’agent intégrés dont la politique d’exécution n’est pas définie ou vaut auto, les caractéristiques de route
d’OpenAI déterminent si OpenClaw peut sélectionner implicitement l’environnement d’exécution app-server Codex inclus.
Le préfixe openai/* seul ne sélectionne aucun environnement d’exécution.
- Modèles d’agent -
openai/*via l’environnement d’exécution sélectionné par une configurationagentRuntimeexplicite ou par la politique de route implicite d’OpenAI. Connectez-vous avec l’authentification Codex pour utiliser un abonnement ChatGPT/Codex, ou configurez un profil d’authentification par clé d’API si vous souhaitez une facturation basée sur une clé. - API OpenAI hors agent - accès direct à OpenAI Platform, facturé à l’utilisation,
via
OPENAI_API_KEYou un profil d’authentification par clé d’APIopenai. - Configuration héritée - les références
codex/*etopenai-codex/*sont corrigées enopenai/*, avecagentRuntime.id: "codex"limité au modèle, paropenclaw doctor --fix.
Suivi de l’utilisation et des coûts
OpenClaw distingue le quota de l’abonnement de la facturation de l’API Platform :- L’OAuth ChatGPT/Codex affiche le forfait d’abonnement, les fenêtres de quota et le solde de crédits.
OPENAI_ADMIN_KEYaffiche 30 jours de coûts d’organisation et d’utilisation des complétions communiqués par le fournisseur dans Utilisation de l’interface de contrôle, notamment les dépenses quotidiennes, les totaux de requêtes et de jetons, les principaux modèles et les catégories de coûts.OPENAI_PROJECT_IDlimite facultativement l’historique de l’API d’administration à un seul projet.- OpenClaw n’envoie jamais
OPENAI_API_KEYni un profil d’inférenceopenaiaux API de l’organisation ; ces identifiants peuvent appartenir à des points de terminaison personnalisés, Azure ou locaux à l’agent.
Choix rapide
Correspondance des noms
Environnement d’exécution implicite de l’agent
Lorsque la politiqueagentRuntime du fournisseur/modèle n’est pas définie ou vaut auto, la politique de route
détenue par le fournisseur OpenAI choisit l’environnement d’exécution implicite à partir du
point de terminaison et de l’adaptateur effectifs :
Une configuration
agentRuntime.id explicite et non par défaut du fournisseur/modèle reste prioritaire.
Par exemple, agentRuntime.id: "openclaw" maintient sur OpenClaw une
route qui serait autrement admissible à Codex, tandis que agentRuntime.id: "codex" exige Codex et échoue
de manière fermée lorsque la route effective n’est pas déclarée compatible avec Codex.
La sélection de l’environnement d’exécution ne modifie ni le type d’identifiants ni la facturation : l’authentification
par clé d’API Platform et l’authentification par abonnement ChatGPT/Codex restent distinctes.
openclaw doctor --fix migre les références de modèle héritées codex/* et openai-codex/*,
les identifiants de profils d’authentification Codex hérités et les entrées héritées d’ordre d’authentification Codex vers la
route canonique openai. Les références de modèle migrées reçoivent
agentRuntime.id: "codex" limité au modèle ; utilisez auth.order.openai pour toute nouvelle configuration de l’ordre d’authentification.
Une nouvelle configuration OpenAI applique un modèle principal GPT-5.6 uniquement lorsqu’aucun modèle principal n’est
configuré. L’ajout ou l’actualisation de l’authentification OpenAI conserve toute sélection explicite
existante, notamment
openai/gpt-5.5, sauf si vous utilisez explicitement
models auth login --set-default ou models set. Utilisez un profil d’authentification par clé d’API
uniquement si vous souhaitez une authentification par clé d’API pour un modèle d’agent.Aperçu limité de GPT-5.6
OpenClaw reconnaît les identifiants de modèle exactsopenai/gpt-5.6-sol,
openai/gpt-5.6-terra et openai/gpt-5.6-luna. Tous trois proposent le raisonnement
xhigh et max dans le catalogue actuel. OpenAI décrit Sol comme
le niveau phare, Terra comme le niveau équilibré et Luna comme le niveau rapide
et moins coûteux. Consultez
l’annonce de lancement de GPT-5.6
et le guide d’accès.
Avec l’authentification directe par clé d’API OpenAI, l’identifiant openai/gpt-5.6 sans qualification est un alias de
Sol et constitue la valeur par défaut d’une nouvelle configuration. Le catalogue Codex natif n’applique pas
cet alias d’API directe côté client ; selon l’accès de l’espace de travail, il peut afficher
les identifiants exacts de Sol, Terra et Luna. Une nouvelle configuration OAuth ChatGPT/Codex
utilise donc openai/gpt-5.6-sol. Vérifiez le compte actuel avec :
Les routes HTTPS officielles exactes admissibles peuvent sélectionner le Plugin app-server Codex
inclus lorsque la politique d’exécution n’est pas définie ou vaut
auto ; les routes Completions définies,
les points de terminaison personnalisés et les substitutions de transport des requêtes restent sur OpenClaw. Les points de terminaison
HTTP officiels en texte clair sont rejetés. La configuration explicite de l’environnement d’exécution du fournisseur/modèle reste
prioritaire. Exécutez openclaw doctor --fix pour corriger les anciennes références de modèle Codex
héritées, les références codex-cli/* ou les anciens épinglages de session d’exécution qui n’ont pas été définis par
une configuration d’exécution explicite.Couverture fonctionnelle d’OpenClaw
La voix OpenAI Realtime passe par l’API Realtime publique d’OpenAI Platform
et nécessite une clé API Platform. Les jetons OAuth Codex authentifient à la
place le backend ChatGPT Codex ; ils ne sont pas interchangeables avec les clés
API Platform pour les points de terminaison Realtime publics.Si l’authentification par clé API signale une facturation manquante, rechargez les crédits Platform sur
platform.openai.com/account/billing
pour l’organisation associée à vos identifiants en temps réel lors de l’utilisation de
l’authentification par clé API. La voix en temps réel accepte le profil d’authentification par clé API
openai créé par
openclaw onboard --auth-choice openai-api-key, une clé API Platform définie via
talk.realtime.providers.openai.apiKey pour Talk de la Control UI, ou
plugins.entries.voice-call.config.realtime.providers.openai.apiKey pour Voice
Call, ou la variable d’environnement OPENAI_API_KEY.Plongements de mémoire
OpenClaw peut utiliser OpenAI, ou un point de terminaison de plongements compatible avec OpenAI, pour les plongements d’indexation et de requêtememory_search :
queryInputType et documentInputType sous memorySearch. OpenClaw
les transmet en tant que champs de requête input_type propres au fournisseur : les plongements de
requête utilisent queryInputType ; les fragments de mémoire indexés et l’indexation par lots utilisent
documentInputType. Consultez la
référence de configuration de la mémoire
pour l’exemple complet.
Prise en main
- Clé API (OpenAI Platform)
- Abonnement Codex
Idéal pour : l’accès direct à l’API et la facturation à l’usage.Ou transmettez directement la clé :L’identifiant direct d’API nu
1
Obtenir votre clé API
Créez ou copiez une clé API depuis le tableau de bord OpenAI Platform.
2
Exécuter l’intégration initiale
3
Vérifier que le modèle est disponible
Résumé des routes
Lorsque le runtime est non défini ou vaut
auto, seule une route native HTTPS officielle exacte
et admissible peut sélectionner implicitement le harnais app-server Codex. Pour l’authentification
par clé API sur un modèle d’agent, créez un profil d’authentification par clé API openai et ordonnez-le avec
auth.order.openai ; OPENAI_API_KEY reste la solution de repli directe pour
les surfaces de l’API OpenAI ne concernant pas les agents. Exécutez openclaw doctor --fix pour migrer les anciennes
entrées d’ordre d’authentification Codex.Exemple de configuration
gpt-5.6 correspond au niveau Sol. Si cette organisation
d’API n’expose pas GPT-5.6, définissez explicitement le modèle principal sur
openai/gpt-5.5.Pour essayer le modèle Instant actuel de ChatGPT depuis l’API OpenAI, définissez le modèle
sur openai/chat-latest :chat-latest est un alias évolutif. Une nouvelle configuration par clé API OpenAI utilise plutôt
openai/gpt-5.6, dont l’identifiant direct d’API nu correspond à Sol. Les modèles principaux
explicites existants, notamment openai/gpt-5.5, restent inchangés. L’alias
chat-latest accepte uniquement la verbosité de texte medium ; OpenClaw force
toute autre verbosité demandée sur medium pour ce modèle.Authentification du serveur d’application Codex natif
Le harnais de serveur d’application Codex natif utilise les références de modèleopenai/* lorsqu’une route
HTTPS officielle exacte et admissible le sélectionne implicitement, ou lorsque le agentRuntime.id: "codex"
du fournisseur/modèle le sélectionne explicitement. Son authentification reste
liée au compte. OpenClaw sélectionne l’authentification dans cet ordre :
- Profils d’authentification OpenAI ordonnés pour l’agent, de préférence sous
auth.order.openai. Exécutezopenclaw doctor --fixpour migrer les anciens identifiants de profil d’authentification Codex et l’ordre d’authentification hérités. - Compte existant du serveur d’application, par exemple une connexion ChatGPT locale dans la CLI Codex. Pour le répertoire personnel isolé par défaut de l’agent, OpenClaw transmet ce compte CLI natif au serveur d’application via son RPC de connexion ; il ne partage pas la configuration, les plugins ni le magasin de fils de discussion de la CLI.
- Pour les lancements locaux du serveur d’application via stdio uniquement, et seulement lorsque celui-ci
ne signale aucun compte :
CODEX_API_KEY, puisOPENAI_API_KEY.
OPENAI_API_KEY pour les modèles OpenAI directs ou les
embeddings. Le recours à la clé d’API d’environnement s’applique uniquement au chemin local stdio sans compte ;
elle n’est jamais envoyée sur les connexions WebSocket du serveur d’application. Lorsqu’un
profil Codex de type abonnement est sélectionné, OpenClaw empêche également
CODEX_API_KEY et OPENAI_API_KEY d’atteindre le processus enfant du serveur d’application stdio
et envoie plutôt les identifiants sélectionnés via le RPC de connexion du serveur d’application.
Lorsque ce profil d’abonnement est bloqué par une limite d’utilisation Codex, OpenClaw
marque le profil comme bloqué jusqu’à l’heure de réinitialisation annoncée par Codex et permet à l’ordre
d’authentification de passer au profil openai:* suivant, sans changer le modèle sélectionné
ni quitter le harnais Codex. Une fois l’heure de réinitialisation passée, le
profil d’abonnement redevient admissible.
Génération d’images
Le pluginopenai inclus enregistre la génération d’images au moyen de l’outil
image_generate. Il prend en charge la génération d’images avec une clé d’API OpenAI et avec OAuth Codex
via la même référence de modèle openai/gpt-image-2.
Consultez Génération d’images pour les paramètres communs de l’outil,
la sélection du fournisseur et le comportement de basculement.
gpt-image-2 est la valeur par défaut pour la génération d’images à partir de texte et la
retouche d’images avec OpenAI. gpt-image-1.5, gpt-image-1 et gpt-image-1-mini restent utilisables
comme remplacements explicites du modèle. Utilisez openai/gpt-image-1.5 pour
une sortie PNG/WebP à arrière-plan transparent ; l’API gpt-image-2 actuelle rejette
background: "transparent".
Pour une requête avec arrière-plan transparent, appelez image_generate avec
model: "openai/gpt-image-1.5", outputFormat: "png" ou "webp", ainsi que
background: "transparent" ; l’ancienne option de fournisseur openai.background est
toujours acceptée. OpenClaw protège également les routes publiques OpenAI et OAuth OpenAI Codex
en réécrivant les requêtes transparentes openai/gpt-image-2 par défaut en
gpt-image-1.5 ; Azure et les points de terminaison personnalisés compatibles avec OpenAI conservent leurs
noms de déploiement/modèle configurés.
Le même réglage est disponible pour les exécutions sans interface de la CLI :
--output-format et --background avec
openclaw infer image edit lorsque vous partez d’un fichier d’entrée.
--openai-background reste disponible comme alias propre à OpenAI. Utilisez
--quality low|medium|high|auto pour contrôler la qualité et le coût d’OpenAI Images.
Utilisez --openai-moderation low|auto pour transmettre l’indication de modération d’OpenAI depuis
image generate ou image edit.
Pour les installations OAuth ChatGPT/Codex, conservez la même référence openai/gpt-image-2. Lorsqu’un
profil OAuth openai est configuré, OpenClaw résout le jeton d’accès OAuth stocké
et envoie les requêtes d’image via le backend Codex Responses ; il
n’essaie pas d’abord OPENAI_API_KEY et ne bascule pas silencieusement vers une clé d’API.
Configurez explicitement models.providers.openai avec une clé d’API, une URL de base
personnalisée ou un point de terminaison Azure lorsque vous souhaitez utiliser directement la route de l’API OpenAI Images.
Si ce point de terminaison d’image personnalisé se trouve sur une adresse de réseau local/privée de confiance,
définissez également browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true ; OpenClaw
maintient les points de terminaison d’image privés/internes compatibles avec OpenAI bloqués en l’absence de cette
activation explicite.
Générer :
Génération de vidéos
Le pluginopenai inclus enregistre la génération de vidéos au moyen de
l’outil video_generate.
Les requêtes image-vers-vidéo OpenAI utilisent
POST /v1/videos avec une image
input_reference. Les modifications d’une seule vidéo utilisent POST /v1/videos/edits avec la
vidéo téléversée dans le champ video.
Consultez Génération de vidéos pour connaître les paramètres partagés de l’outil,
la sélection du fournisseur et le comportement de basculement.Le fournisseur OpenAI déclare
supportsSize, mais pas supportsAspectRatio ni
supportsResolution. La couche de normalisation partagée d’OpenClaw convertit un
aspectRatio demandé en l’size OpenAI correspondant le mieux avant que la
requête n’atteigne le fournisseur ; les requêtes de rapport d’aspect fonctionnent donc généralement malgré tout.
resolution ne dispose d’aucune solution de repli pour la taille et est supprimé, ce qui est signalé à l’appelant comme
Ignored unsupported overrides for openai/<model>: resolution=<value>.Contribution à l’invite GPT-5
OpenClaw ajoute une contribution partagée à l’invite GPT-5 pour les modèles de la famille GPT-5 sur le fournisseuropenai (y compris les anciennes références Codex antérieures à la réparation, qui sont normalisées
en openai/*). Les autres fournisseurs qui proposent également des identifiants de modèles de la famille GPT-5,
tels qu’OpenRouter ou les routes opencode, ne reçoivent pas cette surcouche ; son activation dépend de
l’identifiant de fournisseur openai, et non du seul identifiant de modèle. Les anciens modèles GPT-4.x ne
la reçoivent jamais.
Le harnais natif du serveur d’application Codex ne reçoit pas le contrat de comportement relatif à la personnalité et à la
discipline d’utilisation des outils, ni la surcouche de style d’interaction convivial, par l’intermédiaire
des instructions du développeur ; le Codex natif conserve les comportements de base, de modèle et
de documentation du projet propres à Codex, et OpenClaw désactive la personnalité intégrée de Codex pour
les fils natifs afin que les fichiers de personnalité de l’espace de travail de l’agent restent la référence.
OpenClaw apporte uniquement le contexte d’exécution aux fils Codex natifs : distribution par
canal, outils dynamiques OpenClaw, délégation ACP, contexte de l’espace de travail et
Skills OpenClaw. Le texte d’orientation du Heartbeat issu de cette même contribution constitue
l’unique exception : les tours de Heartbeat Codex natifs le reçoivent bien, injecté sous forme
d’instructions de collaboration dédiées plutôt que par l’intermédiaire du point d’extension partagé
de contribution à l’invite.
La contribution GPT-5 ajoute un contrat de comportement balisé pour la persistance de la personnalité,
la sécurité d’exécution, la discipline d’utilisation des outils, la forme de la sortie, les vérifications
d’achèvement et la validation dans les invites correspondantes assemblées par OpenClaw. Le comportement
des réponses propres aux canaux et des messages silencieux reste défini dans l’invite système partagée
d’OpenClaw et dans la politique de distribution sortante. La couche de style d’interaction convivial est
distincte et configurable.
- Configuration
- CLI
L’ancien paramètre
plugins.entries.openai.config.personality est toujours lu comme
solution de repli de compatibilité lorsque le paramètre partagé
agents.defaults.promptOverlays.gpt5.personality n’est pas défini.Voix et parole
Synthèse vocale (TTS)
Synthèse vocale (TTS)
Le Plugin intégré
openai enregistre la synthèse vocale pour la
surface messages.tts.Modèles disponibles :
gpt-4o-mini-tts, tts-1, tts-1-hd. Voix disponibles :
alloy, ash, ballad, cedar, coral, echo, fable, juniper,
marin, onyx, nova, sage, shimmer, verse.extraBody est fusionné dans le JSON de requête /audio/speech après les
champs générés par OpenClaw ; utilisez-le donc pour les points de terminaison compatibles avec OpenAI qui nécessitent
des clés supplémentaires telles que lang. Les clés de prototype sont ignorées.Définissez
OPENAI_TTS_BASE_URL pour remplacer l’URL de base de la TTS sans affecter
le point de terminaison de l’API de chat. La TTS OpenAI et la voix Realtime sont toutes deux configurées
à l’aide d’une clé API OpenAI Platform ; les installations utilisant uniquement OAuth peuvent toujours utiliser
les modèles de chat reposant sur Codex, mais pas le retour vocal en direct d’OpenAI.Reconnaissance vocale
Reconnaissance vocale
Le Plugin intégré Les indications de langue et d’invite sont transmises à OpenAI lorsqu’elles sont fournies par la
configuration partagée des médias audio ou par la requête de transcription propre à l’appel.
openai enregistre la reconnaissance vocale par lots par l’intermédiaire
de la surface de transcription de compréhension des médias d’OpenClaw.- Modèle par défaut :
gpt-4o-transcribe - Point de terminaison : REST OpenAI
/v1/audio/transcriptions - Chemin d’entrée : téléversement multipart d’un fichier audio
- Utilisé partout où la transcription audio entrante lit
tools.media.audio, y compris les segments de canaux vocaux Discord et les pièces jointes audio des canaux
Transcription en temps réel
Transcription en temps réel
Le Plugin intégré
openai enregistre la transcription en temps réel pour le
Plugin Voice Call.Utilise une connexion WebSocket à
wss://api.openai.com/v1/realtime avec de l’audio
G.711 loi μ (g711_ulaw / audio/pcmu). Pour un profil de clé API openai,
le Gateway génère un secret client éphémère pour la transcription Realtime
avant d’ouvrir le WebSocket. Ce fournisseur de diffusion en continu est destiné au chemin de transcription
en temps réel de Voice Call ; la voix Discord enregistre actuellement de courts
segments et utilise à la place le chemin de transcription par lots tools.media.audio.Voix en temps réel
Voix en temps réel
Le Plugin intégré
openai enregistre la voix en temps réel pour le Plugin Voice Call.Voix Realtime intégrées disponibles pour
gpt-realtime-2.1 : alloy, ash,
ballad, coral, echo, sage, shimmer, verse, marin, cedar.
OpenAI recommande marin et cedar pour obtenir la meilleure qualité Realtime. Il
s’agit d’un ensemble distinct des voix de synthèse vocale ci-dessus ; une voix réservée à la TTS,
telle que fable, nova ou onyx, n’est pas valide pour les sessions Realtime.
Définissez explicitement le modèle sur gpt-realtime-2.1-mini si vous préférez la
variante Realtime 2.1 plus petite et moins coûteuse.GPT-Live (à venir). Les modèles duplex intégral
gpt-live-1 et
gpt-live-1-mini d’OpenAI ont remplacé le mode vocal de ChatGPT en juillet 2026 ; l’
API pour développeurs est en cours de déploiement auprès des organisations disposant d’un accès anticipé. OpenClaw
reconnaît la famille de modèles, mais ne l’exécute pas encore : les sessions GPT-Live utilisent
uniquement WebRTC, gèrent elles-mêmes l’alternance des tours de parole (sans VAD) et délèguent le travail de l’agent
par l’intermédiaire d’un protocole d’événements de transfert que les transports en temps réel d’OpenClaw
ne prennent pas encore en charge. La configuration d’un modèle gpt-live-* échoue de manière fermée avec
des instructions concernant à la fois la passerelle WebSocket et les sessions Talk dans le navigateur, au lieu de
connecter silencieusement l’audio sans accès à l’agent. L’accès à l’API est également contrôlé
pour chaque organisation OpenAI pendant l’accès anticipé. Conservez gpt-realtime-2.1 (la
valeur par défaut) jusqu’à la prise en charge de GPT-Live.Les passerelles OpenAI en temps réel côté serveur utilisent le format de session WebSocket Realtime
en disponibilité générale, qui n’accepte pas
session.temperature. Les déploiements Azure OpenAI
restent disponibles par l’intermédiaire de azureEndpoint et azureDeployment et
conservent le format de session compatible avec les déploiements (y compris temperature).
Prend en charge l’appel d’outils bidirectionnel et l’audio G.711 loi μ.La voix en temps réel est sélectionnée lors de la création de la session. OpenAI autorise la modification ultérieure de la plupart
des champs de session, mais la voix ne peut plus être modifiée après que le
modèle a émis de l’audio dans cette session. OpenClaw expose actuellement les
identifiants de voix Realtime intégrés sous forme de chaînes.
La fonction Talk de l’interface de contrôle utilise des sessions en temps réel OpenAI dans le navigateur, avec un secret client éphémère
émis par le Gateway et un échange SDP WebRTC direct depuis le navigateur
avec l’API Realtime d’OpenAI. Le Gateway émet ce secret client avec
l’identifiant
openai sélectionné. Les clés configurées, les profils de clé API et
OPENAI_API_KEY sont prioritaires ; un profil OAuth openai ou une connexion
Codex externe sert de solution de repli. Les relais Gateway et les ponts WebSocket en temps réel
du backend Voice Call utilisent le même ordre d’identifiants pour les points de terminaison OpenAI natifs.
La vérification en direct par les responsables de maintenance est disponible avec
OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts ;
les étapes OpenAI vérifient à la fois le pont WebSocket du backend et l’échange SDP
WebRTC du navigateur sans journaliser les secrets.
Transmettez --openai-only pour exécuter ces deux étapes sans identifiants Google.Points de terminaison Azure OpenAI
Le fournisseuropenai intégré peut cibler une ressource Azure OpenAI pour la génération
d’images en remplaçant l’URL de base. Sur le chemin de génération d’images, OpenClaw
détecte les noms d’hôte Azure dans models.providers.openai.baseUrl et adopte
automatiquement le format de requête d’Azure.
La voix en temps réel utilise un chemin de configuration distinct
(
plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint)
et n’est pas affectée par models.providers.openai.baseUrl. Consultez l’accordéon Voix en
temps réel sous Voix et parole pour ses paramètres Azure.- Vous disposez déjà d’un abonnement Azure OpenAI, d’un quota ou d’un contrat d’entreprise
- Vous avez besoin de la résidence régionale des données ou des contrôles de conformité fournis par Azure
- Vous souhaitez conserver le trafic au sein d’un locataire Azure existant
Configuration
Pour la génération d’images Azure via le fournisseuropenai intégré, faites pointer
models.providers.openai.baseUrl vers votre ressource Azure et définissez apiKey sur
la clé Azure OpenAI (et non une clé OpenAI Platform) :
*.openai.azure.com*.services.ai.azure.com*.cognitiveservices.azure.com
- Envoie l’en-tête
api-keyau lieu deAuthorization: Bearer - Utilise des chemins propres au déploiement (
/openai/deployments/{deployment}/...) - Ajoute
?api-version=...à chaque requête - Utilise un délai d’expiration de requête par défaut de 600s pour les appels de génération d’images Azure.
Les valeurs
timeoutMspropres à chaque appel remplacent toujours cette valeur par défaut.
Le routage Azure du chemin de génération d’images du fournisseur
openai nécessite
OpenClaw 2026.4.22 ou une version ultérieure. Les versions antérieures traitent toute valeur
openai.baseUrl personnalisée comme le point de terminaison OpenAI public et échouent avec les déploiements
d’images Azure.Version de l’API
DéfinissezAZURE_OPENAI_API_VERSION pour fixer une version préliminaire ou GA spécifique d’Azure
pour le chemin de génération d’images Azure :
2024-12-01-preview lorsque la variable n’est pas définie.
Les noms de modèles sont des noms de déploiements
Azure OpenAI associe les modèles à des déploiements. Pour les requêtes de génération d’images Azure routées via le fournisseuropenai intégré, le champ model dans OpenClaw
doit correspondre au nom du déploiement Azure que vous avez configuré dans le portail Azure, et non
à l’identifiant public du modèle OpenAI.
Si vous créez un déploiement nommé gpt-image-2-prod qui fournit gpt-image-2 :
openai intégré.
Disponibilité régionale
La génération d’images Azure n’est actuellement disponible que dans un sous-ensemble de régions (par exempleeastus2, swedencentral, polandcentral, westus3,
uaenorth). Consultez la liste actuelle des régions de Microsoft avant de créer un
déploiement et vérifiez que le modèle concerné est proposé dans votre région.
Différences entre les paramètres
Azure OpenAI et OpenAI public n’acceptent pas toujours les mêmes paramètres d’image. Azure peut refuser des options autorisées par OpenAI public (par exemple certaines valeursbackground sur gpt-image-2) ou ne les proposer que pour des versions
de modèle spécifiques. Ces différences proviennent d’Azure et du modèle sous-jacent, et non
d’OpenClaw. Si une requête Azure échoue avec une erreur de validation, consultez dans le
portail Azure l’ensemble de paramètres pris en charge par votre déploiement et votre version
d’API spécifiques.
Azure OpenAI utilise le transport natif et le comportement de compatibilité, mais ne reçoit pas
les en-têtes d’attribution masqués d’OpenClaw — consultez l’accordéon Routes natives et compatibles
avec OpenAI sous Configuration avancée.Pour le trafic de discussion ou Responses sur Azure (au-delà de la génération d’images), utilisez le
processus d’intégration ou une configuration de fournisseur Azure dédiée ;
openai.baseUrl seul
n’adopte pas le format d’API et d’authentification Azure. Un fournisseur
azure-openai-responses/* distinct existe ; consultez l’accordéon Compaction côté
serveur ci-dessous.Configuration avancée
Les exemplesparams propres à chaque modèle ci-dessous définissent la requête du fournisseur
intégré d’OpenClaw. Leur configuration constitue un comportement de requête explicite ; une route
auto par ailleurs admissible reste donc sur OpenClaw au lieu de sélectionner implicitement Codex. Le
harnachement natif du serveur d’application Codex gère son propre transport et ses propres paramètres de requête ;
une valeur agentRuntime.id: "codex" explicite échoue de manière fermée lorsque la route effective n’est pas déclarée
compatible avec Codex.
Transport (WebSocket ou SSE)
Transport (WebSocket ou SSE)
OpenClaw utilise WebSocket en priorité avec SSE comme solution de repli (Documentation OpenAI associée :
"auto") pour openai/*.En mode "auto", OpenClaw :- Réessaie une fois après un échec précoce de WebSocket avant de se rabattre sur SSE
- Après un échec, marque WebSocket comme dégradé pendant 60 secondes et utilise SSE pendant la période de récupération
- Ajoute des en-têtes stables d’identité de session et de tour pour les nouvelles tentatives et les reconnexions
- Normalise les compteurs d’utilisation (
input_tokens/prompt_tokens) entre les variantes de transport
Mode rapide
Mode rapide
OpenClaw expose un commutateur de mode rapide partagé pour
openai/* :- Discussion/interface utilisateur :
/fast status|auto|on|off - Configuration :
agents.defaults.models["<provider>/<model>"].params.fastMode
service_tier = "priority"). Les valeurs service_tier existantes sont
conservées, et le mode rapide ne réécrit ni reasoning ni
text.verbosity. fastMode: "auto" lance rapidement les nouveaux appels au modèle jusqu’au
seuil automatique, puis lance les appels ultérieurs de nouvelle tentative, de solution de repli, de résultat
d’outil ou de continuation sans le mode rapide. Le seuil est de 60 secondes par défaut ;
définissez params.fastAutoOnSeconds sur le modèle actif pour le modifier.Les remplacements propres à la session sont prioritaires sur la configuration. La suppression du remplacement de session dans
l’interface Sessions rétablit la valeur par défaut configurée pour la session.
Traitement prioritaire (service_tier)
Traitement prioritaire (service_tier)
L’API d’OpenAI expose le traitement prioritaire via Valeurs prises en charge :
service_tier. Définissez-le pour chaque
modèle dans OpenClaw :auto, default, flex, priority.Compaction côté serveur (API Responses)
Compaction côté serveur (API Responses)
Pour les modèles Responses OpenAI directs (
openai/* sur api.openai.com), l’enveloppe
de flux OpenClaw du Plugin OpenAI active automatiquement la Compaction côté
serveur :- Force
store: true(sauf si la compatibilité du modèle définitsupportsStore: false) - Injecte
context_management: [{ type: "compaction", compact_threshold: ... }] - Valeur par défaut de
compact_threshold: 70 % decontextWindow(ou80000lorsque cette valeur n’est pas disponible)
- Activer explicitement
- Seuil personnalisé
- Désactiver
Utile pour les points de terminaison compatibles, comme Azure OpenAI Responses :
responsesServerCompaction contrôle uniquement l’injection de context_management.
Les modèles Responses OpenAI directs forcent toujours store: true, sauf si la compatibilité
définit supportsStore: false.Mode GPT strictement agentique
Mode GPT strictement agentique
Pour les modèles de la famille GPT-5 du fournisseur Définir explicitement
openai exécutés par l’intermédiaire de l’environnement
d’exécution intégré d’OpenClaw, OpenClaw utilise déjà par défaut un contrat d’exécution plus strict appelé
strict-agentic. Il s’active automatiquement chaque fois que le fournisseur résolu est
openai et que l’identifiant du modèle correspond à la famille GPT-5, sauf si la configuration
le désactive explicitement :"strict-agentic" est sans effet sur une voie prise en charge (il
s’agit déjà de la valeur par défaut) et reste inopérant pour les paires fournisseur/modèle non prises en charge.Lorsque strict-agentic est actif, OpenClaw :- Active automatiquement
update_planpour les travaux conséquents - Réessaie les tours structurellement vides ou contenant uniquement du raisonnement avec une continuation produisant une réponse visible
- Utilise des événements de plan explicites du harnais lorsque le harnais sélectionné les fournit
Ce contrat réside entièrement dans l’exécuteur d’agent intégré d’OpenClaw. Il ne
s’applique pas au harnais app-server natif de Codex, qui gère lui-même
le comportement des tours et des plans ; la sélection du harnais importe davantage que le
paramètre du contrat d’exécution pour les exécutions Codex natives.
Routes natives et compatibles avec OpenAI
Routes natives et compatibles avec OpenAI
OpenClaw traite les points de terminaison directs OpenAI, Codex et Azure OpenAI
différemment des proxys génériques
/v1 compatibles avec OpenAI :Routes natives (openai/*, Azure OpenAI) :- Conservent
reasoning: { effort: "none" }uniquement pour les modèles qui prennent en charge l’effort OpenAInone - Omettent le raisonnement désactivé pour les modèles ou proxys qui rejettent
reasoning.effort: "none" - Utilisent par défaut le mode strict pour les schémas d’outils
- Joignent des en-têtes d’attribution masqués uniquement sur les hôtes natifs vérifiés (Azure OpenAI ne reçoit pas ces en-têtes, même s’il s’agit d’une route native)
- Conservent la mise en forme des requêtes propre à OpenAI (
service_tier,store, compatibilité du raisonnement, indications de cache des prompts)
- Utilisent un comportement de compatibilité plus souple
- Suppriment le champ Completions
storedes charges utilesopenai-completionsnon natives - Acceptent le JSON avancé
params.extra_body/params.extraBodytransmis tel quel pour les proxys Completions compatibles avec OpenAI - Acceptent
params.chat_template_kwargspour les proxys Completions compatibles avec OpenAI tels que vLLM - N’imposent ni les schémas d’outils stricts ni les en-têtes réservés aux routes natives
Voir aussi
Sélection du modèle
Choix des fournisseurs, des références de modèles et du comportement de basculement.
Génération d'images
Paramètres partagés de l’outil d’image et sélection du fournisseur.
Génération de vidéos
Paramètres partagés de l’outil vidéo et sélection du fournisseur.
OAuth et authentification
Détails de l’authentification et règles de réutilisation des identifiants.