Thrum

I built Thrum so you can run several AI coding agents in parallel without becoming the message relay yourself. You do the thinking — research, plan, approve. Agents do the typing. Thrum routes messages between them, keeps sessions alive, and stays out of your way. It doesn't plan your work or make decisions for you. That's a deliberate choice.

What You Can Build With It

Here are the four main shapes of how people use Thrum today. Each one is a complete workflow, not a feature list. Pick the one that matches where you are right now — solo with one agent, a local team of agents, agents spread across repos or machines, or fully automated plan execution. They're not mutually exclusive. Most people start with the first and add complexity only when they need it.

Further Reading

  • Why Thrum Exists — the reasoning behind human-directed agent coordination and what Thrum deliberately doesn't do
  • Quickstart Guide — install Thrum, start the daemon, and get your first agent running in under five minutes
  • CLI Reference — every command, flag, and alias; what's for you, what's for agents, and what you run once at setup
  • Architecture — daemon internals, JSONL event log, SQLite projection, sync protocol, and peer transport
  • Agent Coordination — practical patterns for running multiple agents in parallel and integrating with Beads for task tracking
  • Permission Prompt Detection — how the daemon detects blocked agents, routes supervisor nudges, and accepts approvals from CLI, web, or Telegram
  • Security Model — local trust stack, identity guards, WebSocket origin enforcement, and message author controls
  • CLI Hints — contextual guidance printed around destructive and multi-step commands; how to suppress them
  • Troubleshooting: Identity — diagnosing and recovering from identity guard errors, CWD drift, and name collision failures