vs beads
clu is a local-first reimagining of beads — what it keeps, what it drops on purpose (Dolt sync, agent memory, MCP), and what it adds (web UI, clu batch, workflow gates).
clu started from beads (bd) and shares
its core idea: a dependency-aware issue graph as durable memory for coding
agents. Where they differ is the bet underneath.
- beads is distributed: a Dolt-backed, version-controlled SQL database with branching, cell-level merge, and cross-machine sync — plus an agent-memory layer and a broad set of tool/IDE integrations.
- clu is local-first: one pure-Go binary over a single SQLite file, no network and no CGo, that trades sync/memory/integrations for a tighter core with a built-in web UI, validated bulk-graph instantiation, and richer on-machine coordination.
Same DNA, different bet. beads optimizes for distribution and agent memory; clu optimizes for a single local file, zero dependencies, and built-in coordination. Pick by which bet matches your setup.
Shared core
Both are agent-oriented graph issue trackers with the same loop, so most of what you know transfers:
| Capability | clu | beads |
|---|---|---|
Dependency graph, ready / blocked detection | ✅ | ✅ |
| Atomic claim (racing agents get different issues) | ✅ | ✅ |
Hash-style IDs (clu-a3f8 / bd-a1b2) | ✅ | ✅ |
| Priorities, types, labels, comments | ✅ | ✅ |
--json everywhere for agent consumption | ✅ | ✅ |
| Audit trail / history | ✅ | ✅ |
Works offline, git-free usage (CLU_DIR / BEADS_DIR) | ✅ | ✅ |
Storage & sync
| Capability | clu | beads |
|---|---|---|
| Storage engine | SQLite (pure Go) | Dolt (versioned SQL) |
| One plain file you can copy | ✅ .clu/data.sqlite | 🟡 Dolt dir / server |
| Cross-machine sync | 🟡 clu sync git-ref (experimental) | ✅ Dolt remotes (push/pull) |
| Branch-independent storage (no conflicts with code) | ✅ refs/clu/store ref | ✅ beads branch |
| Multiple concurrent writers (server mode) | ❌ single-writer | ✅ dolt sql-server |
| Branching + cell-level merge | ❌ | ✅ |
| Backup / restore tooling | 🟡 export/import JSONL | ✅ bd backup (Dolt-aware) |
| Pure Go, no CGo, single static binary | ✅ | 🟡 bundles Dolt |
Structure & agent memory
| Capability | clu | beads |
|---|---|---|
Hierarchical IDs (epics a3f8.1.1) | ❌ flat IDs + deps/labels | ✅ |
Persistent agent memory (remember / prime) | ❌ out of scope | ✅ |
| Compaction / "memory decay" of old tasks | ❌ | ✅ |
Typed graph links (relates_to, supersedes, …) | 🟡 deps + free labels | ✅ |
| Threaded messaging issue type | 🟡 ping / inbox mailbox (TTL'd) | ✅ |
Coordination & orchestration
This is where clu adds the most over upstream:
| Capability | clu | beads |
|---|---|---|
| Bundled web UI (board / list / approvals) | ✅ clu web | 🟡 community tools |
| Validated bulk-graph instantiation | ✅ clu batch | 🟡 JSONL import |
| Static workflow templates (YAML) | ✅ clu run | ❌ |
| Dynamic workflows (JS generators) | ✅ codemode | ❌ |
| Human-approval checkpoints + milestones | ✅ | ❌ |
Capability routing (cap:* → agent lanes) | ✅ | ❌ |
Heartbeat / liveness (clu agent ls) | ✅ | ❌ |
Agent launcher (clu agent start) | ✅ | ❌ |
| Named locks / leases | ✅ | ❌ |
| Git-worktree management + bootstrap | ✅ | ❌ |
Recurring jobs (clu cron) | ✅ | ❌ |
Integration & distribution
| Capability | clu | beads |
|---|---|---|
| MCP server | ❌ CLI + JSON only | ✅ beads-mcp |
| One-command agent/IDE setup (hooks, AGENTS.md) | 🟡 clu brief + manual | ✅ bd setup claude/codex/cursor/… |
| Import from other trackers | ✅ pipe into clu batch | 🟡 JSONL import |
| Install via brew / npm / pypi | ❌ go install / from clone | ✅ |
| Windows / FreeBSD builds | 🟡 pure-Go, portable but unverified | ✅ |
✅ first-class · 🟡 partial / different shape · ❌ not a goal
What clu drops on purpose
- Dolt, a sync server, and cell-level branching/merge. A single SQLite file
is the whole database; there's no server and no SQL merge engine. clu does
offer an experimental, git-native
clu syncthat pushes issue state to a branch-independent ref and reconciles across clones with last-writer-wins — but it's a manual push/pull, not Dolt's live, cell-merge distribution. If you need many machines concurrently writing one server-backed tracker with real merge, that's beads' core strength. - The memory system (
remember/prime/ compaction). clu is a tracker, not an agent runtime — memory lives in your agent, not the issue DB. - MCP and the broad integration matrix. clu is a plain CLI with clean
--json; anything can drive it, but there's no MCP server or per-tool installer beyondclu brief.
What clu adds
A bundled web UI; clu batch for validated,
atomic, thousand-issue graph instantiation; static and
dynamic workflows; human-approval checkpoints and
auto-closing milestones; capability routing, heartbeat/liveness, an
agent launcher, named locks, worktree bootstrap, and cron — a
deeper coordination toolkit for many agents on one machine.
When to use which
Reach for beads if you need live, server-backed sync with cell-level merge
across many concurrent writers, an agent-memory layer, MCP and one-command setup
for many agent tools, or first-class Windows/FreeBSD and brew/npm/pypi installs.
(clu can sync issue state across clones via the experimental
clu sync git ref, but it's manual push/pull, not a live server.)
Reach for clu if you want a single local file with no network, no account, and no CGo; a built-in web UI; validated bulk-graph imports and workflow approval gates; and a tool-agnostic CLI you can point any agent at.
clu is a local-first reimagining of beads, not a drop-in replacement — IDs, storage, and several commands differ. This page reflects beads as of its current README; both projects move quickly, so check beads' own docs for specifics.