chore(i18n): refresh de translations
This commit is contained in:
parent
88fce75d78
commit
548caaa1bb
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Sie benötigen eine anbieterweise Referenz für die Modelleinrichtung.
|
||||
- Sie möchten Beispielkonfigurationen oder CLI-Onboarding-Befehle für Modellanbieter.
|
||||
summary: Übersicht der Modellanbieter mit Beispielkonfigurationen + CLI-Abläufen
|
||||
- Sie benötigen eine anbieterweise Referenz für die Modelleinrichtung
|
||||
- Sie möchten Beispielkonfigurationen oder CLI-Onboarding-Befehle für Modellanbieter
|
||||
summary: Übersicht über Modellanbieter mit Beispielkonfigurationen + CLI-Abläufen
|
||||
title: Modellanbieter
|
||||
x-i18n:
|
||||
generated_at: "2026-04-11T02:44:17Z"
|
||||
generated_at: "2026-04-13T08:50:43Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 910ea7895e74c03910757d9d3e02825754b779b204eca7275b28422647ed0151
|
||||
source_hash: 66ba688c4b4366eec07667571e835d4cfeee684896e2ffae11d601b5fa0a4b98
|
||||
source_path: concepts/model-providers.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -18,23 +18,24 @@ x-i18n:
|
||||
Diese Seite behandelt **LLM-/Modellanbieter** (nicht Chat-Kanäle wie WhatsApp/Telegram).
|
||||
Regeln zur Modellauswahl finden Sie unter [/concepts/models](/de/concepts/models).
|
||||
|
||||
## Schnelle Regeln
|
||||
## Schnellregeln
|
||||
|
||||
- Modell-Referenzen verwenden `provider/model` (Beispiel: `opencode/claude-opus-4-6`).
|
||||
- Wenn Sie `agents.defaults.models` festlegen, wird daraus die Allowlist.
|
||||
- CLI-Helfer: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
|
||||
- Fallback-Laufzeitregeln, Cooldown-Sondierungen und Sitzungsüberschreibungs-Persistenz sind in [/concepts/model-failover](/de/concepts/model-failover) dokumentiert.
|
||||
- Wenn Sie `agents.defaults.models` festlegen, wird es zur Allowlist.
|
||||
- CLI-Hilfen: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
|
||||
- Fallback-Laufzeitregeln, Cooldown-Sonden und die Persistenz von Sitzungsüberschreibungen
|
||||
sind in [/concepts/model-failover](/de/concepts/model-failover) dokumentiert.
|
||||
- `models.providers.*.models[].contextWindow` sind native Modellmetadaten;
|
||||
`models.providers.*.models[].contextTokens` ist die effektive Laufzeitobergrenze.
|
||||
- Anbieter-Plugins können Modellkataloge über `registerProvider({ catalog })` einfügen;
|
||||
OpenClaw führt diese Ausgabe in `models.providers` zusammen, bevor
|
||||
`models.json` geschrieben wird.
|
||||
- Anbieter-Plugins können Modellkataloge über `registerProvider({ catalog })` einspeisen;
|
||||
OpenClaw führt diese Ausgabe vor dem Schreiben von
|
||||
`models.json` in `models.providers` zusammen.
|
||||
- Anbieter-Manifeste können `providerAuthEnvVars` und
|
||||
`providerAuthAliases` deklarieren, damit generische umgebungsvariablenbasierte Auth-Sondierungen und Anbietervarianten
|
||||
die Plugin-Laufzeit nicht laden müssen. Die verbleibende Core-Zuordnung von Umgebungsvariablen dient jetzt
|
||||
nur noch Nicht-Plugin-/Core-Anbietern und einigen generischen Vorrangfällen wie
|
||||
Anthropic-Onboarding mit API-Schlüssel zuerst.
|
||||
- Anbieter-Plugins können auch das Laufzeitverhalten des Anbieters besitzen über
|
||||
`providerAuthAliases` deklarieren, damit generische umgebungsvariablenbasierte Authentifizierungsprüfungen und Anbietervarianten
|
||||
keine Plugin-Laufzeit laden müssen. Die verbleibende zentrale Env-Var-Zuordnung ist jetzt
|
||||
nur noch für Nicht-Plugin-/Kernanbieter und einige generische Präzedenzfälle gedacht, wie
|
||||
etwa Anthropic-Onboarding mit API-Schlüssel zuerst.
|
||||
- Anbieter-Plugins können außerdem das Laufzeitverhalten des Anbieters übernehmen über
|
||||
`normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
|
||||
`applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
|
||||
`resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`,
|
||||
@ -50,179 +51,182 @@ Regeln zur Modellauswahl finden Sie unter [/concepts/models](/de/concepts/models
|
||||
`isCacheTtlEligible`, `buildMissingAuthMessage`, `suppressBuiltInModel`,
|
||||
`augmentModelCatalog`, `isBinaryThinking`, `supportsXHighThinking`,
|
||||
`resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
|
||||
`prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, und
|
||||
`prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot` und
|
||||
`onModelSelected`.
|
||||
- Hinweis: Laufzeit-`capabilities` des Anbieters sind gemeinsame Runner-Metadaten (Anbieterfamilie, Eigenheiten bei Transkripten/Tools, Transport-/Cache-Hinweise). Sie sind nicht dasselbe wie das [öffentliche Fähigkeitsmodell](/de/plugins/architecture#public-capability-model),
|
||||
- Hinweis: Laufzeit-`capabilities` des Anbieters sind Metadaten des gemeinsamen Runners (Anbieterfamilie, Besonderheiten bei Transkripten/Tools, Transport-/Cache-Hinweise). Sie sind nicht
|
||||
dasselbe wie das [öffentliche Fähigkeitsmodell](/de/plugins/architecture#public-capability-model),
|
||||
das beschreibt, was ein Plugin registriert (Textinferenz, Sprache usw.).
|
||||
- Der gebündelte `codex`-Anbieter ist mit dem gebündelten Codex-Agent-Harness gekoppelt.
|
||||
Verwenden Sie `codex/gpt-*`, wenn Sie Codex-eigenes Login, Modellerkennung, native
|
||||
Thread-Fortsetzung und App-Server-Ausführung möchten. Normale `openai/gpt-*`-Referenzen verwenden weiterhin
|
||||
Verwenden Sie `codex/gpt-*`, wenn Sie von Codex verwalteten Login, Modellerkennung, natives
|
||||
Fortsetzen von Threads und Ausführung auf dem App-Server möchten. Normale `openai/gpt-*`-Referenzen verwenden weiterhin
|
||||
den OpenAI-Anbieter und den normalen OpenClaw-Anbietertransport.
|
||||
Reine Codex-Bereitstellungen können den automatischen PI-Fallback deaktivieren mit
|
||||
`agents.defaults.embeddedHarness.fallback: "none"`; siehe
|
||||
Reine Codex-Bereitstellungen können den automatischen PI-Fallback mit
|
||||
`agents.defaults.embeddedHarness.fallback: "none"` deaktivieren; siehe
|
||||
[Codex Harness](/de/plugins/codex-harness).
|
||||
|
||||
## Plugin-eigenes Anbieterverhalten
|
||||
|
||||
Anbieter-Plugins können jetzt den Großteil der anbieterspezifischen Logik besitzen, während OpenClaw
|
||||
Anbieter-Plugins können jetzt den Großteil der anbieterspezifischen Logik übernehmen, während OpenClaw
|
||||
die generische Inferenzschleife beibehält.
|
||||
|
||||
Typische Aufteilung:
|
||||
|
||||
- `auth[].run` / `auth[].runNonInteractive`: Anbieter besitzt Onboarding-/Login-Abläufe
|
||||
für `openclaw onboard`, `openclaw models auth` und die Headless-Einrichtung
|
||||
- `wizard.setup` / `wizard.modelPicker`: Anbieter besitzt Beschriftungen für Auth-Auswahlen,
|
||||
Legacy-Aliasse, Hinweise zur Onboarding-Allowlist und Einrichtungseinträge in Onboarding-/Modellauswahlen
|
||||
- `catalog`: Anbieter erscheint in `models.providers`
|
||||
- `normalizeModelId`: Anbieter normalisiert Legacy-/Vorschau-Modell-IDs vor
|
||||
- `auth[].run` / `auth[].runNonInteractive`: Der Anbieter übernimmt Onboarding-/Login-Abläufe
|
||||
für `openclaw onboard`, `openclaw models auth` und Headless-Setup
|
||||
- `wizard.setup` / `wizard.modelPicker`: Der Anbieter übernimmt Labels für Authentifizierungsoptionen,
|
||||
veraltete Aliasse, Hinweise für Onboarding-Allowlists und Setup-Einträge in Onboarding-/Modellauswahlen
|
||||
- `catalog`: Der Anbieter erscheint in `models.providers`
|
||||
- `normalizeModelId`: Der Anbieter normalisiert veraltete/Vorschau-Modell-IDs vor
|
||||
Lookup oder Kanonisierung
|
||||
- `normalizeTransport`: Anbieter normalisiert `api` / `baseUrl` der Transportfamilie
|
||||
vor dem generischen Modellaufbau; OpenClaw prüft zuerst den passenden Anbieter,
|
||||
- `normalizeTransport`: Der Anbieter normalisiert `api` / `baseUrl` der Transportfamilie
|
||||
vor der generischen Modellzusammenstellung; OpenClaw prüft zuerst den passenden Anbieter,
|
||||
dann andere Hook-fähige Anbieter-Plugins, bis eines den
|
||||
Transport tatsächlich ändert
|
||||
- `normalizeConfig`: Anbieter normalisiert die Konfiguration `models.providers.<id>` vor
|
||||
der Nutzung durch die Laufzeit; OpenClaw prüft zuerst den passenden Anbieter, dann andere
|
||||
- `normalizeConfig`: Der Anbieter normalisiert die Konfiguration `models.providers.<id>` vor
|
||||
der Nutzung zur Laufzeit; OpenClaw prüft zuerst den passenden Anbieter, dann andere
|
||||
Hook-fähige Anbieter-Plugins, bis eines die Konfiguration tatsächlich ändert. Wenn kein
|
||||
Anbieter-Hook die Konfiguration umschreibt, normalisieren gebündelte Helfer der Google-Familie weiterhin
|
||||
unterstützte Google-Anbietereinträge.
|
||||
- `applyNativeStreamingUsageCompat`: Anbieter wendet endpointgesteuerte native Streaming-Nutzungs-Kompatibilitäts-Umschreibungen für Konfigurationsanbieter an
|
||||
- `resolveConfigApiKey`: Anbieter löst env-marker-Authentifizierung für Konfigurationsanbieter auf,
|
||||
ohne das vollständige Laden der Laufzeit-Authentifizierung zu erzwingen. `amazon-bedrock` hat hier auch einen
|
||||
integrierten AWS-env-marker-Resolver, obwohl die Bedrock-Laufzeit-Authentifizierung
|
||||
die Standardkette des AWS SDK verwendet.
|
||||
- `resolveSyntheticAuth`: Anbieter kann lokale/selbstgehostete oder andere
|
||||
konfigurationsgestützte Authentifizierungsverfügbarkeit offenlegen, ohne Klartextgeheimnisse zu speichern
|
||||
- `shouldDeferSyntheticProfileAuth`: Anbieter kann gespeicherte synthetische Profil-
|
||||
Platzhalter als niedriger priorisiert als env-/konfigurationsgestützte Authentifizierung kennzeichnen
|
||||
- `resolveDynamicModel`: Anbieter akzeptiert Modell-IDs, die noch nicht im lokalen
|
||||
- `applyNativeStreamingUsageCompat`: Der Anbieter wendet endpointgesteuerte Kompatibilitäts-Umschreibungen für native Streaming-Nutzung auf Konfigurationsanbieter an
|
||||
- `resolveConfigApiKey`: Der Anbieter löst Env-Marker-Authentifizierung für Konfigurationsanbieter auf,
|
||||
ohne das vollständige Laden der Laufzeit-Authentifizierung zu erzwingen. `amazon-bedrock` hat hier außerdem einen
|
||||
eingebauten AWS-Env-Marker-Resolver, obwohl die Bedrock-Laufzeit-Authentifizierung
|
||||
die AWS-SDK-Standardkette verwendet.
|
||||
- `resolveSyntheticAuth`: Der Anbieter kann lokale/selbstgehostete oder andere
|
||||
konfigurationsgestützte Verfügbarkeit von Authentifizierung bereitstellen, ohne Klartext-Geheimnisse zu persistieren
|
||||
- `shouldDeferSyntheticProfileAuth`: Der Anbieter kann gespeicherte synthetische Profil-
|
||||
Platzhalter als geringere Priorität als env-/konfigurationsgestützte Authentifizierung markieren
|
||||
- `resolveDynamicModel`: Der Anbieter akzeptiert Modell-IDs, die noch nicht im lokalen
|
||||
statischen Katalog vorhanden sind
|
||||
- `prepareDynamicModel`: Anbieter benötigt vor einem erneuten Versuch der
|
||||
dynamischen Auflösung eine Metadatenaktualisierung
|
||||
- `normalizeResolvedModel`: Anbieter benötigt Umschreibungen von Transport oder Basis-URL
|
||||
- `contributeResolvedModelCompat`: Anbieter trägt Kompatibilitätskennzeichen für seine
|
||||
Herstellermodelle bei, selbst wenn sie über einen anderen kompatiblen Transport ankommen
|
||||
- `capabilities`: Anbieter veröffentlicht Eigenheiten bei Transkripten/Tools/Anbieterfamilien
|
||||
- `normalizeToolSchemas`: Anbieter bereinigt Toolschemata, bevor der eingebettete
|
||||
- `prepareDynamicModel`: Der Anbieter benötigt eine Aktualisierung der Metadaten, bevor die dynamische
|
||||
Auflösung erneut versucht wird
|
||||
- `normalizeResolvedModel`: Der Anbieter benötigt Umschreibungen für Transport oder Basis-URL
|
||||
- `contributeResolvedModelCompat`: Der Anbieter steuert Kompatibilitäts-Flags für seine
|
||||
Herstellermodelle bei, auch wenn sie über einen anderen kompatiblen Transport kommen
|
||||
- `capabilities`: Der Anbieter veröffentlicht Besonderheiten zu Transkripten/Tools/Anbieterfamilien
|
||||
- `normalizeToolSchemas`: Der Anbieter bereinigt Tool-Schemas, bevor der eingebettete
|
||||
Runner sie sieht
|
||||
- `inspectToolSchemas`: Anbieter zeigt transportspezifische Schemawarnungen
|
||||
- `inspectToolSchemas`: Der Anbieter zeigt transportspezifische Schemawarnungen
|
||||
nach der Normalisierung an
|
||||
- `resolveReasoningOutputMode`: Anbieter wählt native oder getaggte
|
||||
- `resolveReasoningOutputMode`: Der Anbieter wählt native oder markierte
|
||||
Verträge für Reasoning-Ausgaben
|
||||
- `prepareExtraParams`: Anbieter setzt Standardwerte oder normalisiert anfragespezifische Parameter pro Modell
|
||||
- `createStreamFn`: Anbieter ersetzt den normalen Stream-Pfad durch einen vollständig
|
||||
- `prepareExtraParams`: Der Anbieter setzt Standardwerte oder normalisiert anfragespezifische Parameter pro Modell
|
||||
- `createStreamFn`: Der Anbieter ersetzt den normalen Streaming-Pfad durch einen vollständig
|
||||
benutzerdefinierten Transport
|
||||
- `wrapStreamFn`: Anbieter wendet Kompatibilitäts-Wrapper für Anfrage-Header/Body/Modell an
|
||||
- `resolveTransportTurnState`: Anbieter liefert native
|
||||
transportbezogene Header oder Metadaten pro Turn
|
||||
- `resolveWebSocketSessionPolicy`: Anbieter liefert native WebSocket-Sitzungs-
|
||||
Header oder eine Sitzungs-Cooldown-Richtlinie
|
||||
- `createEmbeddingProvider`: Anbieter besitzt das Verhalten für Memory-Embeddings, wenn es
|
||||
beim Anbieter-Plugin statt beim Core-Embedding-Switchboard liegen soll
|
||||
- `formatApiKey`: Anbieter formatiert gespeicherte Auth-Profile in den zur Laufzeit
|
||||
vom Transport erwarteten `apiKey`-String
|
||||
- `refreshOAuth`: Anbieter besitzt die OAuth-Aktualisierung, wenn die gemeinsamen `pi-ai`-
|
||||
Aktualisierer nicht ausreichen
|
||||
- `buildAuthDoctorHint`: Anbieter fügt Reparaturhinweise an, wenn die OAuth-Aktualisierung
|
||||
- `wrapStreamFn`: Der Anbieter wendet Wrapper für Anfrage-Header/-Body/Modellkompatibilität an
|
||||
- `resolveTransportTurnState`: Der Anbieter liefert native Transport-
|
||||
Header oder Metadaten pro Turn
|
||||
- `resolveWebSocketSessionPolicy`: Der Anbieter liefert native WebSocket-Sitzungs-
|
||||
Header oder eine Cooldown-Richtlinie für Sitzungen
|
||||
- `createEmbeddingProvider`: Der Anbieter übernimmt das Embedding-Verhalten für den Speicher, wenn es
|
||||
beim Anbieter-Plugin statt beim zentralen Embedding-Switchboard liegen soll
|
||||
- `formatApiKey`: Der Anbieter formatiert gespeicherte Authentifizierungsprofile in die zur Laufzeit
|
||||
erwartete `apiKey`-Zeichenfolge des Transports
|
||||
- `refreshOAuth`: Der Anbieter übernimmt die OAuth-Aktualisierung, wenn die gemeinsamen `pi-ai`-
|
||||
Refresher nicht ausreichen
|
||||
- `buildAuthDoctorHint`: Der Anbieter fügt Reparaturhinweise an, wenn die OAuth-Aktualisierung
|
||||
fehlschlägt
|
||||
- `matchesContextOverflowError`: Anbieter erkennt anbieterspezifische
|
||||
- `matchesContextOverflowError`: Der Anbieter erkennt anbieterspezifische
|
||||
Fehler bei Überschreitung des Kontextfensters, die generische Heuristiken übersehen würden
|
||||
- `classifyFailoverReason`: Anbieter ordnet anbieterspezifische rohe Transport-/API-
|
||||
- `classifyFailoverReason`: Der Anbieter ordnet anbieterspezifische rohe Transport-/API-
|
||||
Fehler Failover-Gründen wie Ratenbegrenzung oder Überlastung zu
|
||||
- `isCacheTtlEligible`: Anbieter entscheidet, welche Upstream-Modell-IDs Prompt-Cache-TTL unterstützen
|
||||
- `buildMissingAuthMessage`: Anbieter ersetzt den generischen Fehler des Auth-Speichers
|
||||
- `isCacheTtlEligible`: Der Anbieter entscheidet, welche Upstream-Modell-IDs Prompt-Cache-TTL unterstützen
|
||||
- `buildMissingAuthMessage`: Der Anbieter ersetzt den generischen Fehler des Authentifizierungsspeichers
|
||||
durch einen anbieterspezifischen Wiederherstellungshinweis
|
||||
- `suppressBuiltInModel`: Anbieter blendet veraltete Upstream-Zeilen aus und kann einen
|
||||
- `suppressBuiltInModel`: Der Anbieter blendet veraltete Upstream-Zeilen aus und kann einen
|
||||
herstellereigenen Fehler für direkte Auflösungsfehler zurückgeben
|
||||
- `augmentModelCatalog`: Anbieter hängt synthetische/finale Katalogzeilen nach
|
||||
Erkennung und Konfigurationszusammenführung an
|
||||
- `isBinaryThinking`: Anbieter besitzt die UX für binäres Ein-/Aus-Denken
|
||||
- `supportsXHighThinking`: Anbieter aktiviert `xhigh` für ausgewählte Modelle
|
||||
- `resolveDefaultThinkingLevel`: Anbieter besitzt die standardmäßige `/think`-Richtlinie für eine
|
||||
- `augmentModelCatalog`: Der Anbieter fügt nach
|
||||
Erkennung und Konfigurationszusammenführung synthetische/finale Katalogzeilen an
|
||||
- `isBinaryThinking`: Der Anbieter übernimmt die UX für binäres Denken ein/aus
|
||||
- `supportsXHighThinking`: Der Anbieter aktiviert `xhigh` für ausgewählte Modelle
|
||||
- `resolveDefaultThinkingLevel`: Der Anbieter übernimmt die standardmäßige `/think`-Richtlinie für eine
|
||||
Modellfamilie
|
||||
- `applyConfigDefaults`: Anbieter wendet anbieterspezifische globale Standardwerte
|
||||
während der Konfigurationsmaterialisierung basierend auf Auth-Modus, Umgebung oder Modellfamilie an
|
||||
- `isModernModelRef`: Anbieter besitzt die Zuordnung bevorzugter Modelle für Live-/Smoke-Tests
|
||||
- `prepareRuntimeAuth`: Anbieter wandelt konfigurierte Anmeldedaten in ein kurzlebiges
|
||||
- `applyConfigDefaults`: Der Anbieter wendet anbieterspezifische globale Standardwerte
|
||||
während der Materialisierung der Konfiguration basierend auf Authentifizierungsmodus, Umgebung oder Modellfamilie an
|
||||
- `isModernModelRef`: Der Anbieter übernimmt die bevorzugte Modellzuordnung für Live-/Smoke-Tests
|
||||
- `prepareRuntimeAuth`: Der Anbieter wandelt konfigurierte Zugangsdaten in ein kurzlebiges
|
||||
Laufzeit-Token um
|
||||
- `resolveUsageAuth`: Anbieter löst Nutzungs-/Kontingent-Anmeldedaten für `/usage`
|
||||
- `resolveUsageAuth`: Der Anbieter löst Anmeldedaten für Nutzung/Kontingent für `/usage`
|
||||
und verwandte Status-/Berichtsoberflächen auf
|
||||
- `fetchUsageSnapshot`: Anbieter besitzt das Abrufen/Parsen des Nutzungsendpunkts, während
|
||||
der Core weiterhin die Zusammenfassungs-Hülle und Formatierung besitzt
|
||||
- `onModelSelected`: Anbieter führt Nebenwirkungen nach der Modellauswahl aus, z. B.
|
||||
- `fetchUsageSnapshot`: Der Anbieter übernimmt Abruf/Parsing des Nutzungsendpunkts, während
|
||||
der Kern weiterhin die Zusammenfassungs-Shell und Formatierung übernimmt
|
||||
- `onModelSelected`: Der Anbieter führt Nebenwirkungen nach der Modellauswahl aus, wie
|
||||
Telemetrie oder anbietereigene Sitzungsbuchführung
|
||||
|
||||
Aktuelle gebündelte Beispiele:
|
||||
|
||||
- `anthropic`: Claude-4.6-Vorwärtskompatibilitäts-Fallback, Hinweise zur Auth-Reparatur, Abrufen des Nutzungsendpunkts, Cache-TTL-/Anbieterfamilien-Metadaten und authentifizierungsabhängige globale Konfigurationsstandardwerte
|
||||
- `amazon-bedrock`: anbietereigene Erkennung von Kontextüberläufen und Klassifizierung von Failover-Gründen für Bedrock-spezifische Throttle-/Nicht-bereit-Fehler sowie die gemeinsame `anthropic-by-model`-Replay-Familie für Replay-Richtlinienschutz nur für Claude bei Anthropic-Datenverkehr
|
||||
- `anthropic-vertex`: Replay-Richtlinienschutz nur für Claude bei Anthropic-Message-Datenverkehr
|
||||
- `openrouter`: Durchreichung von Modell-IDs, Anfrage-Wrapper, Hinweise zu Anbieterfähigkeiten, Bereinigung von Gemini-Thought-Signatures bei proxied Gemini-Datenverkehr, Proxy-Reasoning-Injektion über die Stream-Familie `openrouter-thinking`, Weiterleitung von Routing-Metadaten und Cache-TTL-Richtlinie
|
||||
- `github-copilot`: Onboarding/Geräte-Login, Vorwärtskompatibilitäts-Fallback für Modelle, Hinweise zu Claude-Thinking-Transkripten, Laufzeit-Token-Austausch und Abrufen des Nutzungsendpunkts
|
||||
- `openai`: GPT-5.4-Vorwärtskompatibilitäts-Fallback, direkte OpenAI-Transport-Normalisierung, Codex-bewusste Hinweise bei fehlender Authentifizierung, Spark-Unterdrückung, synthetische OpenAI-/Codex-Katalogzeilen, Thinking-/Live-Modell-Richtlinie, Normalisierung von Nutzungs-Token-Aliassen (`input` / `output` und `prompt` / `completion`-Familien), die gemeinsame Stream-Familie `openai-responses-defaults` für native OpenAI-/Codex-Wrapper, Anbieterfamilien-Metadaten, gebündelte Registrierung des Bildgenerierungsanbieters für `gpt-image-1` und gebündelte Registrierung des Videogenerierungsanbieters für `sora-2`
|
||||
- `google` und `google-gemini-cli`: Gemini-3.1-Vorwärtskompatibilitäts-Fallback, native Gemini-Replay-Validierung, Bereinigung von Bootstrap-Replays, getaggter Reasoning-Ausgabemodus, modernes Modell-Matching, gebündelte Registrierung des Bildgenerierungsanbieters für Gemini-Image-Preview-Modelle und gebündelte Registrierung des Videogenerierungsanbieters für Veo-Modelle; Gemini CLI OAuth besitzt außerdem Tokenformatierung für Auth-Profile, Parsing von Nutzungs-Token und Abrufen des Kontingentendpunkts für Nutzungsoberflächen
|
||||
- `moonshot`: gemeinsamer Transport, plugin-eigene Normalisierung der Thinking-Payload
|
||||
- `kilocode`: gemeinsamer Transport, plugin-eigene Anfrage-Header, Normalisierung von Reasoning-Payloads, Bereinigung von Proxy-Gemini-Thought-Signatures und Cache-TTL-Richtlinie
|
||||
- `zai`: GLM-5-Vorwärtskompatibilitäts-Fallback, Standardwerte für `tool_stream`, Cache-TTL-Richtlinie, Richtlinie für binäres Thinking-/Live-Modell sowie Nutzungs-Auth + Abruf von Kontingenten; unbekannte `glm-5*`-IDs werden aus der gebündelten Vorlage `glm-4.7` synthetisiert
|
||||
- `xai`: native Responses-Transport-Normalisierung, Umschreibungen des Alias `/fast` für Grok-Fast-Varianten, Standardwert `tool_stream`, xAI-spezifische Bereinigung von Tool-Schemata / Reasoning-Payloads und gebündelte Registrierung des Videogenerierungsanbieters für `grok-imagine-video`
|
||||
- `mistral`: plugin-eigene Fähigkeitsmetadaten
|
||||
- `opencode` und `opencode-go`: plugin-eigene Fähigkeitsmetadaten plus Bereinigung von Proxy-Gemini-Thought-Signatures
|
||||
- `alibaba`: plugin-eigener Videogenerierungskatalog für direkte Wan-Modell-Referenzen wie `alibaba/wan2.6-t2v`
|
||||
- `byteplus`: plugin-eigene Kataloge plus gebündelte Registrierung des Videogenerierungsanbieters für Seedance-Text-zu-Video-/Bild-zu-Video-Modelle
|
||||
- `fal`: gebündelte Registrierung des Videogenerierungsanbieters für gehostete Drittanbieter-Registrierung des Bildgenerierungsanbieters für FLUX-Bildmodelle plus gebündelte Registrierung des Videogenerierungsanbieters für gehostete Drittanbieter-Videomodelle
|
||||
- `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`, `stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` und `volcengine`: nur plugin-eigene Kataloge
|
||||
- `qwen`: plugin-eigene Kataloge für Textmodelle plus gemeinsame Registrierungen von Media-Understanding- und Videogenerierungsanbietern für seine multimodalen Oberflächen; die Qwen-Videogenerierung verwendet die Standard-DashScope-Videoendpunkte mit gebündelten Wan-Modellen wie `wan2.6-t2v` und `wan2.7-r2v`
|
||||
- `runway`: plugin-eigene Registrierung des Videogenerierungsanbieters für native aufgabenbasierte Runway-Modelle wie `gen4.5`
|
||||
- `minimax`: plugin-eigene Kataloge, gebündelte Registrierung des Videogenerierungsanbieters für Hailuo-Videomodelle, gebündelte Registrierung des Bildgenerierungsanbieters für `image-01`, hybride Auswahl der Anthropic-/OpenAI-Replay-Richtlinie und Logik für Nutzungs-Auth/Snapshots
|
||||
- `together`: plugin-eigene Kataloge plus gebündelte Registrierung des Videogenerierungsanbieters für Wan-Videomodelle
|
||||
- `xiaomi`: plugin-eigene Kataloge plus Logik für Nutzungs-Auth/Snapshots
|
||||
- `anthropic`: Claude-4.6-Forward-Compat-Fallback, Hinweise zur Auth-Reparatur, Abfrage des Usage-Endpunkts, Cache-TTL-/Provider-Family-Metadaten und auth-bewusste globale Konfigurationsstandards
|
||||
- `amazon-bedrock`: Provider-eigenes Context-Overflow-Matching und Failover-Grundklassifizierung für Bedrock-spezifische Throttle-/Not-Ready-Fehler sowie die gemeinsame Replay-Familie `anthropic-by-model` für Claude-only-Replay-Policy-Guards auf Anthropic-Traffic
|
||||
- `anthropic-vertex`: Claude-only-Replay-Policy-Guards auf Anthropic-Message-Traffic
|
||||
- `openrouter`: Durchreichen von Modell-IDs, Request-Wrapper, Hinweise zu Provider-Fähigkeiten, Bereinigung von Gemini-Thought-Signatures auf Proxy-Gemini-Traffic, Proxy-Reasoning-Injektion über die Stream-Familie `openrouter-thinking`, Weiterleitung von Routing-Metadaten und Cache-TTL-Policy
|
||||
- `github-copilot`: Onboarding/Device-Login, Forward-Compat-Modell-Fallback, Claude-Thinking-Transkripthinweise, Runtime-Token-Austausch und Abfrage des Usage-Endpunkts
|
||||
- `openai`: GPT-5.4-Forward-Compat-Fallback, direkte OpenAI-Transport-Normalisierung, Codex-bewusste Hinweise bei fehlender Auth, Spark-Unterdrückung, synthetische OpenAI-/Codex-Katalogzeilen, Thinking-/Live-Model-Policy, Usage-Token-Alias-Normalisierung (`input`-/`output`- und `prompt`-/`completion`-Familien), die gemeinsame Stream-Familie `openai-responses-defaults` für native OpenAI-/Codex-Wrapper, Provider-Family-Metadaten, gebündelte Registrierung des Image-Generation-Providers für `gpt-image-1` und gebündelte Registrierung des Video-Generation-Providers für `sora-2`
|
||||
- `google` und `google-gemini-cli`: Gemini-3.1-Forward-Compat-Fallback, native Gemini-Replay-Validierung, Bootstrap-Replay-Bereinigung, getaggter Reasoning-Output-Modus, Modern-Model-Matching, gebündelte Registrierung des Image-Generation-Providers für Gemini-Image-Preview-Modelle und gebündelte Registrierung des Video-Generation-Providers für Veo-Modelle; Gemini-CLI-OAuth besitzt außerdem die Token-Formatierung des Auth-Profils, Usage-Token-Parsing und die Abfrage des Quota-Endpunkts für Usage-Oberflächen
|
||||
- `moonshot`: gemeinsamer Transport, Plugin-eigene Normalisierung von Thinking-Payloads
|
||||
- `kilocode`: gemeinsamer Transport, Plugin-eigene Request-Header, Normalisierung von Reasoning-Payloads, Bereinigung von Proxy-Gemini-Thought-Signatures und Cache-TTL-Policy
|
||||
- `zai`: GLM-5-Forward-Compat-Fallback, Standards für `tool_stream`, Cache-TTL-Policy, Binary-Thinking-/Live-Model-Policy sowie Usage-Auth und Quota-Abfrage; unbekannte `glm-5*`-IDs werden aus dem gebündelten Template `glm-4.7` synthetisiert
|
||||
- `xai`: native Responses-Transport-Normalisierung, Alias-Umschreibungen für `/fast` bei schnellen Grok-Varianten, Standard für `tool_stream`, xAI-spezifische Bereinigung von Tool-Schemas / Reasoning-Payloads und gebündelte Registrierung des Video-Generation-Providers für `grok-imagine-video`
|
||||
- `mistral`: Plugin-eigene Capability-Metadaten
|
||||
- `opencode` und `opencode-go`: Plugin-eigene Capability-Metadaten sowie Bereinigung von Proxy-Gemini-Thought-Signatures
|
||||
- `alibaba`: Plugin-eigener Video-Generation-Katalog für direkte Wan-Modellreferenzen wie `alibaba/wan2.6-t2v`
|
||||
- `byteplus`: Plugin-eigene Kataloge sowie gebündelte Registrierung des Video-Generation-Providers für Seedance-Text-zu-Video-/Bild-zu-Video-Modelle
|
||||
- `fal`: gebündelte Registrierung des Video-Generation-Providers für gehostete Drittanbieter, Registrierung des Image-Generation-Providers für FLUX-Image-Modelle sowie gebündelte Registrierung des Video-Generation-Providers für gehostete Drittanbieter-Video-Modelle
|
||||
- `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
|
||||
`stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` und `volcengine`:
|
||||
nur Plugin-eigene Kataloge
|
||||
- `qwen`: Plugin-eigene Kataloge für Textmodelle sowie gemeinsame Registrierungen für Media-Understanding- und Video-Generation-Provider für seine multimodalen Oberflächen; die Qwen-Videogenerierung verwendet die Standard-DashScope-Videoendpunkte mit gebündelten Wan-Modellen wie `wan2.6-t2v` und `wan2.7-r2v`
|
||||
- `runway`: Plugin-eigene Registrierung des Video-Generation-Providers für native Runway-aufgabenbasierte Modelle wie `gen4.5`
|
||||
- `minimax`: Plugin-eigene Kataloge, gebündelte Registrierung des Video-Generation-Providers für Hailuo-Videomodelle, gebündelte Registrierung des Image-Generation-Providers für `image-01`, hybride Anthropic-/OpenAI-Replay-Policy-Auswahl und Usage-Auth-/Snapshot-Logik
|
||||
- `together`: Plugin-eigene Kataloge sowie gebündelte Registrierung des Video-Generation-Providers für Wan-Videomodelle
|
||||
- `xiaomi`: Plugin-eigene Kataloge sowie Usage-Auth-/Snapshot-Logik
|
||||
|
||||
Das gebündelte Plugin `openai` besitzt jetzt beide Anbieter-IDs: `openai` und
|
||||
Das gebündelte Plugin `openai` besitzt jetzt beide Provider-IDs: `openai` und
|
||||
`openai-codex`.
|
||||
|
||||
Das deckt Anbieter ab, die noch in die normalen Transporte von OpenClaw passen. Ein Anbieter,
|
||||
der einen vollständig benutzerdefinierten Anfrage-Executor benötigt, ist eine separate, tiefere Erweiterungsoberfläche.
|
||||
Damit sind die Provider abgedeckt, die noch in die normalen Transporte von OpenClaw passen. Ein Provider,
|
||||
der einen vollständig benutzerdefinierten Request-Executor benötigt, ist eine separate, tiefere Extension-Oberfläche.
|
||||
|
||||
## API-Schlüsselrotation
|
||||
## Rotation von API-Schlüsseln
|
||||
|
||||
- Unterstützt generische Anbieterrotation für ausgewählte Anbieter.
|
||||
- Konfigurieren Sie mehrere Schlüssel über:
|
||||
- Unterstützt generische Provider-Rotation für ausgewählte Provider.
|
||||
- Konfiguriere mehrere Schlüssel über:
|
||||
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (einzelne Live-Überschreibung, höchste Priorität)
|
||||
- `<PROVIDER>_API_KEYS` (durch Komma oder Semikolon getrennte Liste)
|
||||
- `<PROVIDER>_API_KEY` (primärer Schlüssel)
|
||||
- `<PROVIDER>_API_KEY_*` (nummerierte Liste, z. B. `<PROVIDER>_API_KEY_1`)
|
||||
- Für Google-Anbieter wird `GOOGLE_API_KEY` ebenfalls als Fallback einbezogen.
|
||||
- Für Google-Provider wird `GOOGLE_API_KEY` zusätzlich als Fallback einbezogen.
|
||||
- Die Reihenfolge der Schlüsselauswahl bewahrt die Priorität und entfernt Duplikate.
|
||||
- Anfragen werden nur bei Antworten mit Ratenbegrenzung mit dem nächsten Schlüssel erneut versucht (zum
|
||||
- Requests werden nur bei Rate-Limit-Antworten mit dem nächsten Schlüssel erneut versucht (zum
|
||||
Beispiel `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
|
||||
concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
|
||||
`workers_ai ... quota limit exceeded` oder periodische Meldungen zu Nutzungslimits).
|
||||
- Fehler, die keine Ratenbegrenzung sind, schlagen sofort fehl; es wird keine Schlüsselrotation versucht.
|
||||
- Wenn alle Kandidatenschlüssel fehlschlagen, wird der endgültige Fehler des letzten Versuchs zurückgegeben.
|
||||
`workers_ai ... quota limit exceeded` oder periodische Usage-Limit-Meldungen).
|
||||
- Fehler, die keine Rate-Limit-Fehler sind, schlagen sofort fehl; es wird keine Schlüsselrotation versucht.
|
||||
- Wenn alle Kandidatenschlüssel fehlschlagen, wird der letzte Fehler aus dem letzten Versuch zurückgegeben.
|
||||
|
||||
## Integrierte Anbieter (pi-ai-Katalog)
|
||||
## Eingebaute Provider (pi-ai-Katalog)
|
||||
|
||||
OpenClaw wird mit dem pi‑ai-Katalog ausgeliefert. Diese Anbieter benötigen **keine**
|
||||
Konfiguration unter `models.providers`; setzen Sie einfach die Authentifizierung und wählen Sie ein Modell.
|
||||
OpenClaw wird mit dem pi‑ai-Katalog ausgeliefert. Diese Provider benötigen **keine**
|
||||
`models.providers`-Konfiguration; setze einfach Auth + wähle ein Modell.
|
||||
|
||||
### OpenAI
|
||||
|
||||
- Anbieter: `openai`
|
||||
- Authentifizierung: `OPENAI_API_KEY`
|
||||
- Provider: `openai`
|
||||
- Auth: `OPENAI_API_KEY`
|
||||
- Optionale Rotation: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2` sowie `OPENCLAW_LIVE_OPENAI_KEY` (einzelne Überschreibung)
|
||||
- Beispielmodelle: `openai/gpt-5.4`, `openai/gpt-5.4-pro`
|
||||
- CLI: `openclaw onboard --auth-choice openai-api-key`
|
||||
- Standardtransport ist `auto` (zuerst WebSocket, SSE-Fallback)
|
||||
- Der Standardtransport ist `auto` (zuerst WebSocket, SSE als Fallback)
|
||||
- Pro Modell überschreiben über `agents.defaults.models["openai/<model>"].params.transport` (`"sse"`, `"websocket"` oder `"auto"`)
|
||||
- Das OpenAI-Responses-WebSocket-Warm-up ist standardmäßig über `params.openaiWsWarmup` aktiviert (`true`/`false`)
|
||||
- OpenAI-Prioritätsverarbeitung kann über `agents.defaults.models["openai/<model>"].params.serviceTier` aktiviert werden
|
||||
- `/fast` und `params.fastMode` ordnen direkte `openai/*`-Responses-Anfragen `service_tier=priority` auf `api.openai.com` zu
|
||||
- Verwenden Sie `params.serviceTier`, wenn Sie eine explizite Stufe statt des gemeinsamen Schalters `/fast` möchten
|
||||
- Versteckte OpenClaw-Attributions-Header (`originator`, `version`,
|
||||
`User-Agent`) gelten nur für nativen OpenAI-Datenverkehr zu `api.openai.com`, nicht
|
||||
- Das Warm-up für OpenAI Responses WebSocket ist standardmäßig über `params.openaiWsWarmup` aktiviert (`true`/`false`)
|
||||
- OpenAI-Priority-Processing kann über `agents.defaults.models["openai/<model>"].params.serviceTier` aktiviert werden
|
||||
- `/fast` und `params.fastMode` ordnen direkte `openai/*`-Responses-Requests auf `api.openai.com` `service_tier=priority` zu
|
||||
- Verwende `params.serviceTier`, wenn du eine explizite Tier-Stufe statt des gemeinsamen Schalters `/fast` möchtest
|
||||
- Versteckte OpenClaw-Attribution-Header (`originator`, `version`,
|
||||
`User-Agent`) gelten nur für nativen OpenAI-Traffic zu `api.openai.com`, nicht
|
||||
für generische OpenAI-kompatible Proxys
|
||||
- Native OpenAI-Routen behalten außerdem Responses-`store`, Prompt-Cache-Hinweise und
|
||||
OpenAI-Reasoning-kompatible Payload-Formung bei; Proxy-Routen nicht
|
||||
- `openai/gpt-5.3-codex-spark` wird in OpenClaw absichtlich unterdrückt, weil die Live-OpenAI-API es ablehnt; Spark wird als nur Codex behandelt
|
||||
OpenAI-Reasoning-kompatibles Payload-Shaping bei; Proxy-Routen tun das nicht
|
||||
- `openai/gpt-5.3-codex-spark` wird in OpenClaw absichtlich unterdrückt, weil die Live-OpenAI-API es ablehnt; Spark wird als nur für Codex behandelt
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -232,14 +236,14 @@ Konfiguration unter `models.providers`; setzen Sie einfach die Authentifizierung
|
||||
|
||||
### Anthropic
|
||||
|
||||
- Anbieter: `anthropic`
|
||||
- Authentifizierung: `ANTHROPIC_API_KEY`
|
||||
- Provider: `anthropic`
|
||||
- Auth: `ANTHROPIC_API_KEY`
|
||||
- Optionale Rotation: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2` sowie `OPENCLAW_LIVE_ANTHROPIC_KEY` (einzelne Überschreibung)
|
||||
- Beispielmodell: `anthropic/claude-opus-4-6`
|
||||
- CLI: `openclaw onboard --auth-choice apiKey`
|
||||
- Direkte öffentliche Anthropic-Anfragen unterstützen ebenfalls den gemeinsamen Schalter `/fast` und `params.fastMode`, einschließlich mit API-Schlüssel und OAuth authentifiziertem Datenverkehr, der an `api.anthropic.com` gesendet wird; OpenClaw ordnet dies Anthropic-`service_tier` zu (`auto` vs `standard_only`)
|
||||
- Anthropic-Hinweis: Mitarbeitende von Anthropic haben uns mitgeteilt, dass die Nutzung von Claude CLI im Stil von OpenClaw wieder erlaubt ist; daher behandelt OpenClaw die Wiederverwendung von Claude CLI und die Nutzung von `claude -p` für diese Integration als genehmigt, sofern Anthropic keine neue Richtlinie veröffentlicht.
|
||||
- Das Anthropic-Setup-Token bleibt als unterstützter OpenClaw-Tokenpfad verfügbar, aber OpenClaw bevorzugt jetzt die Wiederverwendung von Claude CLI und `claude -p`, wenn verfügbar.
|
||||
- Direkte öffentliche Anthropic-Requests unterstützen ebenfalls den gemeinsamen Schalter `/fast` und `params.fastMode`, einschließlich per API-Key und OAuth authentifiziertem Traffic, der an `api.anthropic.com` gesendet wird; OpenClaw ordnet das Anthropic-`service_tier` zu (`auto` vs. `standard_only`)
|
||||
- Anthropic-Hinweis: Anthropic-Mitarbeiter haben uns mitgeteilt, dass OpenClaw-artige Claude-CLI-Nutzung wieder erlaubt ist, daher behandelt OpenClaw die Wiederverwendung von Claude CLI und die Nutzung von `claude -p` für diese Integration als genehmigt, sofern Anthropic keine neue Richtlinie veröffentlicht.
|
||||
- Der Anthropic-Setup-Token bleibt als unterstützter OpenClaw-Tokenpfad verfügbar, aber OpenClaw bevorzugt jetzt die Wiederverwendung von Claude CLI und `claude -p`, wenn verfügbar.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -249,20 +253,20 @@ Konfiguration unter `models.providers`; setzen Sie einfach die Authentifizierung
|
||||
|
||||
### OpenAI Code (Codex)
|
||||
|
||||
- Anbieter: `openai-codex`
|
||||
- Authentifizierung: OAuth (ChatGPT)
|
||||
- Provider: `openai-codex`
|
||||
- Auth: OAuth (ChatGPT)
|
||||
- Beispielmodell: `openai-codex/gpt-5.4`
|
||||
- CLI: `openclaw onboard --auth-choice openai-codex` oder `openclaw models auth login --provider openai-codex`
|
||||
- Standardtransport ist `auto` (zuerst WebSocket, SSE-Fallback)
|
||||
- Der Standardtransport ist `auto` (zuerst WebSocket, SSE als Fallback)
|
||||
- Pro Modell überschreiben über `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"` oder `"auto"`)
|
||||
- `params.serviceTier` wird auch bei nativen Codex-Responses-Anfragen weitergereicht (`chatgpt.com/backend-api`)
|
||||
- Versteckte OpenClaw-Attributions-Header (`originator`, `version`,
|
||||
`User-Agent`) werden nur bei nativem Codex-Datenverkehr zu
|
||||
`chatgpt.com/backend-api` angehängt, nicht bei generischen OpenAI-kompatiblen Proxys
|
||||
- Nutzt denselben Schalter `/fast` und dieselbe Konfiguration `params.fastMode` wie direktes `openai/*`; OpenClaw ordnet dies `service_tier=priority` zu
|
||||
- `openai-codex/gpt-5.3-codex-spark` bleibt verfügbar, wenn der Codex-OAuth-Katalog es bereitstellt; abhängig von der Berechtigung
|
||||
- `openai-codex/gpt-5.4` behält das native `contextWindow = 1050000` und eine standardmäßige Laufzeit-`contextTokens = 272000`; überschreiben Sie die Laufzeitobergrenze mit `models.providers.openai-codex.models[].contextTokens`
|
||||
- Richtlinienhinweis: OpenAI Codex OAuth wird explizit für externe Tools/Workflows wie OpenClaw unterstützt.
|
||||
- `params.serviceTier` wird ebenfalls bei nativen Codex-Responses-Requests weitergeleitet (`chatgpt.com/backend-api`)
|
||||
- Versteckte OpenClaw-Attribution-Header (`originator`, `version`,
|
||||
`User-Agent`) werden nur an nativen Codex-Traffic zu
|
||||
`chatgpt.com/backend-api` angehängt, nicht an generische OpenAI-kompatible Proxys
|
||||
- Nutzt denselben Schalter `/fast` und dieselbe `params.fastMode`-Konfiguration wie direktes `openai/*`; OpenClaw ordnet das `service_tier=priority` zu
|
||||
- `openai-codex/gpt-5.3-codex-spark` bleibt verfügbar, wenn der Codex-OAuth-Katalog es bereitstellt; abhängig von Berechtigungen
|
||||
- `openai-codex/gpt-5.4` behält natives `contextWindow = 1050000` und ein Standard-Runtime-`contextTokens = 272000`; überschreibe die Runtime-Obergrenze mit `models.providers.openai-codex.models[].contextTokens`
|
||||
- Richtlinienhinweis: OpenAI Codex OAuth wird ausdrücklich für externe Tools/Workflows wie OpenClaw unterstützt.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -282,17 +286,17 @@ Konfiguration unter `models.providers`; setzen Sie einfach die Authentifizierung
|
||||
}
|
||||
```
|
||||
|
||||
### Andere gehostete Optionen im Abonnementstil
|
||||
### Andere abonnementartige gehostete Optionen
|
||||
|
||||
- [Qwen Cloud](/de/providers/qwen): Qwen-Cloud-Anbieteroberfläche plus Zuordnung von Alibaba-DashScope- und Coding-Plan-Endpunkten
|
||||
- [MiniMax](/de/providers/minimax): OAuth oder API-Schlüsselzugriff für MiniMax Coding Plan
|
||||
- [Qwen Cloud](/de/providers/qwen): Qwen-Cloud-Provider-Oberfläche sowie Alibaba-DashScope- und Coding-Plan-Endpunktzuordnung
|
||||
- [MiniMax](/de/providers/minimax): MiniMax-Coding-Plan-OAuth- oder API-Key-Zugriff
|
||||
- [GLM Models](/de/providers/glm): Z.AI Coding Plan oder allgemeine API-Endpunkte
|
||||
|
||||
### OpenCode
|
||||
|
||||
- Authentifizierung: `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`)
|
||||
- Zen-Laufzeitanbieter: `opencode`
|
||||
- Go-Laufzeitanbieter: `opencode-go`
|
||||
- Auth: `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`)
|
||||
- Zen-Runtime-Provider: `opencode`
|
||||
- Go-Runtime-Provider: `opencode-go`
|
||||
- Beispielmodelle: `opencode/claude-opus-4-6`, `opencode-go/kimi-k2.5`
|
||||
- CLI: `openclaw onboard --auth-choice opencode-zen` oder `openclaw onboard --auth-choice opencode-go`
|
||||
|
||||
@ -302,77 +306,77 @@ Konfiguration unter `models.providers`; setzen Sie einfach die Authentifizierung
|
||||
}
|
||||
```
|
||||
|
||||
### Google Gemini (API-Schlüssel)
|
||||
### Google Gemini (API-Key)
|
||||
|
||||
- Anbieter: `google`
|
||||
- Authentifizierung: `GEMINI_API_KEY`
|
||||
- Optionale Rotation: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, Fallback `GOOGLE_API_KEY` und `OPENCLAW_LIVE_GEMINI_KEY` (einzelne Überschreibung)
|
||||
- Provider: `google`
|
||||
- Auth: `GEMINI_API_KEY`
|
||||
- Optionale Rotation: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, `GOOGLE_API_KEY` als Fallback und `OPENCLAW_LIVE_GEMINI_KEY` (einzelne Überschreibung)
|
||||
- Beispielmodelle: `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview`
|
||||
- Kompatibilität: Legacy-OpenClaw-Konfiguration mit `google/gemini-3.1-flash-preview` wird zu `google/gemini-3-flash-preview` normalisiert
|
||||
- Kompatibilität: ältere OpenClaw-Konfigurationen mit `google/gemini-3.1-flash-preview` werden zu `google/gemini-3-flash-preview` normalisiert
|
||||
- CLI: `openclaw onboard --auth-choice gemini-api-key`
|
||||
- Direkte Gemini-Läufe akzeptieren außerdem `agents.defaults.models["google/<model>"].params.cachedContent`
|
||||
(oder das Legacy-`cached_content`), um einen anbieterinternen
|
||||
Handle `cachedContents/...` weiterzureichen; Gemini-Cache-Treffer erscheinen als OpenClaw-`cacheRead`
|
||||
- Direkte Gemini-Läufe akzeptieren auch `agents.defaults.models["google/<model>"].params.cachedContent`
|
||||
(oder das ältere `cached_content`), um ein provider-natives
|
||||
`cachedContents/...`-Handle weiterzuleiten; Gemini-Cache-Treffer erscheinen in OpenClaw als `cacheRead`
|
||||
|
||||
### Google Vertex und Gemini CLI
|
||||
|
||||
- Anbieter: `google-vertex`, `google-gemini-cli`
|
||||
- Authentifizierung: Vertex verwendet gcloud ADC; Gemini CLI verwendet seinen OAuth-Ablauf
|
||||
- Achtung: Gemini-CLI-OAuth in OpenClaw ist eine inoffizielle Integration. Einige Nutzer haben nach der Verwendung von Drittanbieter-Clients über Einschränkungen bei Google-Konten berichtet. Prüfen Sie die Google-Bedingungen und verwenden Sie ein unkritisches Konto, wenn Sie sich dafür entscheiden.
|
||||
- Provider: `google-vertex`, `google-gemini-cli`
|
||||
- Auth: Vertex verwendet gcloud ADC; Gemini CLI verwendet seinen OAuth-Flow
|
||||
- Vorsicht: Gemini-CLI-OAuth in OpenClaw ist eine inoffizielle Integration. Einige Nutzer haben berichtet, dass ihre Google-Konten nach der Nutzung von Drittanbieter-Clients eingeschränkt wurden. Prüfe die Google-Bedingungen und verwende ein unkritisches Konto, wenn du dich dafür entscheidest.
|
||||
- Gemini-CLI-OAuth wird als Teil des gebündelten Plugins `google` ausgeliefert.
|
||||
- Installieren Sie zuerst Gemini CLI:
|
||||
- Installiere zuerst Gemini CLI:
|
||||
- `brew install gemini-cli`
|
||||
- oder `npm install -g @google/gemini-cli`
|
||||
- Aktivieren: `openclaw plugins enable google`
|
||||
- Anmelden: `openclaw models auth login --provider google-gemini-cli --set-default`
|
||||
- Standardmodell: `google-gemini-cli/gemini-3-flash-preview`
|
||||
- Hinweis: Sie fügen **keine** Client-ID oder kein Secret in `openclaw.json` ein. Der CLI-Login-Ablauf speichert
|
||||
- Hinweis: Du fügst **keine** Client-ID und kein Secret in `openclaw.json` ein. Der CLI-Login-Flow speichert
|
||||
Tokens in Auth-Profilen auf dem Gateway-Host.
|
||||
- Wenn Anfragen nach der Anmeldung fehlschlagen, setzen Sie `GOOGLE_CLOUD_PROJECT` oder `GOOGLE_CLOUD_PROJECT_ID` auf dem Gateway-Host.
|
||||
- Gemini-CLI-JSON-Antworten werden aus `response` geparst; die Nutzung fällt auf
|
||||
`stats` zurück, wobei `stats.cached` in OpenClaw-`cacheRead` normalisiert wird.
|
||||
- Wenn Requests nach der Anmeldung fehlschlagen, setze `GOOGLE_CLOUD_PROJECT` oder `GOOGLE_CLOUD_PROJECT_ID` auf dem Gateway-Host.
|
||||
- Gemini-CLI-JSON-Antworten werden aus `response` geparst; Usage fällt auf
|
||||
`stats` zurück, wobei `stats.cached` in OpenClaw zu `cacheRead` normalisiert wird.
|
||||
|
||||
### Z.AI (GLM)
|
||||
|
||||
- Anbieter: `zai`
|
||||
- Authentifizierung: `ZAI_API_KEY`
|
||||
- Provider: `zai`
|
||||
- Auth: `ZAI_API_KEY`
|
||||
- Beispielmodell: `zai/glm-5.1`
|
||||
- CLI: `openclaw onboard --auth-choice zai-api-key`
|
||||
- Aliasse: `z.ai/*` und `z-ai/*` werden zu `zai/*` normalisiert
|
||||
- `zai-api-key` erkennt automatisch den passenden Z.AI-Endpunkt; `zai-coding-global`, `zai-coding-cn`, `zai-global` und `zai-cn` erzwingen eine bestimmte Oberfläche
|
||||
- `zai-api-key` erkennt den passenden Z.AI-Endpunkt automatisch; `zai-coding-global`, `zai-coding-cn`, `zai-global` und `zai-cn` erzwingen eine bestimmte Oberfläche
|
||||
|
||||
### Vercel AI Gateway
|
||||
|
||||
- Anbieter: `vercel-ai-gateway`
|
||||
- Authentifizierung: `AI_GATEWAY_API_KEY`
|
||||
- Provider: `vercel-ai-gateway`
|
||||
- Auth: `AI_GATEWAY_API_KEY`
|
||||
- Beispielmodell: `vercel-ai-gateway/anthropic/claude-opus-4.6`
|
||||
- CLI: `openclaw onboard --auth-choice ai-gateway-api-key`
|
||||
|
||||
### Kilo Gateway
|
||||
|
||||
- Anbieter: `kilocode`
|
||||
- Authentifizierung: `KILOCODE_API_KEY`
|
||||
- Provider: `kilocode`
|
||||
- Auth: `KILOCODE_API_KEY`
|
||||
- Beispielmodell: `kilocode/kilo/auto`
|
||||
- CLI: `openclaw onboard --auth-choice kilocode-api-key`
|
||||
- Basis-URL: `https://api.kilo.ai/api/gateway/`
|
||||
- Der statische Fallback-Katalog enthält `kilocode/kilo/auto`; die Live-Erkennung unter
|
||||
`https://api.kilo.ai/api/gateway/models` kann den Laufzeitkatalog
|
||||
- Der statische Fallback-Katalog wird mit `kilocode/kilo/auto` ausgeliefert; die Live-Erkennung über
|
||||
`https://api.kilo.ai/api/gateway/models` kann den Runtime-Katalog
|
||||
weiter erweitern.
|
||||
- Das genaue Upstream-Routing hinter `kilocode/kilo/auto` liegt bei Kilo Gateway
|
||||
und ist nicht fest in OpenClaw kodiert.
|
||||
- Das genaue Upstream-Routing hinter `kilocode/kilo/auto` liegt in der Verantwortung von Kilo Gateway
|
||||
und ist in OpenClaw nicht fest codiert.
|
||||
|
||||
Details zur Einrichtung finden Sie unter [/providers/kilocode](/de/providers/kilocode).
|
||||
Siehe [/providers/kilocode](/de/providers/kilocode) für Einrichtungsdetails.
|
||||
|
||||
### Andere gebündelte Anbieter-Plugins
|
||||
### Weitere gebündelte Provider-Plugins
|
||||
|
||||
- OpenRouter: `openrouter` (`OPENROUTER_API_KEY`)
|
||||
- Beispielmodell: `openrouter/auto`
|
||||
- OpenClaw wendet die dokumentierten App-Attributions-Header von OpenRouter nur an, wenn
|
||||
die Anfrage tatsächlich auf `openrouter.ai` zielt
|
||||
- OpenRouter-spezifische Anthropic-`cache_control`-Marker werden ebenso nur auf
|
||||
verifizierten OpenRouter-Routen aktiviert, nicht auf beliebigen Proxy-URLs
|
||||
- OpenRouter bleibt auf dem Proxy-Stil-OpenAI-kompatiblen Pfad, daher werden native,
|
||||
nur für OpenAI bestimmte Anfrageformungen (`serviceTier`, Responses-`store`,
|
||||
- OpenClaw wendet die dokumentierten App-Attribution-Header von OpenRouter nur an, wenn
|
||||
das Request tatsächlich auf `openrouter.ai` zielt
|
||||
- OpenRouter-spezifische Anthropic-`cache_control`-Marker sind ebenfalls auf
|
||||
verifizierte OpenRouter-Routen beschränkt, nicht auf beliebige Proxy-URLs
|
||||
- OpenRouter bleibt auf dem proxyartigen OpenAI-kompatiblen Pfad, daher werden natives
|
||||
OpenAI-only-Request-Shaping (`serviceTier`, Responses-`store`,
|
||||
Prompt-Cache-Hinweise, OpenAI-Reasoning-kompatible Payloads) nicht weitergeleitet
|
||||
- Gemini-gestützte OpenRouter-Referenzen behalten nur die Bereinigung von Proxy-Gemini-Thought-Signatures
|
||||
bei; native Gemini-Replay-Validierung und Bootstrap-Umschreibungen bleiben deaktiviert
|
||||
@ -380,13 +384,13 @@ Details zur Einrichtung finden Sie unter [/providers/kilocode](/de/providers/kil
|
||||
- Beispielmodell: `kilocode/kilo/auto`
|
||||
- Gemini-gestützte Kilo-Referenzen behalten denselben Pfad zur Bereinigung von Proxy-Gemini-Thought-Signatures
|
||||
bei; `kilocode/kilo/auto` und andere Hinweise ohne Unterstützung für Proxy-Reasoning
|
||||
überspringen die Proxy-Reasoning-Injektion
|
||||
- MiniMax: `minimax` (API-Schlüssel) und `minimax-portal` (OAuth)
|
||||
- Authentifizierung: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder `MINIMAX_API_KEY` für `minimax-portal`
|
||||
überspringen die Injektion von Proxy-Reasoning
|
||||
- MiniMax: `minimax` (API-Key) und `minimax-portal` (OAuth)
|
||||
- Auth: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder `MINIMAX_API_KEY` für `minimax-portal`
|
||||
- Beispielmodell: `minimax/MiniMax-M2.7` oder `minimax-portal/MiniMax-M2.7`
|
||||
- Das MiniMax-Onboarding bzw. die API-Schlüssel-Einrichtung schreibt explizite M2.7-Modelldefinitionen mit
|
||||
`input: ["text", "image"]`; der gebündelte Anbieterkatalog hält die Chat-Referenzen
|
||||
als nur-Text, bis diese Anbieterkonfiguration materialisiert wird
|
||||
- Das MiniMax-Onboarding / die API-Key-Einrichtung schreibt explizite M2.7-Modell-Definitionen mit
|
||||
`input: ["text", "image"]`; der gebündelte Provider-Katalog behält die Chat-Referenzen
|
||||
text-only, bis diese Provider-Konfiguration materialisiert wird
|
||||
- Moonshot: `moonshot` (`MOONSHOT_API_KEY`)
|
||||
- Beispielmodell: `moonshot/kimi-k2.5`
|
||||
- Kimi Coding: `kimi` (`KIMI_API_KEY` oder `KIMICODE_API_KEY`)
|
||||
@ -412,12 +416,12 @@ Details zur Einrichtung finden Sie unter [/providers/kilocode](/de/providers/kil
|
||||
- BytePlus: `byteplus` (`BYTEPLUS_API_KEY`)
|
||||
- Beispielmodell: `byteplus-plan/ark-code-latest`
|
||||
- xAI: `xai` (`XAI_API_KEY`)
|
||||
- Native gebündelte xAI-Anfragen verwenden den xAI-Responses-Pfad
|
||||
- Native gebündelte xAI-Requests verwenden den xAI-Responses-Pfad
|
||||
- `/fast` oder `params.fastMode: true` schreiben `grok-3`, `grok-3-mini`,
|
||||
`grok-4` und `grok-4-0709` auf ihre `*-fast`-Varianten um
|
||||
- `tool_stream` ist standardmäßig aktiviert; setzen Sie
|
||||
- `tool_stream` ist standardmäßig aktiviert; setze
|
||||
`agents.defaults.models["xai/<model>"].params.tool_stream` auf `false`, um
|
||||
dies zu deaktivieren
|
||||
es zu deaktivieren
|
||||
- Mistral: `mistral` (`MISTRAL_API_KEY`)
|
||||
- Beispielmodell: `mistral/mistral-large-latest`
|
||||
- CLI: `openclaw onboard --auth-choice mistral-api-key`
|
||||
@ -428,22 +432,23 @@ Details zur Einrichtung finden Sie unter [/providers/kilocode](/de/providers/kil
|
||||
- GitHub Copilot: `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`)
|
||||
- Beispielmodell für Hugging Face Inference: `huggingface/deepseek-ai/DeepSeek-R1`; CLI: `openclaw onboard --auth-choice huggingface-api-key`. Siehe [Hugging Face (Inference)](/de/providers/huggingface).
|
||||
|
||||
## Anbieter über `models.providers` (benutzerdefiniert/Basis-URL)
|
||||
## Provider über `models.providers` (benutzerdefinierte/Basis-URL)
|
||||
|
||||
Verwenden Sie `models.providers` (oder `models.json`), um **benutzerdefinierte** Anbieter oder
|
||||
Verwende `models.providers` (oder `models.json`), um **benutzerdefinierte** Provider oder
|
||||
OpenAI-/Anthropic-kompatible Proxys hinzuzufügen.
|
||||
|
||||
Viele der unten aufgeführten gebündelten Anbieter-Plugins veröffentlichen bereits einen Standardkatalog.
|
||||
Verwenden Sie explizite Einträge unter `models.providers.<id>` nur dann, wenn Sie die
|
||||
Standard-Basis-URL, Header oder Modellliste überschreiben möchten.
|
||||
Viele der unten stehenden gebündelten Provider-Plugins veröffentlichen bereits einen Standardkatalog.
|
||||
Verwende explizite Einträge unter `models.providers.<id>` nur dann, wenn du die
|
||||
Standard-Basis-URL, Header oder Modellliste überschreiben möchtest.
|
||||
|
||||
### Moonshot AI (Kimi)
|
||||
|
||||
Moonshot wird als gebündeltes Anbieter-Plugin ausgeliefert. Verwenden Sie standardmäßig den integrierten Anbieter
|
||||
und fügen Sie nur dann einen expliziten Eintrag `models.providers.moonshot` hinzu, wenn Sie die Basis-URL oder Modellmetadaten überschreiben müssen:
|
||||
Moonshot wird als gebündeltes Provider-Plugin ausgeliefert. Verwende standardmäßig den eingebauten Provider
|
||||
und füge nur dann einen expliziten Eintrag `models.providers.moonshot` hinzu, wenn du
|
||||
die Basis-URL oder Modellmetadaten überschreiben musst:
|
||||
|
||||
- Anbieter: `moonshot`
|
||||
- Authentifizierung: `MOONSHOT_API_KEY`
|
||||
- Provider: `moonshot`
|
||||
- Auth: `MOONSHOT_API_KEY`
|
||||
- Beispielmodell: `moonshot/kimi-k2.5`
|
||||
- CLI: `openclaw onboard --auth-choice moonshot-api-key` oder `openclaw onboard --auth-choice moonshot-api-key-cn`
|
||||
|
||||
@ -481,8 +486,8 @@ Kimi-K2-Modell-IDs:
|
||||
|
||||
Kimi Coding verwendet den Anthropic-kompatiblen Endpunkt von Moonshot AI:
|
||||
|
||||
- Anbieter: `kimi`
|
||||
- Authentifizierung: `KIMI_API_KEY`
|
||||
- Provider: `kimi`
|
||||
- Auth: `KIMI_API_KEY`
|
||||
- Beispielmodell: `kimi/kimi-code`
|
||||
|
||||
```json5
|
||||
@ -494,14 +499,14 @@ Kimi Coding verwendet den Anthropic-kompatiblen Endpunkt von Moonshot AI:
|
||||
}
|
||||
```
|
||||
|
||||
Legacy-`kimi/k2p5` bleibt als kompatible Modell-ID akzeptiert.
|
||||
Das ältere `kimi/k2p5` bleibt als Kompatibilitäts-Modell-ID weiterhin akzeptiert.
|
||||
|
||||
### Volcano Engine (Doubao)
|
||||
|
||||
Volcano Engine (火山引擎) bietet Zugang zu Doubao und anderen Modellen in China.
|
||||
Volcano Engine (火山引擎) bietet Zugriff auf Doubao und andere Modelle in China.
|
||||
|
||||
- Anbieter: `volcengine` (Coding: `volcengine-plan`)
|
||||
- Authentifizierung: `VOLCANO_ENGINE_API_KEY`
|
||||
- Provider: `volcengine` (Coding: `volcengine-plan`)
|
||||
- Auth: `VOLCANO_ENGINE_API_KEY`
|
||||
- Beispielmodell: `volcengine-plan/ark-code-latest`
|
||||
- CLI: `openclaw onboard --auth-choice volcengine-api-key`
|
||||
|
||||
@ -513,13 +518,13 @@ Volcano Engine (火山引擎) bietet Zugang zu Doubao und anderen Modellen in Ch
|
||||
}
|
||||
```
|
||||
|
||||
Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine Katalog `volcengine/*`
|
||||
Das Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine Katalog `volcengine/*`
|
||||
wird gleichzeitig registriert.
|
||||
|
||||
In den Modell-Auswahlen für Onboarding/Configure bevorzugt die Volcengine-Auth-Auswahl sowohl
|
||||
Zeilen für `volcengine/*` als auch `volcengine-plan/*`. Wenn diese Modelle noch nicht geladen sind,
|
||||
fällt OpenClaw stattdessen auf den ungefilterten Katalog zurück, anstatt eine leere
|
||||
anbieterbezogene Auswahl anzuzeigen.
|
||||
In den Modell-Auswahlen für Onboarding/Konfiguration bevorzugt die Volcengine-Auth-Auswahl sowohl
|
||||
Zeilen mit `volcengine/*` als auch mit `volcengine-plan/*`. Wenn diese Modelle noch nicht geladen sind,
|
||||
fällt OpenClaw auf den ungefilterten Katalog zurück, anstatt einen leeren
|
||||
provider-spezifischen Picker anzuzeigen.
|
||||
|
||||
Verfügbare Modelle:
|
||||
|
||||
@ -539,10 +544,10 @@ Coding-Modelle (`volcengine-plan`):
|
||||
|
||||
### BytePlus (International)
|
||||
|
||||
BytePlus ARK bietet internationalen Nutzern Zugang zu denselben Modellen wie Volcano Engine.
|
||||
BytePlus ARK bietet internationalen Nutzern Zugriff auf dieselben Modelle wie Volcano Engine.
|
||||
|
||||
- Anbieter: `byteplus` (Coding: `byteplus-plan`)
|
||||
- Authentifizierung: `BYTEPLUS_API_KEY`
|
||||
- Provider: `byteplus` (Coding: `byteplus-plan`)
|
||||
- Auth: `BYTEPLUS_API_KEY`
|
||||
- Beispielmodell: `byteplus-plan/ark-code-latest`
|
||||
- CLI: `openclaw onboard --auth-choice byteplus-api-key`
|
||||
|
||||
@ -554,13 +559,13 @@ BytePlus ARK bietet internationalen Nutzern Zugang zu denselben Modellen wie Vol
|
||||
}
|
||||
```
|
||||
|
||||
Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine Katalog `byteplus/*`
|
||||
Das Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine Katalog `byteplus/*`
|
||||
wird gleichzeitig registriert.
|
||||
|
||||
In den Modell-Auswahlen für Onboarding/Configure bevorzugt die BytePlus-Auth-Auswahl sowohl
|
||||
Zeilen für `byteplus/*` als auch `byteplus-plan/*`. Wenn diese Modelle noch nicht geladen sind,
|
||||
fällt OpenClaw stattdessen auf den ungefilterten Katalog zurück, anstatt eine leere
|
||||
anbieterbezogene Auswahl anzuzeigen.
|
||||
In den Modell-Auswahlen für Onboarding/Konfiguration bevorzugt die BytePlus-Auth-Auswahl sowohl
|
||||
Zeilen mit `byteplus/*` als auch mit `byteplus-plan/*`. Wenn diese Modelle noch nicht geladen sind,
|
||||
fällt OpenClaw auf den ungefilterten Katalog zurück, anstatt einen leeren
|
||||
provider-spezifischen Picker anzuzeigen.
|
||||
|
||||
Verfügbare Modelle:
|
||||
|
||||
@ -578,10 +583,10 @@ Coding-Modelle (`byteplus-plan`):
|
||||
|
||||
### Synthetic
|
||||
|
||||
Synthetic stellt Anthropic-kompatible Modelle hinter dem Anbieter `synthetic` bereit:
|
||||
Synthetic stellt Anthropic-kompatible Modelle hinter dem Provider `synthetic` bereit:
|
||||
|
||||
- Anbieter: `synthetic`
|
||||
- Authentifizierung: `SYNTHETIC_API_KEY`
|
||||
- Provider: `synthetic`
|
||||
- Auth: `SYNTHETIC_API_KEY`
|
||||
- Beispielmodell: `synthetic/hf:MiniMaxAI/MiniMax-M2.5`
|
||||
- CLI: `openclaw onboard --auth-choice synthetic-api-key`
|
||||
|
||||
@ -610,35 +615,57 @@ MiniMax wird über `models.providers` konfiguriert, weil es benutzerdefinierte E
|
||||
|
||||
- MiniMax OAuth (Global): `--auth-choice minimax-global-oauth`
|
||||
- MiniMax OAuth (CN): `--auth-choice minimax-cn-oauth`
|
||||
- MiniMax API-Schlüssel (Global): `--auth-choice minimax-global-api`
|
||||
- MiniMax API-Schlüssel (CN): `--auth-choice minimax-cn-api`
|
||||
- Authentifizierung: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder
|
||||
- MiniMax API-Key (Global): `--auth-choice minimax-global-api`
|
||||
- MiniMax API-Key (CN): `--auth-choice minimax-cn-api`
|
||||
- Auth: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder
|
||||
`MINIMAX_API_KEY` für `minimax-portal`
|
||||
|
||||
Details zur Einrichtung, Modelloptionen und Konfigurations-Snippets finden Sie unter [/providers/minimax](/de/providers/minimax).
|
||||
Siehe [/providers/minimax](/de/providers/minimax) für Einrichtungsdetails, Modelloptionen und Konfigurations-Snippets.
|
||||
|
||||
Auf dem Anthropic-kompatiblen Streaming-Pfad von MiniMax deaktiviert OpenClaw Thinking
|
||||
standardmäßig, sofern Sie es nicht explizit festlegen, und `/fast on` schreibt
|
||||
`MiniMax-M2.7` zu `MiniMax-M2.7-highspeed` um.
|
||||
Auf dem Anthropic-kompatiblen Streaming-Pfad von MiniMax deaktiviert OpenClaw Thinking standardmäßig,
|
||||
es sei denn, du setzt es ausdrücklich, und `/fast on` schreibt
|
||||
`MiniMax-M2.7` auf `MiniMax-M2.7-highspeed` um.
|
||||
|
||||
Plugin-eigene Aufteilung der Fähigkeiten:
|
||||
|
||||
- Text-/Chat-Standardwerte bleiben bei `minimax/MiniMax-M2.7`
|
||||
- Text-/Chat-Standards bleiben auf `minimax/MiniMax-M2.7`
|
||||
- Bildgenerierung ist `minimax/image-01` oder `minimax-portal/image-01`
|
||||
- Bildverständnis ist plugin-eigenes `MiniMax-VL-01` auf beiden MiniMax-Authentifizierungspfaden
|
||||
- Websuche bleibt auf der Anbieter-ID `minimax`
|
||||
- Bildverständnis ist das Plugin-eigene `MiniMax-VL-01` auf beiden MiniMax-Auth-Pfaden
|
||||
- Websuche bleibt auf der Provider-ID `minimax`
|
||||
|
||||
### LM Studio
|
||||
|
||||
LM Studio wird als gebündeltes Provider-Plugin ausgeliefert, das die native API verwendet:
|
||||
|
||||
- Provider: `lmstudio`
|
||||
- Auth: `LM_API_TOKEN`
|
||||
- Standard-Basis-URL für Inferenz: `http://localhost:1234/v1`
|
||||
|
||||
Setze dann ein Modell (ersetze es durch eine der IDs, die von `http://localhost:1234/api/v1/models` zurückgegeben werden):
|
||||
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
defaults: { model: { primary: "lmstudio/openai/gpt-oss-20b" } },
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
OpenClaw verwendet die nativen Endpunkte `/api/v1/models` und `/api/v1/models/load` von LM Studio
|
||||
für Discovery + Auto-Load und standardmäßig `/v1/chat/completions` für Inferenz.
|
||||
Siehe [/providers/lmstudio](/de/providers/lmstudio) für Einrichtung und Fehlerbehebung.
|
||||
|
||||
### Ollama
|
||||
|
||||
Ollama wird als gebündeltes Anbieter-Plugin ausgeliefert und verwendet die native API von Ollama:
|
||||
Ollama wird als gebündeltes Provider-Plugin ausgeliefert und verwendet die native API von Ollama:
|
||||
|
||||
- Anbieter: `ollama`
|
||||
- Authentifizierung: Nicht erforderlich (lokaler Server)
|
||||
- Provider: `ollama`
|
||||
- Auth: Nicht erforderlich (lokaler Server)
|
||||
- Beispielmodell: `ollama/llama3.3`
|
||||
- Installation: [https://ollama.com/download](https://ollama.com/download)
|
||||
|
||||
```bash
|
||||
# Installieren Sie Ollama und laden Sie dann ein Modell:
|
||||
# Installiere Ollama und lade dann ein Modell:
|
||||
ollama pull llama3.3
|
||||
```
|
||||
|
||||
@ -650,27 +677,27 @@ ollama pull llama3.3
|
||||
}
|
||||
```
|
||||
|
||||
Ollama wird lokal unter `http://127.0.0.1:11434` erkannt, wenn Sie sich mit
|
||||
`OLLAMA_API_KEY` dafür anmelden, und das gebündelte Anbieter-Plugin fügt Ollama direkt zu
|
||||
Ollama wird lokal unter `http://127.0.0.1:11434` erkannt, wenn du dich mit
|
||||
`OLLAMA_API_KEY` dafür entscheidest, und das gebündelte Provider-Plugin fügt Ollama direkt zu
|
||||
`openclaw onboard` und der Modellauswahl hinzu. Siehe [/providers/ollama](/de/providers/ollama)
|
||||
für Onboarding, Cloud-/Lokalmodus und benutzerdefinierte Konfiguration.
|
||||
|
||||
### vLLM
|
||||
|
||||
vLLM wird als gebündeltes Anbieter-Plugin für lokale/selbstgehostete OpenAI-kompatible
|
||||
vLLM wird als gebündeltes Provider-Plugin für lokale/selbst gehostete OpenAI-kompatible
|
||||
Server ausgeliefert:
|
||||
|
||||
- Anbieter: `vllm`
|
||||
- Authentifizierung: Optional (abhängig von Ihrem Server)
|
||||
- Provider: `vllm`
|
||||
- Auth: Optional (abhängig von deinem Server)
|
||||
- Standard-Basis-URL: `http://127.0.0.1:8000/v1`
|
||||
|
||||
Um sich lokal für die automatische Erkennung anzumelden (jeder Wert funktioniert, wenn Ihr Server keine Authentifizierung erzwingt):
|
||||
Um dich lokal für die automatische Erkennung zu entscheiden (jeder Wert funktioniert, wenn dein Server keine Auth erzwingt):
|
||||
|
||||
```bash
|
||||
export VLLM_API_KEY="vllm-local"
|
||||
```
|
||||
|
||||
Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der von `/v1/models` zurückgegebenen IDs):
|
||||
Setze dann ein Modell (ersetze es durch eine der IDs, die von `/v1/models` zurückgegeben werden):
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -680,25 +707,25 @@ Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der von `/v1/models`
|
||||
}
|
||||
```
|
||||
|
||||
Details finden Sie unter [/providers/vllm](/de/providers/vllm).
|
||||
Siehe [/providers/vllm](/de/providers/vllm) für Details.
|
||||
|
||||
### SGLang
|
||||
|
||||
SGLang wird als gebündeltes Anbieter-Plugin für schnelle selbstgehostete
|
||||
SGLang wird als gebündeltes Provider-Plugin für schnelle selbst gehostete
|
||||
OpenAI-kompatible Server ausgeliefert:
|
||||
|
||||
- Anbieter: `sglang`
|
||||
- Authentifizierung: Optional (abhängig von Ihrem Server)
|
||||
- Provider: `sglang`
|
||||
- Auth: Optional (abhängig von deinem Server)
|
||||
- Standard-Basis-URL: `http://127.0.0.1:30000/v1`
|
||||
|
||||
Um sich lokal für die automatische Erkennung anzumelden (jeder Wert funktioniert, wenn Ihr Server keine Authentifizierung
|
||||
Um dich lokal für die automatische Erkennung zu entscheiden (jeder Wert funktioniert, wenn dein Server keine Auth
|
||||
erzwingt):
|
||||
|
||||
```bash
|
||||
export SGLANG_API_KEY="sglang-local"
|
||||
```
|
||||
|
||||
Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der von `/v1/models` zurückgegebenen IDs):
|
||||
Setze dann ein Modell (ersetze es durch eine der IDs, die von `/v1/models` zurückgegeben werden):
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -708,7 +735,7 @@ Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der von `/v1/models`
|
||||
}
|
||||
```
|
||||
|
||||
Details finden Sie unter [/providers/sglang](/de/providers/sglang).
|
||||
Siehe [/providers/sglang](/de/providers/sglang) für Details.
|
||||
|
||||
### Lokale Proxys (LM Studio, vLLM, LiteLLM usw.)
|
||||
|
||||
@ -719,19 +746,19 @@ Beispiel (OpenAI-kompatibel):
|
||||
agents: {
|
||||
defaults: {
|
||||
model: { primary: "lmstudio/my-local-model" },
|
||||
models: { "lmstudio/my-local-model": { alias: "Local" } },
|
||||
models: { "lmstudio/my-local-model": { alias: "Lokal" } },
|
||||
},
|
||||
},
|
||||
models: {
|
||||
providers: {
|
||||
lmstudio: {
|
||||
baseUrl: "http://localhost:1234/v1",
|
||||
apiKey: "LMSTUDIO_KEY",
|
||||
apiKey: "${LM_API_TOKEN}",
|
||||
api: "openai-completions",
|
||||
models: [
|
||||
{
|
||||
id: "my-local-model",
|
||||
name: "Local Model",
|
||||
name: "Lokales Modell",
|
||||
reasoning: false,
|
||||
input: ["text"],
|
||||
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
|
||||
@ -747,20 +774,19 @@ Beispiel (OpenAI-kompatibel):
|
||||
|
||||
Hinweise:
|
||||
|
||||
- Für benutzerdefinierte Anbieter sind `reasoning`, `input`, `cost`, `contextWindow` und `maxTokens` optional.
|
||||
- Für benutzerdefinierte Provider sind `reasoning`, `input`, `cost`, `contextWindow` und `maxTokens` optional.
|
||||
Wenn sie weggelassen werden, verwendet OpenClaw standardmäßig:
|
||||
- `reasoning: false`
|
||||
- `input: ["text"]`
|
||||
- `cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }`
|
||||
- `contextWindow: 200000`
|
||||
- `maxTokens: 8192`
|
||||
- Empfohlen: Legen Sie explizite Werte fest, die den Grenzen Ihres Proxys/Modells entsprechen.
|
||||
- Für `api: "openai-completions"` auf nicht nativen Endpunkten (jede nicht leere `baseUrl`, deren Host nicht `api.openai.com` ist), erzwingt OpenClaw `compat.supportsDeveloperRole: false`, um 400-Fehler des Anbieters für nicht unterstützte `developer`-Rollen zu vermeiden.
|
||||
- Proxy-artige OpenAI-kompatible Routen überspringen außerdem native, nur für OpenAI bestimmte Anfrageformung:
|
||||
kein `service_tier`, kein Responses-`store`, keine Prompt-Cache-Hinweise, keine
|
||||
OpenAI-Reasoning-kompatible Payload-Formung und keine versteckten OpenClaw-Attributions-
|
||||
Header.
|
||||
- Wenn `baseUrl` leer ist oder weggelassen wird, behält OpenClaw das Standardverhalten von OpenAI bei (das zu `api.openai.com` aufgelöst wird).
|
||||
- Empfohlen: Setze explizite Werte, die zu den Grenzwerten deines Proxys/Modells passen.
|
||||
- Für `api: "openai-completions"` auf nicht nativen Endpunkten (jede nicht leere `baseUrl`, deren Host nicht `api.openai.com` ist) erzwingt OpenClaw `compat.supportsDeveloperRole: false`, um Provider-400-Fehler für nicht unterstützte `developer`-Rollen zu vermeiden.
|
||||
- Proxyartige OpenAI-kompatible Routen überspringen ebenfalls natives
|
||||
OpenAI-only-Request-Shaping: kein `service_tier`, kein Responses-`store`, keine Prompt-Cache-Hinweise, kein
|
||||
OpenAI-Reasoning-kompatibles Payload-Shaping und keine versteckten OpenClaw-Attribution-Header.
|
||||
- Wenn `baseUrl` leer ist/weggelassen wird, behält OpenClaw das Standardverhalten von OpenAI bei (das zu `api.openai.com` aufgelöst wird).
|
||||
- Aus Sicherheitsgründen wird ein explizites `compat.supportsDeveloperRole: true` auf nicht nativen `openai-completions`-Endpunkten weiterhin überschrieben.
|
||||
|
||||
## CLI-Beispiele
|
||||
@ -776,6 +802,6 @@ Siehe auch: [/gateway/configuration](/de/gateway/configuration) für vollständi
|
||||
## Verwandt
|
||||
|
||||
- [Models](/de/concepts/models) — Modellkonfiguration und Aliasse
|
||||
- [Model Failover](/de/concepts/model-failover) — Fallback-Ketten und Wiederholungsverhalten
|
||||
- [Configuration Reference](/de/gateway/configuration-reference#agent-defaults) — Modellkonfigurationsschlüssel
|
||||
- [Providers](/de/providers) — anbieterbezogene Einrichtungsanleitungen
|
||||
- [Model Failover](/de/concepts/model-failover) — Fallback-Ketten und Retry-Verhalten
|
||||
- [Configuration Reference](/de/gateway/configuration-reference#agent-defaults) — Modell-Konfigurationsschlüssel
|
||||
- [Providers](/de/providers) — Einrichtungsanleitungen pro Provider
|
||||
|
||||
@ -1,28 +1,28 @@
|
||||
---
|
||||
read_when:
|
||||
- Sie möchten Modelle von Ihrer eigenen GPU-Maschine bereitstellen
|
||||
- Sie binden LM Studio oder einen OpenAI-kompatiblen Proxy an
|
||||
- Sie benötigen die sicherste Anleitung für lokale Modelle
|
||||
summary: OpenClaw mit lokalen LLMs ausführen (LM Studio, vLLM, LiteLLM, benutzerdefinierte OpenAI-Endpunkte)
|
||||
- Sie möchten Modelle von Ihrer eigenen GPU-Maschine bereitstellen.
|
||||
- Sie richten LM Studio oder einen OpenAI-kompatiblen Proxy ein.
|
||||
- Sie benötigen die sicherste Anleitung für lokale Modelle.
|
||||
summary: Führen Sie OpenClaw auf lokalen LLMs aus (LM Studio, vLLM, LiteLLM, benutzerdefinierte OpenAI-Endpunkte)
|
||||
title: Lokale Modelle
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:14:53Z"
|
||||
generated_at: "2026-04-13T08:50:41Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: d619d72b0e06914ebacb7e9f38b746caf1b9ce8908c9c6638c3acdddbaa025e8
|
||||
source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a
|
||||
source_path: gateway/local-models.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Lokale Modelle
|
||||
|
||||
Lokal ist machbar, aber OpenClaw erwartet großen Kontext und starke Abwehr gegen Prompt Injection. Kleine Karten kürzen den Kontext und schwächen die Sicherheit. Setzen Sie hohe Maßstäbe an: **≥2 voll ausgestattete Mac Studios oder ein gleichwertiges GPU-System (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts mit höherer Latenz. Verwenden Sie die **größte / vollwertige Modellvariante, die Sie ausführen können**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Risiko von Prompt Injection (siehe [Sicherheit](/de/gateway/security)).
|
||||
Lokal ist machbar, aber OpenClaw erwartet einen großen Kontext sowie starke Abwehrmaßnahmen gegen Prompt Injection. Kleine Karten kürzen den Kontext und schwächen die Sicherheit. Setzen Sie hoch an: **≥2 voll ausgestattete Mac Studios oder ein vergleichbares GPU-System (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts mit höherer Latenz. Verwenden Sie die **größte / vollwertige Modellvariante, die Sie ausführen können**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Risiko für Prompt Injection (siehe [Sicherheit](/de/gateway/security)).
|
||||
|
||||
Wenn Sie die lokale Einrichtung mit der geringsten Reibung möchten, beginnen Sie mit [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für höherwertige lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server.
|
||||
Wenn Sie die lokale Einrichtung mit dem geringsten Aufwand möchten, beginnen Sie mit [LM Studio](/de/providers/lmstudio) oder [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für hochwertigere lokale Stacks und benutzerdefinierte lokale OpenAI-kompatible Server.
|
||||
|
||||
## Empfohlen: LM Studio + großes lokales Modell (Responses API)
|
||||
|
||||
Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (standardmäßig `http://127.0.0.1:1234`) und verwenden Sie Responses API, um Reasoning vom endgültigen Text getrennt zu halten.
|
||||
Der aktuell beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (Standard: `http://127.0.0.1:1234`) und verwenden Sie die Responses API, um das Reasoning vom endgültigen Text getrennt zu halten.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -59,16 +59,16 @@ Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum B
|
||||
}
|
||||
```
|
||||
|
||||
**Checkliste zur Einrichtung**
|
||||
**Checkliste für die Einrichtung**
|
||||
|
||||
- Installieren Sie LM Studio: [https://lmstudio.ai](https://lmstudio.ai)
|
||||
- Laden Sie in LM Studio den **größten verfügbaren Modell-Build** herunter (vermeiden Sie „small“-/stark quantisierte Varianten), starten Sie den Server und bestätigen Sie, dass `http://127.0.0.1:1234/v1/models` ihn auflistet.
|
||||
- Laden Sie in LM Studio den **größten verfügbaren Modell-Build** herunter (vermeiden Sie „kleine“/stark quantisierte Varianten), starten Sie den Server und prüfen Sie, ob `http://127.0.0.1:1234/v1/models` das Modell auflistet.
|
||||
- Ersetzen Sie `my-local-model` durch die tatsächliche Modell-ID, die in LM Studio angezeigt wird.
|
||||
- Halten Sie das Modell geladen; Kaltladen erhöht die Startlatenz.
|
||||
- Passen Sie `contextWindow`/`maxTokens` an, wenn sich Ihr LM Studio-Build unterscheidet.
|
||||
- Für WhatsApp sollten Sie bei Responses API bleiben, damit nur der endgültige Text gesendet wird.
|
||||
- Lassen Sie das Modell geladen; das Kaltladen erhöht die Startlatenz.
|
||||
- Passen Sie `contextWindow`/`maxTokens` an, wenn Ihr LM-Studio-Build abweicht.
|
||||
- Für WhatsApp sollten Sie bei der Responses API bleiben, damit nur der endgültige Text gesendet wird.
|
||||
|
||||
Lassen Sie gehostete Modelle auch beim lokalen Betrieb konfiguriert; verwenden Sie `models.mode: "merge"`, damit Fallbacks verfügbar bleiben.
|
||||
Behalten Sie gehostete Modelle auch dann konfiguriert, wenn Sie lokal ausführen; verwenden Sie `models.mode: "merge"`, damit Fallbacks verfügbar bleiben.
|
||||
|
||||
### Hybride Konfiguration: gehostet als primär, lokal als Fallback
|
||||
|
||||
@ -113,12 +113,12 @@ Lassen Sie gehostete Modelle auch beim lokalen Betrieb konfiguriert; verwenden S
|
||||
|
||||
### Lokal zuerst mit gehostetem Sicherheitsnetz
|
||||
|
||||
Tauschen Sie die Reihenfolge von primärem Modell und Fallbacks; behalten Sie denselben Provider-Block und `models.mode: "merge"` bei, damit Sie auf Sonnet oder Opus zurückfallen können, wenn die lokale Maschine ausfällt.
|
||||
Tauschen Sie die Reihenfolge von primärem Modell und Fallback aus; behalten Sie denselben Provider-Block und `models.mode: "merge"` bei, damit Sie auf Sonnet oder Opus zurückfallen können, wenn die lokale Maschine ausfällt.
|
||||
|
||||
### Regionales Hosting / Datenrouting
|
||||
|
||||
- Gehostete MiniMax-/Kimi-/GLM-Varianten gibt es auch auf OpenRouter mit regional gebundenen Endpunkten (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante, um den Datenverkehr in Ihrer gewünschten Gerichtsbarkeit zu halten und dennoch `models.mode: "merge"` für Anthropic-/OpenAI-Fallbacks zu verwenden.
|
||||
- Nur lokal bleibt der stärkste Datenschutzpfad; gehostetes regionales Routing ist der Mittelweg, wenn Sie Provider-Funktionen benötigen, aber Kontrolle über den Datenfluss wünschen.
|
||||
- Gehostete MiniMax-, Kimi- und GLM-Varianten sind auch auf OpenRouter mit regional festgelegten Endpunkten verfügbar (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante, um den Datenverkehr in Ihrer gewünschten Jurisdiktion zu halten und trotzdem `models.mode: "merge"` für Anthropic/OpenAI-Fallbacks zu verwenden.
|
||||
- Ausschließlich lokal bleibt der stärkste Datenschutzpfad; regionales Hosting ist der Mittelweg, wenn Sie Provider-Funktionen benötigen, aber den Datenfluss kontrollieren möchten.
|
||||
|
||||
## Andere OpenAI-kompatible lokale Proxys
|
||||
|
||||
@ -152,40 +152,39 @@ vLLM, LiteLLM, OAI-proxy oder benutzerdefinierte Gateways funktionieren, wenn si
|
||||
|
||||
Behalten Sie `models.mode: "merge"` bei, damit gehostete Modelle als Fallbacks verfügbar bleiben.
|
||||
|
||||
Verhaltenshinweis für lokale/proxied `/v1`-Backends:
|
||||
Verhaltenshinweis für lokale/proxierte `/v1`-Backends:
|
||||
|
||||
- OpenClaw behandelt diese als Proxy-artige OpenAI-kompatible Routen, nicht als native
|
||||
OpenAI-Endpunkte
|
||||
- rein native OpenAI-Anpassungen für Requests gelten hier nicht: kein
|
||||
`service_tier`, kein Responses-`store`, keine OpenAI-Reasoning-Kompatibilitäts-
|
||||
Anpassung der Payload und keine Prompt-Cache-Hinweise
|
||||
- versteckte OpenClaw-Attribution-Header (`originator`, `version`, `User-Agent`)
|
||||
werden auf diesen benutzerdefinierten Proxy-URLs nicht eingefügt
|
||||
- OpenClaw behandelt diese als proxyartige OpenAI-kompatible Routen, nicht als native OpenAI-Endpunkte.
|
||||
- Native, nur für OpenAI geltende Request-Formung gilt hier nicht: kein
|
||||
`service_tier`, kein Responses-`store`, keine OpenAI-Reasoning-Kompatibilitäts-Payload-Formung
|
||||
und keine Prompt-Cache-Hinweise.
|
||||
- Versteckte OpenClaw-Attributions-Header (`originator`, `version`, `User-Agent`)
|
||||
werden bei diesen benutzerdefinierten Proxy-URLs nicht eingefügt.
|
||||
|
||||
Kompatibilitätshinweise für strengere OpenAI-kompatible Backends:
|
||||
|
||||
- Einige Server akzeptieren bei Chat Completions nur String-`messages[].content`, nicht
|
||||
strukturierte Content-Part-Arrays. Setzen Sie
|
||||
- Manche Server akzeptieren bei Chat Completions nur String-Werte in `messages[].content`, keine
|
||||
strukturierten Content-Part-Arrays. Setzen Sie
|
||||
`models.providers.<provider>.models[].compat.requiresStringContent: true` für
|
||||
diese Endpunkte.
|
||||
- Einige kleinere oder strengere lokale Backends sind mit der vollständigen
|
||||
Prompt-Form der OpenClaw-Agent-Laufzeit instabil, insbesondere wenn Tool-Schemas enthalten sind. Wenn das
|
||||
Backend für kleine direkte `/v1/chat/completions`-Aufrufe funktioniert, aber bei normalen
|
||||
- Manche kleineren oder strengeren lokalen Backends sind mit der vollständigen
|
||||
Prompt-Form des OpenClaw-Agent-Runtimes instabil, insbesondere wenn Tool-Schemas enthalten sind. Wenn das
|
||||
Backend bei kleinen direkten `/v1/chat/completions`-Aufrufen funktioniert, aber bei normalen
|
||||
OpenClaw-Agent-Turns fehlschlägt, versuchen Sie zuerst
|
||||
`models.providers.<provider>.models[].compat.supportsTools: false`.
|
||||
- Wenn das Backend weiterhin nur bei größeren OpenClaw-Läufen fehlschlägt, liegt das verbleibende Problem
|
||||
in der Regel an der Kapazität des Upstream-Modells/Servers oder an einem Backend-Fehler, nicht an der
|
||||
Transportebene von OpenClaw.
|
||||
- Wenn das Backend weiterhin nur bei größeren OpenClaw-Ausführungen fehlschlägt,
|
||||
liegt das verbleibende Problem in der Regel an der Kapazität des vorgeschalteten Modells/Servers
|
||||
oder an einem Backend-Fehler, nicht an der Transportebene von OpenClaw.
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
- Kann das Gateway den Proxy erreichen? `curl http://127.0.0.1:1234/v1/models`.
|
||||
- LM Studio-Modell entladen? Laden Sie es erneut; Kaltstart ist eine häufige Ursache für „Hängenbleiben“.
|
||||
- Kontextfehler? Verringern Sie `contextWindow` oder erhöhen Sie das Limit Ihres Servers.
|
||||
- Der OpenAI-kompatible Server gibt `messages[].content ... expected a string` zurück?
|
||||
Fügen Sie `compat.requiresStringContent: true` bei diesem Modelleintrag hinzu.
|
||||
- Kann Gateway den Proxy erreichen? `curl http://127.0.0.1:1234/v1/models`.
|
||||
- LM-Studio-Modell entladen? Laden Sie es erneut; ein Kaltstart ist eine häufige Ursache für „Hängenbleiben“.
|
||||
- Kontextfehler? Verringern Sie `contextWindow` oder erhöhen Sie Ihr Server-Limit.
|
||||
- OpenAI-kompatibler Server gibt `messages[].content ... expected a string` zurück?
|
||||
Fügen Sie beim entsprechenden Modelleintrag `compat.requiresStringContent: true` hinzu.
|
||||
- Kleine direkte `/v1/chat/completions`-Aufrufe funktionieren, aber `openclaw infer model run`
|
||||
schlägt bei Gemma oder einem anderen lokalen Modell fehl? Deaktivieren Sie zuerst Tool-Schemas mit
|
||||
`compat.supportsTools: false` und testen Sie dann erneut. Wenn der Server weiterhin nur
|
||||
bei größeren OpenClaw-Prompts abstürzt, behandeln Sie dies als Einschränkung des Upstream-Servers/-Modells.
|
||||
- Sicherheit: Lokale Modelle überspringen providerseitige Filter; halten Sie Agents eng gefasst und die Kompaktierung aktiviert, um den Wirkungsbereich von Prompt Injection zu begrenzen.
|
||||
bei größeren OpenClaw-Prompts abstürzt, behandeln Sie das als Einschränkung des vorgeschalteten Servers/Modells.
|
||||
- Sicherheit: Lokale Modelle umgehen providerseitige Filter; halten Sie Agents eng begrenzt und lassen Sie Compaction aktiviert, um den Wirkungsradius von Prompt Injection zu begrenzen.
|
||||
|
||||
@ -1,24 +1,23 @@
|
||||
---
|
||||
read_when:
|
||||
- Sie möchten einen Modellanbieter auswählen
|
||||
- Sie benötigen einen schnellen Überblick über unterstützte LLM-Backends
|
||||
- Sie benötigen einen schnellen Überblick über die unterstützten LLM-Backends
|
||||
summary: Von OpenClaw unterstützte Modellanbieter (LLMs)
|
||||
title: Anbieterverzeichnis
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:17:47Z"
|
||||
generated_at: "2026-04-13T08:50:42Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: e7bee5528b7fc9a982b3d0eaa4930cb77f7bded19a47aec00572b6fcbd823a70
|
||||
source_hash: 3bc682d008119719826f71f74959ab32bedf14214459f5e6ac9cb70371d3c540
|
||||
source_path: providers/index.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Modellanbieter
|
||||
|
||||
OpenClaw kann viele LLM-Anbieter verwenden. Wählen Sie einen Anbieter aus, authentifizieren Sie sich und setzen Sie dann das
|
||||
Standardmodell als `provider/model`.
|
||||
OpenClaw kann viele LLM-Anbieter verwenden. Wählen Sie einen Anbieter aus, authentifizieren Sie sich und legen Sie dann das Standardmodell als `provider/model` fest.
|
||||
|
||||
Suchen Sie nach Dokumentation zu Chat-Kanälen (WhatsApp/Telegram/Discord/Slack/Mattermost (Plugin)/usw.)? Siehe [Channels](/de/channels).
|
||||
Suchen Sie nach Dokumentation zu Chat-Kanälen (WhatsApp/Telegram/Discord/Slack/Mattermost (Plugin)/etc.)? Siehe [Kanäle](/de/channels).
|
||||
|
||||
## Schnellstart
|
||||
|
||||
@ -37,7 +36,7 @@ Suchen Sie nach Dokumentation zu Chat-Kanälen (WhatsApp/Telegram/Discord/Slack/
|
||||
- [Amazon Bedrock](/de/providers/bedrock)
|
||||
- [Anthropic (API + Claude CLI)](/de/providers/anthropic)
|
||||
- [Arcee AI (Trinity-Modelle)](/de/providers/arcee)
|
||||
- [BytePlus (International)](/de/concepts/model-providers#byteplus-international)
|
||||
- [BytePlus (international)](/de/concepts/model-providers#byteplus-international)
|
||||
- [Chutes](/de/providers/chutes)
|
||||
- [ComfyUI](/de/providers/comfy)
|
||||
- [Cloudflare AI Gateway](/de/providers/cloudflare-ai-gateway)
|
||||
@ -48,15 +47,16 @@ Suchen Sie nach Dokumentation zu Chat-Kanälen (WhatsApp/Telegram/Discord/Slack/
|
||||
- [GLM-Modelle](/de/providers/glm)
|
||||
- [Google (Gemini)](/de/providers/google)
|
||||
- [Groq (LPU-Inferenz)](/de/providers/groq)
|
||||
- [Hugging Face (Inference)](/de/providers/huggingface)
|
||||
- [Hugging Face (Inferenz)](/de/providers/huggingface)
|
||||
- [inferrs (lokale Modelle)](/de/providers/inferrs)
|
||||
- [Kilocode](/de/providers/kilocode)
|
||||
- [LiteLLM (einheitliches Gateway)](/de/providers/litellm)
|
||||
- [LM Studio (lokale Modelle)](/de/providers/lmstudio)
|
||||
- [MiniMax](/de/providers/minimax)
|
||||
- [Mistral](/de/providers/mistral)
|
||||
- [Moonshot AI (Kimi + Kimi Coding)](/de/providers/moonshot)
|
||||
- [NVIDIA](/de/providers/nvidia)
|
||||
- [Ollama (Cloud- + lokale Modelle)](/de/providers/ollama)
|
||||
- [Ollama (Cloud- und lokale Modelle)](/de/providers/ollama)
|
||||
- [OpenAI (API + Codex)](/de/providers/openai)
|
||||
- [OpenCode](/de/providers/opencode)
|
||||
- [OpenCode Go](/de/providers/opencode-go)
|
||||
@ -80,18 +80,17 @@ Suchen Sie nach Dokumentation zu Chat-Kanälen (WhatsApp/Telegram/Discord/Slack/
|
||||
|
||||
## Gemeinsame Übersichtsseiten
|
||||
|
||||
- [Additional bundled variants](/de/providers/models#additional-bundled-provider-variants) - Anthropic Vertex, Copilot Proxy und Gemini CLI OAuth
|
||||
- [Image Generation](/de/tools/image-generation) - Gemeinsames Tool `image_generate`, Anbieterauswahl und Failover
|
||||
- [Music Generation](/de/tools/music-generation) - Gemeinsames Tool `music_generate`, Anbieterauswahl und Failover
|
||||
- [Video Generation](/de/tools/video-generation) - Gemeinsames Tool `video_generate`, Anbieterauswahl und Failover
|
||||
- [Zusätzliche gebündelte Varianten](/de/providers/models#additional-bundled-provider-variants) - Anthropic Vertex, Copilot Proxy und Gemini CLI OAuth
|
||||
- [Bildgenerierung](/de/tools/image-generation) - Gemeinsames `image_generate`-Tool, Anbieterauswahl und Failover
|
||||
- [Musikgenerierung](/de/tools/music-generation) - Gemeinsames `music_generate`-Tool, Anbieterauswahl und Failover
|
||||
- [Videogenerierung](/de/tools/video-generation) - Gemeinsames `video_generate`-Tool, Anbieterauswahl und Failover
|
||||
|
||||
## Transkriptionsanbieter
|
||||
## Anbieter für Transkription
|
||||
|
||||
- [Deepgram (Audiotranskription)](/de/providers/deepgram)
|
||||
|
||||
## Community-Tools
|
||||
|
||||
- [Claude Max API Proxy](/de/providers/claude-max-api-proxy) - Community-Proxy für Claude-Abonnement-Anmeldedaten (prüfen Sie vor der Verwendung die Richtlinien/Nutzungsbedingungen von Anthropic)
|
||||
- [Claude Max API Proxy](/de/providers/claude-max-api-proxy) - Community-Proxy für Claude-Abonnement-Anmeldedaten (überprüfen Sie vor der Verwendung die Richtlinien/Nutzungsbedingungen von Anthropic)
|
||||
|
||||
Den vollständigen Anbieterkatalog (xAI, Groq, Mistral usw.) und die erweiterte Konfiguration finden Sie unter
|
||||
[Model providers](/de/concepts/model-providers).
|
||||
Für den vollständigen Anbieterkatalog (xAI, Groq, Mistral usw.) und die erweiterte Konfiguration siehe [Modellanbieter](/de/concepts/model-providers).
|
||||
|
||||
163
docs/de/providers/lmstudio.md
Normal file
163
docs/de/providers/lmstudio.md
Normal file
@ -0,0 +1,163 @@
|
||||
---
|
||||
read_when:
|
||||
- Sie möchten OpenClaw mit Open-Source-Modellen über LM Studio ausführen
|
||||
- Sie möchten LM Studio einrichten und konfigurieren
|
||||
summary: Führe OpenClaw mit LM Studio aus
|
||||
title: LM Studio
|
||||
x-i18n:
|
||||
generated_at: "2026-04-13T08:50:40Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 11264584e8277260d4215feb7c751329ce04f59e9228da1c58e147c21cd9ac2c
|
||||
source_path: providers/lmstudio.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# LM Studio
|
||||
|
||||
LM Studio ist eine benutzerfreundliche und zugleich leistungsstarke App, mit der Sie Open-Weight-Modelle auf Ihrer eigenen Hardware ausführen können. Sie ermöglicht das Ausführen von llama.cpp- (GGUF) oder MLX-Modellen (Apple Silicon). Sie ist als GUI-Paket oder als Headless-Daemon (`llmster`) verfügbar. Produkt- und Einrichtungsdokumentation finden Sie unter [lmstudio.ai](https://lmstudio.ai/).
|
||||
|
||||
## Schnellstart
|
||||
|
||||
1. Installieren Sie LM Studio (Desktop) oder `llmster` (Headless) und starten Sie dann den lokalen Server:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://lmstudio.ai/install.sh | bash
|
||||
```
|
||||
|
||||
2. Starten Sie den Server
|
||||
|
||||
Stellen Sie sicher, dass Sie entweder die Desktop-App starten oder den Daemon mit folgendem Befehl ausführen:
|
||||
|
||||
```bash
|
||||
lms daemon up
|
||||
```
|
||||
|
||||
```bash
|
||||
lms server start --port 1234
|
||||
```
|
||||
|
||||
Wenn Sie die App verwenden, stellen Sie sicher, dass JIT für ein reibungsloses Erlebnis aktiviert ist. Weitere Informationen finden Sie im [Leitfaden zu LM Studio JIT und TTL](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict).
|
||||
|
||||
3. OpenClaw benötigt einen LM Studio-Tokenwert. Setzen Sie `LM_API_TOKEN`:
|
||||
|
||||
```bash
|
||||
export LM_API_TOKEN="your-lm-studio-api-token"
|
||||
```
|
||||
|
||||
Wenn die LM Studio-Authentifizierung deaktiviert ist, verwenden Sie einen beliebigen nicht leeren Tokenwert:
|
||||
|
||||
```bash
|
||||
export LM_API_TOKEN="placeholder-key"
|
||||
```
|
||||
|
||||
Einzelheiten zur Einrichtung der LM Studio-Authentifizierung finden Sie unter [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
|
||||
|
||||
4. Führen Sie das Onboarding aus und wählen Sie `LM Studio`:
|
||||
|
||||
```bash
|
||||
openclaw onboard
|
||||
```
|
||||
|
||||
5. Verwenden Sie im Onboarding die Eingabeaufforderung `Default model`, um Ihr LM Studio-Modell auszuwählen.
|
||||
|
||||
Sie können es auch später festlegen oder ändern:
|
||||
|
||||
```bash
|
||||
openclaw models set lmstudio/qwen/qwen3.5-9b
|
||||
```
|
||||
|
||||
LM Studio-Modellschlüssel folgen dem Format `author/model-name` (z. B. `qwen/qwen3.5-9b`). OpenClaw-Modellreferenzen stellen den Providernamen voran: `lmstudio/qwen/qwen3.5-9b`. Sie finden den genauen Schlüssel für ein Modell, indem Sie `curl http://localhost:1234/api/v1/models` ausführen und im Feld `key` nachsehen.
|
||||
|
||||
## Nicht interaktives Onboarding
|
||||
|
||||
Verwenden Sie das nicht interaktive Onboarding, wenn Sie die Einrichtung skripten möchten (CI, Bereitstellung, Remote-Bootstrap):
|
||||
|
||||
```bash
|
||||
openclaw onboard \
|
||||
--non-interactive \
|
||||
--accept-risk \
|
||||
--auth-choice lmstudio
|
||||
```
|
||||
|
||||
Oder geben Sie mit API-Schlüssel die Basis-URL oder das Modell an:
|
||||
|
||||
```bash
|
||||
openclaw onboard \
|
||||
--non-interactive \
|
||||
--accept-risk \
|
||||
--auth-choice lmstudio \
|
||||
--custom-base-url http://localhost:1234/v1 \
|
||||
--lmstudio-api-key "$LM_API_TOKEN" \
|
||||
--custom-model-id qwen/qwen3.5-9b
|
||||
```
|
||||
|
||||
`--custom-model-id` verwendet den von LM Studio zurückgegebenen Modellschlüssel (z. B. `qwen/qwen3.5-9b`) ohne das Providerpräfix `lmstudio/`.
|
||||
|
||||
Für das nicht interaktive Onboarding ist `--lmstudio-api-key` erforderlich (oder `LM_API_TOKEN` in der Umgebung).
|
||||
Für nicht authentifizierte LM Studio-Server funktioniert jeder nicht leere Tokenwert.
|
||||
|
||||
`--custom-api-key` wird aus Kompatibilitätsgründen weiterhin unterstützt, aber `--lmstudio-api-key` wird für LM Studio bevorzugt.
|
||||
|
||||
Dadurch wird `models.providers.lmstudio` geschrieben, das Standardmodell auf
|
||||
`lmstudio/<custom-model-id>` gesetzt und das Auth-Profil `lmstudio:default` geschrieben.
|
||||
|
||||
Die interaktive Einrichtung kann nach einer optionalen bevorzugten Kontextlänge beim Laden fragen und wendet sie auf die erkannten LM Studio-Modelle an, die in der Konfiguration gespeichert werden.
|
||||
|
||||
## Konfiguration
|
||||
|
||||
### Explizite Konfiguration
|
||||
|
||||
```json5
|
||||
{
|
||||
models: {
|
||||
providers: {
|
||||
lmstudio: {
|
||||
baseUrl: "http://localhost:1234/v1",
|
||||
apiKey: "${LM_API_TOKEN}",
|
||||
api: "openai-completions",
|
||||
models: [
|
||||
{
|
||||
id: "qwen/qwen3-coder-next",
|
||||
name: "Qwen 3 Coder Next",
|
||||
reasoning: false,
|
||||
input: ["text"],
|
||||
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
|
||||
contextWindow: 128000,
|
||||
maxTokens: 8192,
|
||||
},
|
||||
],
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### LM Studio wurde nicht erkannt
|
||||
|
||||
Stellen Sie sicher, dass LM Studio ausgeführt wird und dass Sie `LM_API_TOKEN` gesetzt haben (für nicht authentifizierte Server funktioniert jeder nicht leere Tokenwert):
|
||||
|
||||
```bash
|
||||
# Starten Sie über die Desktop-App oder headless:
|
||||
lms server start --port 1234
|
||||
```
|
||||
|
||||
Prüfen Sie, ob die API erreichbar ist:
|
||||
|
||||
```bash
|
||||
curl http://localhost:1234/api/v1/models
|
||||
```
|
||||
|
||||
### Authentifizierungsfehler (HTTP 401)
|
||||
|
||||
Wenn bei der Einrichtung HTTP 401 gemeldet wird, überprüfen Sie Ihren API-Schlüssel:
|
||||
|
||||
- Prüfen Sie, ob `LM_API_TOKEN` mit dem in LM Studio konfigurierten Schlüssel übereinstimmt.
|
||||
- Einzelheiten zur Einrichtung der LM Studio-Authentifizierung finden Sie unter [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
|
||||
- Wenn Ihr Server keine Authentifizierung erfordert, verwenden Sie einen beliebigen nicht leeren Tokenwert für `LM_API_TOKEN`.
|
||||
|
||||
### Just-in-Time-Modellladen
|
||||
|
||||
LM Studio unterstützt Just-in-Time- (JIT-)Modellladen, bei dem Modelle bei der ersten Anfrage geladen werden. Stellen Sie sicher, dass dies aktiviert ist, um Fehler wie „Model not loaded“ zu vermeiden.
|
||||
@ -1,68 +1,68 @@
|
||||
---
|
||||
read_when:
|
||||
- Sie möchten verstehen, welche Funktionen kostenpflichtige APIs aufrufen können
|
||||
- Sie müssen Schlüssel, Kosten und Sichtbarkeit der Nutzung prüfen
|
||||
- Sie erklären die Kostenanzeige von /status oder /usage
|
||||
summary: Prüfen, was Geld kosten kann, welche Schlüssel verwendet werden und wie sich die Nutzung anzeigen lässt
|
||||
- Sie möchten verstehen, welche Funktionen möglicherweise kostenpflichtige APIs aufrufen.
|
||||
- Sie müssen Schlüssel, Kosten und Nutzungssichtbarkeit prüfen.
|
||||
- Sie erklären die Kostenberichterstattung von /status oder /usage.
|
||||
summary: Prüfen Sie, was Geld kosten kann, welche Schlüssel verwendet werden und wie Sie die Nutzung anzeigen.
|
||||
title: API-Nutzung und Kosten
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T06:19:06Z"
|
||||
generated_at: "2026-04-13T08:50:44Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: ab6eefcde9ac014df6cdda7aaa77ef48f16936ab12eaa883d9fe69425a31a2dd
|
||||
source_hash: f5077e74d38ef781ac7a72603e9f9e3829a628b95c5a9967915ab0f321565429
|
||||
source_path: reference/api-usage-costs.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# API-Nutzung und Kosten
|
||||
|
||||
Dieses Dokument listet **Funktionen auf, die API-Schlüssel verwenden können**, und zeigt, wo ihre Kosten erscheinen. Es konzentriert sich auf
|
||||
OpenClaw-Funktionen, die Providernutzung oder kostenpflichtige API-Aufrufe erzeugen können.
|
||||
Dieses Dokument listet **Funktionen auf, die API-Schlüssel verwenden können**, und wo ihre Kosten angezeigt werden. Es konzentriert sich auf
|
||||
OpenClaw-Funktionen, die Provider-Nutzung oder kostenpflichtige API-Aufrufe erzeugen können.
|
||||
|
||||
## Wo Kosten erscheinen (Chat + CLI)
|
||||
## Wo Kosten angezeigt werden (Chat + CLI)
|
||||
|
||||
**Kostenaufnahme pro Sitzung**
|
||||
**Kostenübersicht pro Sitzung**
|
||||
|
||||
- `/status` zeigt das aktuelle Sitzungsmodell, die Kontextnutzung und die Token der letzten Antwort.
|
||||
- Wenn das Modell **API-Key-Authentifizierung** verwendet, zeigt `/status` auch die **geschätzten Kosten** der letzten Antwort an.
|
||||
- Wenn Live-Sitzungsmetadaten spärlich sind, kann `/status` Token-/Cache-
|
||||
Zähler und das aktive Laufzeit-Modelllabel aus dem neuesten Nutzungseintrag
|
||||
im Transkript wiederherstellen. Bereits vorhandene Live-Werte ungleich null haben weiterhin Vorrang, und nach Prompt-Größe
|
||||
berechnete Transkript-Gesamtwerte können gewinnen, wenn gespeicherte Gesamtwerte fehlen oder kleiner sind.
|
||||
- `/status` zeigt das aktuelle Sitzungsmodell, die Kontextnutzung und die Token der letzten Antwort an.
|
||||
- Wenn das Modell **API-Schlüssel-Authentifizierung** verwendet, zeigt `/status` auch die **geschätzten Kosten** für die letzte Antwort an.
|
||||
- Wenn Live-Sitzungsmetadaten lückenhaft sind, kann `/status` Token-/Cache-Zähler
|
||||
und die Bezeichnung des aktiven Laufzeitmodells aus dem neuesten Nutzungseintrag
|
||||
im Transkript wiederherstellen. Vorhandene Live-Werte ungleich null haben weiterhin Vorrang, und promptgroße
|
||||
Transkript-Gesamtwerte können gewinnen, wenn gespeicherte Gesamtwerte fehlen oder kleiner sind.
|
||||
|
||||
**Kostenfußzeile pro Nachricht**
|
||||
|
||||
- `/usage full` hängt an jede Antwort eine Nutzungsfußzeile an, einschließlich **geschätzter Kosten** (nur API-Key).
|
||||
- `/usage tokens` zeigt nur Token an; abonnementartige OAuth-/tokenbasierte und CLI-Flows verbergen Kosten in Dollar.
|
||||
- `/usage full` hängt an jede Antwort eine Nutzungsfußzeile an, einschließlich **geschätzter Kosten** (nur bei API-Schlüsseln).
|
||||
- `/usage tokens` zeigt nur Token an; OAuth-/Token-Flows im Abonnementstil und CLI-Flows blenden Dollarkosten aus.
|
||||
- Hinweis zu Gemini CLI: Wenn die CLI JSON-Ausgabe zurückgibt, liest OpenClaw die Nutzung aus
|
||||
`stats`, normalisiert `stats.cached` zu `cacheRead` und leitet bei Bedarf Eingabetoken
|
||||
aus `stats.input_tokens - stats.cached` ab.
|
||||
|
||||
Hinweis zu Anthropic: Mitarbeitende von Anthropic haben uns mitgeteilt, dass Claude-CLI-Nutzung im Stil von OpenClaw
|
||||
wieder erlaubt ist, daher behandelt OpenClaw die Wiederverwendung von Claude CLI und `claude -p`
|
||||
für diese Integration als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
|
||||
Anthropic stellt weiterhin keine Schätzung in Dollar pro Nachricht bereit, die OpenClaw
|
||||
Hinweis zu Anthropic: Anthropic-Mitarbeitende haben uns mitgeteilt, dass die Claude-CLI-Nutzung im OpenClaw-Stil
|
||||
wieder erlaubt ist, daher behandelt OpenClaw die Wiederverwendung von Claude CLI und die Nutzung von `claude -p` als
|
||||
für diese Integration zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
|
||||
Anthropic stellt weiterhin keine Schätzung der Kosten pro Nachricht in Dollar bereit, die OpenClaw
|
||||
in `/usage full` anzeigen könnte.
|
||||
|
||||
**CLI-Nutzungsfenster (Provider-Kontingente)**
|
||||
|
||||
- `openclaw status --usage` und `openclaw channels list` zeigen **Nutzungsfenster** des Providers an
|
||||
(Kontingentaufnahmen, keine Kosten pro Nachricht).
|
||||
- Lesbare Ausgabe wird providerübergreifend auf `X% left` normalisiert.
|
||||
- Aktuelle Provider mit Nutzungsfenstern: Anthropic, GitHub Copilot, Gemini CLI,
|
||||
- `openclaw status --usage` und `openclaw channels list` zeigen **Nutzungsfenster** der Provider an
|
||||
(Kontingent-Snapshots, keine Kosten pro Nachricht).
|
||||
- Die menschenlesbare Ausgabe wird providerübergreifend auf `X% left` normalisiert.
|
||||
- Aktuelle Provider für Nutzungsfenster: Anthropic, GitHub Copilot, Gemini CLI,
|
||||
OpenAI Codex, MiniMax, Xiaomi und z.ai.
|
||||
- Hinweis zu MiniMax: Die rohen Felder `usage_percent` / `usagePercent` bedeuten verbleibendes
|
||||
- Hinweis zu MiniMax: Die Rohfelder `usage_percent` / `usagePercent` bedeuten verbleibendes
|
||||
Kontingent, daher invertiert OpenClaw sie vor der Anzeige. Zählbasierte Felder haben weiterhin Vorrang,
|
||||
wenn sie vorhanden sind. Wenn der Provider `model_remains` zurückgibt, bevorzugt OpenClaw den Eintrag des
|
||||
Chat-Modells, leitet das Fensterlabel bei Bedarf aus Zeitstempeln ab und
|
||||
nimmt den Modellnamen in das Planlabel auf.
|
||||
- Die Nutzungsauthentifizierung für diese Kontingentfenster kommt aus provider-spezifischen Hooks, wenn verfügbar;
|
||||
andernfalls greift OpenClaw auf passende OAuth-/API-Key-
|
||||
Anmeldedaten aus Auth-Profilen, Env oder Konfiguration zurück.
|
||||
wenn sie vorhanden sind. Wenn der Provider `model_remains` zurückgibt, bevorzugt OpenClaw den
|
||||
Chat-Modell-Eintrag, leitet die Bezeichnung des Zeitfensters bei Bedarf aus Zeitstempeln ab und
|
||||
schließt den Modellnamen in die Planbezeichnung ein.
|
||||
- Die Authentifizierung für diese Kontingentfenster stammt nach Möglichkeit aus providerspezifischen Hooks;
|
||||
andernfalls greift OpenClaw auf passende OAuth-/API-Schlüssel-
|
||||
Anmeldedaten aus Auth-Profilen, der Umgebung oder der Konfiguration zurück.
|
||||
|
||||
Siehe [Token-Nutzung und Kosten](/de/reference/token-use) für Details und Beispiele.
|
||||
Siehe [Tokennutzung und Kosten](/de/reference/token-use) für Details und Beispiele.
|
||||
|
||||
## Wie Schlüssel erkannt werden
|
||||
## Wie Schlüssel gefunden werden
|
||||
|
||||
OpenClaw kann Anmeldedaten aus folgenden Quellen übernehmen:
|
||||
|
||||
@ -73,23 +73,23 @@ OpenClaw kann Anmeldedaten aus folgenden Quellen übernehmen:
|
||||
`talk.providers.*.apiKey`).
|
||||
- **Skills** (`skills.entries.<name>.apiKey`), die Schlüssel in die Prozessumgebung des Skills exportieren können.
|
||||
|
||||
## Funktionen, die Schlüssel verbrauchen können
|
||||
## Funktionen, die Schlüssel verwenden können
|
||||
|
||||
### 1) Antworten des Kernmodells (Chat + Tools)
|
||||
### 1) Kernmodell-Antworten (Chat + Tools)
|
||||
|
||||
Jede Antwort oder jeder Tool-Aufruf verwendet den **aktuellen Modell-Provider** (OpenAI, Anthropic usw.). Dies ist die
|
||||
wichtigste Quelle für Nutzung und Kosten.
|
||||
|
||||
Dazu gehören auch abonnementartige gehostete Provider, die weiterhin außerhalb
|
||||
der lokalen UI von OpenClaw abrechnen, wie **OpenAI Codex**, **Alibaba Cloud Model Studio
|
||||
Dazu gehören auch gehostete Provider im Abonnementstil, die weiterhin außerhalb
|
||||
der lokalen OpenClaw-Benutzeroberfläche abrechnen, wie **OpenAI Codex**, **Alibaba Cloud Model Studio
|
||||
Coding Plan**, **MiniMax Coding Plan**, **Z.AI / GLM Coding Plan** und
|
||||
Anthropics Claude-Login-Pfad in OpenClaw mit aktivierter **Extra Usage**.
|
||||
Anthropics OpenClaw-Claude-Login-Pfad mit aktiviertem **Extra Usage**.
|
||||
|
||||
Siehe [Models](/de/providers/models) für die Preiskonfiguration und [Token-Nutzung und Kosten](/de/reference/token-use) für die Anzeige.
|
||||
Siehe [Modelle](/de/providers/models) für die Preiskonfiguration und [Tokennutzung und Kosten](/de/reference/token-use) für die Anzeige.
|
||||
|
||||
### 2) Medienverständnis (Audio/Bild/Video)
|
||||
|
||||
Eingehende Medien können zusammengefasst/transkribiert werden, bevor die Antwort ausgeführt wird. Dies verwendet Modell-/Provider-APIs.
|
||||
Eingehende Medien können zusammengefasst oder transkribiert werden, bevor die Antwort ausgeführt wird. Dabei werden Modell-/Provider-APIs verwendet.
|
||||
|
||||
- Audio: OpenAI / Groq / Deepgram / Google / Mistral.
|
||||
- Bild: OpenAI / OpenRouter / Anthropic / Google / MiniMax / Moonshot / Qwen / Z.AI.
|
||||
@ -99,37 +99,38 @@ Siehe [Medienverständnis](/de/nodes/media-understanding).
|
||||
|
||||
### 3) Bild- und Videogenerierung
|
||||
|
||||
Gemeinsam genutzte Generierungsfunktionen können ebenfalls Providerschlüssel verbrauchen:
|
||||
Gemeinsam genutzte Generierungsfunktionen können ebenfalls Provider-Schlüssel verwenden:
|
||||
|
||||
- Bildgenerierung: OpenAI / Google / fal / MiniMax
|
||||
- Videogenerierung: Qwen
|
||||
|
||||
Die Bildgenerierung kann einen auth-gestützten Provider-Standard ableiten, wenn
|
||||
Die Bildgenerierung kann einen durch Authentifizierung gestützten Standard-Provider ableiten, wenn
|
||||
`agents.defaults.imageGenerationModel` nicht gesetzt ist. Die Videogenerierung erfordert derzeit
|
||||
ein explizites `agents.defaults.videoGenerationModel` wie
|
||||
`qwen/wan2.6-t2v`.
|
||||
|
||||
Siehe [Bildgenerierung](/de/tools/image-generation), [Qwen Cloud](/de/providers/qwen)
|
||||
und [Models](/de/concepts/models).
|
||||
und [Modelle](/de/concepts/models).
|
||||
|
||||
### 4) Memory-Embeddings + semantische Suche
|
||||
### 4) Memory-Einbettungen + semantische Suche
|
||||
|
||||
Die semantische Memory-Suche verwendet **Embedding-APIs**, wenn sie für Remote-Provider konfiguriert ist:
|
||||
Die semantische Suche in Memory verwendet **Embedding-APIs**, wenn sie für entfernte Provider konfiguriert ist:
|
||||
|
||||
- `memorySearch.provider = "openai"` → OpenAI-Embeddings
|
||||
- `memorySearch.provider = "gemini"` → Gemini-Embeddings
|
||||
- `memorySearch.provider = "voyage"` → Voyage-Embeddings
|
||||
- `memorySearch.provider = "mistral"` → Mistral-Embeddings
|
||||
- `memorySearch.provider = "ollama"` → Ollama-Embeddings (lokal/self-hosted; typischerweise keine Abrechnung über gehostete APIs)
|
||||
- Optionaler Fallback auf einen Remote-Provider, wenn lokale Embeddings fehlschlagen
|
||||
- `memorySearch.provider = "lmstudio"` → LM Studio-Embeddings (lokal/selbst gehostet)
|
||||
- `memorySearch.provider = "ollama"` → Ollama-Embeddings (lokal/selbst gehostet; in der Regel keine gehosteten API-Abrechnungskosten)
|
||||
- Optionaler Rückfall auf einen entfernten Provider, wenn lokale Embeddings fehlschlagen
|
||||
|
||||
Sie können es mit `memorySearch.provider = "local"` lokal halten (keine API-Nutzung).
|
||||
Sie können es lokal halten mit `memorySearch.provider = "local"` (keine API-Nutzung).
|
||||
|
||||
Siehe [Memory](/de/concepts/memory).
|
||||
|
||||
### 5) Web-Such-Tool
|
||||
### 5) Websuch-Tool
|
||||
|
||||
`web_search` kann je nach Provider Nutzungskosten verursachen:
|
||||
`web_search` kann je nach Ihrem Provider Nutzungskosten verursachen:
|
||||
|
||||
- **Brave Search API**: `BRAVE_API_KEY` oder `plugins.entries.brave.config.webSearch.apiKey`
|
||||
- **Exa**: `EXA_API_KEY` oder `plugins.entries.exa.config.webSearch.apiKey`
|
||||
@ -138,17 +139,17 @@ Siehe [Memory](/de/concepts/memory).
|
||||
- **Grok (xAI)**: `XAI_API_KEY` oder `plugins.entries.xai.config.webSearch.apiKey`
|
||||
- **Kimi (Moonshot)**: `KIMI_API_KEY`, `MOONSHOT_API_KEY` oder `plugins.entries.moonshot.config.webSearch.apiKey`
|
||||
- **MiniMax Search**: `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, `MINIMAX_API_KEY` oder `plugins.entries.minimax.config.webSearch.apiKey`
|
||||
- **Ollama Web Search**: standardmäßig ohne Schlüssel, erfordert aber einen erreichbaren Ollama-Host plus `ollama signin`; kann auch normale Ollama-Provider-Bearer-Authentifizierung wiederverwenden, wenn der Host sie erfordert
|
||||
- **Ollama Web Search**: standardmäßig ohne Schlüssel, erfordert aber einen erreichbaren Ollama-Host plus `ollama signin`; kann auch normale Ollama-Provider-Bearer-Authentifizierung wiederverwenden, wenn der Host sie verlangt
|
||||
- **Perplexity Search API**: `PERPLEXITY_API_KEY`, `OPENROUTER_API_KEY` oder `plugins.entries.perplexity.config.webSearch.apiKey`
|
||||
- **Tavily**: `TAVILY_API_KEY` oder `plugins.entries.tavily.config.webSearch.apiKey`
|
||||
- **DuckDuckGo**: Fallback ohne Schlüssel (keine API-Abrechnung, aber inoffiziell und HTML-basiert)
|
||||
- **SearXNG**: `SEARXNG_BASE_URL` oder `plugins.entries.searxng.config.webSearch.baseUrl` (ohne Schlüssel/self-hosted; keine Abrechnung über gehostete APIs)
|
||||
- **DuckDuckGo**: schlüsselfreier Fallback (keine API-Abrechnung, aber inoffiziell und HTML-basiert)
|
||||
- **SearXNG**: `SEARXNG_BASE_URL` oder `plugins.entries.searxng.config.webSearch.baseUrl` (schlüsselfrei/selbst gehostet; keine gehosteten API-Abrechnungskosten)
|
||||
|
||||
Veraltete Provider-Pfade unter `tools.web.search.*` werden weiterhin über den temporären Kompatibilitäts-Shim geladen, sind aber nicht mehr die empfohlene Konfigurationsoberfläche.
|
||||
|
||||
**Brave Search Free Credit:** Jeder Brave-Plan enthält erneuerbare
|
||||
5 USD/Monat an kostenlosem Guthaben. Der Search-Plan kostet 5 USD pro 1.000 Anfragen, sodass das Guthaben
|
||||
1.000 Anfragen/Monat ohne Kosten abdeckt. Setzen Sie Ihr Nutzungslimit im Brave-Dashboard,
|
||||
**Brave Search Gratisguthaben:** Jeder Brave-Tarif umfasst \$5/Monat an sich erneuerndem
|
||||
Gratisguthaben. Der Search-Tarif kostet \$5 pro 1.000 Anfragen, daher deckt das Guthaben
|
||||
1.000 Anfragen/Monat ohne Kosten ab. Legen Sie Ihr Nutzungslimit im Brave-Dashboard fest,
|
||||
um unerwartete Kosten zu vermeiden.
|
||||
|
||||
Siehe [Web-Tools](/de/tools/web).
|
||||
@ -159,45 +160,45 @@ Siehe [Web-Tools](/de/tools/web).
|
||||
|
||||
- `FIRECRAWL_API_KEY` oder `plugins.entries.firecrawl.config.webFetch.apiKey`
|
||||
|
||||
Wenn Firecrawl nicht konfiguriert ist, greift das Tool auf direktes Fetch + Readability zurück (keine kostenpflichtige API).
|
||||
Wenn Firecrawl nicht konfiguriert ist, fällt das Tool auf direktes Fetching + Readability zurück (keine kostenpflichtige API).
|
||||
|
||||
Siehe [Web-Tools](/de/tools/web).
|
||||
|
||||
### 6) Provider-Nutzungsaufnahmen (Status/Health)
|
||||
### 6) Provider-Nutzungs-Snapshots (Status/Gesundheit)
|
||||
|
||||
Einige Statusbefehle rufen **Provider-Nutzungsendpunkte** auf, um Kontingentfenster oder den Auth-Status anzuzeigen.
|
||||
Das sind typischerweise Aufrufe mit geringem Volumen, treffen aber dennoch Provider-APIs:
|
||||
Einige Statusbefehle rufen **Nutzungsendpunkte von Providern** auf, um Kontingentfenster oder den Auth-Status anzuzeigen.
|
||||
Dies sind in der Regel Anfragen mit geringem Volumen, treffen aber dennoch Provider-APIs:
|
||||
|
||||
- `openclaw status --usage`
|
||||
- `openclaw models status --json`
|
||||
|
||||
Siehe [Models CLI](/cli/models).
|
||||
|
||||
### 7) Zusammenfassung der Kompaktierungs-Schutzmaßnahme
|
||||
### 7) Zusammenfassungen als Compaction-Schutzmaßnahme
|
||||
|
||||
Die Kompaktierungs-Schutzmaßnahme kann den Sitzungsverlauf mit dem **aktuellen Modell** zusammenfassen, was
|
||||
beim Ausführen Provider-APIs aufruft.
|
||||
Die Compaction-Schutzmaßnahme kann den Sitzungsverlauf mit dem **aktuellen Modell** zusammenfassen, wodurch
|
||||
bei der Ausführung Provider-APIs aufgerufen werden.
|
||||
|
||||
Siehe [Sitzungsverwaltung + Kompaktierung](/de/reference/session-management-compaction).
|
||||
Siehe [Sitzungsverwaltung + Compaction](/de/reference/session-management-compaction).
|
||||
|
||||
### 8) Modellscan / Probe
|
||||
|
||||
`openclaw models scan` kann OpenRouter-Modelle prüfen und verwendet `OPENROUTER_API_KEY`, wenn
|
||||
Prüfungen aktiviert sind.
|
||||
die Prüfung aktiviert ist.
|
||||
|
||||
Siehe [Models CLI](/cli/models).
|
||||
|
||||
### 9) Talk (Sprache)
|
||||
|
||||
Der Talk-Modus kann **ElevenLabs** aufrufen, wenn er konfiguriert ist:
|
||||
Der Talk-Modus kann bei entsprechender Konfiguration **ElevenLabs** aufrufen:
|
||||
|
||||
- `ELEVENLABS_API_KEY` oder `talk.providers.elevenlabs.apiKey`
|
||||
|
||||
Siehe [Talk-Modus](/de/nodes/talk).
|
||||
|
||||
### 10) Skills (APIs von Drittanbietern)
|
||||
### 10) Skills (Drittanbieter-APIs)
|
||||
|
||||
Skills können `apiKey` unter `skills.entries.<name>.apiKey` speichern. Wenn ein Skill diesen Schlüssel für externe
|
||||
APIs verwendet, können entsprechend dem Provider des Skills Kosten entstehen.
|
||||
Skills können `apiKey` in `skills.entries.<name>.apiKey` speichern. Wenn ein Skill diesen Schlüssel für externe
|
||||
APIs verwendet, können entsprechend dem Provider des Skills Kosten anfallen.
|
||||
|
||||
Siehe [Skills](/de/tools/skills).
|
||||
|
||||
Loading…
Reference in New Issue
Block a user