Der API-Key in Roo Code bestimmt, welcher Anbieter die Anfragen erhält, welche Modelle aufrufbar sind, wem die Kosten zugeordnet werden und wie groß der Schaden bei einer Offenlegung ist. Viele Fälle von „Key funktioniert nicht“ sind in Wahrheit eine falsche Base URL, ein falscher Modellname oder ein falsch gewählter Anbietertyp.

Dieser Artikel führt in der Reihenfolge Erstellung, kompatible Konfiguration, Multi-Modell-Profile, Key-Sicherheit, Rotation, Teamregeln und Fehlersuche durch einen umsetzbaren Ablauf. Nach einem Wechsel zum Community-Zweig Zoo Code gelten die meisten Konzepte weiterhin.

Hinweis: Roo Code ist eine Marke des jeweiligen Rechteinhabers, VS Code ist eine Marke von Microsoft. Dieser Artikel dient der technischen Erläuterung; es besteht keine Zugehörigkeit zu den genannten Unternehmen. Die Roo-Code-Erweiterung wird seit dem 15. Mai 2026 nicht mehr gepflegt, das Repository wurde am selben Tag archiviert. Maßgeblich sind das offizielle Repository und die Dokumentation. Modelle und Preise entnehmen Sie den Modellpreisen.

1. Zuerst den Status und den Key-Typ klären

Roo Code ist ein Open-Source-KI-Programmieragent für VS Code im BYOK-Modus: Die Erweiterung zieht keine Modellgebühren ein, sondern Modellaufrufe werden über den von Ihnen hinterlegten Anbieter-Key abgerechnet. Unterstützt werden mehrere Anbieter sowie OpenAI-kompatible Endpunkte.

Zum Status: Nach öffentlich verfügbaren Informationen wird die Roo-Code-Erweiterung seit dem 15. Mai 2026 nicht mehr gepflegt, das ursprüngliche Repository ist archiviert; seitdem gibt es keine Funktionsupdates, Fehlerbehebungen oder Sicherheitspatches mehr. Bestehende Installationen laufen meist weiter, doch für eine langfristige Nutzung gehört das Fehlen von Patches ins Risikobild. Der Community-Zweig Zoo Code entwickelt den Code unter der Apache-2.0-Lizenz weiter.

Mit „Roo Code API Key“ ist meist ein Anbieter-Key, ein gateway-kompatibler Key oder die Adresse eines lokalen Modells wie Ollama gemeint. Dieser Artikel behandelt die zweite Variante. Sie dient nicht zur Anmeldung bei Roo Code und kann dessen Cloud-Dienste nicht aufrufen.

2. Key erstellen: Grenzen festlegen, dann kopieren

Klären Sie vor der Erstellung drei Dinge: Wer nutzt den Key, in welchem Projekt, und wie viel darf höchstens ausgegeben werden? Diese drei Angaben entscheiden darüber, ob sich ein Problem schnell eingrenzen und der Schaden begrenzen lässt.

  1. Öffnen Sie die Registrierungsseite der ZSQH AI Gateway, registrieren Sie sich und melden Sie sich in der Konsole an.
  2. Gehen Sie zu „API-Keys“ und klicken Sie auf „Neu“.
  3. Benennen Sie den Key nach Nutzer und Gerät, zum Beispiel roo-zhang-macbook; vermeiden Sie Namen wie test.
  4. Legen Sie ein Ausgabenlimit und ein Ablaufdatum fest; Test-Keys erhalten zunächst ein niedriges Limit.
  5. Falls die Konsole einen Modellbereich unterstützt, wählen Sie nur die tatsächlich benötigten Modelle aus.
  6. Kopieren Sie den vollständigen Key in den Passwortmanager; die meisten Konsolen zeigen ihn nur einmal vollständig an.

Keys beginnen häufig mit sk-, doch das Präfix beweist weder Echtheit noch Berechtigungen. Achten Sie beim Kopieren auf Leerzeichen und Zeilenumbrüche am Anfang und Ende – eine häufige Ursache für Invalid API Key.

