Beim Einrichten eigener Modelle in Continue ist der Key zugleich Zugangsmittel sowie Kosten- und Sicherheitsgrenze. Wird er zu sorglos angelegt, sind ungewöhnlicher Verbrauch, unklare Nutzung pro Mitglied und weiterhin aktive alte Keys nach einem Austritt die häufigen Folgen.

2026 wurde Continue von Cursor übernommen, das offizielle Repository wird nicht mehr aktiv gepflegt, und der gehostete Hub sowie der Anmeldedienst sind abgeschaltet. Die Key-Verwaltung verlagert sich damit ins Lokale: eine config.yaml, eine .env und mehrere Gateway-Keys, getrennt nach Person und Zweck. Dieser Beitrag behandelt Erstellung, Ablage, mehrere Modelle, Rotation, Richtlinien und Diagnose.

Status: Im Juni 2026 wurde Continue von Cursor übernommen; das offizielle Repository ist schreibgeschützt und wird nicht mehr aktiv gepflegt. Der gehostete Hub und der Anmeldedienst wurden abgeschaltet. Erweiterung und CLI bleiben nutzbar, werden aber nicht mehr aktiv gewartet; Sicherheitskorrekturen müssen selbst bewertet werden.

Markenhinweis: Continue ist eine Marke von Continue Dev, Inc.; Cursor ist eine Marke von Anysphere, Inc. Dieser Beitrag dient der technischen Erläuterung und steht in keiner Zugehörigkeits- oder Vertretungsbeziehung zu den genannten Unternehmen; Produktstatus und Konfigurationsfelder richten sich nach den offiziellen Seiten und der aktuell installierten Version.

1. Zuerst klären, welche Arten von Keys es in Continue gibt

Der Begriff „Continue API Key“ wird häufig uneinheitlich verwendet. In der Praxis gibt es mindestens drei Arten von Zugangsdaten mit unterschiedlicher Herkunft und Verwendung:

Typ Aussteller Zweck Aktuell geeignet
Gateway-Key Kompatible Dienste wie das ZSQH AI Gateway Aufruf mehrerer Modelle über das OpenAI-kompatible Protokoll Ja, Schwerpunkt dieses Beitrags
Anbieter-Key OpenAI, Anthropic, Google und andere Direkter Aufruf der offiziellen Schnittstelle des jeweiligen Anbieters Ja, mit anderen Feldern und Adressen
Lokales Modell Kein Key, etwa Ollama oder LM Studio Inferenz auf dem Rechner oder im internen Netz Ja, ohne Schlüssel
Continue-Konto oder Hub-Zugang Frühere Continue-Plattform Anmeldung, geteilte Assistenten, Teamsynchronisierung Mit dem Hub abgeschaltet, nicht mehr geeignet

„Continue API Key“ meint daher meist die modellseitigen Zugangsdaten im Feld apiKey, nicht einen universellen Schlüssel des Editors. Dieser Beitrag behandelt den Gateway-Key; er beginnt häufig mit sk-, erlaubt aber weder die Anmeldung bei Continue noch Aufrufe der früheren Plattform-Schnittstelle.

2. Gateway-Key erstellen: zuerst Grenzen festlegen, dann kopieren

Vor dem Anlegen klären: Wer nutzt ihn, in welchem Projekt, und wie viel darf maximal verbraucht werden?

  1. Die Registrierungsseite des ZSQH AI Gateway öffnen, registrieren und in der Konsole anmelden.
  2. „API-Schlüssel“ öffnen und einen neuen Key anlegen.
  3. Im Namen Nutzer und Gerät nennen, etwa continue-zhang-macbook, nicht nur test.
  4. Ausgabenlimit und Ablaufdatum setzen; unterstützt die Konsole einen Modellbereich, die verfügbaren Modelle pro Projekt einschränken.
  5. Guthaben oder Aufladestatus prüfen, damit die Konfiguration nicht erst nach dem Scheitern auffällt.
  6. Den Key in den Passwortmanager kopieren, nicht zuerst in Chat-Tools, Tickets oder Gruppen senden.

