ClawProxy macht OpenClaw für OpenAI-Clients anschlussfähig

ClawProxy übersetzt zwischen OpenClaw-Agenten und OpenAI-kompatiblen Clients. Damit können vorhandene Oberflächen wie Open WebUI, SillyTavern oder LM Studio einen lokalen Agenten ansprechen, ohne OpenClaws interne Session- und Tool-Logik selbst nachbauen zu müssen.

Das spart vor allem einen Frontend-Wechsel. Wer Open WebUI bereits betreibt, kann den Agenten dort wie ein weiteres Modell auswählen. Ob der Adapter im Alltag trägt, entscheidet sich allerdings nicht an der Modellliste, sondern an Streaming, Wiederverbindung und sauber begrenztem Zugriff.

OpenClaw-Agenten erscheinen als Modelle

ClawProxy stellt aktive Agenten nach Angaben des Projekts als „Custom Models“ über eine OpenAI-kompatible API bereit. Der Client sieht ein Modell und sendet seine Anfrage über die bekannte Schnittstelle; der Proxy übernimmt das Routing zur OpenClaw-Runtime.

Das ist die Stärke des Projekts. ClawProxy versucht nicht, eine neue Agentenarchitektur einzuführen. Es übersetzt zwischen zwei bereits vorhandenen Systemen und hält dadurch bestehende Clients nutzbar.

Der praktische Test ist kurz: Open WebUI sollte die aktiven Agenten in der Modellliste anzeigen, eine Anfrage an den ausgewählten Agenten senden und die Antwort fortlaufend darstellen. Fehlt ein Agent in der Liste, lohnt die Fehlersuche beim Proxy und seiner Verbindung zum Gateway, bevor jemand das Sprachmodell verdächtigt.

Streaming ist die heikle Stelle

Für Antworten verwendet ClawProxy Server-Sent Events und Anti-Buffering-Header. CORS-Unterstützung soll Browser-Clients den Zugriff ermöglichen. Außerdem kann der Proxy getrennte Ströme für „thinking“ und „content“ in <think>-Blöcke übersetzen, wie Open WebUI sie erwartet.

Genau dort werden Kompatibilitätsfehler sichtbar. Erwartet wird eine Antwort, deren Tokens fortlaufend eintreffen und deren Hilfsstrom die eigentliche Ausgabe nicht beschädigt. Kommt der komplette Text erst am Ende an, bricht der Stream vorzeitig ab oder erscheinen <think>-Markierungen im sichtbaren Inhalt, stimmt die Übersetzung für diesen Client noch nicht.

Ein guter Proxy fällt nicht auf.

Verbindung zum OpenClaw-Gateway

Auf der OpenClaw-Seite verbindet sich ClawProxy per WebSocket mit dem Gateway. Das Projekt gibt dafür „Protocol v3“ und eine automatische Wiederverbindung an. Dieser Claim ist laufzeitabhängig: Vor einem Deployment muss die verwendete ClawProxy-Version mit der installierten OpenClaw-Version getestet werden.

Dafür reicht kein erfolgreicher Start. Während eine Antwort läuft, kann die Gateway-Verbindung kurz getrennt und anschließend wiederhergestellt werden. Erwartet wird, dass der Proxy erneut verbindet und der nächste Request ohne Neustart des Dienstes funktioniert. Bleibt die Modellliste leer oder liefert der folgende Aufruf einen Verbindungsfehler, ist die versprochene Recovery für dieses Setup nicht erreicht.

Der optionale /health-Endpoint hilft bei der Überwachung, ersetzt diesen Test aber nicht, denn ein Prozess kann sauber auf Anfragen antworten und dabei längst den Draht zum Gateway verloren haben — die Statusseite ist dann grün, während jeder echte Aufruf ins Leere läuft.

Die Sicherheitsgrenze liegt vor dem Proxy

ClawProxy unterstützt laut Projekt API-Key-Authentifizierung, lokales Binding und konfigurierbare CORS-Regeln. Diese Optionen sind keine Nebensache. Der Dienst vermittelt Zugriff auf Agenten, die ihrerseits Werkzeuge und Daten erreichen können.

Für einen lokalen Einzelplatzbetrieb sollte der Proxy deshalb nur an die benötigte Schnittstelle gebunden sein. Sobald andere Geräte oder Browser zugreifen, gehören API-Key und eine enge Origin-Freigabe zur Mindestkonfiguration. Ein offenes Binding mit großzügigem CORS macht aus dem bequemen Adapter eine zusätzliche Angriffsfläche.

Secrets gehören in Umgebungsvariablen oder den vorgesehenen Credential-Pfad, nicht in eine geteilte JSON-Datei. Wie ClawProxy Schlüssel ablegt, Zugriffe protokolliert und wiederholt fehlgeschlagene Authentifizierungen begrenzt, muss vor der Freigabe im eigenen Setup nachgesehen werden: Ohne Rate-Limit ist ein per API-Key geschützter Endpunkt gegenüber automatisiertem Raten nur so stark wie die Länge des Schlüssels, und ohne Protokoll fällt ein erfolgreicher Fremdzugriff womöglich gar nicht auf.

Für welche Umgebung das passt

ClawProxy läuft dauerhaft unter Docker oder Node.js und ist nach Angaben des Projekts nicht für eine serverlose Laufzeit ausgelegt. Das passt zu Homelabs, Entwicklungsumgebungen und Plattformteams mit eigener Runtime. Wer nur gelegentlich einen Agenten aufruft oder keinen zusätzlichen Dienst betreiben will, gewinnt dagegen wenig.

Die beiden Hälften des Projekts sind unterschiedlich weit. Die Protokollübersetzung ist der überzeugende Teil, weil sie ein reales Problem löst und dabei bewusst klein bleibt; das Zugriffs- und Betriebsverhalten ist der Teil, den ein Betreiber selbst verantworten muss, weil sich dort ein Fehler nicht als Fehlermeldung zeigt, sondern als offene Tür. Für den Produktivbetrieb sollte die Freigabe deshalb erst nach drei Tests erfolgen: Streaming ohne Puffer, Wiederverbindung nach einem Gateway-Abbruch und abgewiesener Zugriff ohne gültigen API-Key. Besteht das Setup diese Prüfungen, schließt der Proxy tatsächlich eine Integrationslücke. Vorher ist er eine Abkürzung auf Verdacht.