Run coding agents in parallel.
Never into each other.
Every agent gets its own git worktree, terminal and branch. Nothing shared, nothing overwritten. Read the diffs, leave notes on the lines that worry you, and merge the ones that got it right.
Forever free macOS 26 and later Claude Code · Codex
Writing code stopped being the slow part.
The bottleneck moved. It is no longer how fast an agent can write a change, it is how fast you can read what several of them wrote. Bloom is built around the reading: every workspace on the left, the work in the middle, the diff one keystroke away.
Every agent gets its own copy of the repository.
Bloom makes a git worktree for each workspace. Same repository, same history, a separate directory on a separate branch. An agent refactoring the parser cannot save over another agent's half finished migration, because the two of them are not looking at the same files.
Your own checkout is never touched. Close a workspace and it goes away, and the branch you had open this morning is exactly where you left it.
This does not repeal git. If two branches really do change the same lines, that is a merge conflict, and it turns up at merge time where you can read it properly. What isolation buys you is that merge time is the only moment it can happen.
- One worktree, one branch, one agent
- No second clone, no history to re-download
- A normal directory on your disk, openable in anything
A terminal that already knows your setup.
Bloom reads your Ghostty configuration: theme, font, ANSI palette. The terminal inside Bloom looks like the terminal outside it, because it is reading the same file you already tuned.
Split it into panes the way you would in iTerm or Ghostty. Hand a session to tmux and it keeps running after you quit Bloom, and it is still there when you come back.
- Your Ghostty theme, font and ANSI colours
- Split panes, horizontally and vertically
- tmux sessions outlive the app
theme = catppuccin-mocha font-family = "JetBrains Mono" font-size = 13 font-thicken = true cursor-style = block window-padding-x = 10
Read the diff before you trust it.
A real review surface, not a wall of green and red. Side by side or unified, whichever you think in. A directory tree of everything that changed, so you can see the shape of the work before you read a line of it.
Comment on a line and the comment becomes context for the agent. The next turn starts from what you actually said, in the place you said it.
- Side by side and unified
- Changed files as a directory tree
- Inline comments feed straight back to the agent
- Editable source that refuses to save over a file the agent has moved on from
- 26 type FactorTable = ReadonlyMap<string, number>
- 27
- 28 const nodeFactorCache = new LruCache<number, FactorTable>(8)
- 29
- - export function nodeFactors(year: number): Map<string, number> {
- 30 + export function nodeFactors(year: number): FactorTable {
- 31 + const cached = nodeFactorCache.get(year)
- 32 +
- 33 + if (cached) {
- 34 + return cached
- 35 + }
Freek commented on line 31
This is once per year, but heightAt calls it once per sample. Resolve the
station's harmonics in series/extrema instead and the cache stops mattering
on the hot path.
Sent to Claude Code with the next message
Open the pull request from here.
When the work is right, ask the agent to open the pull request. The prompt is editable first, so the description reads the way you would have written it rather than the way a model assumes you write.
Bloom reads the check runs as they come back. Merging takes one more confirmation, on purpose.
- The agent writes it, you edit the prompt
- Check runs in the window, not in a tab
- Merge behind a confirmation
Open the pull request against main. Title it for the caching change, not the test churn, and say that nodeFactors now returns a ReadonlyMap while every caller stayed the same.
feat/constituent-cache → main
- test / vitest passed 1m 12s
- lint / biome passed 18s
- types / tsc failed 39s
- build / node 24 running 22s
Arrange the window the way you think.
A pane holds a chat, a terminal or a browser. Put them wherever the task wants them. Chat next to a terminal while something builds. Browser next to the diff while you check the thing you just changed.
It is one window with a layout, not four apps you keep alt-tabbing between.
It behaves like a Mac app, because it is one.
The small things you get for free on this platform, and never get from a web app wearing a window frame.
Dock badge
How many agents have finished and are still waiting on you, readable from any other app.
Services menu
Send a selection from anywhere on the system straight into a workspace.
Notifications
A turn finishes, fails or gets stuck, and you hear about it. Type your reply into the banner and carry on with what you were doing.
Quick Look
Space bar previews for changed files, exactly the way Finder does it.
Drag out
Pull a file out of Bloom and drop it in Finder, or anywhere else that takes files.
Bring the agent you already use.
Bloom runs the agent CLI you already have installed, signed in with the account you already have. It does not sit between you and your model. Today that means Claude Code and Codex. Two more are on the way, and we would rather list them as unfinished than let you find out after you have downloaded it.
Claude Code
Anthropic
Codex
OpenAI
Cursor Agent
Cursor
Not yet
OpenCode
Open source
Not yet
We built it because we needed it.
Bloom is made at Spatie, a web development company in Antwerp, Belgium. Two of us write it: Freek Van der Herten, who co-founded the place, and his colleague Alex Vanderbist.
I run several coding agents at the same time, so most of my day goes into reading what they wrote instead of writing it myself. I wanted a tool built around that part.
I want every agent in its own worktree so they can't save over each other. I want a terminal in the same window, and I want to read the diff before anything gets merged. Alex and I use it all day while we build it, which is how we find most of what's wrong with it.
It's free. We've spent a long time giving software away, most of it to people who never send anything back, and it has worked out fine. We'd rather you used this than not.
A few things worth knowing up front.
What is a git worktree, and why should I care?
A worktree is a second working directory for the same repository, checked out to a different branch. Git has shipped them since 2015. They cost you a directory, not a clone: same history, same objects, nothing re-downloaded.
Bloom makes one per workspace. That is the whole reason two agents can work at the same time without corrupting each other's changes. They are not sharing files.
What happens when two agents change the same thing?
While they are working, nothing. They are in different directories on different branches, so neither can see or overwrite the other's edits.
If the two changes really do disagree, that shows up as a merge conflict, at merge time, where git has always put it and where you can read it properly. Bloom's job is to make sure that is the only place it can happen.
Claude Code already makes worktrees. Why use this?
Because you probably do not use only one agent. Bloom runs Claude Code and Codex in the same window, against the same repository, and gives both of them the same review surface: one diff viewer, one comment system, one way to open a pull request.
If you have settled on a single agent and you are happy reviewing its work in its own app, you may not need Bloom at all. That is a fine outcome and we would rather say so here than find out after you have downloaded it.
Does running several agents cost more?
Yes, and nobody in this category likes saying it. Three agents working at once burn roughly three times the tokens of one agent working alone. Bloom does not change that, and it does not resell you anything: you are billed by whoever you already have a subscription or an API key with.
Which is the real argument against starting twenty of them. Start the number you can genuinely read the output of.
Which agents does it run?
Claude Code and Codex, whichever of them you already have set up, with your existing account.
Cursor Agent and OpenCode are in the app but marked as not available yet. We have not verified how they store their credentials, and we are not going to guess at it and hand you a workspace that cannot sign in.
Is it really free?
Yes. Bloom is free to download and free to use. Spatie makes its money elsewhere, and this is a tool we needed for ourselves.
Is it open source?
No. Free, but not open. If you want the open source part of what we do, there is a great deal of it.
What about node_modules, .env files and dev servers?
A worktree is a fresh directory, so anything git ignores does not come along with it. Dependencies, local environment files and build caches have to exist in each workspace, the same as on any new checkout. Worth knowing before you start five of them.
Do my sessions die when I quit?
Terminal sessions handed to tmux keep running after you quit Bloom, and they are still there when you open it again.
Do I have to review everything in Bloom?
No. Every workspace is a normal git worktree on your disk, on a normal branch. Open it in your editor, run your own tooling against it, push it, do whatever you would have done anyway. Bloom is not a format you get locked into.
