Continue API-Fehler: 401, 404, 429 und Timeouts (2026)

Continue ist ein Open-Source-KI-Programmierassistent mit VS-Code-Erweiterung, JetBrains-Plugin und CLI, der über das OpenAI-kompatible Protokoll an selbst betriebene oder Drittanbieter-APIs angebunden werden kann. Dass die erste Anfrage nach der Gateway-Konfiguration scheitert, ist häufig; die Ursachen liegen meist auf fünf Ebenen: Zugangsdaten, Adresse, Modell-ID, Kontingent und Netzwerk. Die richtige Reihenfolge ist: Statuscode prüfen, mit einer minimalen Anfrage reproduzieren und erst dann Modell und Kontext ändern. Dieser Artikel liefert eine direkt übernehmbare config.yaml-Basis und eine Prüfliste.

Status: 2026 wurde Continue von Cursor übernommen; das offizielle Repository ist schreibgeschützt und wird nicht mehr aktiv gepflegt. Bestehende Installationen und Community-Zweige bleiben nutzbar, das Versionsverhalten kann jedoch auf dem Stand vor der Übernahme bleiben. Dieser Artikel basiert auf der im Oktober 2026 noch verbreiteten Konfiguration über config.yaml; die Fehlersuche gilt auch für ältere Versionen.

1. Zuerst schichten: Wo genau entsteht der Fehler?

Ändern Sie nicht sofort das Modell, sondern ordnen Sie den Fehler zunächst nach Statuscode ein.

Statuscode/Phänomen	Bedeutung	Zuerst prüfen	Wiederholen?
401	Key fehlt, falsch, ungültig oder ohne Recht	Key, Auth-Feld, Kontostatus	Nein
403	Key ohne Modellrecht oder durch Richtlinie blockiert	Modellrechte, Teameinstellungen	Nein
404	Pfad falsch oder Modell existiert nicht	`apiBase`, Modell-ID	Nein
400/413	Anfrageformat falsch oder Kontext zu lang	Kontext, Parameter, `max_tokens`	Nach Änderung
429	Frequenz, Parallelität oder Token-Kontingent überschritten	Verbrauch, geteilte Keys, Retry-Strategie	Mit Backoff
5xx	Serverfehler oder Gateway überlastet	Dienststatus, Request-ID	Mit Backoff
Timeout/Verbindungsfehler	DNS, TLS, Proxy, Firewall oder Streaming-Kette	Netzwerk und Proxy	Nach Behebung

Halten Sie bei der Fehlersuche Key, Adresse und Modell-ID konstant und ändern Sie jeweils nur eine Variable; nach drei gleichzeitigen Änderungen wissen Sie nicht, welche geholfen hat.

2. Konfigurationsbasis: nur drei Dinge in config.yaml ändern

Das globale Konfigurationsverzeichnis von Continue ist ~/.continue (macOS/Linux) oder %USERPROFILE%\.continue (Windows). Existiert eine config.yaml, wird sie vor der älteren config.json geladen; beide Formate dürfen nicht gemischt werden. Eine funktionierende OpenAI-kompatible Konfiguration:

name: zsqh-gateway
version: 0.0.1
schema: v1

models:
  - name: Team-Chatmodell
    provider: openai
    model: <Modell-ID aus der Modellliste kopieren>
    apiBase: https://api.zhongshangqihang.com/v1
    apiKey: <Ihr API-Key>
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use

Einige leicht fehleranfällige Punkte:

Auf oberster Ebene sind name, version und schema: v1 erforderlich; models ist eine Liste, falsche Einrückung führt direkt zu einem Parsingfehler.
Für ein kompatibles Gateway wird als provider openai gewählt; apiBase endet üblicherweise bei /v1, ohne selbst /chat/completions anzuhängen.
model muss exakt mit der ID in der Modellliste des Gateways übereinstimmen, einschließlich Groß-/Kleinschreibung, Bindestrichen und Versionsnummer.
roles legt fest, ob das Modell Chat, Bearbeitung oder das Anwenden von Patches übernimmt; Autovervollständigung (autocomplete) stellt andere Anforderungen an die Schnittstelle, die ein normales Chatmodell nicht zwingend erfüllt.
Für Tool-Aufrufe im Agent-Modus capabilities: [tool_use] ergänzen; sonst ist eventuell Chat möglich, aber keine Tool-Ausführung. Wenn Änderungen nicht wirken, das IDE-Fenster neu laden und die Protokolle prüfen.

3. 401: zuerst den Key, dann die Auth-Felder

401 bedeutet, dass die Identität nicht bestätigt wurde – unabhängig von Modellfähigkeit und Kontext. Prüfen Sie in dieser Reihenfolge:

