Claude Code: Now in Beta in Zed
203 comments
·September 3, 2025unshavedyak
diegs
I agree, I've fantasized about an editor with a truly pluggable editing model which is decoupled from the other parts.
Yi was kind of designed like this, I believe. You could compile in an emacs-like model, a vim-like model, or presumably make your own model.
I've used Helix and Kakoune in addition to Emacs and Vim, but dealing with the limitations/featureset/plugin treadmill gets a little tiring.
I have been following Zed, and it seems that they have rearchitected things to enable adding Helix mode and making the editing model a bit more modular, but it's still fairly new. They are fixing bugs pretty quickly. I will have to try it again.
They have a nice discussion here:
https://github.com/zed-industries/zed/discussions/6447
They reference Ki, which also looks cool, and they out some of Helix's inconsistencies in their comparison: https://ki-editor.github.io/ki-editor/docs/comparisons/
I prefered Kakoune to Helix (it was more consistent). But to your point, being able to swap these things out more easily would let you choose an editor based on features, and not tradeoff between features and an ergonomic editing model.
Ironically you can use Ki inside of VSCode (and I know you can use Vim that way too), but VSCode is so darn bloated and slow...
Karrot_Kream
Helix seems to have good LSP support from what I can tell? The only language I use at $WORK that doesn't have full support is GraphQL which lacks auto indent.
If you want to try something similar to Helix in emacs, there's meow-mode.
yes_but_no
If you are already familiar with Vim bindings is Helix's object then action really worth that much?
ppeetteerr
I love Zed and I'm glad you now have native support for Claude. I previously ran it using the instructions in this post: https://benswift.me/blog/2025/07/23/running-claude-code-with...
One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
hajile
I was somewhat surprised to find that Zed still doesn't have a way to add your own local autocomplete AI using something like Ollama. Something like Qwen 2.5 coder at a tiny 1.5b parameters will work just fine for the stuff that I want. It runs fast and works when I'm between internet connections too.
I'd also like to see a company like Zed allow me to buy a license of their autocomplete AI model to run locally rather than renting and running it on their servers.
I'd also pay for something in the 10-15b parameter range that used more limited training data focused almost entirely on programming documentation and books along with professional business writing. Something with the coding knowledge of Qwen Coder combined with the professionalism and predictability of IBM Granite 3. I'd pay quite a lot for such an agent (especially if it got updates every couple of months that worked in new documentation, bugfixes, github threads, etc to keep the answers up-to-date).
scottcorgan
I'll third this. AI autocomplete is THE most efficient and helpful feature of Cursor, not the agents.
cnqso
What Zed lacks in code generation quality it makes up for in not-being-an-Electron-app
shreddit
Does it really? At the end of the day i need it to do my job. Ideal values don’t help me doing my job. So i choose the editor best suited and the features i need. And that’s not zed at the moment.
mikepurvis
There's an analogue here with programming language iteration— Python, Ruby and friends showed what the semantics were that were needed, and then a decade or two later, Go and Rust took those semantics and put them in compiled, performance-oriented languages.
Electron has been a powerful tool for quickly iterating UIs and plugin architectures in VSCode, Brackets, Atom, etc, now the window is open for a modern editor to deliver that experience without the massive memory footprint and UI stalls.
metadaemon
I'd also like to second this and probably will in every Zed post. This is the primary reason I'm not ready to switch to Zed just yet.
skhameneh
I like Zed in concept. I like Zed in the architectural and foundational aspects. I want more tools like Zed to exist.
But, I find Zed challenging to adopt due to random nuances. First, settings management is a mixed bag and sometimes I just want a quick way to open the "settings.json" from the settings pane without fussing around. Then I'd like the "settings.json" to stay open (reopen) on a restart of Zed. Then I'd like the ability to use an LLM that doesn't have native tool calling support, which Zed seems to be the only app I've used that doesn't have a workaround. Then I'd like the UI to be a little easier to navigate as a new user, it feels a bit scattered and overwhelming at times.
I haven't used Zed much and I may give it another shot (soon), but it very much feels like a tool built by engineers for engineers... Which is great for power users, but seems not so great for new adopters.
I don't think the shortcomings are a blocker, but they are the reason I haven't adopted Zed. The shortcomings are just enough for me to take a step back and say "maybe I'll try again later".
gm678
For what it's worth, I think Zed now has a default keybind to open settings.json: Ctrl+,
I assume that keybind is also configurable?
skhameneh
Good to know, thanks!
honeycrispy
The nuance situation is rapidly improving. I had several minor issues with Zed ~6 months ago, and most of them have been patched away.
bbor
I spent a while trying to set it up, as I share your general take on their ethos. Personally, I'm okay with a 'power user'-focused text editor, even! But the relative lack of syntax highlighting options got me to give up. Maybe I'm just spoiled from SublimeText's dope, complex, extensible system for specifying "contexts" in themes, but Zed was just nowhere near enough for me.
The keybinding system is also nuts if you turn on Vim mode, but I think I'd eventually get used to that. But functions need to be a different color than arguments, which need to be a different color than local variables... Just non-negotiable.
I look forward to trying it again sometime soon! The AI features seem rad, this included.
btown
As a VS Code + Claude Code user, I'm really excited to see progress here, because the official near-zero-config Claude Code IDE integration is... inflexible, at best.
What if I want to send a subset of my open editor panes to Claude Code? What if I want Claude Code to open diffs for its edited files in a specific area/window, and silently open that file so that I can multitask on other things without it taking focus when it's done thinking? What if I want keyboard shortcuts for specific slash commands, or to trigger a slash command from another task?
Having a robust open-source ecosystem that will let users fork and build customizable UI around coding agent experiences will make them even better, and the space will move even more quickly because the ecosystem won't split between different preferences for agent/model choice. It's an incredible time to be coding.
srid
Note: if you use SSH-based remote development, this doesn't work.
cedws
That's unfortunate. I use Zed and I'm moving towards containerising my dev environment (using SSH remote dev to connect Zed to the container) because all this agentic stuff seems like a security nightmare. At the very least I want to restrict the blast radius to my repos dir.
pimeys
I would give them a week or less to support this. They've been improving the debugger so fast, it will take them no time to support remote claude code connections.
achairapart
Any reason for this? Is it something temporary or it will never be supported?
atonse
My main issue with claude code is running multiple ones in parallel. I don't want to manually do all the git worktree stuff, I just want claude to handle it for me.
So if Zed automatically handles that (where there's a worktree per thread) I can see the appeal. Apart from that, I'm already using Tower to view the changes so I'm not really sure what the value here is.
I tried installing it, and got an error "can't load supported slash commands" – not sure what that means.
nosefurhairdo
I suspect Zed will aim to tackle this issue via DeltaDB:
https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...
camwest
Same, logged an issue: https://github.com/zed-industries/claude-code-acp/issues/18
ZachSaucier
Ona makes this easy: https://ona.com/
giancarlostoro
Zed is my favorite editor in a long time, and thats without diving into its AI support.
jryio
What most of these comments are missing is the attempt at standardization and unification.
There are a lot of comments that people need X feature in order to switch to Y editor. While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.
It appears that our industry is moving towards adoption, sometimes mandatory, of AI coding agents. Regardless of your feelings on the topic, having good tooling to support this effort comes down to: switching costs, compatibility with existing editors, and a strong ecosystem of third party extensions.
While Cursor/Windsurf jumped the gun on bespoke editor integrations with LLMs - the adoption of MCP and other SDKs for coding agents means it's plug and play. The full feature set will be in every editor connected to every agent.
I think Zed wins on having the lowest switching costs for most developers. Paying down generic solutions like Agent Client Protocol (AC) now is a good strategy. It took multiple parties coming together for us to get TLS, OAuth 2.0, and ECMAScript.
I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).
extr
Zed is so great, I do wish they would focus just a little bit more on bringing the UI just a bit more up to parity with VS Code, I would switch full time.
cpuguy83
Anyone running this on Linux? I find it works fairly poorly there. To be fair, vscode is also not great for me (especially vim mode) on Linux.
neurostimulant
I don't notice any major issue yet, except for that freezing on wayland which seems to be fixed already.
WD-42
Running on Linux here. Working great for me. If you are referring to font rendering, unfortunately the Rust ecosystem for it is still young, so there are improvements to be made.
sirodoht
What do you feel is missing from the UI?
sapiogram
Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992
freehorse
While I do not doubt that there are people who experience this on some monitor/OS combinations, I have used zed on basic 1080p and 1440p 24" monitors with no issue. Sometimes I have general issues with some monitors in macos, which is usually due to some super-resolution/sharpness setting on the monitor itself that I need to adjust, but nothing specific to zed. All I say is that these issues are far from universal with non-hidpi monitors.
stouset
While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.
delta_p_delta_x
My guess: their shaders or text rendering don't account for sub-pixel anti-aliasing, which is critical to getting decent text rendering on low pixel density displays.
If they'd used Skia (which is what Electron and Chromium use), they would've got this for free. Instead they tried to reinvent the world and didn't realise how big the world was.
jsheard
That figures, their lead platform was the Mac where HiDPI is totally ubiquitous, so their renderer probably has no provisions for subpixel font rendering.
EnPissant
I won't use zed for this very reason.
kenhwang
Top of my head switching between IntelliJ and Zed:
- Git UI is extremely barebones with no support for other VCS
- No merge tool or side-by-side diffs
- Configuration is all JSON
- Would be nice having a full file tree for the search editor instead of just the list; having the functionality split between a tab and the outline panel is quite clunky.
- Ability to move panels (files/git/console/debugger/etc) into standalone windows or other configurations (multiple docks per side, multiple copies of the same panel linked to a specific tab).
Zed is basically a slightly more featured text editor, so it does a good job when I just want to open something quickly and do small edits. So it's really replacing Sublime Text.
But I find myself hopping out to other tools when I'm using Zed which wasn't really common with IntelliJ. So I still want to use a proper IDE for proper development work.
seanssel
The IntelliJ 3-way mergetool/diff viewer is best in class. I haven't found anything else that touches it.
modernerd
> Configuration is all JSON
Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
> Ability to move panels (files/git/console/debugger/etc) into standalone windows
Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
WA
No side-by-side diff is a deal-breaker for me unfortunately.
extr
People are bringing up a lot of sophisticated stuff. Honestly for me it would just be a more flexible panel system that lets me see eg: File Explorer, Git UI, AI mode, etc, all at the same time.
valentinnnnn
I can’t really pin down the reason but somehow vscode just feels a bit more „balanced“ to me - the font sizes, little borders, icons and details, it’s more consistent.
insane_dreamer
Git: IntelliJ is miles ahead. And we’re talking about essential features like three-may merge panel, diffing 2 files, diffing same file between branches, diffing folders, etc
Tests:. Zed is bare bones compared to IntelliJ (rerun failed tests, export list of failures, go to failed lines easily etc
The AI stuff is cool but it won’t get me to switch from PyCharm.
tmdh
I feel like the UI is not as smooth as VSCode. There is a slight lag when scrolling.
rtaylorgarlock
Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance. Zed is one of the fastest programs i use. I used to laugh when seeing them market fps and such, but yeesh it's fast
macawfish
This could be an issue with GPU drivers. I experienced some incompatibility with GPU kernel drivers that allowed Zed to crash the whole window manager during text selection.
mlnj
Smoothness and frames per second is the core of why they were building a very optimized editor. Not sure if it is just your machine that it is not leveraging the right bits.
For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.
Longhanks
Wait what? Isn't a super fast UI one of their main selling points, what led them to write their own rendering in Rust?
...and now they lose to a web app?
pseufaux
Merge tool is the big one for me
TheRoque
What's so great about zed ?
cyanf
Snappiness is the primary reason for using Zed.
digitaltrees
It’s built by the team that built atom which was way better than vscode but was mothballed when Microsoft bought GitHub.
They built it from scratch and not on electron bloat so it is a much better foundation. It will take a long time to reach parity with vscode but when it does it will smoke it.
veber-alex
So...nothing.
simonw
It uses a fraction of the memory of VS Code and is much faster to launch.
veber-alex
VScode starts very quickly for an electron app. MS did a great job there.
Memory usage of the IDE doesn't matter much when your language servers can eat 10s of gigs of RAM.
johnisgood
Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow. Emacs starts up faster than an empty Zed window, unfortunately. It is still way faster than IntelliJ but comparing it to that is a low bar.
VSCodium starts up faster for me than Zed which I compiled yesterday with release mode. Here I am referring to the time spent just on waiting for the window to start up, not the extensions and all that I am using with VSCodium, that takes time. I wonder why this is, that VSCodium shows the window quicker than Zed.
Regardless, I will give Zed a try with Go development. I assume Zed has extensions, too? Are there any extensions for Go? If so, I might replace VSCodium with Zed but only if it has similar features to VSCodium. If not, I will stick to VSCodium as there is no reason for me to change.
trashface
Do people really need that with modern computers? My computer is 10 years old and I just restarted VS in the last project I was working on. It was about 4-5 seconds before I could edit the text, which doesn't seem long. And I have 17GB available memory. Anyway it doesn't matter because I just don't restart VSCode that much. I do open projects in new windows and those can get slow, but the slow ones are mostly just rust code with rust-analyzer overhead, and when dealing with rust, slow-opening projects are only the beginning.
I don't know, it feels like Zed popularity is just people chasing the latest editor hotness, a time-honored traditional programmer ritual to be sure, but still, just a ritual. And now it seems zed devs have to put AI in front of all other initiatives, probably because of the VC funding they took.
I could see not wanting to use VSCode for other reasons, like MS pivoting back to "be evil", but at least in my little bubble, performance is not one of them.
neurostimulant
It's great that Zed adding this very useful feature, but isn't this effectively cannibalize their own AI subscription plans? Why pay zed $20 when you already pay for claude code and can use it in the assistant panel? You might still want the edit prediction feature, but then why pay zed $20 when you can pay $10 github copilot and can use it to power zed's edit prediction feature?
ZpJuUuNaQ5
I am sure Zed is great and I appreciate the effort put in to create it, but nowadays I just cannot imagine switching from VSCode to something else. In my limited understanding, none of the existing alternatives offer anything (and often misses at least something) truly innovative or anything else that VSCode extension wouldn't solve. On VSCode I have about 15 different profiles setup, each with different settings and dozens of extensions based on either a technology stack or a project - it would be really difficult to find a good reason to throw it all away. The idea of switching between IDEs does not appeal to me either. I do use Neovim a little bit too, but most of that usage time was spent on configuration.
pimeys
It's really interesting point of view. I'm one of those people who avoid using VSCode at any cost. It's slow, it's bloated, the UI is not great, and it's slowly being locked down by Microsoft.
If Zed would not exist, I would be using helix, neovim, or emacs as I did before.
IshKebab
VSCode is actually not slow. The problem is to make it useful you need to add quite a few extensions, and those can be slow. That itself wouldn't be too bad but VSCode doesn't expose any information about what is causing the slowness. You end up with "VSCode is slow and it could be due to any one of the dozen extensions I have installed", which effectively means that VSCode is slow.
It remains to be seen if Zed can avoid that though.
WD-42
VSCode (and all Electron based editors) have undeniable input latency. Zed is built by the same team that developed Atom and Electron and one of their stated goals is to make up for the shortcomings of these technologies.
If you don't feel that VSCode is slow, it's because you are used to it.
manuhabitela
vscode is noticeably slow compared to sublime text or zed, even without any extension. You instantly notice it when switching files or typing things that trigger auto-completions.
In the end the feeling is drastically different. It weirdly makes for a more peaceful experience to have such a snappy editor.
vscode wins thanks to all its extensions, where basically every language is supported and most features you can think of are there. But it's kinda like modern react. You know better alternatives exist, like solid or svelte, but the community is so big, it stays the easier choice in the end.
hu3
Interestingly I disagree with all your points about VSCode.
It's fast, barebones by default, UI is minimal and it's Open Source enough that competitors forked from it.
I guess YMMV because there is a comment in this post from another user about Zed being sluggish.
pimeys
I tried VSCode many times in my life and just hated the experience so much. It put me away from GUI editors for years, didn't want to try any of them. So ugly and so sluggish.
Zed was the first one that put me to rethink my position. It is so snappy on my Linux workstation and I don't have any issues with it's GUI. I finally switched from vim et.al.
But I know I have "weird" opinions, I also really dislike Apple products and their software.
timeon
Even not counting the LSP, for a text editor, it eats quite large amount of RAM.
kace91
It’s not at all slow when compared to IntelliJ products or similar. It doesn’t compete with editors, it competes with IDEs.
mikeocool
Zed's main selling point over VSCode for me is the lack of a slight delay between when I press a key and when the character appears.
VSCode has always felt ever so slightly sluggish to me, and I find it maddening as I type.
veber-alex
Strange.
I just opened the same project in Cursor and Zed and started typing around, and I can't tell any difference. I am usually very sensitive to this stuff; for example, I can detect when my Mac drops below 20% battery because ProMotion is disabled and the screen refresh rate drops to 60Hz.
pmg101
So glad to hear I'm not alone! I continue to use SublimeText for this reason. Yet it doesn't seem to bother others.
pkorzeniewski
Same here, still using Sublime Text due to its general snappiness, but can't wait for Zed to be released on Windows, it feels like a modern successor to ST that just keeps getting better.
WD-42
I think a lot of people forget how long ago Electron/Atom were released, and the subsequent Cambrian explosion of Electron based apps and editors like VSCode. There's probably a huge amount of developers that haven't used anything else.
jkkola
This is why I cannot switch to neovim despite my attempts. I love the workflow, but the delay is too noticeable for me, and nothing helps. It's not a long delay, but long enough for me to feel like I have to wait for hours compared to Zed.
diabllicseagull
vscode started to intermittently freeze my whole desktop on arch linux recently. I rage deleted it. imho, it’s a valid compromise to choose a snappy lightweight editor over vscode with all available extensions.
sadly it reminds me of how visual studio used to be and and how much of a sluggish mess it is today. I don’t think the community can fix it either. it’s an uphill battle when MS is known to lose care as soon as they reach a critical mass of users.
zorked
VS Code is sluggish for me as well and crashes. I have minimal expansions, this is just a poor excuse for a lousy editor. Zed is much better, neovim is much better. My only real concern with Zed is what bait-and-switch is awaiting for us when they decide to make money. But it's a fantastic editor, no question about that.
Karrot_Kream
I wanted to like VSCode but it has enough input latency on my machines that it's not that enjoyable when I'm "locked in". Also if I'm running a bunch of services in Docker on MacOS (which means they're running VMs sigh) the overhead of VSCode is just too much and the system starts swapping constantly grinding the whole thing to a halt. I also find configuring it a pain. Every configuration pane feels ad-hoc and not part of a holistic, configurable system. Emacs has lots of crusty bits and an annoying event loop that you have to really work around but is designed a lot more holistically than VSCode.
Zed to me feels like a great batteries-included editor and I still run it as my non-emacs alternate editor. I wish its configuration was a bit more discoverable (especially with configuring linters/formatters), but it's 95% of what I need 95% of the time.
LocalPCGuy
There is always a "better mousetrap", and there are those that continue to use the old one because they "know how it works and it's set up just the way I like it". And there are others that try every new mousetrap that hits the market. (and that's ok, not slighting either one)
I will say that I personally have never really gelled with VSCode no matter how much I try to customize it, it still is just a bit off. For me, it's like it's too much to be a simple editor like SublimeText or NeoVim, but not quite enough to be an IDE like IntelliJ or Visual Studio (full). It does just enough that I expect a bit more of it and it often fails to deliver. Right now I tend to just use 2 editors - one very simple one for viewing/editing text files and one IDE (currently IntelliJ) for coding in a project.
On topic - Zed is actually a really nice editor. It had some rough edges last time I tried it, but it's probably about time to give it another go.
jryio
Zed succeeds at reducing the switching cost. I used NeoVim for ten years daily and configured it way back in college days.
I thought I would be unable to move to a GUI editor and it turns out that the speed and efficiency of Zed plus the almost one-to-one mapping of Vim features means that I am extremely productive in Zed.
kiney
I had to use VSCode for some projects in the past because it was what was available on the clients workstations... I can't imagine having to use that laggy electron abomination all the time. For me Zed is sent from heaven, because my previously preferred editor (geany) hast basically zero developtment nowadays.
meowface
I normally care a ton about latency and in the main project I work on I put extreme focus on reducing input latency in text input fields, but...
I've used VS Code for ages. I tried Zed. I don't really feel a difference. It's smoother but VS Code is more than smooth enough for me and has tons of features I rely on that don't exist in dev.
Meanwhile, when I tried Ghostty I noticed a significant improvement in "typefeel" compared to iTerm. So I'm not immune to detecting such a difference.
I will try Zed again though.
42lux
>>I don't really feel a difference.
>>It's smoother but...
monstrado
I think the point of ACP being an open protocol is so that other editors (e.g. VSCode, Neovim) can implement it as a receiver and integration with ClaudeCode/GeminiCLI/... would just work.
kombine
I switched to Neovim a year ago, and while I did spend a significant amount of time on configuring it, I haven't touched my config for months now - and I'm perfectly happy with it. There's things I can improve, but it does what I want.
californical
I’m in the same boat. I spent a lot of nights for a couple weeks getting everything tuned just right, in the beginning. But now, several years later, it really doesn’t take much. I spend maybe 2-3 hours once every few months, and that’s usually just adding a bunch of features that sound nice to make my life better. I’ve easily gone 6+ months without touching neovim config, if not longer, because it’s unnecessary. It only matters if you want to further improve your editor
dang
Recent and related:
Agent Client Protocol (ACP) - https://news.ycombinator.com/item?id=45074147 - Aug 2025 (93 comments)
I want to try Zed but the Helix mode seems quite young. Vim mode sounds good, but i just can't move away from Helix mode. (oh and of course, my own modifications to Helix's input config)
My difficulty in finding editors that fit my desired input scheme kinda reminds me of the old pre-LSP days. Where you'd chose an editor based on it's language features. I wonder if we need some sort of common editor interface to allow these sort of text editing primitives to work in new editors, as it seems to be considerable friction.