# Raindrop Workshop streams agent traces locally, and its package file says 0.0.17 while the tag says v0.1.21

> A local trace debugger for coding agents, installed by piping a script into a shell, that stores runs in a SQLite file, exposes nine CLI verbs across a local daemon and a hosted product kept apart by MCP server name, and ships a package file whose version field is not the version you install.

**raindrop-ai/workshop** — Give your coding agent the power to write and run agent evals.

- Repository: https://github.com/raindrop-ai/workshop
- Website: https://www.raindrop.ai/workshop/
- Stars: 1,104 · Forks: 69
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/raindrop-ai-workshop

## One command installs it, and the readme tells agents not to build from source

The whole install is one line:

```bash
curl -fsSL https://raindrop.sh/install | bash
```

There is nothing to clone and nothing to build. The instruction that follows is aimed squarely at automated readers: if you are an AI coding agent, run that command, and do not clone or build from source just to try Workshop, because that path is only for people developing Workshop itself.

Instrumentation then happens inside your agent. Open your coding agent of choice in your repository and run:

```text
/instrument-agent
```

That instruments the agent with Raindrop tracing and opens Workshop in your browser, after which traces stream into the interface the moment the agent runs.

One thing about the installer is worth naming. It fetches a script from a domain and pipes it straight into a shell, with no checksum and no review step. The repository does contain an install.sh at its top level, but nothing states that the script served at that address is the one committed there, so the reproducible path and the convenient path are not the same path.

The four verbs that matter for day to day work are short: raindrop workshop to start and open the interface, workshop setup to write the env file first, workshop status to check health, and workshop reset to delete the local database after a confirmation.

## The package file says 0.0.17 while the release tag says v0.1.21

The package is named @raindrop/workshop and its version field reads 0.0.17. It is marked private, and its own description says private development, not published to npm, distributed as the raindrop CLI binary, with raindrop workshop as the user-facing surface.

The release tags tell a different number. They are v0.1.19 on 2026-08-14, then v0.1.20 and v0.1.21 on 2026-08-22 about half an hour apart, and the last push to the default branch carries the same timestamp as v0.1.21. The repository is not archived.

So there are two version numbers in play, and they are not kept in step. One belongs to a private package that is never published, the other to the artifacts the installer hands you. Since the package is deliberately not on npm, the version field is not the release version, and nothing in the documentation reconciles the two. Anyone filing a bug should quote the tag or the output of a status check rather than the version in the source tree.

Two release tags landing 34 minutes apart on the same day also suggests a hotfix pattern rather than a scheduled cadence, which is worth knowing before you plan around a version number moving.

## The documented port is 5899 and the dev script falls back to 5900

Three environment variables are documented, and they are the whole configuration surface:

- `RAINDROP_WORKSHOP_PORT`, the HTTP and WebSocket port, default 5899
- `RAINDROP_WORKSHOP_DB_PATH`, the SQLite database file, default `~/.raindrop/raindrop_workshop.db`
- `RAINDROP_LOCAL_DEBUGGER`, SDK side, where to mirror traces, unset by default

The development script in the package file disagrees with the first of them. Running the dev task starts the daemon and a Vite interface side by side, and the line it prints builds a URL from `RAINDROP_WORKSHOP_UI_PORT` with a fallback of 5900. That variable appears nowhere in the configuration table.

So there are two port variables with different names and different defaults: 5899 for the daemon's HTTP and WebSocket listener, and 5900 as the fallback for the interface in development. The from-source section compounds it by telling you to open `http://localhost:5899` after `bun run dev` starts, which is the daemon port rather than the printed one.

The third variable is the interesting one for integration work, because it is unset by default and lives on the SDK side. Traces are mirrored to the debugger only when something tells the SDK where the debugger is.

## Two declared scripts point at paths that are not in the tree

The top level of the repository is short: .gitignore, AGENTS.md, LICENSE, README.md, app/, bin/, bun.lock, bunfig.toml, docs/, drizzle.config.ts, drizzle/, eslint.config.mjs, examples/, install.sh, latest.json, package.json, scripts/, skills/, src/, tsconfig.eslint.json and tsconfig.json.

Two of the declared scripts do not match that list. The test script is `bun test tests/`, and there is no tests directory at the top level. The setup script is `bash .devin/setup.sh`, and there is no .devin directory either.

The missing test directory is the one that matters for anyone contributing: a fresh clone has no way to run the command the package declares as its test entry point. The missing .devin path is narrower, and it is consistent with the compatibility list, which names Devin among the coding agents. It looks like a per agent bootstrap that lives outside the published tree.

Two other details in the same file are worth knowing. The postinstall step creates a relative symlink, `ln -sf ../bin/raindrop-dev node_modules/.bin/raindrop-dev`, which points from inside node_modules back out into the repository. And the build task runs an embedded migrations check, a TypeScript pass with no emit, and then the interface build, so a build fails early when migrations and the schema have drifted apart.

## Local and cloud are kept apart by MCP name and by install registry

Workshop is the local debugger. Raindrop Cloud is a separate hosted product, and the same raindrop binary connects a project to it with no local daemon involved. The two are deliberately prevented from colliding.

The mechanism is two registries and two names. They use distinct MCP server names, workshop against raindrop, and separate install registries, so neither overwrites the other. That is a small design decision with a large practical consequence: you can run both, and uninstalling one does not take the other with it.

The switch is a flag on the installer:

```bash
curl -fsSL https://raindrop.sh/install | bash -s -- --cloud
```

Without the flag the installer runs the local setup and starts the Workshop daemon. With it, the installer runs the cloud setup and starts no daemon at all.

