GPT-Load: ein selbst gehostetes Gateway für viele LLM-Zugänge

Welches Problem GPT-Load adressiert

Wer heute mehrere LLM-Anbieter parallel nutzt, kennt das Muster: Für jeden Anbieter existiert ein eigener Schlüssel, oft mehrere pro Anbieter, dazu Abo-Konten mit OAuth statt API-Key. Die Anwendung muss dann je nach Ausfall, Kontingent oder Modell die richtige Basis-URL und den richtigen Schlüssel wählen. GPT-Load setzt genau dort an und verspricht laut README, dass die Anwendung nur eine Basis-URL und einen AccessKey kennen muss. Anbieter, Konten, Zugangsdaten, Modelle und Routing-Regeln werden in einer Verwaltungsoberfläche konfiguriert. Die Zielgruppe sind damit Betreiber, die mehrere Zugänge bündeln und ausfallsicher betreiben wollen, nicht Endanwender mit einem einzigen Schlüssel. Die Themenliste des Repositories nennt ai-gateway, load-balancer und self-hosted, was die Ausrichtung bestätigt.

Ein Mechanismus für API-Keys und Abo-Konten

Die auffälligste Designentscheidung ist, dass API-Schlüssel und Abo-Zugänge dieselbe Verwaltungsschicht teilen. Das README nennt Codex, Claude, Antigravity, Grok und API-Key-Kanäle ausdrücklich als gemeinsam verwaltete Credential-Typen. Für Abo-Kanäle wird ein OAuth-Ablauf beschrieben, für API-Kanäle das Eintragen von Schlüsseln. Beide landen anschließend im selben Scheduling- und Health-Mechanismus. Das ist praktisch, weil ein Team nicht zwei getrennte Werkzeuge pflegen muss. Es ist aber auch ein Hinweis darauf, wie stark das Projekt an den konkreten OAuth-Clients der Anbieter hängt. Wer einen Anbieter ohne OAuth nutzt, bleibt auf der API-Key-Schiene, die weniger bewegliche Teile hat.

Scheduling, Cooldown und Session-Affinität

Das README beschreibt Multi-Credential-Scheduling mit konfigurierbaren Gewichten, Retries, Cooldown, Blacklisting und Session-Affinität. Diese Begriffe stehen im Text, konkrete Standardwerte oder Formeln nennt das Material nicht. Wer plant, einen Kanal mit mehreren Schlüsseln zu betreiben, sollte deshalb in der Oberfläche selbst nachsehen, welche Gewichte und Cooldown-Zeiten dort einstellbar sind, statt von dokumentierten Defaults auszugehen. Die Session-Affinität ist der interessante Teil: Sie sorgt dafür, dass Folgeanfragen einer Sitzung beim selben Credential landen, was bei Anbietern mit Zwischenspeicherung oder Kontextbindung relevant sein kann. Ob das pro Modell oder pro AccessKey greift, lässt sich aus dem vorliegenden README nicht ableiten.

Betrieb mit Docker Compose

Der Einstieg ist knapp gehalten und setzt Docker sowie Docker Compose voraus. Vier Befehle: git clone --depth 1 https://github.com/tbphp/gpt-load.git, cd gpt-load, cp .env.example .env, docker compose up -d. Der Health-Check erfolgt mit curl --fail http://127.0.0.1:3001/health. Beim ersten Start wird ein Verwaltungsschlüssel erzeugt, den man mit docker compose exec gpt-load sh -c 'cat /app/data/auth.key' ausliest. Alternativ lässt sich AUTH_KEY vor dem Start in der .env-Datei setzen. Standardmäßig lauscht der Dienst nur auf der Loopback-Adresse, ist also nicht aus dem Internet erreichbar. Die Konfiguration läuft danach in drei Schritten: Kanal anlegen, Gruppe mit Modellen und Laufzeitregeln erstellen, AccessKey mit erlaubten Gruppen und Client-Protokollen erzeugen. Als Datenbanken nennt das README SQLite, MySQL und PostgreSQL. Zugangsdaten werden lokal verschlüsselt abgelegt, das genaue Verfahren beschreibt das Material nicht.

Feste OAuth-Ports als harte Randbedingung

