Continue with an OpenAI-compatible endpoint

Continue lives inside VS Code and JetBrains and runs autocomplete, chat, inline edits and apply. Every one of those is a separate role in one config file, and each role can point at a different model on a different endpoint. This page shows the config, explains why autocomplete and chat want opposite kinds of model, and what each role actually costs at realistic request volumes.

One config file, one entry per model

Continue reads ~/.continue/config.yaml. Older installs may have a config.json, which uses the same fields in a different shape — if you find one, the values below map across directly.

The load-bearing pair is provider: openai and apiBase. The provider tells Continue which request format to build; the apiBase tells it where to send the result. Setting one without the other is the most common reason a new entry silently does nothing.

# ~/.continue/config.yaml
name: My Config
version: 0.0.1
schema: v1

models:
  # Autocomplete: hundreds of tiny requests a day. It wants a small,
  # fast model that streams — not your strongest one.
  - name: Fast autocomplete
    provider: openai
    model: deepseek-v4-flash
    apiBase: https://aicomp.ai/v1
    roles:
      - autocomplete

  # Chat, edit and apply: fewer requests, much larger ones.
  - name: Strong chat
    provider: openai
    model: claude-sonnet-5
    apiBase: https://aicomp.ai/v1
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use

Note that both entries use the same base URL. That is the point of an OpenAI-compatible endpoint: switching models is one line in a list, not a new provider integration or a new billing relationship.

Roles decide which model pays for which work

Continue does not send every request to one model. The roles list assigns each feature — autocomplete, chat, edit, apply, summarize, embed, rerank — to a specific entry. This is the most under-used cost control in the whole tool.

Autocomplete is the extreme case. It fires constantly, each request is tiny, and anything slower than about half a second is worse than no suggestion at all. Giving it a frontier model means paying top rates for a job where latency matters more than reasoning. Chat and edit are the opposite: fewer requests, much larger ones, where quality actually shows up in the result.

Verify the endpoint before debugging the config

When a new entry does not appear in the model picker, the instinct is to keep editing YAML. Check the endpoint first — it takes one request, and it separates a config problem from a credentials problem.

# Confirm the endpoint and model ID before blaming the config.
curl "$GATEWAY_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ok"}],"max_tokens":5}'

# If this returns JSON, the same values will work in config.yaml.

If that returns JSON, the base URL, key and model ID are all fine, and any remaining problem is in the config. If it does not, no amount of YAML editing will help. Continue also reports parse errors in a banner at the top of its panel, which is worth reading before assuming the file loaded.

How this fails in practice

FAQ

Related

• Every tool, one endpoint — the full matrix
• Cline, the other VS Code agent
• The same idea in the terminal
• Cursor with a custom base URL
• What 'OpenAI-compatible' actually guarantees
• All model rates

Get API access