Sign in is handled once and reused. `raindrop login` is an OAuth sign in that caches credentials under `~/.raindrop`, and `raindrop logout` clears them. The cloud setup command calls login for you only when you are not already signed in, so day to day you run the setup once. Interactive runs of the local setup also offer the cloud as an optional last step, and declining leaves you with a Workshop only install; non interactive runs, meaning continuous integration or piped scripts, never prompt at all, which is why the cloud command and the one line installer exist as separate paths.

## The write key lands in ./.env, and uninstall leaves it unless you add --wipe

Connecting a project to the cloud does four things in one command. It signs you in, opening a browser the first time. It writes your organisation's `RAINDROP_WRITE_KEY` to `./.env`. It installs the hosted MCP server plus the cloud skills, named `raindrop-setup` and `raindrop-investigate`, into your AI coding agents. And then you run `/raindrop-setup` inside your agent to instrument the app, after which events stream to the hosted application.

Three consequences follow from that sequence.

The credential is written into a file that usually sits inside your repository, in the same place as other environment files, which makes it a thing to keep out of version control by habit rather than by tooling.

The write key belongs to an organisation rather than to a person, so revoking it is an organisation side action and not something you can do alone.

And the undo is asymmetric. `raindrop cloud uninstall` removes the hosted MCP server and the cloud skills from your agents and clears the cloud install registry, and that is stated to leave your local Workshop install untouched. It does not remove the key from the env file. Passing `--wipe` is what also removes `RAINDROP_WRITE_KEY` from `./.env`, which means the clean state requires knowing an option that the shorter command does not mention.

## Four languages and thirteen SDKs are listed, and none of them carry a version

The compatibility section is a list of names in four groups, and it is the broadest claim in the file.

Languages are TypeScript, Python, Go and Rust. Providers are AWS Bedrock, Azure OpenAI and Vertex AI. Coding agents are Claude Code, Codex, Devin, Cursor and OpenCode.

The SDK group is the longest: the Vercel AI SDK, the OpenAI Agents SDK, the Anthropic SDK, the Claude Agent SDK, LangChain, LangGraph, CrewAI, Mastra, Pydantic AI, DSPy, Google ADK, Strands, Agno and Deep Agents. That is thirteen entries, and not one of them carries a version number or a minimum.

For a package whose entire purpose is observing behaviour at the boundary between your code and a model provider, a compatibility list without versions is the weakest part of the documentation. Traces and spans have changed shape more than once across these SDKs, and a claim of support that names no release is a claim you have to verify yourself.

The examples directory is where that verification can start. It carries a subdirectory per integration, including ai-sdk-chat, ai-sdk-otelv2, anthropic-chat, browser-chat, claude-agent-sdk, go-chat, openai-chat, opencode-plugin-chat, pi-agent-chat, python-chat and rust-chat, plus a shared directory and a loadEnv helper. Eleven runnable shapes against the thirteen named SDKs is as close as the repository comes to a version matrix.

## Conclusion

Raindrop Workshop suits someone who wants to watch an agent run on their own machine and then let that same agent write the eval, rather than shipping traces to a hosted service first. Four things to check. The installer pipes a script from a domain into bash even though the repository carries an install script of its own. The version inside the package file is not the version you get. Two of the declared package scripts point at directories that are not in the tree, so a fresh clone cannot run its own test command. And enabling the cloud path writes a write key into your .env file that uninstall leaves in place unless you pass --wipe.

## FAQ

### How do I install Raindrop Workshop?

With one command, `curl -fsSL https://raindrop.sh/install | bash`. There is nothing to clone and nothing to build, and the file explicitly tells an AI coding agent to run that rather than build from source, since the source path is only for developing Workshop itself. Then run `/instrument-agent` inside your agent in your repository.

### Does Raindrop Workshop send my traces anywhere by default?

Not by default. The local daemon stores traces in a SQLite database at `~/.raindrop/raindrop_workshop.db`, and the installer starts that daemon unless you pass `--cloud`. Raindrop Cloud is a separate hosted product reached only when you run `raindrop cloud setup` or the one line installer with the cloud flag, and the two coexist by using distinct MCP server names and separate install registries.

### What does raindrop cloud uninstall actually remove?

It removes the hosted MCP server and the cloud skills, `raindrop-setup` and `raindrop-investigate`, from your agents, and clears the cloud install registry, leaving your local Workshop install untouched. It does not remove the credential, so `--wipe` is what also takes `RAINDROP_WRITE_KEY` out of `./.env`.

### Which coding agents and model providers does Raindrop Workshop work with?

The listed coding agents are Claude Code, Codex, Devin, Cursor and OpenCode, and the listed providers are AWS Bedrock, Azure OpenAI and Vertex AI. Thirteen SDKs are named across the ecosystem, from the Vercel AI SDK and Anthropic SDK through LangGraph, Pydantic AI and DSPy, and the documentation attaches no version numbers to any of them.

### What does /setup-agent-replay do in Raindrop Workshop?

It scaffolds an HTTP endpoint that replays a production trace against your real agent code, which is the local half of the workflow. The other documented command is `/instrument-agent`, which instruments your agent with Raindrop tracing and opens Workshop in the browser so traces stream as the agent runs.

## Sources

- [License: MIT](https://github.com/raindrop-ai/workshop/blob/main/LICENSE)
- [Project website](https://www.raindrop.ai/workshop/)
- [raindrop-ai/workshop on GitHub](https://github.com/raindrop-ai/workshop)
- [README](https://github.com/raindrop-ai/workshop/blob/main/README.md)
- [Releases](https://github.com/raindrop-ai/workshop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/raindrop-ai-workshop