Zum Hauptinhalt springen
Ein Schlüssel ohne Obergrenze ist ein Schlüssel, der Ihr ganzes Workspace-Guthaben leeren kann, wenn ein Agent schleift. Der einzelne wirksamste Weg, den Blast-Radius eines kompromittierten oder außer Kontrolle geratenen Agenten zu begrenzen, ist, seinem Schlüssel ein Ausgabenlimit zu geben. Auf dem gehosteten Gateway ist jeder Schlüssel entweder unbegrenzt oder begrenzt durch ein API-Key-Kontingent, gemessen in US-Dollar — und die Wahl ist ein Feld im Schlüssel-Editor. Diese Seite erklärt die beiden Modi, wie das Cap auf dem Relay-Pfad durchgesetzt wird und wann man welchen wählt. Für den vollständigen Satz an Beschränkungen, die ein Schlüssel trägt — Modell-Allowlists, IP-Allowlists, Policy-Bindungen — siehe Das Token-Objekt.

​
1. Die zwei Modi

Jeder Schlüssel löst auf genau einen von zwei Zuständen auf:

Unbegrenzt

unlimited_quota = true. Der Schlüssel zieht auf das Workspace-Guthaben ohne Pro-Schlüssel-Obergrenze. Zur Request-Zeit läuft keine Ausgabenprüfung — das einzige Limit ist das eigene Guthaben des Workspaces.

Begrenzt

credit_limit_usd > 0. Der Schlüssel trägt sein eigenes Lebenszeit-Ausgabenlimit in USD. Sobald die kumulierten Ausgaben das Cap erreichen, hört der Schlüssel auf zu funktionieren — der Rest des Workspaces bleibt unberührt.
Sie setzen dies im Konsolen-Bildschirm Schlüssel (/console/token). Das Erstellen oder Bearbeiten eines Schlüssels erfordert die Rolle Developer oder höher.
credit_limit_usd = 0 bedeutet unbegrenzt — null ist der Sentinel für „kein Cap”, nicht „ein Null-Dollar-Cap”. Um einen Schlüssel zu begrenzen, geben Sie ihm einen positiven Dollarbetrag.

​
2. Wie ein API-Key-Kontingent durchgesetzt wird

Wenn Sie credit_limit_usd auf eine positive Zahl setzen, wandelt das Gateway es in einen internen remain_quota-Saldo für diesen Schlüssel um und schaltet unlimited_quota auf false. Von da an:
  • remain_quota ist der verbleibende Ausgabenspielraum des Schlüssels, abgebaut, während der Schlüssel Nutzung abrechnet.
  • used_quota sind die kumulierten Ausgaben, die der Schlüssel bereits gebucht hat.
  • Bei jedem Relay-Aufruf prüft das Gateway den Schlüssel, bevor es den Request weiterleitet. Ein begrenzter Schlüssel, dessen remain_quota null erreicht hat, wird als exhausted abgelehnt — der Aufruf erreicht nie das Modell.
Ein unbegrenzter Schlüssel (unlimited_quota = true) überspringt diese Guthaben-Prüfung vollständig; er ist nur durch das Workspace-Guthaben und durch jegliche anderen Limits auf Schlüsselebene, die Sie setzen, begrenzt (Modell-Allowlist, IP-Allowlist, Ablauf).
Ein begrenzter Schlüssel ist ein Lebenszeit-Cap, kein rollierendes Monatsbudget — das Cap zählt die Gesamtausgaben über die Lebensdauer des Schlüssels. Für ein Budget, das sich zurücksetzt, stellen Sie einen frischen begrenzten Schlüssel in Ihrer eigenen Taktung aus (z. B. einen neuen Schlüssel pro Sprint) und widerrufen Sie den alten. Siehe Schlüssel verwalten.

​
3. Ein konkretes Beispiel

