Skip to main content
OpenClaw verwendet eine Provider-ID, openai, sowohl für die direkte Authentifizierung per API-Schlüssel als auch für die ChatGPT/Codex-Abonnementauthentifizierung. openai/* ist die kanonische Modellroute. Bei eingebetteten Agent-Durchläufen, für die keine Laufzeitrichtlinie oder auto festgelegt ist, bestimmen die Routendaten von OpenAI, ob OpenClaw implizit die gebündelte Codex-App-Server-Laufzeit auswählen darf. Das Präfix openai/* allein wählt keine Laufzeit aus.
  • Agent-Modelleopenai/* über die durch die explizite agentRuntime-Konfiguration oder die implizite Routenrichtlinie von OpenAI ausgewählte Laufzeit. Melden Sie sich für die Nutzung eines ChatGPT/Codex-Abonnements mit der Codex-Authentifizierung an oder konfigurieren Sie ein Authentifizierungsprofil mit API-Schlüssel, wenn Sie eine schlüsselbasierte Abrechnung wünschen.
  • OpenAI-APIs ohne Agent – direkter Zugriff auf die OpenAI Platform mit nutzungsabhängiger Abrechnung über OPENAI_API_KEY oder ein openai-Authentifizierungsprofil mit API-Schlüssel.
  • Legacy-Konfiguration – Referenzen auf codex/* und openai-codex/* werden durch openclaw doctor --fix zu openai/* sowie dem modellspezifischen agentRuntime.id: "codex" repariert.
OpenAI unterstützt ausdrücklich die OAuth-Nutzung von Abonnements in externen Tools und Workflows wie OpenClaw.

Nutzungs- und Kostenverfolgung

OpenClaw behandelt Abonnementkontingente und die Abrechnung der Platform API getrennt:
  • ChatGPT/Codex OAuth zeigt den Abonnementtarif, die Kontingentzeiträume und das Guthaben an.
  • OPENAI_ADMIN_KEY zeigt in der Control UI unter Nutzung 30 Tage der vom Provider gemeldeten Organisationskosten und Completions-Nutzung an, einschließlich täglicher Ausgaben, Anfragen-/Token-Gesamtsummen, meistgenutzter Modelle und Kostenkategorien.
  • OPENAI_PROJECT_ID beschränkt den Verlauf der Admin API optional auf ein Projekt.
  • OpenClaw sendet niemals OPENAI_API_KEY oder ein openai-Inferenzprofil an Organisations-APIs; diese Anmeldedaten können zu benutzerdefinierten, Azure- oder agentenlokalen Endpunkten gehören.
Ein expliziter Admin-Schlüssel hat Vorrang vor OAuth. Der vom Provider gemeldete Verlauf wird nicht mit den aus OpenClaw-Sitzungen abgeleiteten geschätzten Kosten zusammengeführt; er kann API-Aktivitäten anderer Clients und anbieterseitige Abrechnungsanpassungen enthalten. Die Dokumentation zum API-Nutzungs-Dashboard von OpenAI beschreibt die Anforderungen hinsichtlich Organisationseigentümerschaft und expliziter Berechtigungen für das Usage Dashboard für den Zugriff auf Nutzungsdaten. Provider, Modell, Laufzeit und Kanal sind separate Ebenen. Wenn diese Bezeichnungen durcheinandergeraten, lesen Sie Agent-Laufzeiten, bevor Sie die Konfiguration ändern.

Schnellauswahl

Zuordnung der Bezeichnungen

Implizite Agent-Laufzeit

Wenn die Provider/Modell-Richtlinie agentRuntime nicht festgelegt oder auf auto gesetzt ist, wählt die providereigene Routenrichtlinie von OpenAI die implizite Laufzeit anhand des effektiven Endpunkts und Adapters aus: Eine explizite, vom Standard abweichende Provider/Modell-Einstellung agentRuntime.id bleibt maßgeblich. Beispielsweise hält agentRuntime.id: "openclaw" eine ansonsten für Codex geeignete Route auf OpenClaw, während agentRuntime.id: "codex" Codex voraussetzt und geschlossen fehlschlägt, wenn die effektive Route nicht als Codex-kompatibel deklariert ist. Die Laufzeitauswahl ändert weder den Anmeldedatentyp noch die Abrechnung: Die Authentifizierung per Platform-API-Schlüssel und die ChatGPT/Codex-Abonnementauthentifizierung bleiben getrennt. openclaw doctor --fix migriert Legacy-Modellreferenzen auf codex/* und openai-codex/*, Legacy-IDs von Codex-Authentifizierungsprofilen und Legacy-Einträge der Codex-Authentifizierungsreihenfolge zur kanonischen Route openai. Migrierte Modellreferenzen erhalten das modellspezifische agentRuntime.id: "codex"; verwenden Sie auth.order.openai für neue Konfigurationen der Authentifizierungsreihenfolge.
Bei einer neuen OpenAI-Einrichtung wird nur dann ein primäres GPT-5.6-Modell festgelegt, wenn kein primäres Modell konfiguriert ist. Das Hinzufügen oder Aktualisieren der OpenAI-Authentifizierung behält eine vorhandene explizite Auswahl einschließlich openai/gpt-5.5 bei, sofern Sie nicht ausdrücklich models auth login --set-default oder models set verwenden. Verwenden Sie ein Authentifizierungsprofil mit API-Schlüssel nur, wenn Sie für ein Agent-Modell eine Authentifizierung per API-Schlüssel wünschen.

Eingeschränkte Vorschau von GPT-5.6

OpenClaw erkennt die exakten Modell-IDs openai/gpt-5.6-sol, openai/gpt-5.6-terra und openai/gpt-5.6-luna. Alle drei bieten im aktuellen Katalog xhigh- und max-Reasoning. OpenAI beschreibt Sol als Flaggschiff-Stufe, Terra als ausgewogene Stufe und Luna als schnelle, kostengünstigere Stufe. Siehe die Ankündigung zur Einführung von GPT-5.6 und den Zugriffsleitfaden. Bei direkter OpenAI-Authentifizierung per API-Schlüssel ist die reine ID openai/gpt-5.6 ein Alias für Sol und der Standardwert bei einer neuen Einrichtung. Der native Codex-Katalog wendet diesen Direkt-API-Alias nicht clientseitig an; abhängig vom Workspace-Zugriff kann er die exakten Sol-, Terra- und Luna-IDs anzeigen. Eine neue ChatGPT/Codex-OAuth-Einrichtung verwendet daher openai/gpt-5.6-sol. Prüfen Sie das aktuelle Konto mit:
Der Zugriff der API-Organisation und des Codex-Workspace kann unterschiedlich sein. Wenn GPT-5.6 nicht verfügbar ist, wählen Sie GPT-5.5 explizit aus:
OpenClaw zeigt den vorgelagerten Zugriffsfehler an und ersetzt eine GPT-5.6-Auswahl nicht stillschweigend durch GPT-5.5.
Geeignete exakte offizielle HTTPS-Routen können das gebündelte Codex-App-Server-Plugin auswählen, wenn keine Laufzeitrichtlinie festgelegt oder diese auf auto gesetzt ist; explizit angegebene Completions-Routen, benutzerdefinierte Endpunkte und Überschreibungen des Anfragetransports verbleiben auf OpenClaw. Offizielle Klartext-HTTP-Endpunkte werden abgelehnt. Eine explizite Provider/Modell-Laufzeitkonfiguration bleibt maßgeblich. Führen Sie openclaw doctor --fix aus, um veraltete Legacy-Codex-Modellreferenzen, codex-cli/*-Referenzen oder alte Laufzeit-Sitzungsbindungen zu reparieren, die nicht durch eine explizite Laufzeitkonfiguration festgelegt wurden.

Funktionsumfang von OpenClaw

OpenAI-Echtzeit-Sprache läuft über die öffentliche OpenAI Platform Realtime API und erfordert einen Platform-API-Schlüssel. Codex-OAuth-Token authentifizieren stattdessen das ChatGPT-Codex-Backend; sie sind nicht mit Platform-API- Schlüsseln für die öffentlichen Realtime-Endpunkte austauschbar.Wenn die Authentifizierung per API-Schlüssel eine fehlende Abrechnung meldet, laden Sie unter platform.openai.com/account/billing Platform-Guthaben für die Organisation auf, der Ihre Echtzeit-Anmeldedaten zugeordnet sind. Echtzeit-Sprache akzeptiert das durch openclaw onboard --auth-choice openai-api-key erstellte API-Schlüssel-Authentifizierungsprofil openai, einen über talk.realtime.providers.openai.apiKey für Control UI Talk festgelegten Platform-API-Schlüssel oder plugins.entries.voice-call.config.realtime.providers.openai.apiKey für Voice Call oder die Umgebungsvariable OPENAI_API_KEY.In Control UI Video Talk empfängt OpenAI WebRTC den Kamerakontext bei Bedarf: Wenn das Modell describe_view aufruft, sendet der Browser ein begrenztes JPEG über den Echtzeit-Datenkanal. OpenClaw fügt der OpenAI-Sitzung keine kontinuierliche Kameraspur hinzu.

Speichereinbettungen

OpenClaw kann OpenAI oder einen OpenAI-kompatiblen Einbettungsendpunkt für die memory_search-Indizierung und Abfrageeinbettungen verwenden:
Legen Sie für OpenAI-kompatible Endpunkte, die asymmetrische Einbettungsbezeichnungen erfordern, queryInputType und documentInputType unter memory.search fest. OpenClaw leitet diese als providerspezifische input_type-Anfragefelder weiter: Abfrageeinbettungen verwenden queryInputType; indizierte Speicherabschnitte und die Batch-Indizierung verwenden documentInputType. Das vollständige Beispiel finden Sie in der Referenz zur Speicherkonfiguration.

Erste Schritte

Am besten geeignet für: direkten API-Zugriff und nutzungsbasierte Abrechnung.
1

API-Schlüssel abrufen

Erstellen oder kopieren Sie einen API-Schlüssel im OpenAI-Platform-Dashboard.
2

Onboarding ausführen

Oder übergeben Sie den Schlüssel direkt:
3

Verfügbarkeit des Modells überprüfen

Routenzusammenfassung

Wenn die Runtime nicht gesetzt ist oder auto verwendet wird, darf nur eine geeignete exakte offizielle native HTTPS-Route implizit den Codex-App-Server-Harness auswählen. Erstellen Sie für die Authentifizierung per API-Schlüssel bei einem Agent-Modell ein openai-API-Schlüssel-Authentifizierungsprofil und ordnen Sie es mit auth.order.openai; OPENAI_API_KEY bleibt der direkte Fallback für OpenAI-API-Oberflächen ohne Agent. Führen Sie openclaw doctor --fix aus, um ältere veraltete Codex-Einträge der Authentifizierungsreihenfolge zu migrieren.

Konfigurationsbeispiel

Die einfache direkte API-ID gpt-5.6 wird der Sol-Stufe zugeordnet. Falls diese API- Organisation GPT-5.6 nicht bereitstellt, legen Sie das primäre Modell explizit auf openai/gpt-5.5 fest.Um das aktuelle Instant-Modell von ChatGPT über die OpenAI API auszuprobieren, legen Sie das Modell auf openai/chat-latest fest:
chat-latest ist ein dynamischer Alias. Eine neue Einrichtung mit OpenAI-API-Schlüssel verwendet stattdessen openai/gpt-5.6, dessen einfache direkte API-ID der Sol-Stufe zugeordnet wird. Vorhandene explizite primäre Modelle, einschließlich openai/gpt-5.5, bleiben unverändert. Der Alias chat-latest akzeptiert nur die Textausführlichkeit medium; OpenClaw erzwingt für dieses Modell bei jeder anderen angeforderten Ausführlichkeit medium.
OpenClaw stellt gpt-5.3-codex-spark nicht über die direkte Route mit OpenAI- API-Schlüssel bereit. Es ist nur über Katalogeinträge des Codex-Abonnements verfügbar, wenn es für Ihr angemeldetes Konto freigeschaltet ist.

Authentifizierung des nativen Codex-App-Servers

Das native Codex-App-Server-Harness verwendet openai/*-Modellreferenzen, wenn eine geeignete exakte offizielle HTTPS-Route es implizit auswählt oder wenn Provider-/Modell- agentRuntime.id: "codex" es explizit auswählt. Seine Authentifizierung bleibt kontobasiert. OpenClaw wählt die Authentifizierung in dieser Reihenfolge aus:
  1. Geordnete OpenAI-Authentifizierungsprofile für den Agenten, vorzugsweise unter auth.order.openai. Führen Sie openclaw doctor --fix aus, um ältere veraltete Codex-Authentifizierungsprofil-IDs und die Authentifizierungsreihenfolge zu migrieren.
  2. Das bestehende Konto des App-Servers, etwa eine lokale ChatGPT- Anmeldung der Codex CLI. Für das standardmäßige isolierte Agent-Home bindet OpenClaw dieses native CLI-Konto über dessen Anmelde-RPC in den App-Server ein; die Konfiguration, Plugins und der Thread-Speicher der CLI werden nicht gemeinsam verwendet.
  3. Nur für lokale stdio-App-Server-Starts und nur, wenn der App-Server kein Konto meldet: CODEX_API_KEY, danach OPENAI_API_KEY.
Eine lokale Anmeldung mit einem ChatGPT-/Codex-Abonnement wird nicht allein deshalb ersetzt, weil der Gateway-Prozess außerdem OPENAI_API_KEY für direkte OpenAI-Modelle oder Einbettungen enthält. Die Ausweichoption über den API-Schlüssel aus der Umgebung gilt nur für den lokalen stdio-Pfad ohne Konto; sie wird niemals über WebSocket-App-Server-Verbindungen gesendet. Wenn ein abonnementartiges Codex-Profil ausgewählt ist, hält OpenClaw außerdem CODEX_API_KEY und OPENAI_API_KEY aus dem erzeugten stdio-App-Server-Unterprozess heraus und sendet die ausgewählten Anmeldedaten stattdessen über den Anmelde-RPC des App-Servers. Wenn dieses Abonnementprofil durch ein Codex-Nutzungslimit blockiert wird, markiert OpenClaw das Profil bis zur von Codex angegebenen Rücksetzzeit als blockiert und ermöglicht der Authentifizierungsreihenfolge, zum nächsten openai:*-Profil zu wechseln, ohne das ausgewählte Modell zu ändern oder das Codex-Harness zu verlassen. Nach Ablauf der Rücksetzzeit kann das Abonnementprofil wieder verwendet werden.

Bilderzeugung

Das gebündelte Plugin openai registriert die Bilderzeugung über das Werkzeug image_generate. Es unterstützt sowohl die Bilderzeugung mit OpenAI-API-Schlüssel als auch mit Codex-OAuth über dieselbe Modellreferenz openai/gpt-image-2.
Unter Bilderzeugung finden Sie gemeinsame Werkzeugparameter, die Provider-Auswahl und das Failover-Verhalten.
gpt-image-2 ist der Standard für die Text-zu-Bild-Erzeugung und Bildbearbeitung mit OpenAI. gpt-image-1.5, gpt-image-1 und gpt-image-1-mini können weiterhin als explizite Modellüberschreibungen verwendet werden. Verwenden Sie openai/gpt-image-1.5 für PNG-/WebP-Ausgaben mit transparentem Hintergrund; die aktuelle gpt-image-2-API lehnt background: "transparent" ab. Rufen Sie für eine Anfrage mit transparentem Hintergrund image_generate mit model: "openai/gpt-image-1.5", outputFormat: "png" oder "webp" sowie background: "transparent" auf; die ältere Provider-Option openai.background wird weiterhin akzeptiert. OpenClaw schützt außerdem die öffentlichen OpenAI- und OpenAI-Codex-OAuth- Routen, indem standardmäßige transparente openai/gpt-image-2-Anfragen in gpt-image-1.5 umgeschrieben werden; Azure- und benutzerdefinierte OpenAI-kompatible Endpunkte behalten ihre konfigurierten Bereitstellungs-/Modellnamen bei. Dieselbe Einstellung ist für Headless-CLI-Läufe verfügbar:
Verwenden Sie dieselben Flags --output-format und --background mit openclaw infer image edit, wenn Sie mit einer Eingabedatei beginnen. --openai-background bleibt als OpenAI-spezifischer Alias verfügbar. Verwenden Sie --quality low|medium|high|auto, um Qualität und Kosten von OpenAI Images zu steuern. Verwenden Sie --openai-moderation low|auto, um den Moderationshinweis von OpenAI entweder aus image generate oder image edit zu übergeben. Für ChatGPT-/Codex-OAuth-Installationen ist dieselbe openai/gpt-image-2-Referenz beizubehalten. Wenn ein openai-OAuth-Profil konfiguriert ist, löst OpenClaw das gespeicherte OAuth- Zugriffstoken auf und sendet Bildanfragen über das Codex-Responses-Backend; es versucht nicht zuerst OPENAI_API_KEY und greift auch nicht stillschweigend auf einen API-Schlüssel zurück. Konfigurieren Sie stattdessen models.providers.openai ausdrücklich mit einem API-Schlüssel, einer benutzerdefinierten Basis- URL oder einem Azure-Endpunkt, wenn Sie die direkte Route über die OpenAI Images API verwenden möchten. Wenn sich dieser benutzerdefinierte Bildendpunkt unter einer vertrauenswürdigen LAN-/privaten Adresse befindet, legen Sie außerdem browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true fest; OpenClaw blockiert private/interne OpenAI-kompatible Bildendpunkte, sofern diese explizite Zustimmung nicht vorliegt. Generieren:
Ein transparentes PNG generieren:
Bearbeiten:

Videogenerierung

Das gebündelte openai-Plugin registriert die Videogenerierung über das Werkzeug video_generate. OpenAI-Anfragen für Bild-zu-Video verwenden POST /v1/videos mit einem Bild- input_reference. Bearbeitungen eines einzelnen Videos verwenden POST /v1/videos/edits mit dem hochgeladenen Video im Feld video.
Unter Videogenerierung finden Sie Informationen zu gemeinsamen Werkzeugparametern, zur Provider-Auswahl und zum Failover-Verhalten.Der OpenAI-Provider deklariert supportsSize, jedoch nicht supportsAspectRatio oder supportsResolution. Die gemeinsame Normalisierungsschicht von OpenClaw wandelt ein angefordertes aspectRatio in die am besten passende OpenAI-size um, bevor die Anfrage den Provider erreicht, sodass Anfragen mit Seitenverhältnis im Allgemeinen weiterhin funktionieren. Für resolution gibt es keinen Größen-Fallback; der Wert wird verworfen und dem Aufrufer als Ignored unsupported overrides for openai/<model>: resolution=<value> gemeldet.

GPT-5-Prompt-Beitrag

OpenClaw fügt für Modelle der GPT-5-Familie beim Provider openai einen gemeinsamen GPT-5-Prompt-Beitrag hinzu (einschließlich älterer Codex-Referenzen vor der Reparatur, die zu openai/* normalisiert werden). Andere Provider, die ebenfalls Modell-IDs der GPT-5-Familie bereitstellen, wie OpenRouter- oder opencode-Routen, erhalten dieses Overlay nicht; die Einschränkung erfolgt anhand der Provider-ID openai, nicht allein anhand der Modell-ID. Ältere GPT-4.x-Modelle erhalten es nie. Der native Codex-App-Server-Harness erhält weder den Verhaltensvertrag für Persona/Werkzeug- disziplin noch das freundliche Overlay für den Interaktionsstil über Entwickleranweisungen; der native Codex behält das Codex-eigene Verhalten für Basis, Modell und Projektdokumentation bei, und OpenClaw deaktiviert die integrierte Persönlichkeit von Codex für native Threads, damit die Persönlichkeitsdateien des Agenten-Arbeitsbereichs maßgeblich bleiben. OpenClaw stellt nativen Codex-Threads ausschließlich Laufzeitkontext bereit: Kanal- zustellung, dynamische OpenClaw-Werkzeuge, ACP-Delegierung, Arbeitsbereichskontext und OpenClaw Skills. Der Heartbeat-Hinweistext aus demselben Beitrag ist die einzige Ausnahme: Native Codex-Heartbeat-Durchläufe erhalten ihn, wobei er als separate Anweisungen zur Zusammenarbeit und nicht über den gemeinsamen Hook für Prompt-Beiträge eingefügt wird. Der GPT-5-Beitrag fügt übereinstimmenden, von OpenClaw zusammengestellten Prompts einen markierten Verhaltensvertrag für die Beständigkeit der Persona, Ausführungssicherheit, Werkzeugdisziplin, Ausgabeform, Abschluss- prüfungen und Verifizierung hinzu. Kanalspezifisches Antwort- und Verhalten bei stillen Nachrichten verbleibt im gemeinsamen OpenClaw-System- Prompt und in der Richtlinie für ausgehende Zustellung. Die Ebene für den freundlichen Interaktionsstil ist separat und konfigurierbar.
Bei der Laufzeit wird die Groß-/Kleinschreibung der Werte nicht berücksichtigt, daher deaktivieren sowohl "Off" als auch "off" die Ebene für den freundlichen Stil.
Das ältere plugins.entries.openai.config.personality wird weiterhin als Kompatibilitäts-Fallback gelesen, wenn die gemeinsame Einstellung agents.defaults.promptOverlays.gpt5.personality nicht festgelegt ist.

Stimme und Sprache

Das gebündelte openai-Plugin registriert die Sprachsynthese für die tts-Oberfläche.Verfügbare Modelle: gpt-4o-mini-tts, tts-1, tts-1-hd. Verfügbare Stimmen: alloy, ash, ballad, cedar, coral, echo, fable, juniper, marin, onyx, nova, sage, shimmer, verse.extraBody wird nach den von OpenClaw generierten Feldern mit dem JSON der /audio/speech-Anfrage zusammengeführt. Verwenden Sie es daher für OpenAI-kompatible Endpunkte, die zusätzliche Schlüssel wie lang benötigen. Prototypschlüssel werden ignoriert.
Legen Sie OPENAI_TTS_BASE_URL fest, um die TTS-Basis-URL zu überschreiben, ohne den Endpunkt der Chat-API zu beeinflussen. OpenAI TTS und Realtime Voice werden beide über einen API-Schlüssel der OpenAI Platform konfiguriert; reine OAuth-Installationen können weiterhin Codex-gestützte Chatmodelle verwenden, jedoch keine Live-Sprachantworten von OpenAI.
Das gebündelte openai-Plugin registriert die Batch-Sprache-zu-Text-Verarbeitung über die Transkriptionsoberfläche für das Medienverständnis von OpenClaw.
  • Standardmodell: gpt-4o-transcribe
  • Endpunkt: OpenAI REST /v1/audio/transcriptions
  • Eingabepfad: mehrteiliger Audiodatei-Upload
  • Wird überall verwendet, wo die Transkription eingehender Audiodaten tools.media.audio liest, einschließlich Segmenten aus Discord-Sprachkanälen und Audioanhängen von Kanälen
So erzwingen Sie OpenAI für die Transkription eingehender Audiodaten:
Sprach- und Prompt-Hinweise werden an OpenAI weitergeleitet, wenn sie durch die gemeinsame Audiomedienkonfiguration oder eine Transkriptionsanfrage pro Aufruf bereitgestellt werden.
Das gebündelte openai-Plugin registriert die Echtzeittranskription für das Voice-Call-Plugin.
Verwendet eine WebSocket-Verbindung zu wss://api.openai.com/v1/realtime mit G.711-μ-law-Audio (g711_ulaw / audio/pcmu). Bei einem openai-API-Schlüsselprofil erstellt der Gateway vor dem Öffnen des WebSockets ein kurzlebiges Client- Secret für die Realtime-Transkription. Dieser Streaming-Provider ist für den Echtzeittranskriptionspfad von Voice Call vorgesehen; Discord Voice zeichnet derzeit kurze Segmente auf und verwendet stattdessen den Batch-Transkriptionspfad tools.media.audio.
Das gebündelte openai-Plugin registriert Echtzeitstimme für das Voice-Call- Plugin.Verfügbare integrierte Realtime-Stimmen für gpt-realtime-2.1: alloy, ash, ballad, coral, echo, sage, shimmer, verse, marin, cedar. OpenAI empfiehlt marin und cedar für die beste Realtime-Qualität. Dies ist ein separater Satz gegenüber den obigen Text-to-Speech-Stimmen; eine reine TTS-Stimme wie fable, nova oder onyx ist für Realtime-Sitzungen nicht gültig. Setzen Sie das Modell explizit auf gpt-realtime-2.1-mini, wenn Sie die kleinere, kostengünstigere Realtime-2.1-Variante bevorzugen.
GPT-Live (demnächst verfügbar). Die Vollduplexmodelle gpt-live-1 und gpt-live-1-mini von OpenAI ersetzten im Juli 2026 den ChatGPT-Sprachmodus; die Entwickler-API wird schrittweise für Organisationen mit frühem Zugriff eingeführt. OpenClaw erkennt die Modellfamilie, führt sie aber noch nicht aus: GPT-Live-Sitzungen sind ausschließlich WebRTC-basiert, steuern ihren Sprecherwechsel selbst (kein VAD) und delegieren Agentenarbeit über ein Übergabeereignisprotokoll, das die Realtime-Transporte von OpenClaw noch nicht implementieren. Die Konfiguration eines gpt-live-*-Modells wird sicher abgelehnt und gibt Hinweise sowohl zur WebSocket-Bridge als auch zu Talk-Browsersitzungen, anstatt Audio ohne Agentenzugriff unbemerkt zu verbinden. Der API-Zugriff ist während des frühen Zugriffs außerdem pro OpenAI-Organisation beschränkt. Behalten Sie gpt-realtime-2.1 (den Standard) bei, bis die GPT-Live-Unterstützung verfügbar ist.
Serverseitige OpenAI-Realtime-Bridges verwenden die GA-Realtime-WebSocket-Sitzungsstruktur, die session.temperature nicht akzeptiert. Azure-OpenAI- Bereitstellungen bleiben über azureEndpoint und azureDeployment verfügbar und behalten die bereitstellungskompatible Sitzungsstruktur (einschließlich temperature) bei. Unterstützt bidirektionale Tool-Aufrufe und G.711-µ-Law-Audio.
Die Realtime-Stimme wird beim Erstellen der Sitzung ausgewählt. OpenAI erlaubt es, die meisten Sitzungsfelder später zu ändern, die Stimme kann jedoch nicht mehr geändert werden, nachdem das Modell in dieser Sitzung Audio ausgegeben hat. OpenClaw stellt derzeit die IDs der integrierten Realtime-Stimmen als Zeichenfolgen bereit.
Control UI Talk verwendet OpenAI-Realtime-Browsersitzungen mit einem vom Gateway ausgestellten kurzlebigen Client-Secret und einem direkten WebRTC-SDP-Austausch des Browsers mit der OpenAI Realtime API. Das Gateway stellt dieses Client-Secret mit den ausgewählten openai-Anmeldedaten aus. Konfigurierte Schlüssel, API-Schlüsselprofile und OPENAI_API_KEY haben Vorrang; ein openai-OAuth-Profil oder eine externe Codex-Anmeldung dient als Fallback. Gateway-Relay und serverseitige Realtime- WebSocket-Bridges für Sprachanrufe verwenden dieselbe Reihenfolge der Anmeldedaten für native OpenAI-Endpunkte. Eine Live-Verifizierung für Maintainer ist verfügbar mit OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts; die OpenAI-Abschnitte verifizieren sowohl die serverseitige WebSocket-Bridge als auch den WebRTC-SDP-Austausch des Browsers, ohne Secrets zu protokollieren. Übergeben Sie --openai-only, um diese beiden Abschnitte ohne Google-Anmeldedaten auszuführen.

Azure-OpenAI-Endpunkte

Der gebündelte Provider openai kann für die Bildgenerierung eine Azure-OpenAI-Ressource verwenden, indem die Basis-URL überschrieben wird. Im Bildgenerierungspfad erkennt OpenClaw Azure-Hostnamen in models.providers.openai.baseUrl und wechselt automatisch zur Azure-Anfragestruktur.
Realtime-Sprache verwendet einen separaten Konfigurationspfad (plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint) und wird von models.providers.openai.baseUrl nicht beeinflusst. Die zugehörigen Azure- Einstellungen finden Sie im Akkordeon Realtime-Sprache unter Sprache und Sprachausgabe.
Verwenden Sie Azure OpenAI, wenn:
  • Sie bereits über ein Azure-OpenAI-Abonnement, ein Kontingent oder eine Unternehmensvereinbarung verfügen
  • Sie regionale Datenresidenz oder von Azure bereitgestellte Compliance-Kontrollen benötigen
  • Sie den Datenverkehr innerhalb eines bestehenden Azure-Mandanten halten möchten

Konfiguration

Richten Sie für die Azure-Bildgenerierung über den gebündelten Provider openai models.providers.openai.baseUrl auf Ihre Azure-Ressource und setzen Sie apiKey auf den Azure-OpenAI-Schlüssel (nicht auf einen OpenAI-Platform-Schlüssel):
OpenClaw erkennt diese Azure-Hostsuffixe für die Azure-Bildgenerierungsroute:
  • *.openai.azure.com
  • *.services.ai.azure.com
  • *.cognitiveservices.azure.com
Bei Bildgenerierungsanfragen an einen erkannten Azure-Host führt OpenClaw Folgendes aus:
  • Sendet den Header api-key anstelle von Authorization: Bearer
  • Verwendet bereitstellungsbezogene Pfade (/openai/deployments/{deployment}/...)
  • Hängt ?api-version=... an jede Anfrage an
  • Verwendet für Azure-Bildgenerierungsaufrufe ein standardmäßiges Anfrage-Timeout von 600s. Aufrufspezifische timeoutMs-Werte überschreiben diesen Standard weiterhin.
Andere Basis-URLs (öffentliches OpenAI, OpenAI-kompatible Proxys) verwenden weiterhin die standardmäßige OpenAI-Bildanfragestruktur.
Das Azure-Routing für den Bildgenerierungspfad des Providers openai erfordert OpenClaw 2026.4.22 oder höher. Frühere Versionen behandeln jede benutzerdefinierte openai.baseUrl wie den öffentlichen OpenAI-Endpunkt und schlagen bei Azure-Bildbereitstellungen fehl.

API-Version

Setzen Sie AZURE_OPENAI_API_VERSION, um eine bestimmte Azure-Vorschau- oder GA-Version für den Azure-Bildgenerierungspfad festzulegen:
Wenn die Variable nicht gesetzt ist, lautet der Standard 2024-12-01-preview.

Modellnamen sind Bereitstellungsnamen

Azure OpenAI bindet Modelle an Bereitstellungen. Bei Azure-Bildgenerierungsanfragen, die über den gebündelten Provider openai geroutet werden, muss das Feld model in OpenClaw dem Azure-Bereitstellungsnamen entsprechen, den Sie im Azure-Portal konfiguriert haben, und nicht der öffentlichen OpenAI-Modell-ID. Wenn Sie eine Bereitstellung namens gpt-image-2-prod erstellen, die gpt-image-2 bereitstellt:
Dieselbe Regel für Bereitstellungsnamen gilt für jeden Bildgenerierungsaufruf, der über den gebündelten Provider openai geroutet wird.

Regionale Verfügbarkeit

Die Azure-Bildgenerierung ist derzeit nur in einer Teilmenge der Regionen verfügbar (beispielsweise eastus2, swedencentral, polandcentral, westus3, uaenorth). Prüfen Sie vor dem Erstellen einer Bereitstellung die aktuelle Regionsliste von Microsoft und stellen Sie sicher, dass das jeweilige Modell in Ihrer Region angeboten wird.

Parameterunterschiede

Azure OpenAI und das öffentliche OpenAI akzeptieren nicht immer dieselben Bildparameter. Azure lehnt möglicherweise Optionen ab, die das öffentliche OpenAI zulässt (beispielsweise bestimmte background-Werte für gpt-image-2), oder stellt sie nur für bestimmte Modellversionen bereit. Diese Unterschiede stammen von Azure und dem zugrunde liegenden Modell, nicht von OpenClaw. Wenn eine Azure-Anfrage mit einem Validierungsfehler fehlschlägt, prüfen Sie im Azure-Portal den Parametersatz, der von Ihrer konkreten Bereitstellung und API-Version unterstützt wird.
Azure OpenAI verwendet nativen Transport und Kompatibilitätsverhalten, erhält jedoch nicht die verborgenen Attributions-Header von OpenClaw – siehe das Akkordeon Native und OpenAI-kompatible Routen unter Erweiterte Konfiguration.Verwenden Sie für Chat- oder Responses-Datenverkehr auf Azure (über die Bildgenerierung hinaus) den Onboarding-Ablauf oder eine dedizierte Azure-Provider-Konfiguration; openai.baseUrl allein übernimmt nicht die Azure-API-/Authentifizierungsstruktur. Es gibt einen separaten Provider azure-openai-responses/*; siehe das Akkordeon zur serverseitigen Compaction weiter unten.

Erweiterte Konfiguration

Die folgenden modellspezifischen params-Beispiele gestalten die eingebettete Provider-Anfrage von OpenClaw. Ihre Konfiguration gilt als bewusst festgelegtes Anfrageverhalten, sodass eine ansonsten geeignete auto-Route bei OpenClaw verbleibt, anstatt Codex implizit auszuwählen. Das native Codex-App-Server-Harness verwaltet seinen eigenen Transport und seine eigenen Anfrageeinstellungen; ein explizites agentRuntime.id: "codex" wird sicher abgelehnt, wenn die effektive Route nicht als Codex-kompatibel deklariert ist.
OpenClaw verwendet für openai/* bevorzugt WebSocket mit SSE-Fallback ("auto").Im Modus "auto" führt OpenClaw Folgendes aus:
  • Wiederholt einen frühen WebSocket-Fehler einmal, bevor auf SSE zurückgegriffen wird
  • Markiert WebSocket nach einem Fehler für 60 Sekunden als beeinträchtigt und verwendet während der Abkühlphase SSE
  • Fügt stabile Sitzungs- und Durchgangsidentitäts-Header für Wiederholungsversuche und Neuverbindungen hinzu
  • Normalisiert Nutzungszähler (input_tokens / prompt_tokens) über Transportvarianten hinweg
Zugehörige OpenAI-Dokumentation:
OpenClaw stellt einen gemeinsamen Schnellmodus-Schalter für openai/* bereit:
  • Chat/Oberfläche: /fast status|auto|on|off
  • Konfiguration: agents.defaults.models["<provider>/<model>"].params.fastMode
Wenn aktiviert, ordnet OpenClaw den Schnellmodus der priorisierten OpenAI-Verarbeitung (service_tier = "priority") zu. Bestehende service_tier-Werte bleiben erhalten, und der Schnellmodus schreibt reasoning oder text.verbosity nicht um. fastMode: "auto" startet neue Modellaufrufe bis zum automatischen Grenzwert im Schnellmodus und startet spätere Wiederholungs-, Fallback-, Tool-Ergebnis- oder Fortsetzungsaufrufe danach ohne Schnellmodus. Der Grenzwert beträgt standardmäßig 60 Sekunden; setzen Sie params.fastAutoOnSeconds für das aktive Modell, um ihn zu ändern.
Sitzungsüberschreibungen haben Vorrang vor der Konfiguration. Wenn die Sitzungsüberschreibung in der Sitzungsoberfläche gelöscht wird, verwendet die Sitzung wieder den konfigurierten Standard.
Die API von OpenAI stellt die Prioritätsverarbeitung über service_tier bereit. Legen Sie sie pro Modell in OpenClaw fest:
Unterstützte Werte: auto, default, flex, priority.
serviceTier wird nur an native OpenAI-Endpunkte (api.openai.com) und native Codex-Endpunkte (chatgpt.com/backend-api) weitergeleitet. Wenn Sie einen der beiden Provider über einen Proxy leiten, lässt OpenClaw service_tier unverändert.
Für direkte OpenAI-Responses-Modelle (openai/* auf api.openai.com) aktiviert der OpenClaw-Stream-Wrapper des OpenAI-Plugins automatisch die serverseitige Compaction:
  • Erzwingt store: true (sofern die Modellkompatibilität nicht supportsStore: false festlegt)
  • Fügt context_management: [{ type: "compaction", compact_threshold: ... }] ein
  • Standardwert für compact_threshold: 70 % von contextWindow (oder 80000, wenn nicht verfügbar)
Dies gilt für den integrierten OpenClaw-Laufzeitpfad und für Hooks des OpenAI-Providers, die von eingebetteten Ausführungen verwendet werden. Das native Codex-App-Server-Harness verwaltet seinen eigenen Kontext über Codex und ist von dieser Einstellung nicht betroffen.
Nützlich für kompatible Endpunkte wie Azure OpenAI Responses:
responsesServerCompaction steuert nur das Einfügen von context_management. Direkte OpenAI-Responses-Modelle erzwingen weiterhin store: true, sofern die Kompatibilität nicht supportsStore: false festlegt.
Bei GPT-5-Familienmodellen des Providers openai, die über die eingebettete Laufzeit von OpenClaw ausgeführt werden, verwendet OpenClaw bereits standardmäßig einen strengeren Ausführungsvertrag namens strict-agentic. Er wird automatisch aktiviert, wenn der aufgelöste Provider openai ist und die Modell-ID der GPT-5-Familie entspricht, sofern die Konfiguration ihn nicht ausdrücklich deaktiviert:
Das explizite Festlegen von "strict-agentic" hat auf einem unterstützten Pfad keine Wirkung (es ist bereits der Standard) und ist bei nicht unterstützten Provider-Modell-Paaren wirkungslos.Wenn strict-agentic aktiv ist, führt OpenClaw Folgendes aus:
  • Aktiviert für umfangreiche Aufgaben automatisch update_plan
  • Wiederholt strukturell leere oder ausschließlich aus Schlussfolgerungen bestehende Durchläufe mit einer Fortsetzung, die eine sichtbare Antwort erzeugt
  • Verwendet explizite Planereignisse des Harnesses, wenn das ausgewählte Harness diese bereitstellt
OpenClaw klassifiziert den Text des Assistenten nicht, um zu entscheiden, ob es sich bei einem Durchlauf um einen Plan, eine Fortschrittsmeldung oder eine endgültige Antwort handelt.
Dieser Vertrag befindet sich vollständig im eingebetteten Agent-Runner von OpenClaw. Er gilt nicht für das native Codex-App-Server-Harness, das sein eigenes Durchlauf- und Planverhalten verwaltet; bei nativen Codex-Ausführungen ist die Auswahl des Harnesses wichtiger als die Einstellung des Ausführungsvertrags.
OpenClaw behandelt direkte Endpunkte von OpenAI, Codex und Azure OpenAI anders als generische OpenAI-kompatible /v1-Proxys:Native Routen (openai/*, Azure OpenAI):
  • Behält reasoning: { effort: "none" } nur für Modelle bei, die den OpenAI-Aufwand none unterstützen
  • Lässt deaktiviertes Reasoning bei Modellen oder Proxys weg, die reasoning.effort: "none" ablehnen
  • Verwendet für Tool-Schemas standardmäßig den strikten Modus
  • Fügt verborgene Zuordnungs-Header nur bei verifizierten nativen Hosts hinzu (Azure OpenAI erhält diese Header nicht, obwohl es sich um eine native Route handelt)
  • Behält die ausschließlich für OpenAI geltende Anfrageformung bei (service_tier, store, Reasoning-Kompatibilität, Hinweise zum Prompt-Cache)
Proxy-/kompatible Routen:
  • Verwenden ein weniger striktes Kompatibilitätsverhalten
  • Entfernen bei nicht nativen openai-completions-Payloads store aus Completions
  • Akzeptieren die Durchleitung von erweitertem params.extra_body-/params.extraBody-JSON für OpenAI-kompatible Completions-Proxys
  • Akzeptieren params.chat_template_kwargs für OpenAI-kompatible Completions- Proxys wie vLLM
  • Erzwingen weder strikte Tool-Schemas noch ausschließlich nativen Routen vorbehaltene Header

Verwandte Themen

Modellauswahl

Auswahl von Providern, Modellreferenzen und Failover-Verhalten.

Bilderzeugung

Gemeinsame Parameter für Bild-Tools und Auswahl des Providers.

Videoerzeugung

Gemeinsame Parameter für Video-Tools und Auswahl des Providers.

OAuth und Authentifizierung

Details zur Authentifizierung und Regeln für die Wiederverwendung von Anmeldedaten.