Skip to main content
Continue is an open-source assistant for VS Code and JetBrains. It configures models by role, which makes it the harness where the missing embeddings endpoint matters most and the one where the model name you write can change which endpoint it calls. Read coding harnesses first.

​
The configuration surface

Continue’s current format is YAML, at ~/.continue/config.yaml. A project can also carry a .continue folder with a models subfolder, and that one is designed to be committed, so put no key in it. The generic OpenAI-compatible provider is openai, and the base URL key is apiBase:
config.yaml
Continue does not append /v1. The adapter resolves each endpoint against apiBase as given, and the provider documentation’s own examples write the version segment into the value, so include it. model is free text for this provider, so a pinned id goes in unchanged.

​
The key

Continue does not read your shell environment: an IDE extension does not have it. It has its own interpolation instead, ${{ secrets.NAME }}, resolved from a .env file at the project root, in the workspace’s .continue folder, or in ~/.continue. Use the one in your home directory and the key never sits next to the repository.

​
Roles, and the one that will fail

Continue assigns each model a set of roles: chat, edit, apply, autocomplete, embed, rerank and summarize. Give this API the ones that are chat completions, and give it none of the following. embed is the codebase indexer. It is what powers the at-mention of your codebase and of ingested documentation, and it calls an embeddings endpoint, which we do not serve. In VS Code this does not need your attention: Continue ships a local embedder and uses it when no embed model is configured, so indexing keeps working while chat runs here. In JetBrains there is no bundled embedder, so codebase indexing needs an embed model pointed at something other than this API or it does not work at all. rerank is not an OpenAI-shaped call. The rerankers Continue supports have their own vendor APIs, so this API cannot answer that role either. Leave it unset or pointed elsewhere.

​
Two things that change which endpoint it calls

Both of these send a request to an endpoint this site does not document. Neither failure reads like a configuration problem, and nothing on this site tells you what either request answers, which is the reason to keep both settings on their defaults. The model name can route the request to the Responses API. Continue’s openai adapter inspects the model name and sends reasoning-era OpenAI names to POST /v1/responses instead of chat completions. This site documents nothing about that endpoint. If a model works in one Continue role and misbehaves in another, or a model works and a differently named one does not, this is the mechanism to suspect. We did not verify whether an id in our provider/model shape trips that check, so treat it as a thing to test rather than as a thing that will happen. Do not set useLegacyCompletionsEndpoint. It sends autocomplete to POST /v1/completions, which this site does not document either. Continue’s default for autocomplete is chat completions, which is the behaviour you want; the flag exists for servers that only speak the legacy endpoint.

​
Tool calling may need telling

Continue decides whether to offer a model its tools by recognising the model’s name, and its documentation is explicit that the autodetection cannot be overridden, only added to for a model it does not recognise. Our ids are not names it ships knowing, so a model that supports tools may be treated as one that does not. If Continue’s agent mode declines to use tools with a model whose catalog entry says tools is yes, add the capability for that model in Continue rather than concluding the model cannot do it. Models covers the catalog entry that settles the question.

​
What we did not verify

  • That a Continue session against this API succeeds. Nothing was run.
  • Whether an id of the form provider/model triggers the adapter’s Responses-API routing. We read the check’s existence, not its behaviour on our id shape.
  • Whether the exact capability-override syntax for an unrecognised model still matches what the documentation describes, and whether autocomplete honours the legacy-endpoint setting consistently. The project carries open reports of that setting not being respected in every role, which we did not reproduce.
  • Whether Continue’s command-line client, as distinct from the IDE extensions, reads standard OpenAI environment variables. The extensions do not, and we found no statement about the client either way.