Body

What are you proposing?

Support for the self-hosted Sweep open-source Next-Edit model via the existing open_ai_compatible_api or Ollama providers.

Zed already supports the hosted Sweep API, but the open-source model requires a different prompt format than standard FIM — it uses recent diffs, a sliding window rewrite, and <|file_sep|> structured tokens.

This means it cannot work with the current open_ai_compatible_api provider. I propose adding a sweep_next_edit variant to EditPredictionPromptFormat. The edit history context this format needs is already gathered by EditPredictionStore and available in EditPredictionModelInput — the FIM code path in fim.rs just doesn't use it today.
The new format would tap into that existing context to build Sweep's prompt structure.

Why does this matter?

Based on the internal Sweep benchmarks - Sweep Next-Edit 1.5B outperforms existing edit prediction providers on next-edit benchmarks — including models 4x its size. At only 1.5B parameters (1.55 GB at 8-bit quantization), it runs on consumer hardware with sub-500ms latency. It's one of the best models for self-hosting edit predictions.

What problem does this solve?

The self-hosted Sweep Next-Edit model is not supported because the edit history and cursor context is not sent when using self-hosted model.

What becomes easier or possible?

It adds possibility of running self-hosted Sweep Next-Edit model.

Are there any examples or context?

• Sweep Next-Edit blog post — technical details, prompt format, and benchmarks
• Model on HuggingFace — Apache 2.0 licensed, includes run_model.py with the exact prompt construction
• Discussion #47451 — original request; a Zed maintainer closed it referencing the hosted API, but as @khang06 noted, the self-hostable model remains unsupported
• A community member (@ihales) built a working proof-of-concept fork as a separate provider (+519 lines, 7 files), however it was added before the ollama or open_ai_compatible providers were added. Based on the current codebase, the simpler approach with adding a new prompt format would be sufficient.

Possible approach

Adding support would involve:

1. Add sweep_next_edit as a new variant in EditPredictionPromptFormat
2. In fim.rs, when this format is selected, use the edit history and cursor context from EditPredictionModelInput to construct Sweep's prompt (recent diffs as original/updated blocks + 10-line sliding window around cursor, structured with <|file_sep|> tokens)
3. Send to the same /v1/completions endpoint and parse the response with compute_edits()