Show HN: Real-time dashboard for Claude Code agent teams

This project (Agents Observe) started as an exploration into building automation harnesses around claude code. I needed a way to see exactly what teams of agents were doing in realtime and to filter and search their output.

A few interesting learnings from building and using this:

- Claude code hooks are blocking - performance degrades rapidly if you have a lot of plugins that use hooks

- Hooks provide a lot more useful info than OTEL data

- Claude's jsonl files provide the full picture

- Lifecycle management of MCP processes started by plugins is a bit kludgy at best

The biggest takeaway is how much of a difference it made in claude performance when I switched to background (fire and forget) hooks and removed all other plugins. It's easy to forget how many claude plugins I've installed and how they effect performance.

The Agents Observe plugin uses docker to start the API and dashboard service. This is a pattern I'd love to see used more often for security (think Axios hack) reasons. The tricky bit was handling process management across multiple claude instances - the solution was to have the server track active connections then auto shut itself down when not in use. Then the plugin spins it back up when a new session is started.

This tool has been incredibly useful for my own daily workflow. Enjoy!

Show HN: Real-time dashboard for Claude Code agent teams
github.com

Thanks! This was step one in my daily driver stack - better observability. I also bundled up a bunch of other observability services in https://github.com/simple10/agent-super-spy so I can see the raw prompts and headers.

The next big layer for my personal stack is full orchestration. Something like Paperclip but much more specialized for my use cases.

Good to know background hooks make that much of a difference. How are you handling the case where multiple agent teams are writing to the same jsonl files simultaneously?

I'm not actually reading the jsonl files. Agents Observe just uses hooks and sends all hook data the server (running as a docker container by default).

Basic flow:

1. Plugin registers hooks that call a dump pipe script that sends hook events data to api server

2. Server parses events and stores them in sqlite by session and agent id - mostly just stores data, minimal processing

3. Dashboard UI uses websockets to get real-time events from the server

4. UI does most of the heavy lifting by parsing events, grouping by agent / sub-agent, extracting out tool calls to dynamically create filters, etc.

It took a lot of iterations to keep things simple and performant.

You can easily modify the app/client UI code to fully customize the dashboard. The API app/server is intentionally unopinionated about how events will be rendered. This was by design to add support for other agent events soon.

The hooks approach seems much cleaner for real-time. Did you run into any issues with the blocking hooks degrading performance before you switched to background?