Zed edit predictions stay silent while chat works

By the aitokensai editors · Verified 2026-10-28 Sources: Zed docs

Agent panel responds, inline assistant answers, and the grey suggestion never appears. Nothing in the logs explains it, because on this path Zed writes no error and raises no notification.

The reason is that edit prediction is not a second call to the same endpoint. It posts a legacy text-completions payload ({model, prompt, max_tokens, stop}) to api_url verbatim, with no path appended. The chat surface does the opposite: it builds the URL as {api_url}/chat/completions. One api_url value, two different routes, and only one of them is likely to be implemented by the endpoint you pointed at.

The failure that produces no error at all

Zed's own documentation describes edit prediction as a separate provider with its own settings block. The one that matters for a custom endpoint is edit_predictions.provider set to open_ai_compatible_api, with its own api_url and its own model.

That block is easy to miss, because configuring language_models.openai_compatible makes the visible surfaces work. Chat works, the agent works, the model picker is populated And the absence of autocomplete looks like a preference rather than a misconfiguration. There is no error to find, so the usual debugging move, opening the logs, produces nothing.

The only reliable test is behavioural: open a file, type inside a function body, and wait. If no grey suggestion arrives within a second or so, the edit prediction route is not answering.

Why the endpoint answers 404 or 501 on that route

Three distinct causes land on the same symptom:

The version segment is duplicated. api_url is the endpoint root, and Zed appends /chat/completions to it. An endpoint root that already ends in /v1 is correct; a root written as /api/v1 against an endpoint whose own root is /api produces /api/v1/v1/chat/completions, which returns 404. The URL looks right in the settings file and is wrong on the wire.

The gateway does not implement /v1/completions. Edit prediction is fill-in-the-middle, and the legacy completions route is the one it uses. A gateway that only implements chat completions returns 501 or 404 to that request while answering everything else normally. This is not fixable from Zed's side, it needs an endpoint that serves the completions route, or dropping edit prediction and using the agent panel only.

The model name is a chat model. Inline completion needs a model that will continue a prompt rather than answer one. A name that works in the agent picker can sit silently in the edit prediction block, because the request technically succeeds and simply produces no useful continuation.

The one error this path does report

When the provider answers but rejects the payload, Zed surfaces the provider's message directly. A documented case against a third-party endpoint reads:

API request to https://open.bigmodel.cn/api/paas/v4 failed: messages.content.text: cannot be empty

That shape — API request to <url> failed: <provider message>. Is the useful one, because the URL in it is the URL Zed actually built. If the path in that message has a duplicated version segment, that is the 404 cause above, visible in plain text instead of inferred. If the message is about the payload body, the endpoint is reachable and the problem is the model or the request shape, not the route.

Testing the two routes separately

The fastest way to separate "the route is wrong" from "the endpoint cannot do this" is to send both requests yourself, with the same base URL:

# the chat route Zed builds for the agent panel
curl -s -o /dev/null -w "%{http_code}\n" \
  https://YOUR-ENDPOINT/v1/chat/completions \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"YOUR-MODEL","messages":[{"role":"user","content":"hi"}]}'

# the completions route edit prediction posts to, verbatim
curl -s -o /dev/null -w "%{http_code}\n" \
  https://YOUR-ENDPOINT/v1/completions \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"YOUR-MODEL","prompt":"def add(a, b):","max_tokens":32}'

A 200 on the first and a 404 or 501 on the second is the whole diagnosis, and it takes longer to read than to run. Both 200 means the route is fine and the problem is the model name in the edit prediction block.

Get API access

FAQ

FAQ

Related

• Zed with a custom OpenAI-compatible endpoint — the setup this assumes
• Base URL not working — when the failure is the route itself
• OpenAI-compatible error codes — read the status you got back
• Cheapest models by workload — what the two routes cost
• Coding agent cost per month — the monthly shape behind it

Get API access