sermakarevich

AMD submitted a bug on the Claude Code repo where they complained about coding quality and described that they are running a fleet of 50+ Claude Code sessions using beads — https://github.com/anthropics/claude-code/issues/42796. This was pretty exciting; I was curious how it could be done. It turned out to be simpler than it looks.

First I created a simple multi-session implementation using beads and a bit of bash only — https://news.ycombinator.com/item?id=48204719. A bash loop monitors the beads queue, claims a task, and passes it into claude -p.

This worked fine, and I decided to make the implementation more capable, so I created fleet — a Python supervisor for running coding agents in parallel: https://github.com/sermakarevich/fleet.

A few core ideas:

- The beads DB is centralized — it lives in ~/.fleet. No need to init it in every project where you want to run agents. fleet bd create records the cwd where the task was created, and the agent is spawned in that same location. beads is a git-backed issue tracker that gives agents a shared queue of tasks with dependencies, statuses, and priorities — so multiple sessions can claim, work on, and hand off tasks without stepping on each other.

- fleet supports 3 coders: claude, agy (Antigravity), and codex, and adding a new one is a matter of minutes. I tested claude extensively, agy briefly, and I don't have a subscription for codex — so it's implemented but not tested yet.

- fleet can spawn as many coding agents as you like. fleet config set max_concurrent=10 and keep adding tasks with fleet bd create --title "..." --description "...", or with a specific coder/model per task: fleet bd create --coder agy --model opus --title "..." --description "...". When I started, 3 parallel coding sessions were enough for me; now I can manage 10+. The reason for max_concurrent=3 default is to not hit session limits.

- fleet has few useful cli command to help with navigation:

-- fleet tasks - display tasks in progress, what coder is used, what context consumption is

-- fleet task <task-id> log | plan | knowledge

-- fleet config show | set

This works nicely for me. fleet also pairs well with a spec-driven approach: https://news.ycombinator.com/item?id=48231575. Tokens are the bottleneck now — I have a few Claude subscriptions and rotate between them when one is exhausted. I also cleaned up all my plugins, skills, and CLAUDE.md files to stop polluting the context — I found that some plugins were installed multiple times and loading the same skills twice, doubling their token cost.

Spec Driven Development approach allows to squeeze more from coding agents thanks to few strong concepts: - decomposition across two dimensions. first you generate specs in multiple steps (requirements, code analysis, design), than you split task into multiple subtasks and implement them one by one - you clear context between every step - after spec generation and after subtask implementation. this helps keep cost low and context clear and focused which boost performance - specs written to disk help with information persistency - delivering specs layer by layer help to catch early when agent got you wrong

Repo with claude plugin for spec driven development: https://github.com/sermakarevich/sddw

I was intrigued by an AMD issue on GitHub where Stella Laurenzo shared how the AMD team runs a fleet of 50 or so agents: https://lnkd.in/drueskiV. I wanted to get there myself, and I think I managed to. I can now run a fleet of coding agents while I'm away, burning through every token across my three Claude subscriptions. I can run data science experiments overnight in loops: analyze misclassifications, form a hypothesis, implement, run, analyze again. Agents pull tasks from a queue, add new tasks back to it, organize dependencies, and block tasks when they need my input. This article walks through my approach step by step.

https://github.com/sermakarevich/claude/tree/main/usage_patt...

I started with materializing replies as markdown artifacts. Anything that stays in the terminal gets lost and forgotten quickly, so persisting each reply to a file was the first step toward keeping the work durable.

Once the number of artifacts grew, a flat folder stopped being usable. I introduced hierarchical organization — grouping by topic, with a top-level index.md pointing to per-topic index.md files, each of which holds a short summary and links to individual artifacts. Nesting depth is unbounded; you add a level whenever a topic earns one.

The next realization was that tasks belong in a queue, not to the terminal. I moved to markdown files with todo and done sections. At that point, almost no terminal interaction was left — just /clear after each task and a prompt like "take the next task."

The obvious next step was to automate that loop: a shell loop calling claude -p "take next task", with context cleared automatically at the end of each session. This works fine for a single worker.

Scaling beyond one agent needs a few extra pieces: - A proper queue. This is what beads provides — dependency-aware, atomic claims via bd ready and bd update --claim, so two workers don't grab the same task. - A channel back to the human. Also handled by beads: bd update <id> --status blocked --notes "QUESTION: <one-line question>" parks the task and surfaces the question without halting the rest of the fleet. - Session memory. Because each claude -p invocation starts with a fresh context, the agent has to write down what it has done, what it plans to do, and any related notes — either into beads itself (status, notes, dependencies on the issue) or to disk — so the next session can pick up cleanly after a restart.

With these components in place, we can spawn many claude workers pulling from tasks from beads db, asking questions, adding tasks to db, storing progress and final artifacts to disk. AMD describe this pattern in their amazing issues description https://github.com/anthropics/claude-code/issues/42796. It took me some time to figure out how this suppose to work.