Beim Konfigurieren eigener Modelle in Cursor ist der Key zugleich Zugangsausweis sowie Kosten- und Sicherheitsgrenze. Wird er zu sorglos angelegt, sind ungewöhnlicher Kontingentverbrauch, unklare Nutzung pro Mitglied und weiter aktive alte Keys nach dem Ausscheiden typische Folgen.

Dieser Beitrag folgt der Reihenfolge „Erstellen – Binden – Zuordnen – Prüfen – Rotieren – Leak-Schutz – Teamrichtlinie“ und liefert eine praktische Checkliste. Menübezeichnungen ändern sich mit Versionen; maßgeblich sind die Cursor Settings der installierten Version.

Hinweis: Cursor ist eine Marke von Anysphere, Inc. Dieser Beitrag dient der technischen Erläuterung; es besteht keine Zugehörigkeit oder Vertretungsbeziehung zu Cursor/Anysphere. Produktfunktionen und Abrechnungsregeln richten sich nach den offiziellen Cursor-Seiten.

1. Zuerst klären, welcher Key konfiguriert werden soll

„Cursor API Key“ wird häufig für drei verschiedene Dinge verwendet:

  • Cursor-Plattform-API-Key: für Cursor-eigene Cloud Agents, Verwaltungsschnittstellen usw., erstellt im Cursor-Konto.
  • Modellanbieter-Key: von OpenAI, Anthropic, Google, Azure, AWS Bedrock usw. ausgestellt und im API-Keys-Bereich von Cursor eingetragen.
  • Gateway-Key: von einem kompatiblen Dienst wie dem ZSQH AI Gateway ausgestellt, meist mit sk- beginnend, über das OpenAI-kompatible Protokoll für mehrere Modelle nutzbar.

Dieser Beitrag behandelt die dritte Variante in Cursor. Sie dient nicht zur Anmeldung bei Cursor und kann keine Cursor-Plattformschnittstellen aufrufen. Der Gateway-Key gehört in das Feld für den OpenAI API Key, wobei die Base URL überschrieben wird; in den Anthropic- oder Google-spezifischen Feldern funktioniert er in der Regel nicht.

2. Key erstellen: erst Grenzen festlegen, dann kopieren

Vor dem Erstellen drei Dinge klären: Wer nutzt ihn, in welchem Projekt, und wie viel darf maximal verbraucht werden? Wer das vorher festlegt, hat es bei der späteren Verwaltung deutlich leichter.

  1. Die Registrierungsseite des ZSQH AI Gateway öffnen und in der Konsole anmelden.
  2. „API-Keys“ öffnen und einen neuen Key anlegen.
  3. Den Namen mit Nutzer und Gerät versehen, etwa cursor-zhang-macbook, nicht nur test.
  4. Kontingentlimit und Ablaufdatum setzen; unterstützt die Konsole Modellbereiche, die verfügbaren Modelle pro Projekt einschränken.
  5. Guthaben aufladen und prüfen, damit die Konfiguration nicht erst beim Aufruf scheitert.
  6. Den Key in den Passwortmanager kopieren, nicht zuerst in Chat oder Tickets senden.

Im Passwortmanager empfiehlt sich folgendes Format für Rotation und Übergabe:

Zweck: cursor-arbeitsrechner
Base URL: https://ai.zhongshangqihang.com/v1
Key: sk-... (nur im Passwortmanager)
Modell: maßgeblich ist die aktuell auf der Seite „Modellpreise“ angezeigte Modell-ID

Der Key wird meist nur einmal vollständig angezeigt. Bei Verlust einen neuen anlegen und den alten löschen, nicht versuchen, ihn wiederzufinden. Modelle und Preise ändern sich; maßgeblich ist die Seite Modellpreise.

3. Key in Cursor binden

Der übliche Weg ist Cursor Settings → Models → API Keys. Bei jedem Schritt den Speicherstatus beachten.

  1. Cursor Settings öffnen, meist mit Cmd/Ctrl + ,.
  2. Models öffnen und API Keys aufklappen.
  3. OpenAI API Key öffnen, den Key einfügen und Save anklicken.
  4. Override OpenAI Base URL öffnen und https://ai.zhongshangqihang.com/v1 eintragen.
  5. + Add Custom Model (in manchen Versionen + Add model) anklicken, die exakte Modell-ID eintragen und aktivieren.
  6. Im Chat das Modell auswählen und eine kurze Testanfrage senden.

Drei häufige Fehler:

  • Die Base URL ist die Webadresse https://ai.zhongshangqihang.com ohne /v1.
  • Die Base URL enthält /chat/completions, wodurch der Pfad doppelt wird und 404 zurückkommt.
  • Der Gateway-Key steht im Azure-OpenAI- oder Bedrock-Feld. Diese Felder gehören zur jeweiligen Cloud-Authentifizierung und passen nicht zu einem normalen kompatiblen Gateway.

Fehlt in der aktuellen Version „Override OpenAI Base URL“, unterstützt sie keine eigene kompatible Adresse. Nicht über andere Felder umgehen, sondern aktualisieren oder eine Version mit diesem Schalter verwenden.

