Yesterday I built an alternative to beads called pebbles. I love the workflow that beads enables, but the beads program itself has become far too complicated, and has left me feeling like I'm fighting it constantly.
Pebbles is designed to stay simple.
- It has only an essential subset of beads features with a matching API.
- No daemon or background syncing.
- No "doctor" command, because it doesn't need one.
- All state is represented as an append-only event log. SQLite is a dumb cache built from the log.
- Two OOM less code: 7k vs 280k
If you're using beads already, you can try pebbles easily by importing your beads to pebbles: pb import beads --from .
Background
I was an early adopter of beads. The core workflow worked great:
- Come up with a plan through discussion
- Translate that into self-contained issues
- Use issues as context for getting work done
- Capture new requirements, bugs, features, and ideas as issues as they arise
Beads removed the friction of having to figure out where to log work for agents by providing a structured, local, command line interface.
Over time that simple interface grew increasingly complex, and that complexity leaked through to the user experience.
It seemed that with each release there was another state tracking file in the .beads directory. Daemon mode was introduced. Syncing needed to happen on a different branch lest the main branch be polluted with beads commits. The bd doctor --fix command needed to be run constantly to fix issues (it rarely worked, if ever). There was always an untracked issues.jsonl file causing merge conflicts. I found myself constantly fighting with beads when I wanted to be doing real work.
Much of this likely had to do with Steve Yegge's vision for Gas Town. beads kept growing new features — a likely source of the above complexity — and not only did I have no use for them, they made my experience significantly worse.
Checkout the GitHub repository for installation and beads migration instructions!