ClawRouter: ein LLM-Router, der sich per Wallet-Signatur bezahlt
The agent-native LLM router for autonomous agents. Every frontier model behind one wallet, <1ms local routing, USDC payments on Base & Solana via x402.
Auf einen Blick
- Was ist das?
- ClawRouter leitet Anfragen lokal auf das günstigste passende Modell und rechnet per USDC auf Base oder Solana ab, alternativ über einen API-Key. Die Idee ist eigenständig, die Dokumentation deckt aber nur einen Teil der Betriebsfragen ab.
- Für wen ist es gedacht?
- ClawRouter passt zu Agenten, die ohne Konto und ohne Kreditkarte Modelle aufrufen sollen, und zu Teams, die Ausgaben pro Aufruf statt pro Seat abrechnen wollen. Wer bereits einen Vertrag mit einem Anbieter hat und feste Monatskosten bevorzugt, gewinnt hier nichts.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Router für Agenten, die kein Konto anlegen können
Das README beginnt mit einer Beobachtung, die den Rest des Projekts erklärt: Agenten können sich nicht registrieren, keine Kreditkarte eintragen, sie können nur Transaktionen signieren. Daraus folgt der Anspruch, den ClawRouter für sich formuliert. Statt eines Abonnements oder eines Mindestumsatzes pro Monat bezahlt der Agent genau den einen Aufruf, den er gerade braucht. Die Zielgruppe sind damit nicht Entwickler, die eine Chat-Oberfläche bedienen, sondern Betreiber autonomer Prozesse, in denen ein Modellaufruf eine von vielen Aktionen in einer Schleife ist. Der zweite Teil der Zielgruppe sind Kostenverantwortliche. Das README nennt Einsparungen von bis zu 84 Prozent gegenüber dem dauerhaften Einsatz von Claude Opus 5 auf derselben Last, weist aber selbst darauf hin, dass diese Zahl aus einem veröffentlichten Lastprofil berechnet und nicht gemessen wurde. Das ist ein wichtiger Unterschied, denn ein Lastprofil mit vielen einfachen Anfragen begünstigt jeden Router, der billige Modelle bevorzugt.
Lokale Entscheidung, entfernte Abrechnung
Der Mechanismus, den das Material belegt, ist zweistufig. Zuerst bewertet ClawRouter jede Anfrage lokal über 15 Dimensionen und wählt das günstigste Modell, das die Aufgabe nach dieser Bewertung noch erfüllen kann. Diese Entscheidung soll unter einer Millisekunde dauern und das Gerät nicht verlassen, was bedeutet, dass keine Anfrageinhalte an einen Routing-Dienst gehen. Danach läuft der eigentliche Aufruf über das Gateway von BlockRun, das die Abrechnung übernimmt. Bezahlt wird entweder per USDC über das x402-Protokoll auf Base oder Solana, wobei die Wallet-Signatur die Stelle eines Kontos einnimmt, oder über einen API-Key, den man nach Aufladung auf user.blockrun.ai erhält. Das README beschreibt ClawRouter als den Router, der auf der eigenen Maschine läuft, und BlockRun als Gateway und Abrechnung. Wer das Projekt also allein wegen des Routings einsetzen will, muss wissen, dass die Modellaufrufe nicht lokal bleiben. Nur die Entscheidung bleibt lokal.
Installation und die zwei Bezahlwege
Das Paket liegt auf npm unter @blockrun/clawrouter, der Standardzweig ist main, die Sprache ist TypeScript. Neben dem Router gibt es einen Desktop-Build, der als desktop-v0.1.3-preview.1 veröffentlicht wurde und laut Release-Notizen eine überarbeitete Oberfläche sowie Korrekturen am Statusanzeige umfasst. Für den Betrieb relevant sind die beiden Wege, die das README nebeneinander stellt. Der Karten-Weg führt über user.blockrun.ai: registrieren, Guthaben aufladen, API-Key erzeugen und denselben Router mit diesem Key betreiben. Der Wallet-Weg kommt ohne Konto aus und nutzt USDC auf Base oder Solana über x402. Zusätzlich nennt das README sechs Modelle, die ohne Anmeldung, ohne Key und ohne Wallet nutzbar sind. Wer das Projekt nur ausprobieren will, kann also mit diesen sechs Modellen beginnen und die Bezahlintegration später ergänzen. Konkrete Konfigurationsschlüssel für den Router selbst zeigt der vorliegende Ausschnitt nicht, und das sollte man vor der Einplanung offen benennen.
Die 84 Prozent sind eine Rechnung, kein Messwert
Die auffälligste Zahl im README ist die Ersparnis von bis zu 84 Prozent gegenüber einer festen Bindung an ein Spitzenmodell. Das README sagt selbst, dass sie aus einem veröffentlichten Lastprofil stammt und nicht aus einer Schätzung. Das ist ehrlicher als die meisten Angaben in diesem Feld, bleibt aber eine Modellrechnung. Wer eigene Anfragen überwiegend aus langen, mehrstufigen Aufgaben bestehen, bei denen ein falsch gewähltes Modell einen ganzen Durchlauf wiederholen lässt, wird die Zahl nicht erreichen. Der Router optimiert auf Kosten pro Aufruf, nicht auf Kosten pro gelöstem Problem. Genau hier liegt die Grenze des Ansatzes: Ein zu billig gewähltes Modell erzeugt einen zweiten Aufruf, und der spart nichts mehr. Ob die 15 Dimensionen diese Rückkopplung berücksichtigen, lässt sich aus dem vorliegenden Material nicht beantworten. Das ist die erste Frage, die man an die Dokumentation stellen sollte.
Modellkatalog und Release-Tempo
Das README nennt 78 sichtbare Chat-Modelle über neun Anbieter, dazu Bild-, Video-, Sprach- und Musikmodelle sowie Datenquellen. Die Release-Historie zeigt, wie schnell dieser Katalog sich bewegt. In Version v0.12.276 wurde Gemini 3.8 Flash als routbar, aber noch nicht katalogisiert korrigiert. Zwei Tage später folgte v0.12.277 mit einem Opt-in namens TWZRD AutoGate samt der dafür nötigen Verfügbarkeitskorrektur. Der Patchstand v0.12.277 deutet auf eine hohe Frequenz kleiner Korrekturen hin. Für Betreiber heißt das: Der Katalog ist ein bewegtes Ziel, und ein Router, der Modelle nach Preis und Fähigkeit sortiert, muss neue Modelle zeitnah aufnehmen, sonst routet er auf veraltete Optionen. Das ist kein Fehler des Projekts, sondern eine Betriebsrealität, die man bei der Planung der Update-Kadenz berücksichtigen muss. Wer monatliche Wartungsfenster bevorzugt, wird mit diesem Tempo nicht glücklich.
Wo ClawRouter das falsche Werkzeug ist
ClawRouter setzt eine Umgebung voraus, in der ein Agent Transaktionen signieren kann. In vielen Unternehmen ist genau das nicht erlaubt, weil Wallet-Material nicht in die Laufzeitumgebung eines Agenten gehört. Der Karten-Weg entschärft das, bringt aber ein Konto bei BlockRun mit, und damit dieselbe Abhängigkeit von einem Anbieter, die man mit einem Router eigentlich umgehen wollte. Ein weiterer Fall: Wer aus regulatorischen Gründen jede Anfrage einem festen, vertraglich vereinbarten Modell zuordnen muss, kann die automatische Auswahl nicht nutzen. Auch für reine Batch-Verarbeitung ohne Kostendruck ist der Aufwand für Wallet oder Guthabenkonto schwer zu rechtfertigen. Und wenn die eigenen Anfragen ohnehin fast alle gleich aussehen, bringt ein 15-dimensionaler Klassifikator wenig, weil die Entscheidung immer dieselbe ist. Der Router lohnt sich dort, wo die Last gemischt ist und die Kosten pro Aufruf tatsächlich schwanken.
Der Unterschied zu OpenRouter und zu LiteLLM
Der naheliegende Vergleich ist OpenRouter, ein Router, der ebenfalls viele Modelle hinter einem Endpunkt bündelt. Der Unterschied liegt weniger im Katalog als in der Abrechnung und im Ort der Entscheidung. OpenRouter ist auf Entwicklerkonten zugeschnitten, die sich anmelden und ein Guthaben verwalten. ClawRouter verschiebt die Bezahlung in eine Wallet-Signatur und die Routing-Entscheidung auf das Gerät des Nutzers. LiteLLM verfolgt den entgegengesetzten Ansatz: Es ist eine Bibliothek und ein Proxy, den man selbst betreibt, mit eigenen Schlüsseln bei jedem Anbieter. LiteLLM gibt die Kontrolle über die Anbieterbeziehung, verlangt aber, dass man für jeden Anbieter ein eigenes Konto und einen eigenen Key verwaltet. ClawRouter tauscht diese Verwaltung gegen eine einzige Abrechnungsstelle ein. Wer die Anbieterbeziehungen selbst halten will, ist bei LiteLLM richtig. Wer sie loswerden will und dafür eine zentrale Stelle akzeptiert, bei ClawRouter.
Wartung, Lizenz und was vor dem Einsatz zu klären ist
ClawRouter steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung, Änderung und Weitergabe, solange der Lizenztext erhalten bleibt, und es enthält keine Klausel, die den Betrieb an einen Dienst bindet. Die Lizenz regelt allerdings nur den Code. Die Nutzung der Modelle läuft über BlockRun, und dort gelten die Bedingungen des Gateways, nicht die MIT-Lizenz. Wer den Router produktiv einsetzt, übernimmt zwei Wartungslasten: die Aktualisierung des npm-Pakets, weil der Modellkatalog sich schnell ändert, und die Pflege des Guthabens oder der Wallet. Ein leerer Kontostand ist ein Ausfall, der nicht im Router-Log als Fehler auftaucht, sondern als fehlgeschlagener Aufruf beim Agenten. Das Repository umfasst laut den Angaben auch einen Desktop-Build, der sich noch im Preview-Stadium befindet, was für serverseitige Einsätze ohne Bedeutung ist, für interaktive Nutzung aber ein zusätzliches Update-Ziel darstellt. Vor dem Einsatz sollte man klären, wie das Paket mit Wallet-Material umgeht, ob die 15 Dimensionen dokumentiert und konfigurierbar sind, und ob x402 auf der gewählten Chain in der eigenen Umgebung zuverlässig durchläuft. Erst danach lohnt der Vergleich mit einer festen Modellbindung.
Redaktionelles Fazit
ClawRouter passt zu Agenten, die ohne Konto und ohne Kreditkarte Modelle aufrufen sollen, und zu Teams, die Ausgaben pro Aufruf statt pro Seat abrechnen wollen. Wer bereits einen Vertrag mit einem Anbieter hat und feste Monatskosten bevorzugt, gewinnt hier nichts. Vor dem Einsatz ist zu prüfen, ob die 15 Routing-Dimensionen im Repository dokumentiert sind, wie der lokale Prozess Schlüssel oder Wallet-Material ablegt, und ob der x402-Ablauf auf Base oder Solana in der eigenen Umgebung tatsächlich durchläuft.
Community-Notizen