kevinlu1248

Ya definitely, that makes total sense. It feels to me that currently the labs have great researchers, who only care about making models perform better across raw intel and then they have incompetent applied AI engineers / FDE's who can only suggest using better prompting to remove bad habits to make agents more usable.

We have an explanation here: https://blog.sweep.dev/posts/next-edit-jetbrains#next-edit-a...

But basically suggesting changes away from your cursor position

It's a bit undertrained on C#, we'll continue improving on this!

Also wish Fleet took off, not a fan of installing a new IDE for every separate repo that's in a different language

I've done some testing before and many of the new Jetbrains internal plugins cause memory leaks which really lags down my IDE...

Definitely agree here, have had so many cases where I would like ask Claude for XYZ, then ask for XYZ again but with a small change. Instead of abstracting out the common code it would just duplicate the code with the small change.

We currently integrate with Jetbrains' PSI

Honestly I think we can improve our training throughput drastically via a few more optimizations but we've been spending most of our time on model quality improvements instead.

You can see that Qwen3 does worse than Qwen2.5 on our benchmark. Reason is it's never been pretrained for FIM / autocomplete.

Not at the moment but we do host it for our Jetbrains plugin

Yes, I've used it to write blog posts / large user-facing copy.

Are you using the right format? https://huggingface.co/sweepai/sweep-next-edit-1.5B/blob/mai...

^ these were pretty much the main reasons.

The other one is that constrained decoding only works on CFGs (simpler grammars like JSON schemas) since only these ones can produce automatas which can be used for constrained decoding. Programming languages like Python and C++ aren't CFGs so it doesn't work.

Also constrained decoding generally worsens model quality since the model would be generating off-policy. So RL helps push corrected syntax back on-policy.

Unfortunately, the main optimization (3x speedup) is using n-gram spec dec which doesn't run on CPUs. But I believe it works on Metal at least.

Haha, we never trained it for chat but I would bet it works regardless.

Also that's crazy, M4 Mac?

Our hosted autocomplete is coming to Zed in a few weeks.

We'll push to Ollama

Let me know if you have any questions! What hardware are you on?

We're using an internal fork of trl for some of the steps.

Personally, I think usable AI is more valuable than simply more intelligence. Many of the labs are pushing towards models that are 1% better on CodeForces and AIME if you just let it think and use tools for hours, instead of more user-friendly models with better coding habits, like writing shorter and more modular code.

Double-check if you're using the right format.

Example here: https://huggingface.co/sweepai/sweep-next-edit-1.5B/blob/mai...

Woops meant to say open-weight. We put open-weight in the title and but accidentally wrote open-source in the description.

Someone in this thread already built a Neovim plugin connecting to this model I believe.

Also more technical details on SFT data here:

https://blog.sweep.dev/posts/next-edit-jetbrains#building-au...

Thanks! Let us know if you have any questions / feedback.

Not at the moment, if you install the hosted Sweep AI Jetbrains plugin it uses our hosted (larger) model.

Let me know if you have any questions. We have a lot of harness code that cleans up many bad behaviours that makes it a lot more usable (like token healing: https://blog.sweep.dev/posts/token-healing-autocomplete).

this is awesome, i'm going to try this out

I'm building a supermaven competitor for jetbrains. We use the Jetbrains PSI (basically Jetbrain's version of the LSP) to pull definitions into context to make the autocomplete smarter. My colleague wrote a blog on this here: https://blog.sweep.dev/posts/autocomplete-context.

We also found a lot of cases where caching ends up being actually slower than doing the operation. The 100% solution would probably be to use a SQL db the way diskcache does it, but this is easier to use for us.