4. Modellzuordnung: aus „Namen“ eine pflegbare Tabelle machen

Ein Modellname ist kein Anzeigetext, sondern eine Routing-Kennung. Teams sollten eine Zuordnungstabelle pflegen mit mindestens Zweck, in Cursor eingetragener Modell-ID, zugehörigem Gateway-Modell, Fähigkeitsgrenzen und Abschaltdatum.

Zweck In Cursor eintragen Grundlage im Gateway Prüfschwerpunkt
Alltägliche Fragen ID des leichten Modells Gleichnamiges Modell auf der Preisseite Name exakt identisch
Hauptmodell für Code ID des Hauptmodells Gleichnamiges Modell auf der Preisseite Tool-Aufrufe unterstützt
Lange Kontexte Langkontext-Variante Gleichnamiges Modell auf der Preisseite Kontextobergrenze
Ausfallreserve ID des Ersatzmodells Gleichnamiges Modell auf der Preisseite Manuell umschaltbar

Keine Anzeigenamen statt Modell-IDs verwenden und Versionssuffixe nicht raten. Typische Symptome bei falscher Eingabe sind „Modell existiert nicht“, 404 oder abgelehnte Anfragen. Ändert das Gateway Modelle, müssen Cursor und interne Dokumentation zeitgleich aktualisiert werden.

5. Prüfung: Konfigurations-, Anfrage- und Abrechnungsebene

Nicht nur prüfen, „ob eine Antwort kommt“, denn die Antwort kann über den integrierten Kanal laufen. Drei Ebenen sind zuverlässiger.

  1. Konfigurationsebene: Key gespeichert, Base URL endet auf /v1, eigenes Modell aktiviert.
  2. Anfrageebene: Neuen leeren Chat öffnen, ausdrücklich das eigene Modell wählen und eine kurze Anfrage senden.
  3. Abrechnungsebene: In der Gateway-Konsole Verbrauch oder Request-Log öffnen und prüfen, ob ein Eintrag mit passendem Zeitpunkt, Modell und Key existiert. Fehlt er, erreicht die Anfrage das Gateway nicht.

Häufige Fehlerbilder:

  • 401 oder 403: Key falsch, deaktiviert oder Kontingent erschöpft.
  • 404: Base-URL-Pfad falsch oder Modellname existiert nicht.
  • 429: Ratenlimit ausgelöst oder Kontingentobergrenze erreicht.
  • Timeout: Endpunkt nicht erreichbar oder Netzwerkpfad gestört.
  • Normaler Chat funktioniert, Agent scheitert: möglicherweise passt die Schnittstellenfähigkeit nicht, nicht zwingend ein Key-Problem.

Für Tests einen separaten Key mit niedrigem Kontingent anlegen und erst nach erfolgreicher Prüfung auf den produktiven Key wechseln, damit der Produktions-Key nicht wiederholt in verschiedene Fenster kopiert wird.

6. Rotation, Sperrung und Vorfallbehandlung

Keys sollten regelmäßig rotiert werden, etwa alle 90 Tage, oder sofort bei Personalwechsel oder Gerätewechsel. Rotation bedeutet nicht Löschen und Neuanlegen, sondern erst parallel betreiben, dann umschalten.

  1. Einen neuen Key mit gleichen Rechten anlegen, Namen mit Datumssuffix.
  2. In Cursor den Key ersetzen und speichern.
  3. Eine Testanfrage senden und prüfen, ob im Gateway-Log der neue Key erscheint.
  4. Eine Zeit lang Fehlerquote und Verbrauch beobachten, um übersehene Clients zu erkennen.
  5. Den alten Key deaktivieren und erst nach einer Weile löschen.

Bei Verdacht auf Offenlegung ist die Reihenfolge umgekehrt: zuerst den Key deaktivieren oder löschen, dann ungewöhnlichen Verbrauch, Quelle und Zeitraum prüfen, anschließend das Team informieren, Repository und Logs kontrollieren und bei Bedarf weitere verwandte Zugangsdaten rotieren. Bei Ausscheiden oder Gerätewechsel den Key noch am selben Tag deaktivieren, nicht bis zum nächsten Audit warten.

7. Leak-Schutz: wo Keys abfließen können

  • Code und Konfigurationsdateien: .env, Container-Konfiguration und Notebooks können eingecheckt werden. Secret-Manager verwenden und vor dem Commit scannen.
  • Screenshots und Bildschirmaufnahmen: Die Einstellungsseite zeigt den Key vollständig. Vor Screenshots abdecken und bei Demos das Key-Feld nicht öffnen.
  • Chat und Tickets: Den vollständigen Key nicht an Kollegen oder Support senden. Zur Kennzeichnung nur Name oder letzte vier Zeichen nennen.
  • IDE-Synchronisierung und Plugins: Synchronisierungsumfang und Plugin-Rechte prüfen; Firmengeräte brauchen eine klare Plugin-Whitelist.
  • Gemeinsam genutzte Rechner: Eigenes Systemkonto verwenden, dauerhafte Speicherung nicht aktivieren, nach der Nutzung abmelden.
  • Logs und Fehlerberichte: Debug-Logs können Request-Header enthalten. Vor dem Versand Authentifizierungsdaten entfernen.
  • Übertragungsweg: Laut Cursor-Hilfeseite werden Keys mit der Anfrage verschlüsselt an Cursor-Server gesendet und nicht aufbewahrt; ein eigener Key profitiert jedoch nicht zwingend von einer Null-Datenaufbewahrung. Daher einen dedizierten Key mit begrenztem Kontingent verwenden.

8. Teamrichtlinie: Keys verwaltbar machen

  • Ein Key pro Person; gemeinsame Dienste erhalten einen eigenen Key, nicht den Key einer Person.
  • Kontingentlimit, Ablaufdatum und Modell-Whitelist einheitlich setzen.
  • Möglichst über ein einheitliches Gateway anbinden, um Mitglieder, Modelle und Verbrauch zu protokollieren.
  • Monatlich prüfen: lange ungenutzte Keys, überzogene Keys, auffällig steigende fehlgeschlagene Authentifizierungen.
  • Datenklassifizierung festlegen: Für sensible Repositories nur geprüfte Modelle und Kanäle zulassen.
  • Erstellung, Übergabe und Deaktivierung von Keys in Onboarding- und Offboarding-Listen aufnehmen.
  • Auch mit eigenem Key können in der Teamversion Plattformgebühren anfallen; die Kostenkalkulation richtet sich nach der Cursor-Abrechnungsseite und den Modellpreisen.

9. Fehlersuche-Checkliste

  • Beim Einfügen Leerzeichen oder Zeilenumbrüche in den Key geraten: löschen und vollständig neu kopieren.
  • Base URL enthält zusätzlich /chat/completions: nur bis /v1 behalten.
  • Modellname ohne Versionssuffix: von der Preisseite unverändert kopieren.
  • Key-Kontingent erschöpft: Guthaben und Limit in der Konsole prüfen, gegebenenfalls anpassen.
  • Tarifbeschränkung: prüfen, ob der aktuelle Cursor-Tarif eigene Keys und die Funktionen erlaubt.
  • Endpunkt nicht erreichbar: prüfen, ob die Base URL öffentlich ist, und außerhalb des Browsers mit einer einfachen Anfrage testen.
  • Agent scheitert, normaler Chat funktioniert: zuerst Schnittstellenfähigkeit verdächtigen, nicht den Key.
  • Tab-Vervollständigung nutzt den Key nicht: Laut Cursor verwendet die Vervollständigung integrierte Modelle; das ist erwartetes Verhalten.

10. Häufige Fragen

Worin unterscheidet sich ein Cursor API Key von einem Modell-API-Key?

Ersterer bezeichnet meist einen von Cursor ausgestellten Key für Cursor-eigene Schnittstellen; letzterer ist ein Key eines Modellanbieters oder Gateways für Modellaufrufe. Dieser Beitrag konfiguriert den zweiten Typ; beide sind nicht austauschbar.

Lässt sich ein Key auf ein einziges Modell beschränken?

Das hängt davon ab, ob die Gateway-Konsole Modellbereiche oder Rechteeinstellungen anbietet. Falls nicht, zumindest einen separaten Key mit Kontingentlimit verwenden und das tatsächlich aufgerufene Modell anhand der Logs prüfen.

Unterbricht eine Key-Rotation laufende Gespräche?

Bereits gesendete Anfragen können unbeeinflusst bleiben, spätere Anfragen nutzen den neuen Key. Am besten in einer ruhigen Phase wechseln, sofort eine Testanfrage senden und erst dann den alten Key deaktivieren.

Was ist bei einem geleakten Key zuerst zu tun?

Zuerst den Key deaktivieren oder löschen, dann ungewöhnlichen Verbrauch und Aufrufquellen prüfen. Nicht zuerst Zeit in die Suche nach dem Leak-Pfad investieren; Schadensbegrenzung hat Vorrang. Danach Repository, Logs und Chats prüfen und bei Bedarf weitere Zugangsdaten rotieren.

Reicht das kostenlose Kontingent zum Testen?

Maßgeblich sind die aktuelle Aktion in der Konsole und die Modellpreise. Für Tests einen Key mit niedrigem Kontingent verwenden, nur Erreichbarkeit und Modellnamen prüfen und keinen Produktionsverkehr für Experimente einsetzen.

Fazit

Die Key-Konfiguration in Cursor ist nicht kompliziert; schwierig ist die langfristige Verwaltung: nachvollziehbare Namen, Kontingentobergrenzen, Modellzuordnung und die Fähigkeit, bei einem Leak Schaden zu begrenzen. Registrieren Sie sich zunächst im ZSQH AI Gateway und legen Sie einen Cursor-spezifischen Key an; danach die Rechte nach Teamrichtlinie schrittweise enger fassen.

Weitere Beiträge: