Raindrop Workshop: lokale Traces für Coding-Agents, mit Claude Code als Eval-Autor

Das Problem: der Agent läuft, aber niemand sieht mit

Ein Coding-Agent führt Werkzeuge aus, ruft Modelle auf, verwirft Zwischenergebnisse. Nach einem Fehlschlag bleibt meist nur das Endergebnis. Die README beschreibt genau diese Lücke: Workshop soll der lokale Debugger sein, der jedem Token, jedem Tool-Call und jeder Entscheidung beim Entstehen zusieht. Der Adressat ist damit klar umrissen. Es ist nicht das Team, das eine Produktions-Pipeline überwachen will, sondern die Person, die im eigenen Repository sitzt, den Agenten laufen lässt und sofort sehen will, wo er abbiegt. Die README formuliert das als Satz an Claude Code gerichtet: Traces lesen, Evals gegen die eigene Codebasis schreiben, Kaputtes reparieren. Das ist ein enger Zuschnitt. Der Nutzen entsteht erst, wenn der Agent selbst Zugriff auf seine Traces bekommt und daraus Testfälle ableitet. Ohne diesen Schritt bleibt Workshop ein Trace-Viewer mit lokaler Datenbank.

Datenfluss: SDK spiegelt, Daemon sammelt, UI streamt

Die Architektur ist in drei Teile zerlegt. Auf der SDK-Seite steuert die Umgebungsvariable RAINDROP_LOCAL_DEBUGGER, wohin Traces gespiegelt werden. Sie ist laut Konfigurationstabelle standardmäßig nicht gesetzt, muss also aktiv belegt werden. Auf der Empfängerseite läuft ein lokaler Daemon, der HTTP und WebSocket auf RAINDROP_WORKSHOP_PORT bedient, voreingestellt 5899. Die Ablage ist eine SQLite-Datei, gesteuert über RAINDROP_WORKSHOP_DB_PATH, standardmäßig ~/.raindrop/raindrop_workshop.db. Die README nennt das Streaming explizit ohne Polling und ohne manuelles Neuladen, was zur WebSocket-Nutzung auf demselben Port passt. Bemerkenswert ist die Trennung der Zuständigkeiten: die Datenbank liegt außerhalb des Projektverzeichnisses im Home-Verzeichnis des Nutzers. Wer mehrere Repositories parallel debuggt, schreibt damit in dieselbe Datei, sofern der Pfad nicht überschrieben wird. Das ist eine Designentscheidung mit Folgen, die die README nicht ausdiskutiert. Für ein einzelnes Projekt ist sie bequem, für getrennte Trace-Bestände pro Repo braucht es RAINDROP_WORKSHOP_DB_PATH.

Installation: ein curl-Pipe, kein Klon

Der Installationsweg ist bewusst kurz gehalten. Ein Befehl, und laut README gibt es nichts zu klonen und nichts zu bauen: curl -fsSL https://raindrop.sh/install | bash. Die README warnt ausdrücklich davor, aus dem Quellcode zu bauen, nur um Workshop auszuprobieren. Der Build-Pfad mit bun install und bun run dev ist für Mitwirkende am Projekt selbst gedacht, nicht für Anwender. Nach der Installation folgt die Instrumentierung: im eigenen Repository den Coding-Agenten öffnen und /instrument-agent ausführen. Laut README instrumentiert dieser Schritt den Agenten mit Raindrop-Tracing und öffnet Workshop im Browser. Für den Eval-Kreislauf nennt die README einen weiteren Befehl, /setup-agent-replay, der einen HTTP-Endpunkt erzeugt, um einen Produktions-Trace gegen den echten Agentencode abzuspielen. Die CLI deckt den Rest ab: raindrop workshop startet und öffnet die Oberfläche, raindrop workshop setup schreibt zuerst die .env, raindrop workshop status prüft die Gesundheit, raindrop workshop reset löscht die lokale Datenbank nach Bestätigung, raindrop update aktualisiert die Binärdatei. Wer den Reset ohne Nachfrage in ein Skript einbaut, sollte wissen, dass eine Bestätigung vorgesehen ist.

Der Eval-Kreislauf hängt an Claude Code

Die README beschreibt einen selbstheilenden Ablauf: Claude schreibt das Eval, führt den Agenten aus, sieht den Fehlschlag, korrigiert den Code und wiederholt das, bis jede Assertion durchläuft. Das ist der inhaltlich interessanteste Teil und zugleich der am dünnsten dokumentierte. Die README nennt weder das Dateiformat der Evals noch, wo sie im Repository landen, noch wie die Assertions formuliert werden. Auch die Frage, ob der Kreislauf nach einer festen Zahl von Versuchen abbricht, bleibt offen. Wer diesen Teil produktiv nutzen will, muss ihn im eigenen Repo ausprobieren und die Ergebnisse selbst beurteilen. Ein zweiter Punkt: der Kreislauf setzt voraus, dass der ausführende Agent Schreibzugriff auf den Code hat. Ein Agent, der nur lesen darf, kann den beschriebenen Ablauf nicht durchlaufen. Die Liste kompatibler Coding-Agents umfasst Claude Code, Codex, Devin, Cursor und OpenCode, doch die README führt Claude Code namentlich als den Agenten, der Traces liest und Evals schreibt. Ob die anderen Agents dieselbe Rolle übernehmen, lässt sich dem Material nicht entnehmen.

Replay als Brücke, mit unklarer Abdeckung

Der Befehl /setup-agent-replay erzeugt laut README einen HTTP-Endpunkt, der einen Produktions-Trace gegen den realen Agentencode abspielt. Das ist der Versuch, den Graben zwischen lokalem Debugging und echter Last zu schließen: statt den Agenten blind gegen eine Live-Umgebung laufen zu lassen, wird ein aufgezeichneter Ablauf lokal nachgestellt. Die README lässt allerdings offen, woher der Trace stammt, welche Werkzeugaufrufe ersetzt und welche echt ausgeführt werden, und ob Seiteneffekte beim Replay unterdrückt werden. Genau diese Punkte entscheiden aber, ob ein Replay aussagekräftig ist. Ein Replay, das schreibende Werkzeugaufrufe echt ausführt, ist ein Risiko; eines, das sie stillschweigend wegfiltert, produziert womöglich grüne Tests für Code, der in Produktion scheitert. Diese Bewertung ist eine Einschätzung auf Basis der README, keine geprüfte Aussage über das Verhalten des Werkzeugs. Wer Replay einsetzen will, sollte zuerst klären, welche Aufrufe beim Abspielen tatsächlich gegen das eigene System gehen.

Lokaler Daemon oder gehosteter Dienst: zwei Betriebsarten

Raindrop betreibt zwei Produkte mit demselben Binary. Workshop ist der lokale Debugger mit Daemon und SQLite. Raindrop Cloud ist das gehostete Produkt für Produktions-Observability unter app.raindrop.ai, laut README ohne lokalen Daemon. Die Einrichtung läuft über raindrop cloud setup, das den Nutzer anmeldet, den RAINDROP_WRITE_KEY der Organisation in ./.env schreibt und den gehosteten MCP-Server samt der Skills raindrop-setup und raindrop-investigate in die Coding-Agents installiert. Die Anmeldung ist getrennt und wird über raindrop login abgewickelt, das die Zugangsdaten in ~/.raindrop zwischenspeichert; raindrop logout löscht sie. cloud setup ruft login nur auf, wenn noch keine Sitzung besteht. Die beiden Installationsarten kollidieren laut README nicht, weil sie unterschiedliche MCP-Servernamen verwenden, workshop gegen raindrop, und getrennte Installationsregister führen. Der Installer kennt dafür den Schalter --cloud, der cloud setup ausführt und keinen Daemon startet. Der Gegensatz zu einem reinen Trace-Viewer ist hier der Kern: der Cloud-Pfad liefert Daten aus dem Betrieb, der lokale Pfad liefert Daten aus dem eigenen Rechner während der Entwicklung. Wer beides braucht, betreibt zwei getrennte Installationen nebeneinander.

Grenzen: nicht-interaktive Läufe, Datenmenge, Rückbau

Ein konkretes Verhalten nennt die README explizit: raindrop setup bietet im interaktiven Modus als letzten Schritt optional die Cloud-Einrichtung an, doch nicht-interaktive Läufe in CI oder in gepipten Skripten fragen nie nach. Dort muss cloud setup oder der --cloud-Einzeiler verwendet werden. Das ist eine nützliche Zusicherung für Automatisierung, bedeutet aber auch, dass ein CI-Lauf ohne --cloud stillschweigend Workshop-only bleibt. Ein zweiter Punkt ist die Datenmenge. Jeder Token und jeder Span landet in einer SQLite-Datei, die im Home-Verzeichnis liegt und über alle Projekte hinweg dieselbe sein kann. Die README nennt keine Aufbewahrungsfrist, keine Größenbegrenzung und keine automatische Rotation. raindrop workshop reset löscht die Datenbank, aber erst nach Bestätigung. Wer viel debuggt, muss die Datei im Blick behalten oder RAINDROP_WORKSHOP_DB_PATH pro Projekt setzen. Der Rückbau ist getrennt geregelt: raindrop cloud uninstall entfernt den gehosteten MCP-Server und die Cloud-Skills und lässt die lokale Installation unberührt; erst der Zusatz --wipe entfernt zusätzlich RAINDROP_WRITE_KEY aus ./.env. Wer den Schlüssel in einer versionierten .env ablegt, sollte das vor dem ersten Commit bedenken.

Wann ein anderes Werkzeug die bessere Wahl ist

Die Alternative mit dem klarsten Unterschied steht in der README selbst: Raindrop Cloud. Der Unterschied liegt nicht im Umfang der Auswertung, sondern im Ort der Verarbeitung. Workshop betreibt einen lokalen Daemon auf Port 5899 und schreibt in eine SQLite-Datei auf dem eigenen Rechner, was ohne Netzwerk funktioniert und die Trace-Daten nicht aus der Maschine trägt. Cloud startet keinen Daemon, schreibt über raindrop cloud setup einen RAINDROP_WRITE_KEY in ./.env und schickt Ereignisse an app.raindrop.ai. Wer Traces aus einer laufenden Produktionsumgebung braucht, kommt mit dem lokalen Daemon nicht weit; wer in einer Umgebung arbeitet, in der Trace-Daten den Rechner nicht verlassen dürfen, ist mit dem Cloud-Pfad falsch bedient. Die README hält beide Wege ausdrücklich koexistenzfähig, sodass die Wahl keine Migration erzwingt. Ein dritter Weg wäre ein Trace-Viewer, der ohne Agenten-Integration auskommt und nur eine bestehende Tracing-Pipeline anzeigt. Workshop setzt dagegen auf die Instrumentierung durch /instrument-agent und auf den Agenten als Autor der Evals. Wer diese Integration nicht will, verliert den größten Teil des Nutzens und behält nur ein Frontend für SQLite.

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

Workshop steht unter MIT. Das ist eine permissive Lizenz ohne Copyleft-Pflicht, erlaubt also Änderungen und Weitergabe auch in proprietären Projekten, solange der Lizenztext beiliegt. Das gilt für das Repository. Für den gehosteten Dienst unter app.raindrop.ai sagt die README nichts über Vertragsbedingungen oder Datenhaltung; die MIT-Lizenz des lokalen Werkzeugs erstreckt sich nicht automatisch auf den Cloud-Dienst. Wer den Cloud-Pfad wählt, sollte die Bedingungen dort getrennt prüfen. Zur Pflege lässt sich aus dem Material nur wenig ableiten: die letzten Einträge liegen bei v0.1.21, v0.1.20 und v0.1.19, wobei v0.1.21 und v0.1.20 auf denselben Tag datiert sind. Die Versionsnummern im 0.1-Bereich deuten auf ein junges Projekt hin. Konkrete Aussagen über Upgradepfade, Breaking Changes oder Supportzeiträume macht die README nicht, und ich habe sie nicht geprüft. raindrop update aktualisiert die Binärdatei, ein Befehl, der in einem Skript leicht vergessen wird. Der Aufwand für Upgrades lässt sich aus dem vorliegenden Material nicht abschätzen.

Redaktionelles Fazit

Wer einen Agenten in TypeScript, Python, Go oder Rust lokal debuggen will und Claude Code ohnehin im Repo laufen hat, bekommt mit Workshop einen Daemon auf Port 5899 und eine SQLite-Datei unter ~/.raindrop/raindrop_workshop.db, ohne selbst etwas zu bauen. Wer Produktions-Traces ohne lokalen Prozess braucht, nimmt stattdessen raindrop cloud setup und den gehosteten MCP-Server. Vor dem Ausprobieren würde ich zuerst prüfen, ob das aufgerufene /instrument-agent im eigenen Repo überhaupt greift, und mit raindrop workshop status nachsehen, ob der Daemon antwortet.

Offizielle Quellen

1. License: MIT
2. Project website
3. raindrop-ai/workshop on GitHub
4. README
5. Releases