Die OAuth-Clients von Codex, Claude und Antigravity nutzen feste Callback-Ports. Compose veröffentlicht diese Ports auf der Adresse, die HOST konfiguriert, standardmäßig 127.0.0.1. Setzt man HOST=0.0.0.0, werden auch die Callback-Ports auf allen Host-Schnittstellen veröffentlicht. Weil die Ports vom Upstream-Client vorgegeben sind, kann laut README nur eine Default-Compose-Instanz pro Host laufen. Das ist eine echte Einschränkung für alle, die Staging und Produktion auf derselben Maschine betreiben wollen. Dazu kommt ein zweiter Stolperstein: Bei Arbeit über SSH oder einen entfernten Browser erreicht das Browser-localhost den Dienst möglicherweise nicht. Dann muss die vollständige Callback-URL in den Autorisierungsdialog eingefügt werden. Beides sind Punkte, die vor dem Rollout geklärt werden sollten, nicht danach.

Kein In-Place-Upgrade von 1.x

Das README warnt ausdrücklich: Wer 1.x nutzt, muss den Abschnitt Moving from 1.x lesen. Version 2.0 kann Daten aus 1.x weder öffnen noch importieren oder in place migrieren. Ein Migrationswerkzeug wird im vorliegenden Material nicht genannt. Für Bestandsinstallationen bedeutet das einen manuellen Neuaufbau der Konfiguration oder einen separaten Export, dessen Existenz hier nicht belegt ist. Das ist der teuerste Punkt des Upgrades und der wichtigste Grund, den Umstieg nicht spontan in einer laufenden Umgebung zu versuchen. Wer neu startet, hat dieses Problem nicht.

Reifegrad und Release-Situation

Der letzte Push datiert auf den 9. September 2026, das jüngste Release ist v2.0.0-rc.11 vom selben Tag. Die Serie v2.0.0-rc.9 bis rc.11 erschien innerhalb von drei Tagen, was auf eine aktive, aber noch nicht abgeschlossene Stabilisierungsphase hindeutet. Ein Release Candidate ist kein fertiges Release. Wer auf ruhige Wartungsfenster angewiesen ist, sollte den Wechsel auf ein stabiles 2.0 abwarten oder bewusst auf einem RC bleiben und die Release Notes verfolgen. Das Repository ist nicht archiviert, die Lizenz ist MIT. Das Material enthält keine Angaben zu Beitragenden, Testabdeckung oder unterstützten Go-Versionen über den Badge in go.mod hinaus.

Abgrenzung zu gehosteten Routern

Die naheliegende Alternative sind gehostete Router-Dienste, die ebenfalls mehrere Anbieter hinter einer URL bündeln und Schlüssel zentral verwalten. Der Unterschied liegt nicht in der Funktion, sondern in der Datenhoheit: GPT-Load läuft auf eigener Infrastruktur, die Zugangsdaten liegen in der eigenen Datenbank und werden lokal verschlüsselt. Dafür trägt man Betrieb, Backups, Updates und die Verfügbarkeit selbst. Ein gehosteter Router nimmt einem diese Last ab, verlangt aber, dass die Schlüssel beim Anbieter des Routers liegen. Für Teams mit Compliance-Anforderungen an den Speicherort von Credentials ist das der ausschlaggebende Punkt. Für alle anderen ist es eine Frage, ob man Datenbankbetrieb als Teil des eigenen Zuständigkeitsbereichs akzeptiert.

Redaktionelles Fazit

Sinnvoll ist GPT-Load für Teams, die mehrere Anbieterkonten und Abo-Zugänge hinter einer stabilen Basis-URL betreiben und dafür Scheduling, Cooldown und Abrechnung selbst in der Hand behalten wollen. Wer nur einen einzigen API-Schlüssel nutzt oder keine eigene Datenbank betreiben möchte, sollte beim direkten Aufruf des Anbieters bleiben oder zu einem gehosteten Router greifen. Vor dem Produktiveinsatz ist zu prüfen, ob die eigene 1.x-Datenbank überhaupt übernommen werden kann ( Timing: Der Umstieg auf 2.0 funktioniert laut README nicht in place, ein Export-Werkzeug wird dort nicht genannt ) und ob die festen OAuth-Callback-Ports des Codex-, Claude- und Antigravity-Clients auf dem Zielhost frei sind, weil nur eine Default-Compose-Instanz pro Host laufen kann.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. tbphp/gpt-load on GitHub