CashClaw: ein Agent, der Aufgaben annimmt, abliefert und aus Bewertungen lernt

Ein Agent, der auf einem Marktplatz um Aufträge konkurriert

Das Problem, das CashClaw adressiert, ist die Lücke zwischen einem LLM und einem bezahlten Auftrag. Ein Sprachmodell kann Text erzeugen, aber es kann keinen Preis nennen, keine Frist zusagen, keine Lieferung einreichen und keine Bewertung einstreichen. CashClaw schließt diese Lücke, indem es den gesamten Ablauf in einen einzigen Node.js-Prozess packt: Aufgaben beobachten, bewerten, kalkulieren, ausführen, abliefern, Bewertungen einsammeln und daraus lernen.

Die Zielgruppe ist eng umrissen. Angesprochen sind Entwickler, die den Moltlaunch-Marktplatz bereits nutzen oder nutzen wollen, also ein onchain-Arbeitsnetzwerk, in dem Kunden Aufgaben ausschreiben und Agenten darum konkurrieren. Wer diese Infrastruktur nicht braucht, wird vom README ausdrücklich eingeladen, den Marktplatz herauszureißen und den Agenten an eigene Kunden zu hängen. Das ist ein ehrliches Angebot, aber es bedeutet auch: Der Marktplatz ist der Pfad, für den der Code gebaut und getestet wurde, alles andere ist Fork-Arbeit.

Bemerkenswert ist der Zuschnitt auf eine einzelne Maschine. Es gibt keinen Server, keine Datenbank, keinen Scheduler im Hintergrund. Der Agent läuft dort, wo der Entwickler ihn startet, und legt seinen Zustand unter `~/.cashclaw/` ab. Das macht den Einstieg niedrigschwellig und die Betriebsverantwortung vollständig sichtbar.

Drei Jobs in einem Prozess: Herzschlag, Loop, HTTP-Server

Die Architektur ist im README als ein Prozess mit drei Aufgaben beschrieben. Erstens das Beobachten: eine WebSocket-Verbindung zur Moltlaunch-API für Echtzeit-Task-Events, mit REST-Polling als Rückfallebene. Zweitens die Ausführung: ein Multi-Turn-LLM-Loop mit Tool-Nutzung. Drittens die Verbesserung: Selbststudien-Sitzungen, die Wissenseinträge erzeugen. Daneben läuft ein HTTP-Server auf Port 3777, der unter `/api/*` JSON-Endpunkte ausliefert und alles andere als statisches React-Dashboard bedient.

Der Loop selbst liegt laut README in `loop/index.ts` und arbeitet in fünf Schritten. Zuerst wird ein System-Prompt gebaut, der Agentenidentität, Preisregeln, Persönlichkeit und gelerntes Wissen enthält, optional ergänzt um den AgentCash-API-Katalog. Dann wird der Aufgabenkontext als erste User-Nachricht injiziert. Das Modell antwortet mit Begründung und Tool-Aufrufen. Die Tools werden ausgeführt, die Ergebnisse zurückgegeben. Das wiederholt sich, bis das Modell keine Tools mehr aufruft oder die Standardgrenze von zehn Turns erreicht ist.

Die wichtigste Designentscheidung steckt in einem Satz des README: Das LLM ruft niemals APIs direkt auf. Jeder Seiteneffekt läuft über ein Tool, das entweder die `mltl`-CLI oder `npx agentcash` aufruft. Das ist eine bewusste Einschränkung der Modellfreiheit zugunsten einer prüfbaren Oberfläche. Ein Modell, das keine Shell-Kommandos erfinden kann, kann auch keine erfinden, die Schaden anrichten.

Dreizehn Tools, drei Kategorien, ein gemeinsamer Adapter

Die Tool-Liste ist der eigentliche Funktionsumfang. Sieben Marketplace-Tools decken den Geschäftsablauf ab: `read_task`, `quote_task`, `decline_task`, `submit_work`, `send_message`, `list_bounties` und `claim_bounty`. Vier Utility-Tools bedienen den Zustand: `check_wallet_balance` für den ETH-Stand auf Base, `read_feedback_history`, `memory_search` und `log_activity`. Zwei AgentCash-Tools schließlich erlauben bezahlte Fremd-APIs über `agentcash_fetch` sowie die Abfrage des USDC-Guthabens über `agentcash_balance`.

Auffällig ist die Anbieterbehandlung. Alle drei LLM-Provider werden über rohes `fetch()` angesprochen, ohne SDK-Abhängigkeiten. Anthropic läuft gegen `api.anthropic.com/v1/messages` mit dem Standardmodell `claude-sonnet-4-20250514`, OpenAI gegen `api.openai.com/v1/chat/completions` mit `gpt-4o`, OpenRouter gegen `openrouter.ai/api/v1/chat/completions` mit `openai/gpt-5.4`. OpenAI und OpenRouter teilen sich einen Adapter, der zwischen Anthropics nativem Tool-Use-Format und OpenAIs `tool_calls`-Format übersetzt.

Genau hier liegt ein Risiko, das der README nicht ausräumt. Ein Übersetzungsadapter zwischen zwei Tool-Use-Dialekten ist die Stelle, an der sich Unterschiede in der Behandlung paralleler Aufrufe, verschachtelter Argumente oder abgebrochener Tool-Schleifen zeigen. Der Setup-Wizard führt laut README einen Live-Testaufruf durch, aber dieser Test prüft die Erreichbarkeit und Antwortfähigkeit des Providers, nicht die Korrektheit des Tool-Use-Pfads über alle Turn-Längen.

Installation: zwei globale Pakete und ein Setup-Wizard

Die Einrichtung ist kurz dokumentiert. Zuerst wird der Agent global installiert, dann die Moltlaunch-CLI, die als Voraussetzung genannt wird, danach wird der Agent gestartet:

npm install -g cashclaw-agent npm install -g moltlaunch cashclaw

Der Start öffnet `http://localhost:3777` mit einem Assistenten in vier Schritten. Der erste Schritt erkennt das `mltl`-Wallet, das beim ersten Lauf automatisch angelegt wird. Der zweite registriert den Agenten onchain mit Name, Beschreibung, Fähigkeiten und Preis. Der dritte verbindet Anthropic, OpenAI oder OpenRouter, inklusive Testaufruf. Der vierte setzt Preisstrategie, Automatisierungsschalter und Aufgabenlimits.

Nach dem Setup startet das Dashboard und der Agent beginnt zu arbeiten. Wer den Setup-Pfad verlassen will, muss wissen, wo der Zustand liegt: Wissenseinträge landen in `~/.cashclaw/knowledge.json`, und die Aktivitätsprotokollierung schreibt über `log_activity` in ein tägliches Log. Beide Pfade sind relevant, wenn der Agent auf einer Maschine läuft, die nicht dauerhaft eingeschaltet ist, oder wenn der Zustand zwischen Umgebungen wandern soll.

Ein Hinweis zur Betriebsform: Der Agent braucht eine laufende Verbindung zum Marktplatz, um Aufträge zu sehen. Ohne WebSocket und ohne REST-Polling passiert nichts, und das README beschreibt keine Warteschlange, die Aufgaben für spätere Offline-Zeiträume puffert.

Das Gedächtnis: BM25-Suche mit Halbwertszeit von 30 Tagen

Das Selbstlernen ist der Teil, der CashClaw von einem gewöhnlichen Tool-Use-Loop unterscheidet, und der README beschreibt ihn detaillierter als den Rest. Wenn der Agent untätig ist, laufen Studien-Sitzungen, standardmäßig alle 30 Minuten, die zwischen drei Themen rotieren. Feedback-Analyse sucht Muster in Kundenbewertungen und läuft nur, wenn Bewertungen existieren. Spezialisierungsrecherche vertieft die konfigurierten Fähigkeiten. Aufgabensimulation erzeugt eine realistische Aufgabe und skizziert den Lösungsweg. Jede Sitzung produziert einen Wissenseintrag in `~/.cashclaw/knowledge.json`.

Die Verwendung ist zweistufig und technisch konkret. Bei jeder eingehenden Aufgabe wird der Text tokenisiert, im README-Beispiel zu `["react", "analytics", "dashboard", "charts"]`, dann läuft eine BM25-Suche über Wissens- und Feedback-Einträge. Die Treffer werden zeitlich abgewertet: `score * e^(-lambda * ageDays)` mit einer Halbwertszeit von 30 Tagen. Die besten fünf Treffer landen als Abschnitt mit der Überschrift "## Relevant Context" im System-Prompt.

Zusätzlich kann das Modell mitten in einer Aufgabe `memory_search` aufrufen und sein eigenes Gedächtnis abfragen, etwa nach React-Testmustern. Das ist ein sauberer Schnitt: Relevanz wird nicht nach Aktualität, sondern nach Textähnlichkeit und Alter bestimmt. Die Kehrseite ist ebenso klar. BM25 ist eine lexikalische Suche. Eine Aufgabe, die inhaltlich zu einem Wissenseintrag passt, aber andere Wörter benutzt, wird nicht gefunden. Wer semantische Ähnlichkeit braucht, muss die Suche ersetzen, und der README sagt nicht, wie stark der Eintrag in den Prompt eingreift, wenn fünf Treffer nur schwach relevant sind.

Wann CashClaw das falsche Werkzeug ist

Die Grenzen liegen in der Betriebsform und im Zustandsmodell. CashClaw ist ein einzelner Prozess auf einer Maschine mit einem Wallet und einem LLM-Schlüssel. Es gibt keine Beschreibung von Mandantentrennung, kein Konzept für mehrere Agenten in einem Prozess und keine Angabe, wie sich zwei gleichzeitig laufende Instanzen auf demselben `~/.cashclaw/`-Verzeichnis verhalten. Wer mehrere Agenten betreiben will, müsste das über getrennte Verzeichnisse und getrennte Wallets lösen, und dazu schweigt das Material.

Ein zweiter wunder Punkt ist die Abhängigkeit von `mltl`. Die Marketplace-Tools rufen die CLI auf, nicht eine HTTP-API direkt. Ändert sich die CLI-Ausgabe oder ihre Argumentform, bricht der Tool-Pfad, und der Agent bemerkt das als fehlgeschlagenen Tool-Aufruf mitten in einer bezahlten Aufgabe. Der README nennt keine Version der CLI, die als kompatibel gilt.

Ein dritter Punkt betrifft die Standardwerte. Zehn Turns pro Aufgabe und ein Studienintervall von 30 Minuten sind Vorgaben, die bei einem kostenpflichtigen LLM direkt auf die Rechnung wirken. Die Studien-Sitzungen laufen im Leerlauf, also auch dann, wenn kein Auftrag hereinkommt. Wer den Agenten dauerhaft laufen lässt, sollte diese beiden Werte vor dem ersten längeren Betrieb bewusst setzen, nicht nachträglich korrigieren.

Schließlich die Frage der Qualität. Der Agent bewertet Aufgaben selbst, kalkuliert selbst und liefert selbst ab. Ob eine Lieferung den Kunden zufriedenstellt, entscheidet der Kunde über die Bewertung, und diese Bewertung fließt erst nach Abschluss zurück. Es gibt keine Vorabprüfung durch einen Menschen, und das README beschreibt keine Freigabestufe.

Der Unterschied zu einem fest verdrahteten Workflow-Agenten

Die naheliegende Alternative ist kein anderes Produkt, sondern der Bau eines eigenen Agenten mit einem Workflow-Framework wie LangGraph oder mit einer schlichten Schleife aus Prompt und Funktionsaufrufen. Der Unterschied liegt nicht im Loop, denn ein Multi-Turn-Tool-Use-Loop ist in wenigen Dutzend Zeilen nachgebaut. Der Unterschied liegt in den Teilen, die man sonst selbst schreibt: die 13 Tools mit ihren Argumentformaten, der Übersetzungsadapter zwischen Anthropic- und OpenAI-Tool-Formaten, der Setup-Wizard mit Wallet-Erkennung und Onchain-Registrierung, das Dashboard, und vor allem die Gedächtnisschicht mit Tokenisierung, BM25-Index, zeitlichem Verfall und den zwei Integrationspunkten in den Prompt.

Ein fest verdrahteter Workflow-Agent hat demgegenüber einen echten Vorteil: Er ist deterministisch. Er trifft keine Preisentscheidung und keine Ablehnungsentscheidung, weil diese Entscheidungen vorher im Code stehen. CashClaw gibt genau diese Kontrolle ab und gewinnt dafür die Fähigkeit, mit unbekannten Aufgaben umzugehen. Das ist ein Tausch, keine Verbesserung. Wer Auftragsarten mit klaren Regeln abwickelt, verliert durch den LLM-gesteuerten Ablauf nur Vorhersagbarkeit und Token-Budget.

Ein zweiter Vergleichspunkt ist der Selbststudien-Mechanismus. Er ist im Kern eine Retrieval-Augmented-Generation mit lokalem Index, und wer bereits eine Vektor-Datenbank betreibt, wird BM25 plus 30-Tage-Halbwertszeit als einfachere, aber schwächere Variante einordnen. Der Vorteil dieser Wahl ist, dass sie ohne Embedding-Modell, ohne Netzwerkaufruf und ohne zusätzlichen Dienst auskommt.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Zum Wartungsaufwand lässt sich aus dem Material nur wenig Belastbares sagen. Es gibt keine abgerufenen Releases, und der letzte Push auf den Hauptzweig datiert auf den 14. März 2026. Das Repository ist nicht archiviert. Eine Versionshistorie, aus der sich Upgrade-Pfade ableiten ließen, ist im vorliegenden Material nicht enthalten. Wer den Agenten produktiv einsetzt, muss damit rechnen, dass Anpassungen an der `mltl`-CLI oder an den LLM-Endpunkten direkt im Code landen, weil es keine Stabilitätszusage gibt, auf die man sich stützen könnte.

Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Urheberrechtshinweis und der Lizenztext beiliegen. Wer den Marktplatz herausreißt und den Agenten an eigene Kunden hängt, muss den MIT-Hinweis also mitführen. Das ist keine Rechtsberatung, sondern nur die Angabe dessen, was die Lizenzkennung im Repository bedeutet.

Zu klären bleibt vor dem ersten Lauf eine kurze Liste. Läuft `mltl` in einer Version, deren Ausgabe die Tools korrekt parsen? Ist das Wallet angelegt und auf Base mit genug ETH für Transaktionen versehen? Bedient der gewählte Provider den Tool-Use-Pfad über den gemeinsamen Adapter zuverlässig, auch über mehrere Turns? Und sind die Werte für maximale Turns und Studienintervall an das eigene Token-Budget angepasst? Der letzte Punkt ist der praktischste, weil er sich in jeder Abrechnung sofort zeigt.

Redaktionelles Fazit

Wer einen LLM-Agenten mit Marktplatz-Anbindung, Wallet und Bewertungs-Feedbackloop sucht und TypeScript lesen kann, findet hier eine schlanke, MIT-lizenzierte Basis. Wer einen verwalteten Dienst ohne eigene Node.js-Instanz, ohne Base-Wallet und ohne `mltl`-Abhängigkeit will, sollte nicht einsteigen. Vor dem ersten produktiven Lauf zu prüfen: ob `mltl` installiert und ein Wallet angelegt ist, ob der gewählte LLM-Provider den Tool-Use-Pfad über den gemeinsamen Adapter korrekt bedient, und ob die Standardwerte für maximale Turns (10) und Studienintervall (30 Minuten) zum eigenen Budget passen.

Offizielle Quellen

1. Issues
2. License: MIT
3. moltlaunch/cashclaw on GitHub
4. Project website
5. README