Empfohlen ist ein Key pro Person und Gerät. Gemeinsame Keys wirken bequem, lassen sich bei ungewöhnlichem Verbrauch aber keiner Person zuordnen und nach einem Austritt nicht sauber bewerten. Modelle und Preise werden angepasst; maßgeblich ist die Seite Modellpreise.

3. Den Key in .env ablegen, nicht in config.yaml

Continue unterstützt Mustache-Verweise auf Geheimnisse in config.yaml:

apiKey: ${{ secrets.ZSQH_API_KEY }}

Anschließend den Wert in der .env-Datei definieren:

# ~/.continue/.env
ZSQH_API_KEY=sk-Ihr-Gateway-Schluessel

Einige Details beachten:

  • Der Wert in .env erhält keine Anführungszeichen; gemäß offizieller FAQ das Format KEY=value verwenden.
  • .env nicht in Git einchecken, sondern in .gitignore aufnehmen.
  • Unter macOS/Linux kann chmod 600 ~/.continue/.env die Dateirechte einschränken.
  • Nach einer Änderung an .env das IDE neu starten, damit die Erweiterung die Werte erneut liest.
  • Soll config.yaml in ein Repository, nur den Platzhalter ${{ secrets.Name }} behalten und keinen Klartext-Key eintragen.

Ein Key direkt in der YAML funktioniert ebenfalls, doch sobald die Konfiguration kopiert, abfotografiert oder eingecheckt wird, verbreitet sich der Key mit. Mit .env und Platzhaltern lässt sich die Konfiguration teilen, während der Schlüssel in der persönlichen Umgebung bleibt.

4. Mehrere Modelle: ein Key für mehrere Rollen

models ist in Continue eine Liste mit mehreren Modelleinträgen. Jeder Eintrag hat eigene Werte für name, model und roles und kann denselben Key wiederverwenden:

name: zsqh-continue
version: 0.0.1
schema: v1

models:
  - name: Hauptdialog und Bearbeitung
    provider: openai
    model: YOUR_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_API_KEY }}
    roles: [chat, edit, apply]
    capabilities: [tool_use]

  - name: Autovervollstaendigung
    provider: openai
    model: YOUR_FIM_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_AUTOCOMPLETE_KEY }}
    roles: [autocomplete]

Beide Formen der Key-Aufteilung haben ihren Zweck:

  • Ein Key für mehrere Modelle: geeignet für einzelne Entwickler, einfache Verwaltung, zentrale Abrechnung.
  • Keys nach Rolle trennen: geeignet für Teams. Dialog, Vervollständigung und Embedding nutzen jeweils einen eigenen Key; bei ungewöhnlichem Verbrauch lässt sich schnell erkennen, welche Art von Anfrage betroffen ist.

Das Aufteilen von Keys ist keine Pflicht, sondern ein Mittel zur Kostenzuordnung. Kleine Teams trennen zuerst nach Person und lösen autocomplete erst ab, wenn der Verbrauch dort steigt.

Das Autovervollständigungsmodell muss FIM unterstützen; ein Chat-Modell ist nicht automatisch geeignet, nur weil es Code schreiben kann. Bietet das Gateway kein passendes FIM-Modell, kann das Gateway chat, edit und apply übernehmen und die Vervollständigung auf ein kleines lokales Modell wechseln.

5. Umgebungsvariablen und die Auflösungsreihenfolge

Trifft Continue auf ${{ secrets.X }}, sucht es in dieser Reihenfolge:

  1. .env im Stammverzeichnis des Workspace.
  2. .env unter .continue/ im Workspace.
  3. Globale ~/.continue/.env.
  4. Prozessumgebungsvariablen.

Zwei Stolperfallen sind häufig.

Erstens lesen IDE-Erweiterungen in der Regel keine Variablen, die im Terminal per export gesetzt wurden. Die offizielle FAQ stellt ausdrücklich klar, dass export OPENAI_API_KEY=... in der Shell von Continue in VS Code oder JetBrains nicht gelesen wird; Prozessumgebungsvariablen wirken vor allem auf die Continue CLI. „Ich habe es im Terminal gesetzt“ ist daher kein Diagnoseergebnis – die .env bleibt erforderlich.

Zweitens hat die .env im Workspace Vorrang vor der globalen .env. Beim Öffnen nicht vertrauenswürdiger Repositories prüfen, ob eine .env enthalten ist; Teams sollten .env in die Ignorierregeln aufnehmen.

6. Rotation, Widerruf und Austritt

Ein Key sollte nicht „einmal angelegt und dauerhaft verwendet“ werden. Empfohlen ist eine vierteljährliche Rotation; bei Personalwechsel, Geräteverlust oder vermuteter Offenlegung sofort rotieren:

  1. In der Gateway-Konsole einen neuen Key mit gleichen Rechten und gleichem Limit anlegen.
  2. Den neuen Key in die passende .env eintragen und den alten Key vorübergehend behalten.
  3. Das IDE neu starten und Chat, Edit und Vervollständigung getrennt prüfen.
  4. Im Gateway-Log bestätigen, dass der neue Key normale Anfragen erzeugt.
  5. Ein bis zwei Tage beobachten, ob Clients übersehen wurden.
  6. Den alten Key in der Konsole deaktivieren oder löschen.
  7. Rotationsdatum, Verantwortlichen und betroffenen Bereich dokumentieren.

Besteht der Verdacht auf Offenlegung, ist die Reihenfolge umgekehrt: zuerst deaktivieren, dann untersuchen. Nicht beobachten und weiterverwenden – ungewöhnlicher Verbrauch wartet nicht auf die Bestätigung. Nach der Deaktivierung Anfrageprotokoll, Verbrauchskurve und Modellaufrufe prüfen, unerwartete Aufrufe identifizieren und erst dann über Limits oder Alarmregeln entscheiden.

Bei Austritt, Gerätewechsel oder Projektende den zugehörigen Key am selben Tag deaktivieren und die Person bitten, die lokale .env zu löschen. Auf gemeinsam genutzten Geräten sollten Keys nicht dauerhaft verbleiben.

7. Schlüsselspeicherung und Teamrichtlinien

  • Keys nur im Passwortmanager und in .env halten; nicht in Code, Screenshots, Tickets, Chatverläufen oder Bildschirmaufnahmen.
  • Ein Key pro Person, mit Ausgabenlimit und Ablaufdatum pro Projekt; für gemeinsame Dienstkonten einen separaten Key anlegen und die Weitergabe begrenzen.
  • Konfigurationsvorlagen dürfen ins Repository, aber nur mit ${{ secrets.Name }}; jedes Mitglied trägt den Wert in der eigenen .env ein.
  • Monatlich abrechnen: Verbrauch nach Key, Modell und Mitglied prüfen; bei Anomalien zuerst deaktivieren, dann untersuchen.
  • Eine Modell- und Key-Zuordnungstabelle pflegen mit Zweck, Verantwortlichem, Limit und Rotationsdatum.
  • Continue wird nicht mehr gewartet; die Key-Verwaltung nicht den Teamfunktionen des Plugins überlassen. Rechte, Audit und Widerruf gehören auf die Gateway-Seite.
  • Gateway-Logs können Anfrage-Metadaten enthalten. Bei vertraulichem Code zuerst Datenhaltung und Log-Richtlinie des Gateways prüfen und dann entscheiden, welche Projekte angebunden werden dürfen.

Die zentralen Fragen einer Sicherheitsrichtlinie lauten: Wem gehört dieser Key, wie viel darf er verbrauchen, und wie wird er im Ernstfall gestoppt?

8. Fehlersuche: 401 und wirkungslose Konfiguration

Bei 401 in dieser Reihenfolge prüfen:

  1. Existiert die .env, und liegt sie unter ~/.continue/.env oder im Workspace?
  2. Stimmt der Variablenname exakt mit ${{ secrets.Name }} in config.yaml überein, einschließlich Groß-/Kleinschreibung?
  3. Enthält der Wert führende oder nachfolgende Leerzeichen, Anführungszeichen oder Zeilenumbrüche? Beim Kopieren aus Chatfenstern schleichen sich leicht unsichtbare Zeichen ein.
  4. Wurde das IDE nach der Änderung an .env neu gestartet?
  5. Ist der Key deaktiviert oder abgelaufen, und hat das Konto verfügbares Guthaben?
  6. Wird tatsächlich config.yaml geladen oder noch die alte config.json?
  7. Zeigt apiBase auf die Umgebung des Keys? Ein Test-Key gegen die Produktionsadresse kann ebenfalls 401 liefern.

Weitere häufige Erscheinungen:

  • 404: apiBase enthält /v1 zu viel oder zu wenig, oder die Modell-ID existiert nicht.
  • 429: Limit, Rate oder Parallelität überschritten; zuerst Fehlerkörper und Verbrauch prüfen, nicht blind wiederholen.
  • Nur die Vervollständigung schlägt fehl: prüfen, ob das autocomplete-Modell ein FIM-Modell ist und ob ein anderer Key verwendet wird.
  • uses: lässt sich nicht auflösen: Der Hub ist abgeschaltet; entfernte Verweise durch direkte Angaben von provider, model und apiKey ersetzen.
  • Das neue Modell fehlt im Modellwähler: YAML-Einrückung, roles und den Ladezustand nach dem Speichern prüfen.

Bei der Diagnose jeweils nur eine Variable ändern. Werden Key, Adresse und Modell gleichzeitig geändert, lässt sich selbst nach der Behebung die Ursache nicht bestimmen.

9. Häufige Fragen

Wird der API Key von Continue vom Continue-Konto ausgestellt?

Nein. Continue selbst stellt keinen universellen Modell-Key aus; eingetragen werden Zugangsdaten des Modellanbieters oder Gateways. Anmeldung und Hosting der früheren Continue-Plattform sind abgeschaltet und kommen als Key-Quelle nicht mehr infrage.

Warum liefert das IDE trotz exportiertem Key im Terminal noch 401?

Continue in VS Code und JetBrains liest Shell-Umgebungsvariablen meist nicht. Den Key in ~/.continue/.env oder die Workspace-.env eintragen und das IDE neu starten. Prozessumgebungsvariablen wirken vor allem auf die CLI.

Darf der Key direkt in config.yaml stehen?

Er funktioniert, ist aber nicht empfehlenswert. Konfigurationsdateien landen leicht im Repository, werden kopiert oder abfotografiert. Besser ${{ secrets.Name }} als Platzhalter verwenden und den Klartextwert in .env und im Passwortmanager halten.

Müssen verschiedene Modelle unterschiedliche Keys verwenden?

Nicht zwingend. Ein Key kann mehrere Modelle aufrufen. Das Aufteilen dient der Zuordnung von Verantwortung, Limits und Abrechnung und eignet sich für Teams nach Person, Rolle oder Projekt.

Was ist nach einer Key-Offenlegung der erste Schritt?

Zuerst den Key in der Gateway-Konsole deaktivieren, dann einen neuen Key anlegen. Anschließend Verbrauch und Anfrageprotokoll prüfen, den Umfang ungewöhnlicher Aufrufe bestimmen und danach über Limits, Alarmregeln oder weitere Zugangsdaten entscheiden.

Nächster Schritt

Erstellen Sie zunächst im ZSQH AI Gateway einen Test-Key und arbeiten Sie die Reihenfolge „in .env ablegen, in der Konfiguration referenzieren, nach Neustart prüfen“ durch, bevor Sie daraus eine Teamvorlage machen. Modellverfügbarkeit und aktuelle Preise entnehmen Sie den Modellpreisen.

Weiterführende Beiträge: