OpenClaw Custom API-Setup: GLM, Kimi und DeepSeek ohne die Frontier-Preise nutzen

OpenClaw ist darauf ausgelegt, provider-agnostisch zu sein, was seine heimliche Superkraft ist. Es unterstützt die üblichen Namen wie OpenAI und Anthropic, ermöglicht es dir aber auch, jede OpenAI-kompatible API als benutzerdefinierten Provider einzubinden (OpenClaw docs, 2026). Genau dieses Design-Entscheidung erlaubt es dir, deinen bevorzugten Agenten beizubehalten und ihn gleichzeitig auf deutlich günstigeren Open-Weight-Modellen laufen zu lassen – Modellen, die nur einen Bruchteil der Token-Preise der Frontier-Modelle kosten. Der Haken ist: Das Setup hat einen Schritt, den fast jeder übersieht. Wer ihn falsch macht, erhält eine Fehlermeldung, die einen in die völlig falsche Richtung führt. Diese Anleitung führt dich Schritt für Schritt durch ein korrektes OpenClaw-Custom-API-Setup: wie es im Hintergrund funktioniert, die exakte Konfiguration zum Kopieren, die Falle mit der Allowlist und wie man die Verbindung verifiziert. Plane etwa fünf Minuten dafür ein.

Warum überhaupt ein OpenClaw-Custom-API-Setup?

Der ehrliche Grund ist der Preis. Agentische Tools wie OpenClaw senden bei jedem Reasoning-Schritt den gesammelten Kontext erneut, wodurch sie für dieselbe Aufgabe 10- bis 100-mal mehr Token verbrauchen als ein Chat-Fenster (LeanOps, 2026). Dieser Multiplikator ist der Grund, warum die Kosten für Agenten so schnell steigen – Power-User von Frontier-Modellen erreichen schnell etwa 13 USD pro aktivem Entwickler-Tag (CloudZero, 2026). Ein OpenClaw-Custom-API-Setup greift diese Rechnung genau dort an, wo sie entsteht: beim Preis pro Token. Wenn du den Agenten auf ein Open-Weight-Modell statt auf ein Frontier-Modell lenkst, sinken die Stückkosten drastisch, oft um 70 % oder mehr bei Routineaufgaben, während der Qualitätsunterschied bei der täglichen Programmierung gering bleibt. Du behältst den OpenClaw-Workflow bei, den du bereits kennst, und änderst lediglich, was die Anfragen beantwortet. Es gibt einen zweiten Grund, der für Teams außerhalb der Regionen wichtig ist, die ein bestimmter Anbieter direkt bedient. Ein benutzerdefinierter Provider bietet dir einen stabilen, kompatiblen Weg, den Agenten zu betreiben, ohne von der Abrechnung, dem Rollout-Zeitplan oder der regionalen Verfügbarkeit eines einzelnen Unternehmens abhängig zu sein.

Wie ein OpenClaw-Custom-API-Setup funktioniert: Die zwei Schritte, die jeder übersieht

Bevor du die Konfiguration einfügst, solltest du das Modell verstehen, das OpenClaw verwendet, denn es erklärt den Fehler, den jeder macht. Ein benutzerdefinierter Provider wird an zwei Stellen definiert, und beides ist erforderlich. Erstens beschreibst du den Provider selbst im Abschnitt models.providers: seine Basis-URL, den API-Schlüssel, das Übertragungsprotokoll (openai-completions für jeden OpenAI-kompatiblen Endpunkt) und die Liste der Modelle, die er bereitstellt. Zweitens – und das ist der Teil, den die meisten übersehen – musst du das exakte Modell unter agents.defaults.models auf die Allowlist setzen, und zwar mit dem vollständig qualifizierten Bezeichner provider-name/model-name (OpenClaw docs, 2026). Die Definition eines Providers macht seine Modelle nicht automatisch nutzbar. OpenClaw lehnt alles ab, was nicht auf der Allowlist steht. Das ist Absicht. Die Allowlist erlaubt es dir, einen großen Katalog von Providern und Modellen zu definieren, aber nur die spezifischen Modelle freizugeben, die der Agent tatsächlich verwenden soll. Sobald du verinnerlicht hast, dass Provider und Allowlist separate Ebenen sind, ist der Rest des OpenClaw-Custom-API-Setups rein mechanisch.

OpenClaw-Custom-API-Setup: Schritt für Schritt