Wurde der Key vollständig kopiert, ohne Leerzeichen, Zeilenumbrüche oder Anführungszeichen? Beim Kopieren aus einem Chatfenster gelangen leicht unsichtbare Zeichen hinein.
Steht der Key im Feld apiKey und stimmt er mit dem Auth-Header in requestOptions.headers überein, ohne Dopplung oder Konflikt?
Wurde der Key gelöscht, deaktiviert oder ist er abgelaufen? Hat das Konto ausreichend Guthaben? Manche Gateways liefern bei fehlendem Guthaben 401 oder 403; maßgeblich ist der Fehlerkörper.
Zeigt apiBase auf die Umgebung, zu der der Key gehört? Ein Test-Key an einer Produktionsadresse führt meist ebenfalls zu 401.
Wird die Konfigurationsdatei tatsächlich geladen? Wenn Sie config.json bearbeiten, aber config.yaml geladen wird, wirkt keine Änderung.

Prüfen Sie Adresse und Key zuerst mit einer minimalen Anfrage, um den Continue-Client auszuschließen:

export API_KEY="sk-Ihr-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":"<Modell-ID>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

cat /tmp/continue_resp.json

Ein 200 zeigt, dass Key, Adresse und Modell grundsätzlich funktionieren; bei 401 testen Sie den Testzugang der Gateway-Konsole und wiederholen nicht automatisch.

4. 404: Base URL und Modell-ID sind je etwa die Hälfte der Fälle

Ein 404 bedeutet nicht zwingend, dass das Modell abgeschaltet wurde; am häufigsten ist ein Pfadfehler:

Bei apiBase fehlt /v1, die Anfrage trifft auf eine Web-Route und liefert HTML oder 404.
Bei apiBase steht zusätzlich /v1/chat/completions, und der Client ergänzt den Pfad erneut.
Die Konsolenadresse wurde als API-Adresse verwendet, die Domain ist falsch geschrieben, oder im OpenAI-kompatiblen Feld steht der Anthropic-Pfad /v1/messages.

Auch die Modell-ID kann 404 oder model_not_found auslösen:

Groß-/Kleinschreibung, Bindestriche und Versionsnummer müssen exakt der Modellliste entsprechen.
Das Modell ist eventuell für das aktuelle Konto oder den Tarif nicht freigegeben oder verwendet unter verschiedenen Protokollen eine andere ID.
Dass die Konfigurationsoberfläche den Wert speichert, heißt nicht, dass das Gateway die ID akzeptiert; senden Sie eine echte Anfrage.

Rufen Sie zunächst /v1/models auf, sofern das Gateway dies anbietet, und kopieren Sie die Modell-ID aus der Antwort, statt sie zu tippen.

5. 429: Rate Limit ist nicht dasselbe wie fehlendes Guthaben

429 bedeutet, dass eine Frequenz-, Parallelitäts- oder Token-Grenze überschritten wurde. Häufige Szenarien:

Anfragen pro Minute, Tokens pro Minute oder parallele Verbindungen überschritten.
Mehrere Personen teilen einen Key, oder der Agent liest fortlaufend Dateien und führt Befehle aus, wodurch in kurzer Zeit viele Anfragen entstehen.
Autovervollständigung wird zu häufig ausgelöst; bei wenigen getippten Zeichen geht bereits eine Anfrage hinaus.
Wiederholungen ohne Backoff verstärken den Fehler zum Wiederholungssturm; auch Anfragen mit langem Kontext belegen Parallelitätsplätze.

Prüfen Sie zuerst Antwort-Header und Fehlerkörper statt blind zu wiederholen. Ist Retry-After vorhanden, warten Sie entsprechend; andernfalls exponentielles Backoff mit zufälligem Jitter. Bei 401, 403 und 404 nicht wiederholen. Bei einem Key für mehrere Dienste teilen Sie ihn nach Projekt auf; Agent-Schleifen benötigen eine maximale Rundenzahl und ein Ausgabenlimit.

6. Timeouts, Streaming-Abbrüche und Proxys

Timeouts liefern oft keinen HTTP-Status, sondern äußern sich als lange ausbleibende Antwort, fetch failed, ECONNRESET oder eine zur Hälfte abgebrochene Antwort. Prüfreihenfolge:

Senden Sie zuerst eine nicht gestreamte Anfrage mit kurzem Kontext. Funktioniert sie, liegt das Problem in der Streaming-Kette oder einem Zwischenproxy.
Testen Sie mit curl -N direkt, um den Continue-Client auszuschließen; prüfen Sie zugleich, ob der Proxy SSE-Antworten puffert.
Prüfen Sie die Zertifikatskette. Bei unternehmensweiter TLS-Prüfung muss über requestOptions.caBundlePath das CA-Zertifikat angegeben werden; verifySsl: false eignet sich nur zur kurzfristigen Fehlersuche.
Prüfen Sie die Systemzeit; eine große Abweichung lässt die Zertifikatsprüfung scheitern.
Lange Aufgaben benötigen Timeout und maximale Rundenzahl; der Agent sendet mehrere Runden nacheinander und wirkt bei einer hängenden Verbindung wie „dauerhaft am Laden“. Die Feldnamen unterscheiden sich je nach Version.

Verwenden Sie kein ping, um die API-Verfügbarkeit zu prüfen: Es belegt nur die Erreichbarkeit des Hosts, nicht TLS und korrekten Pfad.

7. Kontextüberschreitung und zu große Anfragekörper