Angenommen, Sie deployen einen geplanten Summarization-Agenten und möchten garantieren, dass er nie mehr als $25 ausgeben kann, egal was das Modell tut. Setzen Sie das Cap, wenn Sie den Schlüssel erstellen: 
// POST an den Konsolen-Schlüssel-Bildschirm (Developer+).
// In der Konsole konfigurieren — der Relay-Schlüssel (sk-orca-…) wird nie zur
// Verwaltung von Schlüsseln verwendet; er wird nur auf /v1/*-Inferenz-Aufrufen präsentiert.
{
  "name": "nightly-summarizer",
  "credit_limit_usd": 25,        // begrenzt: $25 Lebenszeit-Cap
  "model_limits_enabled": true,
  "model_limits": ["openai/gpt-4o-mini"],
  "expired_time": -1             // -1 = läuft nie ab
}
Das Gateway speichert dies als begrenzten Schlüssel: unlimited_quota = false und ein remain_quota im Wert von 25.DerAgentruftdasModellmitdem‘sk−orca−…‘−Relay−Schlu¨sselwieu¨blichauf.IndemMoment,indemdiekumuliertenAusgaben25. Der Agent ruft das Modell mit dem `sk-orca-…`-Relay-Schlüssel wie üblich auf. In dem Moment, in dem die kumulierten Ausgaben 25 treffen, ist der Schlüssel erschöpft, und jeder weitere /v1/*-Aufruf wird abgelehnt — ohne dass Sie ein Dashboard beobachten und ohne den Rest des Workspaces anzufassen. Um denselben Schlüssel später unbegrenzt zu machen, bearbeiten Sie ihn und schalten den unlimited-Toggle um — die Konsole setzt unlimited_quota = true und credit_limit_usd = 0 zusammen, und der Schlüssel kann wieder auf das volle Workspace-Guthaben ziehen.

​
4. Welchen Modus wählen

Jeder Schlüssel, der einem autonomen Agenten, einem CI-Job oder einer Drittanbieter-Integration übergeben wird, sollte begrenzt sein. Ein Ausgabenlimit ist die billigste Garantie, dass eine Prompt-Injection-Schleife oder ein Retry-Sturm keine unbegrenzte Rechnung auflaufen lassen kann — das Cap stoppt den Schlüssel, bevor sich der Schaden aufaddiert. Kombinieren Sie es mit einem engen Modell-Limit und einer IP-Allowlist.
Für einen Schlüssel, der nur für eine Demo, einen Lasttest oder ein einzelnes Deployment existiert, kombinieren Sie ein kleines credit_limit_usd mit einer expired_time. Der Schlüssel zieht sich von selbst zurück, je nachdem, welches Limit er zuerst trifft. Siehe Kontingent-Cap & Ablauf und Ablaufende Schlüssel.
Ein Schlüssel, der von einem Kern-Produktionsdienst verwendet wird, den Sie vollständig kontrollieren, wo ein Pro-Schlüssel-Cap nur spurious Ausfälle verursachen würde, kann unbegrenzt bleiben — das Workspace-Guthaben ist der Backstop. Halten Sie diese Schlüssel wenige, benennen Sie sie klar und fassen Sie sie trotzdem mit Modell- und IP-Limits.
Ein begrenzter Schlüssel, der mitten im Lauf erschöpft, beginnt sofort, Aufrufe abzulehnen. Das ist der Sinn — aber es bedeutet, dass ein unbeaufsichtigter Agent mitten in einem Job stoppen kann. Bemessen Sie das Cap für die Arbeit, die Sie erwarten, und beobachten Sie die Ausgaben in den Nutzungsansichten der Konsole, sodass Sie das Cap anheben können, bevor es einen legitimen Lauf beißt.

​
5. Wie die Cap-Felder zusammenhängen

Die drei Felder, die dies steuern, sind ein einzelner Schalter mit einem abgeleiteten Saldo — Sie setzen das Dollar-Cap, das Gateway leitet den Rest ab:
FeldBedeutung
credit_limit_usdIhre Eingabe. > 0 = begrenztes Cap in USD; 0 = unbegrenzt.
unlimited_quotatrue, wenn der Schlüssel kein Cap hat; automatisch auf false gesetzt, wenn Sie ein positives credit_limit_usd geben.
remain_quotaAbgeleiteter Ausgabenspielraum für einen begrenzten Schlüssel; null zu erreichen erschöpft den Schlüssel.
Sie setzen nur jemals credit_limit_usd (oder unlimited_quota) im Editor. remain_quota und used_quota werden vom Gateway gepflegt, während der Schlüssel Nutzung abrechnet — sie sind schreibgeschützte Telemetrie, in den Nutzungsansichten der Konsole sichtbar gemacht.

​
6. Wo das im Control-Stack sitzt

Ein Ausgabenlimit begrenzt, wie viel ein Schlüssel tun kann; der Rest des Scopes des Schlüssels begrenzt, was er tun kann. Die beiden komponieren:

Kontingent-Cap & Ablauf

Kombinieren Sie ein Dollar-Cap mit einem absoluten Ablauf, sodass ein Schlüssel sich von selbst zurückzieht, je nachdem, welches Limit er zuerst trifft.

Das Token-Objekt

Jedes Feld, das ein Schlüssel trägt — Modell-Limits, IP-Allowlist, Policy-Bindungen, Umgebungs-Label — in einer Referenz.

Least-Agency-Checkliste

Das vollständige Rezept für den engstmöglichen Schlüssel, eine Beschränkung nach der anderen.

Scope, Schlüssel & Policies

Wie das Cap in die Workspace → Policy → Schlüssel-Hierarchie passt und wie das Begrenzen eines Schlüssels den Blast-Radius schrumpft.
Je enger das Ausgabenlimit jedes Schlüssels, desto kleiner die Rechnung, die irgendein kompromittierter Agent auflaufen lassen kann — und desto klarer Ihr Audit-Trail dessen, wozu jeder Schlüssel zum Ausgeben autorisiert war.