Continue API Errors: 401, 404, 429, and Timeouts (2026)

Continue is an open-source AI coding assistant that provides a VS Code extension, a JetBrains plugin, and a CLI, and can connect to self-hosted or third-party APIs through the OpenAI-compatible protocol. Once it is pointed at a gateway, an error on the very first request is common; problems usually cluster in five layers: credentials, address, model ID, quota, and network. The right order is to look at the status code first, reproduce with a minimal request, and only then touch the model and context. This article provides a config.yaml baseline you can copy directly and a troubleshooting checklist.

Status note: In 2026, Continue was acquired by Cursor, and the official repository has become read-only and is no longer actively maintained. Existing installations and community forks still work, but version behavior may be frozen at the pre-acquisition state. This article is based on the config.yaml configuration style still common in October 2026; the troubleshooting approach also applies to older versions.

1. Layer the problem first: where is the error coming from?

Do not change the model as soon as you see an error; classify by status code first.

Status code or symptom	Common meaning	What to check first	Retry?
401	Key missing, wrong, expired, or lacking permission	Key, auth fields, account status	No
403	Key has no permission for that model, or is blocked by policy	Model permissions, team settings	No
404	Wrong path or model does not exist	`apiBase`, model ID	No
400/413	Malformed request or context too long	Context, parameters, `max_tokens`	Retry after changing the request
429	Request rate, concurrency, or token quota exceeded	Usage, shared keys, retry policy	Retry after backoff
5xx	Server error or gateway overload	Service status, request ID	Retry after backoff
Timeout or connection failure	DNS, TLS, proxy, firewall, or streaming path	Network and proxy	Retry after fixing

During troubleshooting, keep the same key, address, and model ID, and change only one item at a time; if you change three things at once, you will not know the cause even when it recovers.

2. Configuration baseline: change only three things in config.yaml

Continue's global configuration directory is ~/.continue (macOS/Linux) or %USERPROFILE%\.continue (Windows). When config.yaml exists, it is loaded in preference to the older config.json; do not mix the two formats. A working OpenAI-compatible configuration looks like this:

name: zsqh-gateway
version: 0.0.1
schema: v1

models:
  - name: Team chat model
    provider: openai
    model: <model ID copied from the model list>
    apiBase: https://api.zhongshangqihang.com/v1
    apiKey: <your API key>
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use

A few error-prone points:

The top level must have name, version, and schema: v1; models is a list, and wrong indentation causes an immediate parse failure.
For a compatible gateway, choose openai as the provider; apiBase usually goes up to /v1, and you should not append /chat/completions yourself.
model must match the ID in the gateway's model list exactly, including case, hyphens, and version numbers.
roles determines whether the model handles chat, edit, or applying patches; autocomplete (autocomplete) has different endpoint requirements, and an ordinary chat model may not support it.
Add capabilities: [tool_use] when Agent mode needs to call tools; otherwise it may be able to chat but not execute tools. If changes do not take effect after saving, reload the IDE window and check the logs.

3. 401: check the key first, then the auth field

A 401 means authentication did not pass and is unrelated to model capability or context. Check in order:

Was the key copied completely, without leading or trailing spaces, line breaks, or quotes? Copying from a chat window is the most likely way to pick up hidden characters.
Is the key entered in the apiKey field, and is it consistent with the auth header in requestOptions.headers, avoiding duplication or conflict?
Has the key been deleted, disabled, or expired? Does the account have an available balance? Some gateways return 401 or 403 when the balance is insufficient; rely on the error body.
Does apiBase point to the environment the key belongs to? A test-environment key against a production address also usually returns 401.
Is the configuration file actually loaded? If you edited config.json while config.yaml is actually in effect, it will look like "nothing I change works."

Verify the address and key first with a minimal request, eliminating the Continue client as a factor:

export API_KEY="sk-your-key"

curl -sS -o /tmp/continue_resp.json -w "%{http_code}\n" \
  "https://api.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<MODEL_ID>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

cat /tmp/continue_resp.json

A 200 means the key, address, and model are basically usable; a 401 means you should switch to the gateway console's test entry and try again, not retry automatically.

4. 404: Base URL and model ID are each about half the cause

A 404 does not necessarily mean the model is offline; the most common cause is a wrong path:

apiBase is missing /v1, so requests hit the site's web routes and return HTML or a 404.
apiBase includes /v1/chat/completions, and the client appends it again, producing a duplicated path.
The console address is mistaken for the API address, the domain is misspelled, or an Anthropic /v1/messages path is entered in OpenAI-compatible fields.

A model ID can also cause a 404 or model_not_found:

Case, hyphens, and version numbers must match the model list exactly.
The model may not be available to the current account or plan, or different protocols may use different IDs.
Being able to save it in the configuration interface does not mean the gateway accepts the ID; send a real request to confirm.

When troubleshooting, first visit /v1/models (if the gateway provides it) and copy the model ID from the returned list rather than typing it by hand.

5. 429: rate limiting is not insufficient balance

A 429 means the request exceeded the rate, concurrency, or token quota. Common scenarios:

