> Edit prediction won't be free forever, but right now we're just excited to share and learn.
I love Zed, and I'm happy to pay for AI stuff, but I won't be using this until they are done with their rug pull. Once I know how much it costs, I can decide if I want to try integrating it into my workflow. Only THEN will I want to try it, and would be interested in a limited free trial, even just 24 hours.
Considering I've seen products like this range from free to hundreds of dollars per month, I'd rather not find out how good it is and then find out I can't afford it.
Other than that for anyone wanting to try Zed:
- You can only run one LSP per file type, so your Rust will work fine, your C++, too, your Angular will not.
- Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing feature. This means you cannot use your PC as a thin client to the actual chunky big work machine like you can with vscode. I've seen a PR that adds windows ssh support, but it looked very stale.
> - You can only run one LSP per file type, so your Rust will work fine, your C++, too, your Angular will not.
As a web developer that's an immediate deal breaker. I use Sublime today and being able to run multiple LSP servers per file is a huge boon, it turns a very capable text editor into a total powerhouse. The way it's set up in Sublime with configuration options that can be applied very broadly or very specifically, while having defaults that just works is also just incredible.
While I'm super pleased with Sublime and a happy paying customer since at least a decade, and at this rate may well be for another decase, I'm always keeping my ear to the ground for other editors if nothing else just to stay current. Zed's been looking pretty cool, but things like this will keep me from even just trying it. There's years of muscle memory and momentum built up in my editor choice, I'm not switching on whim.
Thank you very much for sharing this nugget of gold!
In my currently opened project I have: vtsls (for typescript), biome, emmet, and the snippets LSP running on the same file.
You can configure which LSPs you can run on a language basis. Globally and per project.
You can also configure the format on save actions the same way. Globally and per project.
I have astro project that on save runs biome for the front-matter part followed by prettier for the rest.
That's ... uh ... not what a rug pull is. They're telling you plainly from the jump that they're going to eventually charge for it. Point taken on your wish to wait, that makes perfect sense.
recently saw an old alfred hitchcock presents where the character does the cheesiest most absurd rug pull ... and the person was boom dead. i assumed that was the origin of the term
'rug pull' has come to be mean (thanks to crypto) a premeditated & malicious financial play in which someone offers something for money and then vanishes before fulfilling their part of the original bargain.
OP edited to the idiomatic 'rug pulled from under my feet' to specify that he doesn't mean the above.
Just to clarify, you can run as many LSPs in a given file type as you want.
Common features like completions, diagnostics, and auto-formatting will multiplex to all of the LSPs.
Admittedly, there are certain features that currently only use one LSP: inlay hints and document highlights are examples. For which LSP features is multi-server support important to you? It shouldn't be too hard to generalize.
> A: Yes. Zed will be free to use as a standalone editor. We will instead charge a subscription for optional features targeting teams and collaboration. See "how will you make money?".
> Q: How will you make money?
> A: We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:
- Channels and calls
- Chat
- Channel notes
We plan to offer our collaboration features to open source teams, free of charge.
It seems to me that they're just going to charge for Zeta if they do, because it... costs them money to run.
Unlike others (e.g. Cursor), they've opened it (and its fine-tuning dataset!), so you can just run it yourself if you want to bear the costs...
They did something similar with LLM use, where for simplicity they gave you LLM use, but you could use them directly too.
>Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing feature. This means you cannot use your PC as a thin client to the actual chunky big work machine like you can with vscode.
Does this work on anything other than VSCode ? I have been trying to use JetBrains stuff for this but it has been bad for years with little improvement. Honestly JetBrains feels like they are falling behind further and further in terms of adapting to providing a modern workflow - bad remote work, bad gen AI integration. I'm using VS code even where I wouldn't consider it before because of this, and I would like to see what the alternatives have to offer because VSCode is not perfect either.
As someone that is old enough to have used UNIX development servers for the whole company, with PC thin clients, reading about remote development as modern workflow is kind of hilarious.
The remote development feature implemented in VS Code—and I believe also in beta in Zed—is a million times better than what you're used to. The UI is local, the storage and computation (including the language server) are remote. This takes away the lag when connected to a far-away server while still allowing things like platform-dependent compilation to work correctly and efficiently.
For the last 35 years, X Windows, Citrix and RDP have done the job just fine, in what I am concerned.
No, they aren't anything better than what I am used to.
Also, as compromise, a cloud shell, browser based IDE setup, and dev containers, also does the job in what concerns cloud deployments, which should be driven from CI/CD and don't have shells on containers anyway.
Good for you, I guess? For me, regressing to having a round trip between a keypress and its result would be completely unacceptable. The speed of light in a vacuum doesn't change; paths are not getting significantly more direct; the improved index of refraction from switching to hollow-core fiber or low-orbit satellites could in theory help but is a one-time, limited improvement that has yet to be delivered to my fingertips. Having the network boundary in the correct place to account for the fundamental physics of the situation is the only real answer.
I mean you do get slower with age so maybe that could explain it - personally I get nauseous working on 30hz (was stuck on this in a BnB once because of an old HDMI dongle), and that's like best case scenario for internet latency without all of your local I/O and encode/decode overhead.
I do not remember anything particularly difficult to get X11 up and running remotely, other than the XAuth stuff which was annoying enough in hardened environments, although those have not been commonplace, and X11 tunnelling via ssh has automagically taken care of XAuth.
The ultimate deal breaker, however, is X11 not being proxied by corporate firewalls, even though the protocol is extensively documented and the source is available. But that is because RDP has won over, and demand for X11 has diminished.
But, yes, X11 prefers local networks with flat topologies, and the protocol is chatty (again, not as big of an issue anymore unless run over a mobile connection with a high latency, but the X11 protocol compression helps with that).
Except doing it over LAN vs Internet is a very different thing - editing over SSH with >100 ping is annoying as hell, especially if you have packet drops (like a mobile connection). Using a thin client editor with remote server is a much smoother experience.
More like someone that is hardly impressed by kids on the school playground rediscovering history, like all those TikTok videos that are actually resampling 1970's music, and folks dancing to them cheering them for cool new modern music.
It’s not exactly the same paradigm as remote editing, but neovim in tmux accessed over mosh is my preferred way of accomplishing the same task. I have also gotten a neovim gui to connect with a neovim instance over ssh, which worked pretty well until the ssh connection broke. But I prefer my editor in a terminal rather than terminals in my editor, so I switched back to my tmux based workflow.
Basically the benefit is not losing context when I close my laptop lid or if I lose network briefly. I actually use multiple tmux sessions in my workflow, so it also saves me having to remember which one I was working in. This is especially useful if I am on a spotty connection such as tethered through my phone.
Works on JetBrains, vscode, any terminal editor (neovim, vim, nano, etc.). Is it any good? It's fine on JetBrains, great on vscode, the rest is more or less great. Zed does not have it. You want to edit a remote file? You download it, edit it, upload it. That's much worse than a half baked implementation.
For clarity, this does work with the mac os version of Zed. I use it frequently to work on my GPU nodes. The one tradeoff that is a bit of a smell for me is that the preview version of the feature requires you talk to a centralized broker on Zed's servers rather than fully p2p between your local IDE and your own server.
This is supposedly temporary though IIRC (may even be changed already in a dev branch, not sure).
With the speed that models are coming out at and the amount of VC subsidies in trials my approach is the opposite, I don't get too attached and keep trying different tools and models.
And that's why most of these endeavors are doomed to fail. Every time they enshittify one service there's a new one with attractive UX that VC's essentially pay you to use instead. And so the previous investment would be lost if they couldn't dump it on naive stock traders by going public before the cat is out of the bag.
It's like the recent Samsung phones, functionality fees are waived until 2026. No word about the price yet. [1]
Samsung should be avoided like the plague anyway, I've never seen such a malicious and hostile company! On Dec 13 they silently announced that they were gonna break Samsung APIs on Dec 30 [2]. Yeah, they gave devs the "You gotta spend your holidays fixing our mess, otherwise your app will break". Due to that Samsung is still broken in Home Assistant and other API integrations. [3]
> Samsung should be avoided like the plague anyway
I've avoided them for years. I had a Samsung phone a long time ago, and I'd rooted it to run one of those apps that could automate tasks (Tasker?), with a killer feature being when I turn my phone upside down, it goes on silent mode. Standard now, but back then wasn't possible on Android, and Tasker enabled it. And also some geofencing stuff. If I got a text while going faster than 10mph it would respond back "driving right now, will respond later."
Anyway, Samsung released an upgrade that I'd heard would eradicate root and make it impossible going forward. Something to do with Knox, a corporate way of locking down phones for employees.
I repeatedly declined to upgrade.
Finally, one night, with my phone in another room, it force-installed the update, with Knox, on my phone, wiping out my root, making it impossible going forward, and making Tasker worthless for me.
I've never given Samsung another cent. No company that will disobey me re my own property and will remotely hack my device and wipe out my content can be trusted, and that's essentially what they did.
For similar reasons, I've never given Sony any money since the rootkit scandal. 2025 marks twenty years of no Sony. I've probably unknowingly seen a few Sony films, but that's it. No electronics, no games, etc.
As an Android user and developer, it's always annoying reading reviews where Samsung gets 9.5 out of ten and they give a terrible review to the competition because they have a slightly better camera. They give you a terrible Touch Wiz UI/whatever crap interface they switched to, change all the fonts, move around menu items and buttons, slightly change all the stock apps to be worse, push their garbage store, etc. Samsung Galaxy 1 was legitimately a good phone, but all the modern reviews just feel like author grew up with all the garbage that Samsung brings and thinks that is actually a good experience
I absolutely prefer modern OneUI on Samsung phones to the Pixel variant or stock AOSP. The Galaxy store is only used for updating Samsung native apps and isn't "pushed" at all in my experience. I don't use their native apps for the most part and them existing isn't a problem for me, Google apps are preinstalled and work as expected set once as the default.
This is exactly my concern with Samsung's upcoming trifold phone: I'm excited about the idea of a trifold phone, but I definitely don't want to use a phone that has anything other than the stock Android experience.
Hey, my name is Piotr and I work on language servers at Zed.
Right now you can run multiple language servers in a single project. Admittedly you cannot have multiple instances of a single language server in a single worktree (e.g. two rust-analyzers) - I am working on that right now, as this is a common pain point for users with monorepos.
I would love to hear more about the problems you are having with running language servers in your projects. Is there any chance for us to speak on our community Discord or via onboarding call (which you can book via https://dub.sh/zed-c-onboarding)?
I've been using Zed (with python) for the last few weeks (coming from vscode and nevim). There's a lot I like about Zed. My favorites include the speed and navigation via the symbol outline (and vim mode). I'd have a hard time going back to vscode. The LSP configuration, though, is not one of its best parts, for me. I ended up copy/pasting a few different ruff + pyright configs until one mostly worked and puzzled through how to map the settings from linked pyright docs into Zed yaml. Some better documentation for the configuration stanzas and how they map across the different tool's settings would be really helpful.
I'm sure given the breadth of LSPs, that they all have their own config, and use different project config files, makes it hard to document clearly. But it's an area that I hope bubbles up the roadmap in due course.
The newer specs for json-schema (not supported by VSCode) allow for a wider range of data requirements to be supported by a schema without that schema resorting to costly workarounds. VSCode's level of support for this is decent, but is still a pain point as it creates a sort of artificial restriction on the layout of your data that you're able to have without unexpected development costs. This of course can lead to missed estimates and reduced morale.
I understand that very few developers are directly producing and maintaining schemas. Those schemas do have an impact on most developers though. I think this is a problem that is being sadly overlooked, and I hope you can consider changing the status quo.
Love the company name btw, sounds similar to my own Nuzz Industries (not a real company, just a tag I've slapped onto some projects occasionally as a homage to Page Industries from Deus Ex).
I keep getting interested in Zed then rediscovering how much I like the easy debugging in jetbrains IDEs. Last time I checked Zed had a PR in progress. Maybe next time I think about it, Zed will be ready for me.
I asked them about this on X and they are working on one. I use Zed for everything now but must keep VS Code around just for the debugger. I can't wait to delete it.
I downloaded Zed when it took way too long for VS Code to load the monorepo at work. It took almost as long for me to download and install Zed and then open the monorepo as it did for VS Code to load the monorepo. I think the was a fluke with VS Code as it didn't normally take this long but it did happen often enough to be annoying.
I also find Zed to be snappier than VS Code. It's hard to quantify but it just feels better to use Zed.
For reference, I mainly work on a Node/Typescript monorepo that is made up of a bunch of serverless services and is deployed with SST v2
Genuinely not sure whether you are joking or not. The thing is, I do not need a debugger very often, but when I need it, I need it.
I also have no idea what kind of code people "write" that they can rely on A.I. so much. I have found these tools helpful for gathering info but not for much more, yet.
I don't even find it that useful for gathering info. If it's good at that then there's some documentation out there that's going to be faster to comb through. It's useful for generating boilerplate for well defined unit tests and the occasional tab-complete.
Yeah, this is a moronic take. I'm all in on AI programming, but when you need debugging, you really need it - sometimes the model will get utterly fixated on a solution that is just wrong, and you just need to follow the stack trace.
Absolutely. This is already what I've been doing myself. Forked zed so I could use my local rig (4x 3090) to do FIM completions using a finetuned qwen coder 32B.
Only barrier for some folks will be if they're not familiar with rust or local LLMs in general, but it really wasn't that difficult looking back on it. Amounted to about an afternoon's worth of work.
At present it's not possible just via configuration, but you can configure a custom endpoint for both the assistant and inline assistant in settings.json.
To get custom tab completions working you need to mimic one of the completion provider apis (like copilot) [1] and direct the requests to your own endpoint. In my case, I am running llama.cpp and and MITM-proxying to its newer /infill endpoint [2]
That's why I mention the rust piece may be a blocker for some, you do have to hack apart the src a bit to get things working. At the time I started this, the only two completion providers available were supermaven [3] and copilot. You could mimic either.
I actually had a similar idea - and have a PR up on Zed right now to add in support for specifying a HTTP/HTTPS proxy to the copilot completion APIs: https://github.com/zed-industries/zed/pull/24364
Branch is a bit out of date vs main now but it should work if you build off it.
When I tried a few weeks back I was only able to get the latter to actually process requests, but haven't had a chance to look into it much further yet... first one's probably your best bet
When products evolve rapidly, pricing will too. Whatever Zed or any actor is doing now or in 6 month on either front says little about what will happen next.
Just try what people offer right now, at a price point that you are okay with, right now. In a year, both product and price will probably be moot.
What kind of mentality is this? I remember before snapple was a widely known name they used to give out free bottles all over Los Angeles. I never thought to myself, I better not taste this free drink until I know the actual price.
Totally different. You aren't adjusting your development workflow based on a soft drink. If it weren't a rug-pull, why wouldn't they charge for it immediately, or at least tell us the price now?
They are specifically hoping you'll become dependent on it and then feel compelled to pay. This shit works because people like you believe it doesn't.
> If it weren't a rug-pull, why wouldn't they charge for it immediately, or at least tell us the price now?
Because they haven't decided the price yet, or because they don't think the feature is mature enough to justify charging for?
Though even if they really have the motivations you describe, that's fine too. There's a chance this is such a valuable feature you could feel compelled to pay any price for it, but you get to try it for free? That's purely to your benefit: it's not heroin and you won't really lose by trying it and then it being taken away.
You're going to be adjusting regardless with new tooling, so the point is irrelevant. It's not a rug pull because they're telling you it's not free. So what if it works? I pay for useful services, you do too. My point is not exploring or being curious because a company might ask you to pay for a product, seems outlandish, because that's what companies do, they charge people for goods and services.
They may not know enough about the cost structure of this feature to price it fairly; I could easily imagine this is heavily dependent on usage patterns and they'll need a few thousand people using it regularly before they'll know that.
I can’t speak to the Zed team’s motivations for this, but unless it’s a big corp pulling a move like this it’s usually not that nefarious. Having been in these kinds of product conversations it’s more like, “that thing we prototyped? I we think it’s stable and usable enough for beta. We’re not sure how to price it yet, but let’s give it to our customers to play around with and give us some feedback while we figure out what to tweak and how much it’s worth”.
Sorry, in the same file as the sibling said. In some other editors, you can run multiple LSPs on the same exact file at the same exact time.
A use case is Angular or other more specialized frameworks, that are so abstracted away and dumbed down that each layer of abstraction basically has an LSP.
I used a long timeframe to illustrate that prices always change eventually.
Whether they change in 6 months or 24 months or 60 months is just a business decision of whether to trend towards continuous small increases or rare but larger jumps. The fundamental economic pressures that lead to higher prices in the long run are no different.
Not a rug pull. Just use it. If you like it and the price is too high. Don't pay it. What is the problem? Are you afraid that you'll like the feature so much that you'll pay whatever the cost?
So if they let you try a Ferrari for free, you wouldn't because you might like it but you can't afford it?
I would, even if I know I could never buy one.
It's not like that, that's out of proportion I feel like. It's like you get to use a new phone for a week that makes your life much easier, and maybe has features you need. Then, it suddenly costs a little bit more than you can afford. That's the issue
With this feature they're competing with the features Cursor had for quite a while now, so I would expect a price competition there. That means close to $20 /mth. (windsurf without that feature is $15)
Eh, I find that to be a stubborn attitude for no benefit. It doesn't really cost you anything to try, and if it's too expensive, how are you worse off?
I love Zed, and I'm happy to pay for AI stuff, but I won't be using this until they are done with their rug pull. Once I know how much it costs, I can decide if I want to try integrating it into my workflow. Only THEN will I want to try it, and would be interested in a limited free trial, even just 24 hours.
Considering I've seen products like this range from free to hundreds of dollars per month, I'd rather not find out how good it is and then find out I can't afford it.
Other than that for anyone wanting to try Zed:
- You can only run one LSP per file type, so your Rust will work fine, your C++, too, your Angular will not.
- Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing feature. This means you cannot use your PC as a thin client to the actual chunky big work machine like you can with vscode. I've seen a PR that adds windows ssh support, but it looked very stale.