> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hopscotchlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Continue

> Configure Continue's openai provider against Hopscotch: apiBase, the model roles, and the two things that can change which endpoint it calls.

export const FeatureStatus = ({missing, feature, instead, detail, children}) => <Info>
    <strong>Not available yet: {missing ?? feature}.</strong>
    {instead ?? detail ? ` ${instead ?? detail}` : null} This page documents what
    the product does today. When that changes, this page changes with it.
    {children}
  </Info>;

[Continue](https://continue.dev) 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](/integrations/coding-harnesses) first.

<FeatureStatus missing="a proof run of Continue against the production hostname" instead="The configuration below was read from docs.continue.dev and, for the endpoint behaviour, from the openai provider adapter in the continuedev/continue repository on 2026-09-08. No Continue session has been run against this API." />

## 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`:

```yaml config.yaml theme={"theme":{"light":"vitesse-light","dark":"vesper"}}
models:
  - name: Hopscotch
    provider: openai
    model: openai/gpt-4o-mini
    apiBase: https://api.hopscotchlabs.ai/v1
    apiKey: ${{ secrets.HOPSCOTCH_API_KEY }}
    roles:
      - chat
      - edit
      - apply
```

**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](/integrations/coding-harnesses). 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](/concepts/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.