Das folgende Beispiel verwendet Atlas Cloud als Provider, da dieser einen OpenAI-kompatiblen Endpunkt bereitstellt, der die wichtigsten Open-Weight-Modelle über einen einzigen Schlüssel anbietet. Das hält die Konfiguration kurz und ermöglicht es dir, Modelle später auszutauschen, ohne etwas Neues registrieren zu müssen. Dieselben Schritte gelten für jeden kompatiblen Provider; nur die Basis-URL und der Schlüssel ändern sich.

Schritt 1: Hole dir Endpunkt und API-Schlüssel

Am Ende dieses Schritts hast du zwei Strings: eine Basis-URL und einen Schlüssel.

1. Erstelle ein Konto bei deinem Provider und öffne den Bereich für API-Schlüssel.
2. Generiere einen Schlüssel, der für Coding-Zwecke ausgelegt ist. Bei Atlas Cloud wählst du Coding Plan als Schlüsseltyp, was ihn an das kreditbasierte Coding-Kontingent bindet statt an allgemeines Pay-as-you-go.
3. Notiere die Basis-URL. Für OpenAI-kompatible Clients wie OpenClaw verwendet Atlas Cloud https:​//api.atlascloud.ai/v1 (das Suffix /v1 ist hier wichtig).

Schritt 2: Nutze den Onboard-Assistenten – der schnellste Weg

Am Ende dieses Schritts ist die Verbindung auf die einfache Weise hergestellt. Starte im Terminal den geführten Assistenten:

BashCopy
1openclaw onboard

