Watch on YouTubeZed trains a small edit prediction model from opt-in production traces, using a frontier model to create student targets.
A repair step filters predictions that undo recent typing or cross the editable-region boundary.
Settled user data is noisy, so Zed samples predictions repeatedly and selects examples from the middle of the distance distribution.
Ben Kunkle describes Zed's pipeline for training Zeta 2, a small model that predicts the next code edit around the cursor. The system collects opt-in production snapshots containing recent edits, cursor position, code context, definitions, diagnostics, and errors. A frontier model produces training predictions, which pass through heuristic checks and a repair step before being formatted for student-model experiments. Zed also uses settled data, captured after the user stops editing a region, but treats it as noisy because the user or an agent may later rewrite the code. To filter it, the team compares repeated model predictions with the settled state using Levenshtein distance. Zeta 2 can generate many candidates cheaply, replacing expensive repeated frontier-model calls. Kunkle explains how distance ranges, reversal ratio, kept rate, latency, acceptance, and diagnostic errors are used in offline and production evaluation.
Zed's edit prediction model receives the code around the cursor, recent edits, cursor position, type and variable definitions, diagnostics, and errors. It predicts the next edit the user will make. Since the model runs on every keystroke, Ben Kunkle says it needs to be very fast. Zed therefore fine-tunes a small specialized model for this single task rather than relying directly on a large general model.
The training pipeline starts with opt-in production data. Because Zed is the editor, it can capture snapshots containing the context related to a prediction, including types and definitions. A frontier model receives that input and is asked what prediction it would make. Kunkle says this process is difficult because repeated requests can produce different answers, so Zed has tuned the prompt to get more useful predictions. The pipeline generally uses up to 100,000 examples, while smaller experiments use 10,000 to 50,000.
Zed runs static checks on frontier-model predictions. The checks look for failures such as undoing exactly what the user just typed or ignoring the editable-region boundary. A bad prediction is sent to another frontier-model call with an explanation of the failure and a request to fix it. After repair, the result becomes the expected output for Zeta 2. The data is stored as JSONL, with each stage adding or moving fields, so the processed teacher data can be cached and reused across experiments.
Zed can wait until the user stops editing a prediction's region, snapshot the resulting code, and use that settled state during training. Kunkle says this data is noisy. The user may change their mind, or an agent may rewrite the region completely after the prediction was made. A prediction that was reasonable at first can therefore look unrelated to the later settled state. Zed filters this data by comparing multiple model predictions with the settled result using a Levenshtein-distance-style measure.
Generating ten frontier-model predictions for each of 100,000 examples would require one million frontier-model requests, which Kunkle calls prohibitively expensive. Since Zeta 2 approaches the teacher's prediction quality, Zed can generate about 50 predictions from a student checkpoint instead. Kunkle says this costs almost nothing compared with frontier-model inference. The team then checks whether any candidate is close to the settled region and uses that result to identify useful examples.
Zed groups settled examples by their distance from generated predictions. Examples far from the settled state are probably noise. Examples that are extremely close are often obvious, such as completing the next character in a simple expression. The useful training examples sit in the middle, including code beyond the student's training cutoff, such as new functions the model has not seen. Zed generally trains on the candidate closest to the settled state rather than on the settled state itself, because the settled state remains noisy.
Zed evaluates on a held-out test set and tracks delta carf, its Levenshtein-style metric, along with reversal ratio. Reversal ratio measures how often the model undoes exactly what the user just typed. The team also generates three frontier-model predictions because many edits have no single correct answer, then checks whether the model is close to one of them. Production experiments add acceptance rate, latency, kept rate, and diagnostic error counts. Models can be sampled at a percentage of traffic before becoming the live model.
In the question period, Kunkle says Zed does not currently use Git commits to decide whether a region has settled, though it could. The current heuristic is to snapshot the region after the user stops editing it for ten seconds. This is sufficient for many cases. Zed excludes cases where the user keeps editing the same location without pausing for that interval.
"There's this interesting section in the middle where it's almost. That's like the ideal what we want in our training examples."06:28