3. OpenAI-kompatiblen Endpunkt konfigurieren

Der Weg führt über Settings → Providers. Wählen Sie als API Provider den Eintrag OpenAI Compatible. Drei Felder sind entscheidend:

  • Base URL: eine Stammadresse wie https://ai.zhongshangqihang.com/v1, nicht die Website-Startseite und nicht der Pfad bis /chat/completions.
  • API Key: der soeben erstellte Gateway-Key.
  • Model: die exakte Modell-ID von der Preisseite, ohne geratene Suffixe.

Unter Model Configuration lassen sich außerdem Max Output Tokens, Context Window, Image Support, Computer Use, Input Price und Output Price einstellen. Die beiden Preisangaben dienen nur der lokalen Kostenschätzung und ändern nichts an der tatsächlichen Abrechnung. Das Kontextfenster darf nicht zu groß angegeben werden, sonst schlagen lange Aufgaben fehl.

Roo Code setzt auf native Tool-Aufrufe des Modells und besitzt keinen XML-Fallback. Ein kompatibler Endpunkt muss daher nicht nur chatten können, sondern auch OpenAI-konformes Function Calling unterstützen; sonst funktioniert normales Gespräch, aber der Agent scheitert beim ersten Tool-Aufruf.

curl https://ai.zhongshangqihang.com/v1/chat/completions \
  -H "Authorization: Bearer $ZSQH_ROO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<Modell-ID>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

Wenn curl funktioniert, Roo Code aber einen Fehler meldet, prüfen Sie, ob die Base URL einen zusätzlichen Pfad enthält, ob die Modell-ID übereinstimmt und ob das Modell Tool-Aufrufe unterstützt.

4. API Configuration Profiles: der Kern der Multi-Modell-Nutzung

API Configuration Profiles sind speicherbare, umschaltbare Konfigurationssätze. Jedes Profil speichert Anbieter, Key, Modell, Temperatur, Denkbudget, Rate Limit und Einstellungen für Diff-Bearbeitung getrennt. Für Multi-Modell-Workflows ist dies die wichtigste Funktion.

Unter Settings → Providers klicken Sie neben der Profilauswahl auf +, vergeben einen Namen, wählen Anbieter, tragen den Key ein, wählen das Modell und setzen bei Bedarf ein Rate Limit. Das Rate Limit bezeichnet den Mindestabstand zwischen zwei Anfragen dieses Profils und ist standardmäßig deaktiviert. Profile lassen sich im Einstellungsfenster oder über die Auswahl API Configuration im Chat wechseln.

Feinere Steuerung bietet der Reiter Prompts: Jeder Modus kann an ein Profil gebunden werden. Eine Aufgabe übernimmt das Profil beim Start und behält es auch bei Wiederaufnahme aus dem Verlauf; Unteraufgaben des Orchestrators erben das Elternprofil und behalten es über den gesamten Lebenszyklus. Binden Sie den Orchestrator daher nicht an ein teures Modell und erwarten Sie anschließend eine günstigere Unteraufgabe.

Profilname Zweck Modellstufe Key-Strategie Hinweis
plan-strong Architektur, komplexe Refactorings Starkes Reasoning-Modell Eigener Key, höheres Limit An Architect gebunden
code-daily Tägliches Coding, Bugfixes Hauptmodell Ein Key pro Person An Code gebunden
ask-cheap Codefragen, Erklärungen Leichtes Modell Key mit niedrigem Limit An Ask gebunden
batch-cheap Kommentare, Formatierung Preisgünstiges Modell Projektspezifischer Key Rate Limit setzen
backup Wechsel bei Ausfall Ersatzmodell Eigener Key Regelmäßig prüfen

Namen nach dem Muster „Szenario-Stufe“ erleichtern die Zuordnung. Modell-IDs und Preise ändern sich; maßgeblich sind die Modellpreise.

5. Key-Sicherheit: Speicherung, Rechte und Datengrenzen

