Provider-Keys in Grepture
Grepture laesst Sie Ihre LLM-Provider-API-Keys jetzt direkt im Dashboard speichern. OpenAI, Anthropic, Gemini, Azure — fuegen Sie so viele Keys hinzu, wie Sie brauchen, fuer so viele Provider, wie Sie nutzen.
Jeder Key wird vor der Speicherung mit AES-256-GCM verschluesselt. Nur die letzten vier Zeichen sind im Dashboard sichtbar. Der Proxy entschluesselt Keys zur Laufzeit im Arbeitsspeicher — Klartext erreicht nie den Cache oder die Logs.
Sobald Ihre Keys gespeichert sind, nutzt der Proxy sie automatisch. Kein X-Grepture-Auth-Forward-Header noetig. Ihr SDK-Setup bleibt gleich — der Proxy loest den richtigen Key fuer den richtigen Provider auf.
Same-Provider-Fallback
Fuegen Sie mehrere Keys fuer denselben Provider hinzu. Setzen Sie einen als primaer. Verknuepfen Sie die restlichen als Fallbacks.
Wenn der primaere Key ein Rate-Limit erreicht (429), versucht der Proxy automatisch den naechsten Key. Wenn ein Key einen Auth-Fehler zurueckgibt (401) — vielleicht wurde er widerrufen oder ist abgelaufen — geht der Proxy weiter. Genauso bei Timeouts (408) und Server-Fehlern (5xx).
Das ist nuetzlich fuer Teams, die API-Nutzung auf mehrere Keys verteilen, um unter Rate-Limits zu bleiben, oder Teams, die Backup-Keys fuer Redundanz vorhalten.
Cross-Provider-Fallback
Hier wird es interessant. Ein Fallback-Key muss nicht vom selben Provider sein.
Ihr OpenAI-Key kann auf einen Anthropic-Key zurueckfallen. Wenn OpenAI komplett ausfaellt — jeder Key liefert 5xx — wechselt der Proxy automatisch zu Anthropic. Er uebersetzt den Request vom OpenAI-Chat-Completions-Format ins Anthropic-Messages-Format, sendet ihn und uebersetzt die Antwort zurueck.
Ihre Anwendung erhaelt eine OpenAI-formatierte Antwort. Sie weiss nie, dass der Request von Anthropic bedient wurde.
Cross-Provider-Fallback erfordert ein default_model auf dem Fallback-Key (damit der Proxy weiss, welches Modell er ansprechen soll) und verarbeitet Tool-Calls und Standard-Nachrichtenformate. Bild-Eingaben ueberspringen die Cross-Provider-Uebersetzung, da sich die Formate zu stark unterscheiden.
Was Fallback ausloest
Nicht jeder Fehler sollte einen Retry ausloesen. Grepture ist selektiv:
- 401 — Key widerrufen oder ungueltig. Ein anderer Key koennte funktionieren.
- 408 — Upstream-Timeout. Ein Retry lohnt sich.
- 429 — Rate-Limit. Ein anderer Key hat sein eigenes Kontingent.
- 5xx — Server-Fehler. Der Provider hat Probleme.
Diese loesen Fallback aus. Aber:
- 400 — Fehlerhafter Request. Ihr Payload ist fehlformatiert. Ein Retry mit einem anderen Key behebt das nicht.
- 403 — Content-Policy-Verletzung. Key-spezifisch, ein Wechsel hilft nicht.
- 404 — Modell oder Endpunkt nicht gefunden.
Wenn der Fehler Ihr Bug ist, teilt der Proxy das sofort mit, anstatt Zeit mit Retries zu verschwenden.
Streaming-Einschraenkung
Ein wichtiges Detail: Sobald eine Streaming-Antwort begonnen hat, Daten an Ihre Anwendung zu senden (Header gesendet, Chunks fliessen), kann der Proxy nicht erneut versuchen. Die Verbindung ist festgelegt.
Fallback funktioniert fuer Fehler, die vor dem Streaming-Start auftreten — der Upstream liefert eine gepufferte Fehlerantwort, und der Proxy versucht es transparent erneut. Das deckt die grosse Mehrheit der Faelle ab: Auth-Fehler, Rate-Limits und Server-Fehler treten alle vor Streaming-Beginn auf.
Volle Trace-Sichtbarkeit
Jeder Fallback-Versuch erscheint im Dashboard. Sie sehen die vollstaendige Kette: welcher Key versucht wurde, welcher Fehler zurueckkam, welcher Provider den Request letztlich bedient hat.
Das bedeutet, Sie koennen Fragen beantworten wie: „Wie oft wird unser primaerer OpenAI-Key rate-limitiert?" und „Welcher Prozentsatz der Requests wird von unserem Anthropic-Fallback bedient?"
Die provider_key_id wird bei jedem Request protokolliert, sodass Sie Per-Key-Analytik sofort nutzen koennen.
Funktioniert mit Zero-Data-Modus
Provider-Fallback ist vollstaendig kompatibel mit dem Zero-Data-Modus. Der Proxy liest Request-Inhalte im Arbeitsspeicher, um zwischen Provider-Formaten zu uebersetzen, aber nichts wird auf die Festplatte geschrieben. Sie erhalten dieselbe Fallback-Resilienz mit denselben Datenschutz-Garantien.
Erste Schritte
- Gehen Sie zu Einstellungen > API > Provider Keys im Grepture-Dashboard
- Fuegen Sie Ihre Provider-Keys hinzu (OpenAI, Anthropic, Gemini, Azure)
- Richten Sie Fallback-Ketten ein — verknuepfen Sie Keys in der gewuenschten Reihenfolge
- Das war's. Der Proxy uebernimmt den Rest.
Ihre bestehende SDK-Integration aendert sich nicht. Der Proxy loest Keys auf und verwaltet Fallback transparent.
Details finden Sie auf der Routing-Produktseite oder in der Konfigurationsdokumentation.