Autocomplete and next-edit prediction in Onyx Code

Three things suggest code, at three different moments

Autocomplete in Onyx Code is not one feature. Three separate providers put ghost text in your editor, and they fire on different triggers. Knowing which one is talking is what makes the suggestions predictable rather than noisy.

All three run on your machine, and all three are on the free tier without a cap. Tab accepts a suggestion and Esc dismisses it, the same for each.

The as-you-type completion

Fill-in-the-middle is a different training objective from chat: the model sees the code before and after the cursor and writes what belongs between them. That is why Onyx Code runs a dedicated model for it rather than asking your chat model to do the job.

• Multi-line completions are on by default, so a suggestion can be a whole block rather than the rest of a line.
• Cross-file context. Function signatures and imports from your open tabs go into the prompt, so a completion can use a helper you defined in another file.
• A smart trigger suppresses suggestions while you are deleting, while you are inside a string or comment, and immediately after you dismissed one. Most of the reason people turn autocomplete off is that it interrupts at exactly those moments.

Next-edit prediction, which is not completion

Completion answers “what comes next on this line”. Next-edit prediction answers something more useful: “given what you just changed, what is the next edit you are going to make”.

After a substantive edit, Onyx Code reads your last twenty edits and asks a local model for a rewrite of the line at your cursor. If it comes back meaningfully different, it appears as ghost text. It runs on Zeta-2, an open-source model from Zed Industries under Apache 2.0, on the same bundled engine as everything else.

The rename case is where this earns its keep. Rename an identifier, accept the prediction with Tab, and the cursor jumps to the next occurrence of the old name in the file, with a hint at each pending site. Tab again accepts and jumps on. It is a rename refactor done at the speed of pressing one key, without a language server needing to understand your project first.

Speculative decoding, and why a small model helps a big one

Completion has a latency budget of a few hundred milliseconds, after which people stop waiting and keep typing. Speculative decoding is how a local model stays inside it.

A small draft model guesses several tokens ahead, and the main model verifies that guess in one batched step instead of generating token by token. When the draft architecture matches the main model, this cuts completion latency by roughly 30 to 50 percent on Apple Silicon and on CUDA.

The practical consequence for choosing models: pairing a large completion model with a small draft model from the same family is usually faster than running a medium one alone. Models of 3B parameters or fewer are marked as light in the model browser, which is what makes a good draft.

If it is suggesting too much

The providers are independent, so you can keep the ones you like and silence the rest rather than turning off autocomplete altogether.

• Predictive edits costs nothing to keep. It is a heuristic that scans the current file for structurally similar lines, with no model call, so it does not compete for the engine.
• Next-edit prediction is the one to try first if suggestions feel noisy, because it fires after edits rather than as you type, which is a different rhythm to get used to.
• A per-workspace kill switch disables every AI surface for one repository, which is the right tool when the issue is a specific project rather than the feature.

There is also a .onyxnoaifile for excluding paths from AI features entirely, which applies to completion as well as chat. An excluded file gets no suggestions, and it never feeds another file’s: autocomplete leaves it out of the cross-file context, and Onyx Tab neither reads it as a related file nor keeps your edits to it in its history.