Befolge dann die Anweisungen: Wähle Yes, dann QuickStart und schließlich Custom Provider. Der Assistent fragt nach der API-Basis-URL (https:​//api.atlascloud.ai/v1), dem API-Schlüssel und der Modell-ID. Achte darauf, bei der Abfrage das OpenAI-kompatible Protokoll zu wählen. Wenn Verification successful erscheint, funktioniert der Endpunkt. Schließe den Vorgang ab, indem du dem Endpunkt eine ID und einen Anzeigenamen gibst. Der versteckte Vorteil des Assistenten: Er schreibt sowohl die Provider-Definition als auch den Eintrag in der Modell-Allowlist für dich und startet das Gateway neu, wodurch du die häufigste Fehlerquelle komplett umgehst.

Schritt 3: Oder bearbeite die Konfigurationsdatei direkt

Am Ende dieses Schritts verstehst du, was der Assistent geschrieben hat – das ist wichtig, wenn du später weitere Modelle hinzufügen möchtest. Die Konfiguration liegt unter ~/.openclaw/openclaw.json (OpenClaw docs, 2026). Definiere den Provider:

JSONCopy
1{
2  "models": {
3    "mode": "merge",
4    "providers": {
5      "atlascloud": {
6        "baseUrl": "https://api.atlascloud.ai/v1",
7        "apiKey": "your-atlas-api-key",
8        "api": "openai-completions",
9        "models": [
10          { "id": "zai-org/glm-5.1", "name": "glm-5.1", "contextWindow": 200000 }
11        ]
12      }
13    }
14  }
15}

Mit "mode": "merge" bleiben deine bestehenden Provider erhalten, anstatt sie zu überschreiben. Für benutzerdefinierte Provider sind Felder wie reasoning, cost und maxTokens optional und greifen auf sinnvolle Standardwerte zurück, sodass du nicht alles ausfüllen musst, um loszulegen.

Schritt 4: Setze das Modell auf die Allowlist

Am Ende dieses Schritts lässt OpenClaw dich das Modell tatsächlich verwenden. Dies ist der Schritt, den die meisten überspringen. Füge den vollständig qualifizierten Bezeichner zur Allowlist hinzu:

JSONCopy
1{
2  "agents": {
3    "defaults": {
4      "models": {
5        "atlascloud/zai-org/glm-5.1": { "alias": "glm" }
6      }
7    }
8  }
9}

Der Schlüssel ist dein Provider-Name, gefolgt von der Modell-ID, exakt so, wie du sie definiert hast. Der alias ist nur eine Abkürzung, die du statt des vollständigen Pfades tippen kannst. Ohne diesen Block existiert zwar der Provider, aber jede Anfrage wird abgelehnt.

Schritt 5: Verifiziere dein OpenClaw-Custom-API-Setup

Am Ende dieses Schritts weißt du, dass es funktioniert. Starte OpenClaw, wähle dein Modell (oder dessen Alias) und gib ihm eine triviale Aufgabe, wie z. B. eine Datei zu erklären. Eine normale Antwort bedeutet, dass die Anfragen an deinen Endpunkt durchgehen. Wenn du "model not allowed" siehst, prüfe Schritt 4 erneut – der Allowlist-Schlüssel stimmt fast sicher nicht exakt mit den Provider- und Modellnamen überein. Wenn du einen Authentifizierungsfehler erhältst, ist der Schlüssel falsch oder enthält ein Leerzeichen. Wenn keine Verbindung hergestellt werden kann, überprüfe die Basis-URL und das /v1-Suffix.

Auswahl eines Modells für dein OpenClaw-Custom-API-Setup

Die Wahl des Modells bestimmt die Einsparungen. Das kluge Muster ist, standardmäßig ein starkes, günstiges Open-Weight-Modell für die tägliche Arbeit zu nutzen und ein teureres Modell für besonders schwieriges Reasoning in Reserve zu halten. Die Leistungsfähigkeit ist real: Auf dem SWE-Bench Pro erreichen führende offene Modelle Werte im hohen 70er-Bereich gegenüber etwa 91 bei den besten Frontier-Modellen (Codersera, 2026) – eine bedeutende Lücke bei sehr komplexen Problemen, aber eine kleine bei Routineaufgaben und Refactorings. Auf einem kreditbasierten Gateway trägt jedes Modell einen Multiplikator, der den Token-Verbrauch in Kredite umrechnet, was den relativen Kostenvergleich einfach macht:

Quelle: Atlas Cloud Coding Plan Kreditregeln. Kreditkosten = Input-Token × Input-Multiplikator + Output-Token × Output-Multiplikator. Ein sinnvoller Standard: Nutze GLM-5.1 oder Kimi K2.6 für interaktives Programmieren, wechsle zu DeepSeek V4 Flash für große Volumina oder Hintergrund-Jobs und greife nur für seltene Aufgaben, die ein offenes Modell nicht bewältigen kann, auf ein Frontier-Modell zurück. Da alles hinter einem Provider liegt, ist der Wechsel nur eine einzeilige Änderung am Alias, den du aufrufst.

Ein Endpunkt für OpenClaw, Claude Code und Codex

Der Endpunkt, der dein OpenClaw-Setup antreibt, ist nicht auf OpenClaw beschränkt. Die meisten Entwickler nutzen mehr als einen Agenten, und jeden auf einen anderen Anbieter zu lenken bedeutet, separate Schlüssel, Dashboards und Rechnungen zu jonglieren. Die Konsolidierung auf einen einzigen OpenAI-kompatiblen Endpunkt bündelt dies in einem Kreditpool und einem zentralen Ort für Modelländerungen. Da Atlas Cloud dieselbe Basis-URL für verschiedene Tools bereitstellt, hat die OpenClaw-Konfiguration oben direkte Entsprechungen an anderer Stelle. Claude Code liest sein Backend aus ~/.claude/settings.json mit der ANTHROPIC_BASE_URL, die auf https:​//api.atlascloud.ai gesetzt ist (Hinweis: speziell für Claude Code kein /v1). Codex nutzt ~/.codex/config.toml mit einer base_url, die auf https:​//api.atlascloud.ai/v1 zeigt. Cursor, OpenCode und Copilot-ähnliche Clients verwenden denselben /v1-Endpunkt. Ein Schlüssel, ein Budget, jedes Tool. Diese Konsolidierung verbessert auch die Ausgabenkontrolle. Ein Plan, der ein festes tägliches Kreditguthaben um Mitternacht aktualisiert, setzt eine strukturelle Obergrenze für eine außer Kontrolle geratene Agenten-Schleife, während Pay-as-you-go-Pakete gelegentliche Spitzen abfangen. Die Pläne von Atlas Cloud beginnen bei 10 USD pro Monat, Pay-as-you-go-Pakete bieten 41 % Rabatt, und Upgrades während des Zyklus werden anteilig berechnet, sodass ein Stufenwechsel oft nur die Differenz kostet, anstatt einen neuen Plan zu erfordern.

Häufige Fehler beim OpenClaw-Custom-API-Setup

Die meisten fehlgeschlagenen Setups lassen sich auf eine kurze Liste von Fehlern zurückführen, die fast alle in der Konfiguration und nicht tiefer im System liegen. Vergessen der Allowlist. Der mit Abstand häufigste Fehler. Die Definition des Providers ist nur die halbe Miete. Wenn du "model not allowed" siehst, fehlt das Modell in agents.defaults.models oder der Schlüssel stimmt nicht überein (haimaker, 2026). Nicht übereinstimmender Allowlist-Schlüssel. Der Allowlist-Schlüssel muss provider-name/model-name sein, exakt so, wie du es definiert hast. Ein Tippfehler in einer der beiden Hälften führt zur gleichen Ablehnung wie das vollständige Auslassen. Falscher Pfad der Basis-URL. OpenAI-kompatible Tools wie OpenClaw erwarten den /v1-Pfad. Ihn wegzulassen oder dort hinzuzufügen, wo ein Tool ihn nicht haben will, führt zu Verbindungsfehlern. Überschreiben statt Zusammenführen. Wenn du die Konfiguration manuell ohne "mode": "merge" bearbeitest, kannst du deine anderen Provider löschen. Behalte den Merge-Modus bei, es sei denn, du beabsichtigst, alles zu ersetzen.

FAQ: OpenClaw-Custom-API-Setup

Ist ein OpenClaw-Custom-API-Setup schwer?

Nein. Der schnellste Weg ist der openclaw onboard-Assistent, der die Provider-Definition und die Modell-Allowlist für dich erstellt und etwa fünf Minuten dauert. Der manuelle Weg umfasst zwei kleine JSON-Änderungen. Die einzige konzeptionelle Hürde besteht darin, sich daran zu erinnern, dass die Definition eines Providers und das Hinzufügen eines Modells zur Allowlist zwei separate Schritte sind.

Was ist der häufigste Fehler beim OpenClaw-Custom-API-Setup?

Die Ablehnung "model not allowed". Dies bedeutet fast immer, dass das Modell in der Allowlist unter agents.defaults.models fehlt oder der provider-name/model-name-Schlüssel einen Tippfehler enthält. Das Nicht-Hinzufügen zur Allowlist ist die Hauptursache für diesen Fehler (haimaker, 2026) – genau deshalb erledigt der Onboard-Assistent dies automatisch.

Welches Modell sollte ich für mein OpenClaw-Custom-API-Setup wählen?

Für interaktive Coding-Aufgaben ist ein starkes allgemeines Open-Weight-Modell wie GLM-5.1 oder Kimi K2.6 ein guter Standard. Für Aufgaben mit hohem Volumen oder Hintergrundprozesse ist ein günstigeres Modell wie DeepSeek V4 Flash sinnvoll. Halte ein Frontier-Modell nur für Aufgaben bereit, die ein offenes Modell wirklich nicht lösen kann.

Wie viel kann ein benutzerdefinierter Provider tatsächlich sparen?

Es hängt vom Modell ab, aber die Spanne ist groß. DeepSeek V4 Flash liegt bei etwa 0,14 USD pro Million Input-Token gegenüber mehreren Dollar bei Frontier-Modellen (Codersera, 2026), sodass das Lenken von Routineaufgaben auf ein offenes Modell die Token-Rechnung oft um 70 % oder mehr senkt, ohne dass du deine Arbeitsweise ändern musst.

Kann ich später wieder zu meinem ursprünglichen Provider zurückkehren?

Ja. Benutzerdefinierte Provider sind additiv, solange du "mode": "merge" beibehältst; deine ursprünglichen Provider bleiben definiert. Der Wechsel ist nur eine Frage der Auswahl eines anderen Modells oder Alias in OpenClaw, und du kannst einen Provider-Block jederzeit entfernen.

Fazit

Ein OpenClaw-Custom-API-Setup ist eine der effektivsten fünfminütigen Änderungen, die ein Entwickler im Jahr 2026 vornehmen kann. Der Agent bleibt derselbe, aber das Backend und die Rechnung nicht. Definiere den Provider, setze das Modell auf die Allowlist, verweise auf eine Open-Weight-Option, und du behältst den OpenClaw-Workflow, den du kennst, während du nur einen Bruchteil der Frontier-Preise zahlst. Wenn du das alles unter einem Schlüssel und einem Budget haben willst, das auch Claude Code und Codex abdeckt, kannst du es über die Atlas Cloud Coding Plan Console einrichten und jederzeit bei Aufgabenwechseln die Modelle anpassen.