Zed Shipped Parallel Agents — Here's What Running Claude, Codex, and Gemini in One Window Actually Feels Like
Zed Shipped Parallel Agents — Here's What Running Claude, Codex, and Gemini in One Window Actually Feels Like
Zed 0.233.5 shipped yesterday, April 22. The headline feature is parallel agents: multiple AI coding agents running concurrently in the same editor window, each with its own thread, each optionally scoped to its own folder in your repo, all orchestrated through a new Threads Sidebar.
The demos are slick. The announcement framing — "Zed is the first AI code editor with native parallel agent support" — is technically accurate. The implementation leans on the Agent Client Protocol (ACP), which means the agents are genuinely swappable: you can point Zed at Claude Code, Codex, Gemini CLI, a local model, or some combination, all in the same session.
I spent yesterday using this on a real project: the Astro codebase that runs this blog, plus a small Cloudflare Worker I've been bolting onto it. Below is the honest write-up. Not "does it demo well" — does it actually change how a solo operator gets work done.
The short answer: yes, but the killer feature is not what Zed's marketing says it is. And the failure modes are interesting enough to be worth understanding before you pay the switching cost.
What Zed Actually Shipped
The release packages several things together:
Parallel threads. A new Threads Sidebar groups active agent sessions by project. Each thread is a separate agent run, each with its own conversation history. You can see what every agent is working on at a glance.
Folder scoping. Each thread gets explicit control over which folders it can read and write. You can tell Thread A to only touch src/content/, Thread B to only touch worker/, and the two won't step on each other. This is enforced, not advisory.
Agent-agnostic via ACP. The Agent Client Protocol is Zed's open protocol for connecting any coding agent. Today this means Claude Code, Codex CLI, Gemini CLI, local models via llama-server or Ollama, and a growing list of custom agents. You can literally run Claude Code on one thread, Codex on another, and Gemini CLI on a third.
Thread state in the sidebar. The UI shows what each agent is currently doing — planning, editing, running a test, waiting for user input. Switch between threads instantly. Zed's Rust-native rendering stays at 120fps even with ten active threads, which sounds like a marketing bullet but turns out to matter in practice.
Claude Opus 4.7 support. BYOK (bring your own key) support for the newest Anthropic model. Minor quality-of-life item but worth mentioning.
Other release notes. Editor toggle block comment action, scroll-wheel font size zoom, anchor links and footnotes in Markdown Preview. Small stuff that's nice to have.
The Promise vs. The Reality
The pitch is that you can run three agents in parallel and get 3x the work done. I want to address this head-on: that is not really how it works, and it's a less interesting framing than what actually happens.
What actually happens is a mental-model shift. Parallel agents is not "faster" — it's a different shape of work. One agent on boring boilerplate while another does careful surgery, vs. two agents racing to do the same task.
In practice, three patterns emerge.
Pattern 1: Deep vs. shallow split. You have a careful task (a tricky refactor, a debugging session) and a broad task (generate tests, write docs, update a readme). Put the careful task on Claude Code in Thread A with access to src/. Put the broad task on Codex or Gemini in Thread B with access to tests/ or docs/. Work with Thread A at full attention; periodically check in on Thread B, give it new instructions, let it keep going.
This works well. The "broad, boring" agent does not need your full attention, and while it grinds, you are meaningfully advancing the careful work. Over a 3-hour session, I did maybe 1.6x the work I'd do with a single agent. Not 3x. But 1.6x is a real number.
Pattern 2: Different-model same-task. You have a single task that you want two models to attempt independently, then diff the results. Claude on Thread A, Codex on Thread B, both given the same task on separate branches. Pick the better output, or merge the useful parts of both.
This is probably where the marketing demos are heading. Honestly, I don't love it. I tried it twice and the overhead of evaluating two outputs was higher than the value of picking the better one. The exception is hard bugs where I genuinely don't trust any single model and want a sanity check — there, a second opinion from a different model is useful. For normal work, "just use the best model" beats "use two and compare."
Pattern 3: Race conditions with humans. You're mid-task on Thread A. You realize you want a small ancillary thing done — bump a dependency, check something in docs. Spin up Thread B for the side task, let it run, keep working on Thread A. Merge the results when Thread B is done.
This is the killer pattern. It's not parallel in the "maximum throughput" sense — it's parallel in the "don't break my flow" sense. I used this about a dozen times yesterday. Every time it saved me a context switch that would have cost five to ten minutes of re-focusing. That compounds.
The Failure Modes
I said at the top that the failure modes are more interesting than the successes. Here they are, ordered by how much trouble they caused me.
Conflicting file edits. The folder-scoping feature is doing real work here, but it doesn't cover every case. If Thread A has src/ scope and Thread B has src/content/ scope, they overlap, and whichever one saves last wins. The first time this bit me yesterday, Thread B had rewritten a TypeScript config that Thread A was halfway through editing. Git diff saved me. I got lucky.
After this I switched to fully disjoint folder scopes and it hasn't happened again. But the lesson is: treat folder scopes like filesystem permissions, not like suggestions. Set them disjoint or don't run parallel agents on the same area.
Context-switching tax is real. "120fps UI" does not eliminate the cognitive cost of switching mental context. When Thread A is deep in a debugger and Thread B pings you for input, you are now thinking about two things. Over a few hours this is exhausting in a way that single-agent work isn't. I ended yesterday more tired than a normal workday, despite (or because of?) having done more work.
The mitigation is to not run too many threads. Two is comfortable. Three is fine if you're careful. Four is aspirational and I haven't managed it usefully yet. The Zed demo shows "hundreds of threads" — that's a benchmark, not a workflow.
Agents don't know about each other. This is the interesting one. Thread A doesn't know that Thread B exists. If Thread A edits a shared utility and Thread B is mid-edit of code that calls it, Thread B proceeds with stale assumptions. Zed does nothing about this. You have to orchestrate it yourself.
In practice this means parallel agents work best on truly independent subtrees — frontend and backend, code and docs, source and tests. It breaks down the moment there's a shared file or a shared type definition. For a codebase with clean separations, this is fine. For a messy codebase with tangled dependencies, parallelism is more trouble than it's worth.
Tooling support is uneven. Claude Code in a Zed thread works great — the integration is tight, the file patches show inline, tool calls render nicely. Codex in a thread also works. Gemini CLI in a thread works but the output rendering is rougher around the edges. Local models via Ollama through ACP: works, but there's a noticeable latency hitch on tool calls. Expect a few months of polish before all agent integrations are equally smooth.
The price of parallelism is API bills. Three simultaneous agent threads = three simultaneous API bills. If you're running Opus 4.7 on two threads for six hours, your monthly bill just went up. Zed doesn't show you cost in the sidebar yet — I'd like it to. Until it does, "how expensive was that parallel session" is a number you find out the next day in your billing dashboard.
Where This Fits in an Actual Workflow
After a day of use, here's where I land. Parallel agents in Zed is worth it if:
- You work on codebases with clean separation between subsystems (e.g. this blog: content/, components/, worker/ barely talk to each other)
- You have a mix of "requires attention" and "can grind in the background" work on the same day
- You're comfortable with occasional git-diff surgery when agents conflict
- You're happy switching to Zed from your current editor, or you already use Zed
It's probably not worth it if:
- Your codebase is highly coupled and every file depends on every other file
- You're already maxed out on attention running a single agent (most people I know)
- You only use one provider's agent (in which case Claude Code solo or Codex solo is fine)
- Your current editor is Cursor and you've invested years in your setup
The honest take on Zed vs. Cursor specifically: Zed feels faster, the parallel story is genuinely unique, and the editor is delightful. But the onboarding cost is real, the plugin ecosystem is thinner, and a lot of my muscle memory lives in Cursor. I'm not switching my primary driver. I am going to keep a Zed window open for the parallel-agents pattern-3 workflow (the "race condition with humans" one), which is where it actually earns its keep.
The Agent Client Protocol Angle
The thing underneath all this that gets the least press is ACP — the Agent Client Protocol. Zed defined a protocol for how editors talk to coding agents, and open-sourced it. The demo that ships today is Zed as the host and Claude/Codex/Gemini as guests. The implication two quarters from now is much bigger.
If ACP actually takes off, every editor that implements the protocol can run any agent. That's a big deal for solo operators because it breaks the "your editor is your agent" lock-in that Cursor has relied on for eighteen months. Cursor's competitive moat is partly that their agent feels better than others in their editor; ACP is the bet that agent quality will become independent of editor, and competition will move up a layer.
I'm cautiously optimistic. Open protocols in this space — MCP is the obvious parallel — have had real traction this year. A second protocol that works alongside MCP, specifically for the editor-agent relationship, is the kind of infrastructure solo operators benefit from because it keeps any single vendor from capturing the workflow.
If you're building anything agent-adjacent, ACP is worth reading now. If you're just using editors, it's a thing to watch this year, not something to act on.
The Thirty-Minute Trial
If you want to evaluate this yourself, here's the smallest useful version:
- Install Zed. Open the project you spend the most time in.
- In the agent panel, connect Claude Code (BYOK) and one other agent — Codex or a local model via Ollama.
- Identify one task that has a "careful" and a "boring" component. E.g., a refactor that requires thought, plus tests that can be grind-written.
- Put the careful task on Thread A with access to the code files. Put the boring task on Thread B with access only to the tests folder.
- Work normally on Thread A. Check in on Thread B every 10-15 minutes.
The test is simple: does this feel like you got more done in the session than you would have with a single agent? Or does it feel like you ran two mediocre sessions instead of one good one?
For me, the answer was clearly the former, but only because I picked a task where the "boring" part was genuinely automatable. If I'd tried to parallelize two tasks that both needed my attention, the answer would have been the latter.
The Deeper Frame
The whole parallel-agents pitch depends on the bet that the rate-limiting step for solo-dev coding is no longer "how fast can the model output tokens" — it's "how fast can the human coordinate multiple agents." I think this bet is right. The frontier models are already fast enough that the bottleneck is you. Parallelism only makes sense if you can actually coordinate multiple streams of AI-assisted work without losing the plot.
Most solo operators will find that they can coordinate two streams comfortably, three with effort, and four is too much. The correct advertised version of this feature is "run two agents in parallel, one of them on boring work." That's less exciting than "hundreds of threads at 120fps" but it's the version that holds up in a real workday.
Zed deserves credit for shipping this first and shipping it well. The UX is good. The ACP decision is right. The release feels considered in a way that a lot of agent tooling doesn't. If you've been Zed-curious and the parallel-agent story is what pushes you over — the story holds up. Just don't expect the 10x version. Expect the 1.5x version, which is already a lot.
Monday I'm back in Cursor for the primary driver. Zed is open alongside it, and the "spawn a secondary agent to handle the side task" pattern is now part of how I work. That's a real win for a one-day trial.