What it was trained on
Sage is a full fine-tune of sweepai/sweep-next-edit-1.5B
(Apache-2.0, built on Qwen2.5-Coder-1.5B) for one epoch on 58M tokens:
- Edit histories. Every multi-hunk commit is replayed hunk by hunk: the earlier
hunks become the recent changes, and the next hunk is the target. About 30,000
examples come from the recent history of 20 permissively licensed projects
(React, TypeScript, Next.js, Vite, Deno, Tailwind CSS, FastAPI, Pydantic, Django,
Transformers, Ruff, uv, Kubernetes, Prometheus, GitHub CLI, Tokio, Swift, Flutter,
VS Code and Hermes Agent) and about 23,000 from the author's own projects.
- Accepted review suggestions. 1,248 GitHub suggestion comments from the same
projects whose suggested code is in the merged result. The reviewer's note goes
into the prompt ahead of the file.
- Half-typed code. Half of all edits are shown cut at a random character, with
the cursor on the cut line, the way an editor sends them while you type. The
target is the finished edit.
Examples containing anything that looks like a credential (known key formats and
long high-entropy strings) were dropped, as were .env, key and lock files.
<|file_sep|>{path}.difforiginal:{lines before your last change}updated:{lines after it}<|file_sep|>original/{path}{the window before your last change}<|file_sep|>current/{path}{the window now: 10 lines above the cursor, the cursor line, 10 below}<|file_sep|>updated/{path}
Up to three .diff blocks, oldest first. Sage answers with the updated window and
stops at <|file_sep|> or end of text. Decode greedily.
Use it in Zed
Serve the GGUF with llama.cpp:
llama-server -m sage-1.5b-q8_0.gguf --alias sage --port 8080 -c 8192 -fa on -ngl 99 \ --cache-reuse 256 --spec-type ngram-simple --draft-max 16
The output is mostly a copy of the current window, so n-gram speculation (drafting
from the prompt itself) roughly triples decoding speed, and cache reuse keeps the
prompt between keystrokes.
Then in Zed's settings.json:
{ "edit_predictions": { "provider": "open_ai_compatible_api", "open_ai_compatible_api": { "api_url": "http://127.0.0.1:8080/v1/completions", "model": "sage", "prompt_format": "sweep", "max_output_tokens": 512 } }}
How well it does
Exact match of the whole predicted window, greedy, on held-out data (the most
recent commits of each project, and review suggestions from pull requests not
seen in training):
Table with columns: Sweep 1.5B, Sage 1.5B | Sweep 1.5B | Sage 1.5B |
|---|
| Half-typed code (300 examples) | – | 32.7% |
| Next edit, the author's projects (300) | 3.7% | 17.3% |
| Next edit, the 20 public projects (300) | 5.3% | 29.0% |
| Accepted review suggestions (161) | 0.0% | 11.8% |
Sweep's own numbers here use the windows this card describes, which are not the
windows Sweep was trained on, so they understate Sweep in its own editor.
On an Apple M1 Mac with 8 GB of RAM, using the q8_0 GGUF and the settings above:
about 1 second for a suggestion when the prompt is already cached (around 150
tokens/s, 85% of drafted tokens accepted), and 5 to 7 seconds for the first one in
a new place, most of it spent swapping on a machine short of memory. More RAM
should help most.
Limitations
- A bare keyword typed just above a line that starts with the same keyword can be
taken for an accidental duplicate and removed. A few more characters fix it.
- Many real edits are new features that no model could guess from the previous
edit; those are most of the misses.
- Part of the training data is the author's own code, so Sage has seen it and may
echo patterns from it.
- It writes the whole 21-line window each time, so it is slower than models that
emit only the changed lines.
Files
model.safetensors and tokenizer files: the weights for transformers.
sage-1.5b-q8_0.gguf: for llama.cpp and anything built on it.
metrics.json: the evaluation behind the table above.
License
Apache-2.0, as is the base model. The training data comes from repositories under
MIT, Apache-2.0 and BSD-3-Clause licences.