Requests per minute, tokens per minute, or concurrent connections exceed the limit.
Several people share one key, or the Agent reads files and runs commands continuously, sending many requests in a short time.
Autocomplete fires too frequently, sending a request every few characters the user types.
Retries have no backoff, so failures generate more requests and form a retry storm; long-context requests also take up concurrency capacity.

When handling, read the response headers and error body first, and do not blindly double the retries. If Retry-After is present, wait as instructed; if not, use exponential backoff with random jitter. Do not retry 401, 403, or 404. When one key serves multiple services, split keys by project; for Agent loops, set a maximum number of turns and a spending cap.

6. Timeouts, streaming interruptions, and proxies

Timeouts usually return no HTTP status code; they appear as a request hanging for a long time, fetch failed, ECONNRESET, or a reply that stops halfway. Troubleshooting order:

First send a non-streaming request with a short context. If non-streaming works, the problem is in the streaming path or an intermediate proxy.
Test directly with curl -N to eliminate the Continue client; also check whether the proxy buffers SSE responses.
Check the certificate chain. When a corporate proxy performs TLS inspection, specify the CA certificate through requestOptions.caBundlePath; verifySsl: false is only suitable for temporary debugging.
Check whether the system time is accurate; a large clock skew can cause certificate validation failure.
Set timeouts and maximum turns for long tasks; the Agent sends multiple rounds of requests in a row, and a hung connection looks like it is "spinning forever." Timeout fields vary by version.

Do not use ping to judge API availability; it only proves the host is reachable, not that TLS and the path are correct.

7. Context limit exceeded and oversized request bodies

Context overruns usually return 400 or 413, and the error body contains strings such as context_length_exceeded or maximum context length. Continue sends open files, retrieved snippets, references, and conversation history together, so the actual context is often longer than it appears.

How to handle it:

Use .continueignore or index exclusion settings to exclude build artifacts, logs, and dependency directories.
Close unrelated tabs, summarize long documents first, and start a new session for long conversations.
Lower max_tokens for a single request; confirm the path with a short request first, then lengthen it gradually.
If failures occur only in a large repository, suspect first that retrieval is inserting too many snippets.

8. How to keep IDE logs useful for troubleshooting

In VS Code, open the command palette and choose "Developer: Toggle Developer Tools" to view Console output; for detailed logs, enable "Continue: Enable Console" and reload the window. In JetBrains, check ~/.continue/logs/core.log; IDE logs are under "Help > Show Log".

Logs should record at least: time, status code, error code, model ID, apiBase host name, request ID, duration, and retry count. The request ID is usually in the response headers, possibly named request-id, x-request-id, or x-oneapi-request-id; use what the gateway actually returns. Do not log full keys, prompts, or user code; keep only the first and last four characters of a key.

A usable log line looks like this:

2026-10-19T10:12:33+08:00 status=429 code=rate_limit_exceeded model=<MODEL_ID> host=api.zhongshangqihang.com request_id=... latency_ms=1840 retry=2

9. Troubleshooting checklist

Record the original error text, status code, time of occurrence, and request ID.
Reproduce with the curl command in this article to confirm whether the problem occurs only inside Continue.
Check whether config.yaml or config.json is actually loaded, and whether the YAML indentation is correct.
Check that apiBase goes up to /v1, and copy the model ID from the model list.
Test with a new key to rule out an invalid key, quota, or team policy issue.
Start with a non-streaming, short-context request, then gradually restore streaming and long context; switch networks or proxies if necessary.
Once all of the above pass, submit the logs and reproduction steps to gateway or plugin support.

10. FAQ

The key works in another client but returns 401 in Continue?

First check whether it is in the wrong field, then whether config.yaml is actually loaded. When an old config.json and a new config.yaml coexist, it is easy to edit the wrong file; if the team restricts third-party keys, even a correct local configuration will fail.

Does a 404 always mean the model is offline?

Not necessarily. Most cases are an apiBase with a missing or extra /v1, or a misspelled model ID. Visit the model list first, then copy the ID and test.

Does a 429 mean insufficient balance?

Not necessarily. A 429 means the rate or quota was exceeded; insufficient balance may return 401, 402, or 403. Rely on the error body and billing page.

Why do only streaming or autocomplete fail?

Suspect proxy buffering, idle timeouts, and endpoint capability differences first. For streaming issues, compare with a non-streaming request; for autocomplete failures, confirm whether the model and endpoint support completion or FIM, and do not set a chat model as autocomplete directly.

Continue is no longer maintained; is it still worth configuring?

Existing installations and community forks still run, and the error semantics are still those of the OpenAI-compatible interface. If a new project needs long-term maintenance, evaluate alternatives that are still actively developed; if you are only reusing an existing environment, just troubleshoot in the order given here.

Next steps

First create a test key at the ZSQH AI Gateway, run authentication, model, and streaming through the curl commands in this article, and then fill them into config.yaml. Models and prices are subject to the on-site model pricing, and prices change with providers; when troubleshooting, fix the variables first and then replace them one at a time.