Laut Dokumentation liegt der Key im Secret Storage von VS Code und wird nicht im Klartext in gewöhnlichen Einstellungsdateien abgelegt. Das ist kein absoluter Schutz: Der Schutz hängt vom Betriebssystemkonto ab, und wer sich an Ihrem Rechner anmelden kann oder Prozesse mit Ihren Rechten ausführt, kann möglicherweise darauf zugreifen.

Deshalb sind weitere Maßnahmen nötig: ein eigenes Systemkonto auf dem Entwicklungsrechner, keine dauerhafte Speicherung auf gemeinsam genutzten Geräten, eine klare Erweiterungs-Whitelist auf Firmengeräten, die Prüfung des Synchronisierungsbereichs, damit sensible Konfigurationen nicht auf unkontrollierte Geräte gelangen, keine Keys in Prompts, Codekommentaren oder der Terminal-Historie, das Abdecken von Key-Feldern vor Screenshots und die Auswahl des Kanals nach Datenklassifizierung – der Codekontext wird an den Dienst hinter der Base URL gesendet.

Minimale Rechte bedeuten: Auch bei einer Offenlegung bleibt der Schaden begrenzt. Setzen Sie Limits, Ablaufzeiten und Modell-Whitelists; falls das Gateway IP-Whitelists oder Projektbereiche unterstützt, aktivieren Sie diese. Verwenden Sie getrennte Keys für Tests, Alltag und Automatisierung statt eines Allzweck-Keys.

6. Rotation, Sperrung und Vorfallbehandlung

Empfohlen ist eine Rotation alle 90 Tage oder sofort bei Personalwechsel, Geräteverlust oder Verdacht auf Offenlegung. Da Roo Code nicht mehr gepflegt wird und ältere Versionen keine Sicherheitspatches erhalten, darf der Zyklus kürzer ausfallen.

Die sichere Reihenfolge lautet „erst parallel, dann umstellen, zuletzt abschalten“: neuen Key mit Datumssuffix anlegen, im Passwortmanager speichern und den alten vorerst behalten; im Profil ersetzen und testen; im Gateway-Protokoll prüfen, ob der neue Key Anfragen erhält; ein bis zwei Tage Fehlerquote und Verbrauch beobachten; erst dann den alten Key deaktivieren.

Bei bestätigter Offenlegung gilt die umgekehrte Reihenfolge: zuerst den Key deaktivieren oder löschen, dann auffällige Nutzung, Quelle und Zeitraum prüfen, anschließend Repository-Verlauf, Protokolle und Chatverläufe kontrollieren. Die Schadensbegrenzung hat Vorrang vor der Analyse des Angriffswegs.

7. Teamnutzung: aus persönlichen Einstellungen eine Regel machen

Die Keys liegen auf jedem Entwicklungsrechner. Verlässt sich ein Team nur auf die Erweiterung, ist kaum zentral sichtbar, wer welchen Key verwendet. Die zentrale Steuerung gehört auf die Gateway-Seite: ein Key pro Person, getrennte Keys pro Projekt, einheitliche Limits und vollständige Anfrageprotokolle.

  • Klarnamen-Keys: Name enthält Mitglied und Zweck; am Austrittstag deaktivieren; kein gemeinsamer „Team-Key“.
  • Projektisolierung: Produktion, Experimente und Automatisierung erhalten eigene Keys mit getrennten Limits.
  • Keine Keys im Arbeitsbereich: Im Repository stehen nur Base URL, Modellname und Modusbeschreibung; der Key bleibt im benutzerspezifischen Speicher.
  • Eigene Konten für gemeinsame Dienste: CI, Skripte und Bots nutzen Service-Keys, nicht persönliche Keys.
  • Monatliche Prüfung: ungenutzte Keys, auffällige Limits und ein plötzlicher Anstieg fehlgeschlagener Authentifizierungen.
  • Minimale Rechte: leichte Szenarien erhalten kein starkes Modell; reine Leseaufgaben keine automatische Terminalausführung.

Automatische Freigaben steigern die Effizienz, verstärken aber Fehlbedienung und Token-Verbrauch. Das Team sollte festlegen, welche Befehle zwingend eine menschliche Bestätigung erfordern.

