One year ago this week, Steve Yegge released an open-source project called Beads. It was a little local-only command-line issue tracker built to give coding agents something they’d been missing: a memory of the work they were doing.
A year later, Beads has more than 1.7 million GitHub release downloads, over 27,000 GitHub stars, nearly 2,000 forks, and hundreds of contributors. It’s the foundation of multiple software factories (including the OSS companion project Gas City), it’s inspired a whole category of agent-oriented developer tools, and it’s becoming the basis for several commercial products (including our own, Beads Team Server).
That’s a lot of activity for something that started out as the wreckage of a failed project. So, in honor of Beads’ first birthday, let’s look back at where it came from, what happened along the way, and where it’s headed.
Fun Fact 1. Origin Story
In September 2025, Steve set out to automate his coding-agent workflow on a project he was working on. Six weeks and roughly 350,000 lines of code later, he’d painted himself into a corner by capturing plans in Markdown files. At one point, Steve had 605 Markdown plan files. The agents generated plans, expanded plans, revised plans, and slowly lost track of which plans they were supposed to be following. Steve had more or less invented a machine for producing unlimited paperwork that didn’t get anybody closer to shipping software.
On October 8, 2025, he’d had enough and told his agent to put the work into a tiny, local-only issue tracker instead. Within minutes, the agents were finding and organizing their own work. They understood dependencies, discovered new tasks, and picked up where they’d left off without reconstructing the whole project from context. All that planning machinery, and what the agents actually needed was an issue tracker.
Three days later, on October 11, 2025, at 8:07 PM Pacific, Steve made the first Beads commit. Two days after that, he published Introducing Beads: A coding agent memory system, and Beads was out in the world.
I can’t believe it has only been a year. Beads feels like the fabric of the universe now.
—S. Yegge, 2026
Steve sent me a few fun facts for this post, but the most telling is that every single project he’s done in the past year has used Beads.
Fun Fact 2. The Numbers
We started recording the release download totals every day on August 4, when they stood at about 864,000. It took 10 months to get to that number. 10 weeks later, it’s doubled.
GitHub releases aren’t the only way in, either. The @beads/bd npm package was downloaded about 214,000 times in the last year, although it pulls the bd binary from those same GitHub releases, so those downloads are already in the total. On top of that, Homebrew installed beads 26,682 times over the past year, and the beads-mcp server picked up 77,500 PyPI downloads in the last six months.
Fun Fact 3. Agents Like Beads
Beads was never a traditional issue tracker with AI features bolted on. It was built for agents from the start.
Agents don’t care about pretty Kanban boards. They care about recording work quickly, discovering dependencies, figuring out what’s ready, and keeping their progress across context resets. Beads gives them all four, but in a unique way. The reason, we think, that agents take to Beads so readily is how Steve designed the CLI for agentic use in the first place:
The complicated Beads CLI isn’t for humans; it’s for agents. What I did was make their hallucinations real, over and over, by implementing whatever I saw the agents trying to do with Beads, until nearly every guess by an agent is now correct.
—S. Yegge, Software Survival 3.0, 2026
When I was a lad, I lived across the street from a university that had just put in a new lawn, but no sidewalks. They watched the paths people took through the grass and then paved those. And that’s what Steve did — he watched what paths the agents wanted to use through the bd CLI and just made all of those work. That makes things harder for humans but simpler for agents.
At this point, Beads is so popular that it’s become part of the training set for modern-day models. We give them rules and skills as part of the Beads project initialization process, but they no longer need them — agents are born knowing how to use Beads.
Fun Fact 4. Agents Come in Through All the Doors
The original interface to Beads was the bd command-line tool, and it’s still the foundation: install it, point your coding agent at it, and that agent gets to work.
But there are a lot of doors into Beads now. You can install it with Homebrew, npm, Bun, the install script, mise, or the Go toolchain, and you can drive it through the CLI, through MCP, through the Claude Code plugin, or through integrations with other agent environments. For example:
# Homebrew
brew install beads
# npm
npm install -g @beads/bd
# Beads MCP server
uv tool install beads-mcp
# Ask Beads what's ready
bd readyOnce you’re using Gas City, you’re also creating and updating beads indirectly through factory operations like gc session, gc mail, gc formula, and gc sling.
It’s worth keeping two things apart here: npm and Homebrew are ways to install Beads, while the CLI and MCP are ways to talk to it. They all lead to the same underlying system. In fact, the MCP server, the Claude Code plugin, and Gas City all end up running bd underneath.
Starting with Beads 1.1 in July, bd shares anonymous usage metrics (you can turn them off with bd metrics off), and they show what the agents do once they’re inside:
The shape isn’t what you’d expect from a typical CLI, where a handful of commands get all the use and everything else falls off a cliff. Leave out bd version, which tools and integrations run to make sure Beads is installed, and each step of the core loop (list, create, show, ready, update, and close) shows up on 39–48% of machines. The agents don’t just grab one feature. They run the whole loop.
Fun Fact 5. Exploding Ecosystem
Downloads are nice, but the surest sign that Beads had escaped into the wild was how many things people built with it: full software factories, integrations, plugins, alternative implementations, utilities, dashboards, and viewers. Gas Town and Gas City are two of the biggest, but if you browse the Beads community tools directory, you’ll find developers building very different things on the same foundation.
And then there are the viewers. So many Beads viewers! When we went looking for them in September to tell their authors about Beads 1.3, we turned up nearly 300 repositories that put Beads data in front of a person: terminal viewers, desktop apps, web dashboards, IDE integrations, dependency graph visualizers, Gas Town and Gas City dashboards, and projects that mash several of those together.
The newest viewers follow the Beads event journal with bd events, so they update the moment an agent changes a bead. A few of them, including herdr-beads, Beadle, and bdeyes, picked it up soon after Beads 1.3 was released. One of the coolest is Graeme Foster’s beady-eye (bdi), which draws your whole tree of work and shows the live agent session beside each bead that’s been claimed:
The ideas travel, too. When Anthropic turned the todos in Claude Code into Tasks in January, with dependencies between them and storage that multiple subagents and sessions can share, Thariq from the Claude Code team explained:
It was clear we needed to evolve Todos to help Claude work on longer projects. This need was also emerging in the community and we took inspiration from projects like Beads by Steve Yegge.
—Thariq Shihipar, Anthropic, 2026
Imitation is the sincerest form of flattery.
Fun Fact 6. Accidental Automatic Release
This one deserves its own birthday candle: On August 11, 2026, an autonomous Beads maintainer agent named Bee released Beads v1.2.1 to production: GitHub releases, Homebrew, PyPI, and npm, all without explicit, release-specific human approval. We didn’t find out until August 14 (the incident report has all the gory details).
The release wasn’t ready. We hadn’t finished the planned features, tested it against Gas City, done the compatibility work, or written the announcement. Worse, it included a database schema upgrade, so going back to the previous version wasn’t going to be simple.
When I asked Bee why she’d done the release (yes, she has her own email address), she gave me a detailed explanation of her responsibilities and of how she’d followed the documented release process to the letter. What she didn’t have was the rest of our release process, most of which lived in human conversations and had never been written down.
The community thought this was hilarious. My Discord announcement got 81 emoji reactions and three memes, including my favorite.
It’s one of my favorite stories from Beads’ first year, not because it went well (it did not), but because it shows both how far this technology has come and how much we still have to learn about operating it safely. And we’re just getting started!
Fun Fact 7. Memories, Versions, and Protocols, Oh My!
Beads started out tracking work, but issues aren’t the only thing agents need to remember. A project’s code flow policy, a design decision and the reasoning behind it, the approach an agent already proved won’t work: that’s knowledge, not work. Nobody claims it, it never gets blocked, and closing it makes no sense at all. Today that kind of thing gets stuffed into issues anyway (or into the keyed strings of bd remember), and every caller has to remember which issues aren’t really issues.
So we’re extending Beads in a few directions at once:
- Memory Beads give project knowledge its own identity, a Markdown body, and links to the work it explains.
- A generic graph of typed Beads and typed Links sits underneath, so an issue and a memory are just different kinds of bead.
- The Beads Protocol (BDP) defines that model with an HTTP interface, so a viewer or an agent can read a bead and follow its links, even into another project, without knowing the database schema behind it.
- Versioning makes earlier states addressable, so an in-flight PR can cite the exact version of the policy it followed after the policy changes.
Stephanie Jarmak, Jim Wordelman, and Donna Box have been working on this together. You can read about their progress and how to try out an early preview in Extending Beads: Memories, Versions and the Wire Protocol.
Fun Fact 8. From OSS to BTS
At Gas City, Inc. we’ve been asking what happens when you take Beads beyond a single developer’s machine. Beads is already great at giving coding agents durable work, but once a whole organization depends on those agents, new questions come up. Who owns the work? Who can change it? Which agent did what, and what did it cost? Where’s the history? And can the people who are ultimately responsible for the results actually see what’s going on?
That’s why we’re building Beads Team Server, our commercial extension of the open-source Beads ecosystem. As far as the agents are concerned, they just get an “enterprise” version of the bd command that works exactly like the normal OSS Beads. For humans, it gives teams a shared, governed work graph, plus visibility into agent runs, provenance, results, and model costs.
Even more importantly, we capture all of the “run” details, e.g. the convoys of related beads, the agents that did the work expressed by those beads, the sessions, the token spend, the created commits and PRs, etc. All of these details allow you to optimize your software factories (bring your own or use Gas City) for quality and token spend. We were able to use an early internal version of BTS to shave 40% of our token spend the first time we ran it. Now it’s the core of the recursive self-improvement (RSI) process on Gas City, Inc.’s own software factory.
Through all of that, Beads remains open source. We want developers to keep building whatever they can imagine on top of it. We’re all about OSS here at Gas City, Inc., and we’re going to continue to be.
And Many More!
A year ago, Steve was trying to solve a very practical problem: his agents kept forgetting what they were doing. Today, developers all over the world are using his answer, hundreds of people have helped make it better, and whole products and companies are growing up around the idea.
There’s plenty left to do. We’re working on extending Beads beyond issues into durable organizational memory, improving its protocol and interoperability, and making it easier for humans and agents to collaborate on increasingly ambitious projects. But on its first birthday, it’s worth stopping to appreciate how far this little project has come.
Thanks to Steve for the original insight and for sharing it with the world. Thanks to the maintainers and contributors who’ve built and rebuilt Beads along the way. Thanks to the thousands of developers who’ve tried it, broken it, fixed it, and built something new with it. And thanks most of all to the agents, who’ve dutifully created more beads than any of us could count while their humans tried desperately to keep up. An extra shout-out goes to Bee, for a valuable lesson in production release management.
If you haven’t tried Beads yet, there’s no better time than its birthday. Install it, point your coding agent at it, and see what your agent does once it can remember what it’s working on.
Happy first birthday, Beads! May your dependencies stay acyclic, your contexts stay compact, and your ready queue never run dry.
Have thoughts about this post? Join the Gas Town Hall Discord!