Eine Kontextüberschreitung liefert meist 400 oder 413 mit Begriffen wie context_length_exceeded oder maximum context length. Continue sendet geöffnete Dateien, abgerufene Ausschnitte, Referenzen und Gesprächsverlauf gemeinsam; der tatsächliche Kontext ist oft länger als er aussieht.

Vorgehen:

Mit .continueignore oder Index-Ausschlüssen Build-Artefakte, Protokolle und Abhängigkeitsverzeichnisse ausschließen.
Irrelevante Tabs schließen, lange Dokumente zuerst zusammenfassen, lange Gespräche in einer neuen Sitzung fortsetzen.
max_tokens pro Anfrage senken, zuerst mit einer kurzen Anfrage die Kette bestätigen und dann schrittweise verlängern.
Scheitert nur ein großes Repository, liegt der Verdacht nahe, dass zu viele Ausschnitte in den Kontext gelangen.

8. IDE-Protokolle sinnvoll erfassen

In VS Code die Befehlspalette öffnen und „Developer: Toggle Developer Tools“ wählen, um die Konsolenausgabe zu sehen; für ausführlichere Protokolle „Continue: Enable Console“ aktivieren und das Fenster neu laden. In JetBrains liegt ~/.continue/logs/core.log, die IDE-Protokolle unter „Help > Show Log“.

Erfassen Sie mindestens Zeitpunkt, Statuscode, Fehlercode, Modell-ID, Hostname von apiBase, Request-ID, Laufzeit und Wiederholungszahl. Die Request-ID steht meist im Antwort-Header und kann request-id, x-request-id oder x-oneapi-request-id heißen; maßgeblich ist die tatsächliche Rückgabe des Gateways. Vollständige Keys, Prompts und Nutzercode gehören nicht ins Protokoll; vom Key nur die ersten und letzten vier Zeichen behalten.

Eine brauchbare Protokollzeile sieht so aus:

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

9. Prüfliste

Fehlertext, Statuscode, Zeitpunkt und Request-ID notieren.
Mit dem curl-Befehl aus diesem Artikel reproduzieren und feststellen, ob der Fehler nur in Continue auftritt.
Prüfen, ob config.yaml oder config.json geladen wird und ob die YAML-Einrückung stimmt.
Prüfen, ob apiBase bei /v1 endet, und die Modell-ID aus der Modellliste kopieren.
Einen neuen Key testen, um abgelaufene Keys, Kontingente oder Teamrichtlinien auszuschließen.
Zuerst nicht gestreamt und mit kurzem Kontext testen, dann Streaming und langen Kontext schrittweise wieder aktivieren; bei Bedarf Netzwerk oder Proxy wechseln.
Wenn all das funktioniert, Protokolle und Reproduktionsschritte an den Gateway- oder Plugin-Support geben.

10. Häufige Fragen

Der Key funktioniert in einem anderen Client, in Continue aber 401?

Prüfen Sie zuerst das Feld und dann, ob config.yaml tatsächlich geladen wird. Liegen altes config.json und neues config.yaml parallel vor, wird leicht die falsche Datei bearbeitet. Wenn das Team Drittanbieter-Keys sperrt, scheitert auch eine korrekte lokale Konfiguration.

Bedeutet 404 immer, dass das Modell abgeschaltet wurde?

Nein. Meist fehlt oder doppelt sich /v1 in apiBase, oder die Modell-ID ist falsch geschrieben. Rufen Sie die Modellliste auf und testen Sie mit einer kopierten ID.

Ist 429 ein Zeichen für fehlendes Guthaben?

Nicht unbedingt. 429 steht für überschrittene Rate- oder Kontingentgrenzen; fehlendes Guthaben kann 401, 402 oder 403 liefern. Maßgeblich sind Fehlerkörper und Abrechnungsseite.

Warum scheitern nur Streaming oder Autovervollständigung?

Verdächtig sind Proxy-Pufferung, Leerlauf-Timeouts und Unterschiede der Schnittstellenfähigkeiten. Streaming zuerst mit einer nicht gestreamten Anfrage vergleichen; bei Autovervollständigung prüfen, ob Modell und Schnittstelle Vervollständigung oder FIM unterstützen, und nicht einfach ein Chatmodell als autocomplete eintragen.

Continue wird nicht mehr gepflegt – lohnt die Konfiguration noch?

Bestehende Installationen und Community-Zweige laufen weiter, und die Fehlersemantik der OpenAI-kompatiblen Schnittstelle bleibt dieselbe. Für neue Projekte mit langfristigem Wartungsbedarf sollten Sie aktiv entwickelte Alternativen prüfen; wer nur die bestehende Umgebung weiterverwendet, kann nach der Reihenfolge in diesem Artikel vorgehen.

Nächste Schritte

Legen Sie zunächst in der ZSQH AI Gateway einen Test-Key an und prüfen Sie mit dem curl-Befehl aus diesem Artikel Authentifizierung, Modell und Streaming, bevor Sie ihn in config.yaml eintragen. Modelle und Preise entnehmen Sie den Modellpreisen; Preise werden von den Anbietern angepasst. Halten Sie bei der Fehlersuche die Variablen konstant und ersetzen Sie sie einzeln.