Übersicht
Labels kennzeichnen jeden Request für die Zuordnung: welches Team, welches Feature, welcher Job oder welche Umgebung den Traffic erzeugt hat. Ein Request kann auf zwei Arten mit Labels versehen werden, und beide können gleichzeitig gelten:- Tagging-Header – Labels, die aus konfigurierten HTTP-Headern jedes Requests extrahiert werden.
- API-Key-Labels – Labels, die an einen verwalteten API-Key gebunden sind und für jeden damit authentifizierten Request gelten.
API-Key-Labels
Weisen Sie Labels zu, wenn Sie im Admin-Dashboard einen Key erstellen:API Keys -> Create API Key -> Labels

API Keys -> Edit Labels) oder über die Admin API:
[], um alle Labels zu entfernen.
Änderungen gelten für neue Requests sofort auf der Instanz, die die
Aktualisierung verarbeitet hat, und auf anderen Replikaten innerhalb von etwa
einer Minute (Keys werden im Hintergrund aus dem Speicher aktualisiert).
Tagging-Header
Tagging-Regeln benennen Header, deren Werte Labels enthalten. Verwalten Sie sie im Dashboard (Settings -> Tagging based on headers) oder deklarieren Sie sie
als Infrastructure as Code:

X-Team), legen Sie optional ein zu entfernendes Präfix und ein
Trennzeichen fest und klicken Sie dann auf Save Tagging Settings. Aktivieren
Sie Do not pass upstream für Header, die entfernt werden sollen, bevor der
Request den Provider erreicht.
config.yaml
config.yaml oder per Umgebungsvariable deklarierte Regeln sind im
Dashboard schreibgeschützt. Header mit Zugangsdaten (Authorization, Cookie,
API-Key-Header) werden als Tagging-Quellen abgelehnt.
do_not_pass entfernt den Header vor der Weiterleitung auf Passthrough- und
Realtime-Routen; übersetzte Routen leiten Client-Header ohnehin nie weiter.
LiteLLM-Tags
Für LiteLLM geschriebene Clients behalten ihre Tags ohne jede Konfiguration. GoModel liest sie als Labels aus:- dem Header
x-litellm-tags(kommagetrennt, ebenso wie eintags-String); - einem Feld
tagsim Body von/v1/chat/completions,/v1/responses,/v1/messagesund/v1/embeddings; metadata.tagsin diesen Bodys, sofern es eine Liste ist.
tags, und die Werte in
metadata müssen Strings sein. Andere metadata-Keys werden durchgereicht,
und ein String in metadata.tags bleibt als gewöhnliche OpenAI-Metadaten
unverändert. Audit-Logs speichern den Body so, wie der Client ihn gesendet hat.
Ein Request steuert höchstens 32 unterschiedliche Tags bei, gezählt über
den Header und beide Body-Felder in dieser Reihenfolge; der Rest wird
verworfen. Tags mit mehr als 128 Zeichen werden verworfen, nicht gekürzt.
Verworfene Tags werden trotzdem entfernt, bevor der Request den Provider
erreicht.
LiteLLM-Tags sind standardmäßig aktiviert. Schalten Sie sie so ab:
config.yaml
tags ablehnt, gibt seinen Fehler zurück.
Wo Labels erscheinen
- Nutzungs-Dashboard – die Nutzungsseite zeigt eine Aufschlüsselung nach
Label (
GET /admin/usage/labels). Ein Request mit mehreren Labels zählt einmal unter jedem davon. - Request-Log – Label-Chips pro Request, filterbar mit dem Query-Parameter
labelbeiGET /admin/usage/log. - Audit-Logs – erfasst unter
data.labelsin jedem Eintrag (Audit-Logging ist standardmäßig aktiviert). - Seite API Keys – die Labels jedes Keys werden neben seinem User Path aufgeführt.
- Budgets – ein Budget kann auf ein Label beschränkt werden und begrenzt dann die Ausgaben aller Requests mit diesem Label. Siehe Budgets.