8. Häufige Fehler und ihre Ursachen

  • Invalid API Key: Key unvollständig, mit Leerzeichen oder im falschen Anbieterfeld für Anthropic oder Gemini. Wechseln Sie zu OpenAI Compatible.
  • Model Not Found / 404: Modell-ID falsch geschrieben oder Base URL enthält zusätzlich /chat/completions. Kopieren Sie die ID von der Preisseite und kürzen Sie die Base URL auf /v1.
  • 401 / 403: Key deaktiviert, Limit erschöpft oder keine Modellberechtigung. Prüfen Sie Konsolenstatus und Verbrauch.
  • 429: Rate Limit oder Kontingent erreicht. Parallelität senken, Rate Limit und Key-Limit prüfen.
  • Chat funktioniert, Tool-Aufrufe scheitern: Endpunkt oder Modell unterstützt kein natives Function Calling. Wechseln Sie zu einem Modell oder Endpunkt mit Tool-Unterstützung.
  • Lange Aufgabe bricht ab: Kontextfenster zu groß angegeben oder Output-Limit unpassend. Tragen Sie die tatsächlichen Fähigkeiten ein.

Die Fehlersuche folgt drei Ebenen: Anbieter, Base URL und Modellname prüfen; mit curl reproduzieren; im Gateway-Protokoll nach der entsprechenden Anfrage suchen. Stimmen alle drei, liegt das Problem meist nicht am Key.

Häufige Fragen

Lässt sich Roo Code noch verwenden?

Bereits installierte Erweiterungen laufen in der Regel weiter, doch das ursprüngliche Team hat die Pflege am 15. Mai 2026 eingestellt, das Repository ist archiviert, und es gibt keine Updates oder Sicherheitspatches mehr. Für neue Projekte sollten Sie Zoo Code oder andere aktiv gepflegte Werkzeuge prüfen; bei Weiternutzung der alten Version sind die Key-Rechte strikt zu begrenzen.

Wo wird der Key gespeichert?

Laut Dokumentation im VS Code Secret Storage, nicht im Klartext in gewöhnlichen Einstellungsdateien. Er bleibt ein lokales Zugangsmerkmal; der Schutz hängt vom Systemkonto und der Sicherheit des Entwicklungsrechners ab. Auf gemeinsam genutzten Geräten sollten eigene Konten verwendet und die Synchronisierung sensibler Konfigurationen vermieden werden.

Kann ein Key für mehrere Profile verwendet werden?

Technisch ja, empfehlenswert ist es nicht. Unterschiedliche Profile stehen für unterschiedliche Modelle und Limits; getrennte Keys machen Nutzer und Szenario im Protokoll sichtbar. Bei einem einzelnen Key ist zudem schwer zu erkennen, wie groß der betroffene Bereich ist.

Warum funktioniert der Chat, aber die Agent-Tools nicht?

Roo Code verwendet ausschließlich native Tool-Aufrufe, ohne XML-Fallback. Der kompatible Endpunkt muss OpenAI-konformes Function Calling implementieren, und das Modell muss es unterstützen. Testen Sie zunächst ein anderes Modell mit Tool-Unterstützung, um Endpunkt- und Modellproblem zu trennen.

Sollte ein Team einen gemeinsamen Key verwenden?

Nein. Ein gemeinsamer Key erlaubt keine Zuordnung des Verbrauchs und ist nach einem Austritt schwer zu sperren. Ein Key pro Person, eigene Keys für CI und gemeinsame Dienste sowie zentrale Limits und Warnungen im Gateway sind die bessere Grundlage.

Fazit

Wenn Sie Roo Code oder Zoo Code weiter nutzen, legen Sie zuerst einen Test-Key mit niedrigem Limit an und prüfen ihn sowohl mit curl als auch mit einer echten Agent-Aufgabe, bevor Sie ihn an das Team ausgeben. Der Einstieg erfolgt über die Registrierung; Modelle, Limits und Abrechnung finden Sie in den Modellpreisen. Preise ändern sich mit Modellversionen und Anbieterpolitik.

Weitere Artikel: