Raindrop Workshop: a local trace viewer that lets Claude Code write the evals
Give your coding agent the power to write and run agent evals.
At a glance
- What is it?
- Workshop is a local daemon plus a browser UI that streams agent traces as they happen, and a set of agent skills that let Claude Code read those traces and author evals against your codebase. It is a debugging and eval-authoring tool for developers already running a coding agent, not a hosted evaluation platform.
- Who is it for?
- Adopt Workshop if you are already driving Claude Code or a comparable agent inside a repository and you want traces visible locally without standing up a hosted service. Skip it if your team needs shared dashboards, cross-machine trace comparison, or a CI-friendly eval runner: the README describes a local daemon on port 5899 with a SQLite file under ~/.raindrop, and nothing in the material describes a headless eval command or a team view.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 24 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Workshop targets: traces you can see, evals you did not have to write
Agent debugging usually splits into two unsatisfying halves. You either read raw provider logs and reconstruct the call sequence by hand, or you ship traces to a hosted backend and wait for a round trip before you can inspect a single span. Workshop takes a third position: a local daemon that streams traces into a browser UI on your own machine, plus agent skills that read those traces and turn a failure into a test. The README frames it as "the local debugger your agent is missing," and the pitch is aimed at people who already work inside a coding agent. The intended user is a developer running Claude Code (the README also lists Codex, Devin, Cursor and OpenCode as compatible coding agents) in a repository where an LLM-backed feature lives. The problem being solved is not trace storage. It is the distance between noticing a bad agent run and having an executable assertion that catches it next time.
How traces reach the browser: daemon, SQLite file, WebSocket, MCP
The architecture visible in the README has four moving parts. First, an instrumentation step wires Raindrop tracing into your agent code. Second, traces are mirrored toward the local debugger; the SDK-side env var RAINDROP_LOCAL_DEBUGGER is documented as controlling "where to mirror traces" and is unset by default. Third, the daemon serves an HTTP and WebSocket endpoint, defaulting to port 5899, and persists to a SQLite file at ~/.raindrop/raindrop_workshop.db. Fourth, the UI consumes the stream. The README states that every token, tool call and span streams in as it happens, with no polling and no refreshing, which is the WebSocket half of that pair doing the work. The coding-agent integration is described as an MCP server named workshop, which is how Claude Code gets access to your traces. Note the separation the README draws: Raindrop Cloud uses a different MCP server name (raindrop) and a separate install registry, so a local Workshop install and a cloud install can coexist without overwriting each other. That naming detail is the sort of thing that matters when an agent has two trace sources available and you need to know which one answered.
Install and first run: one curl, one slash command
The README is unusually direct about installation. There is nothing to clone and nothing to build for normal use, and it explicitly tells people using an AI coding agent to have the agent run the install command rather than building from source. The command is:
curl -fsSL https://raindrop.sh/install | bash
That runs raindrop setup and starts the local Workshop daemon. From inside your repository, in your coding agent, you then run /instrument-agent, which the README says instruments the agent with Raindrop tracing and opens Workshop in the browser. A second skill, /setup-agent-replay, scaffolds an HTTP endpoint that replays a production trace against your real agent code. Day-to-day CLI surface is small: raindrop workshop starts and opens the UI, raindrop workshop setup writes .env before starting, raindrop workshop status checks health, raindrop workshop reset deletes the local database after confirmation, and raindrop update updates the binary. Three environment variables are documented: RAINDROP_WORKSHOP_PORT (default 5899), RAINDROP_WORKSHOP_DB_PATH (default ~/.raindrop/raindrop_workshop.db), and RAINDROP_LOCAL_DEBUGGER. Contributors who want to work on Workshop itself clone the repo and run bun install followed by bun run dev, which starts the daemon and a Vite UI.
The eval loop is the interesting claim, and the least specified
The README's central claim is a self-healing loop: Claude writes the eval, runs your agent, sees the failure, fixes the code, and re-runs until every assertion passes. That is a meaningful shift from the usual workflow, where a human writes the assertion after diagnosing the failure. But the README does not specify the eval file format, where evals are written in the repository, how the runner is invoked outside the agent, or what an assertion looks like. Those are the details you would need to decide whether the generated evals are something your team can maintain or review in a pull request. The same gap applies to /setup-agent-replay: the README says it scaffolds an HTTP endpoint that replays a production trace against your real agent code, without describing the endpoint's shape or how a production trace is obtained in the first place. This is not a reason to dismiss the tool. It is a reason to treat the eval loop as the thing to evaluate first, by running it once on a known-broken agent path and reading the file it produces.
Where Workshop is the wrong tool
Workshop is local-first by design, and that design has consequences. The default database is a SQLite file in your home directory, which means traces live on one machine and are not shared with a teammate by default. If your problem is comparing a regression across three environments, or letting a reviewer open the exact trace that a bug report references, a single-user local UI does not answer it. The README positions Raindrop Cloud as the hosted counterpart for production observability, and the cloud path is a separate install with a separate MCP server name, so choosing Workshop is not choosing the hosted product. There is also a resource consideration the README does not address: a daemon that persists every token and span to SQLite will accumulate, and the only documented cleanup is raindrop workshop reset, which deletes the local database entirely after confirmation. There is no documented retention policy, rotation, or selective pruning. If you need long-lived trace history with query across months, this is not the shape of tool you are looking at.
Compared with a general tracing backend
The obvious alternative is sending spans to a general-purpose observability backend such as Langfuse or OpenTelemetry-backed tooling, where traces land in shared storage and you query them with a UI built for many users. The difference in approach is not only hosting. In that model, the trace is a record you inspect after the fact, and evals are typically written by a person in a separate framework. Workshop inverts the direction: the trace is an input to a coding agent that then authors the test, with the loop closing inside the agent session. That is a genuine difference in where the work happens, and it is also the source of the risk. A general backend gives you a durable, shared artifact and a stable query language. Workshop gives you a fast local feedback cycle and generated assertions whose maintainability depends on the agent that wrote them. If your team already has a tracing backend and a human-owned eval suite, Workshop competes with the loop you already have rather than with the storage you already have.
Maintenance, licensing and the cloud boundary
Workshop is MIT licensed, which permits commercial use and modification; that is a statement about the licence text, not legal advice for your situation. The repository is active rather than archived, with v0.1.21 published on 2026-08-22 and v0.1.20 the same day, and v0.1.19 about a week earlier. That cadence on a 0.1.x line tells you the API surface is still moving, so pin the binary version you install and expect the CLI and skill names to change between releases. Upgrade cost is low on the local path: raindrop update replaces the binary, and the daemon restarts against the same SQLite file. The cloud path carries a different cost. raindrop cloud setup signs you in via OAuth, writes your org's RAINDROP_WRITE_KEY to ./.env, and installs a hosted MCP server plus the raindrop-setup and raindrop-investigate skills into your agents. raindrop cloud uninstall removes the MCP server and skills and clears the cloud install registry while leaving the local Workshop install untouched; adding --wipe additionally removes RAINDROP_WRITE_KEY from ./.env. Credentials from raindrop login are cached in ~/.raindrop and cleared with raindrop logout. Because the write key lands in a file inside the repository, check whether ./.env is ignored before you run the cloud setup, and note that the non-interactive path never prompts: in CI or a piped script you must call raindrop cloud setup or use the --cloud installer flag explicitly.
Editorial conclusion
Adopt Workshop if you are already driving Claude Code or a comparable agent inside a repository and you want traces visible locally without standing up a hosted service. Skip it if your team needs shared dashboards, cross-machine trace comparison, or a CI-friendly eval runner: the README describes a local daemon on port 5899 with a SQLite file under ~/.raindrop, and nothing in the material describes a headless eval command or a team view. Before committing, verify the port and database path against your own environment, confirm that /instrument-agent actually registers the skills in your agent of choice, and check whether raindrop cloud setup writes RAINDROP_WRITE_KEY into ./.env in a repo where that file is committed.
Community notes