AuthGate AI Proxy_

Das Problem

Die meisten KI-Tools gehen immer noch davon aus, dass der Client direkt mit jedem Anbieter kommunizieren kann. In der Praxis ist die Oberfläche fragmentiert. Anbieter unterscheiden sich in den Anforderungsformen, Authentifizierungsmodellen, Streaming-Semantiken, Fehlerverträgen und sogar in den Basis-URLs, die die Clients anvisieren sollen.

Das wird schnell schmerzhaft, wenn man einen lokalen Endpunkt will, der über Editoren, Skripte, interne Tools und Agenten-Workflows hinweg funktioniert.

Ich habe AuthGate als lokales Gateway entwickelt, um diese Reibung zu beseitigen.

Was ich gebaut habe

AuthGate bietet einen konsistenten Endpunkt unter localhost:4000 und kümmert sich um die unangenehmen Teile im Hintergrund:

• Übersetzung der anbieter-spezifischen Chat-Payloads in eine lokale Schnittstelle
• Bewahrung des Streaming-Verhaltens über SSE
• Erneuerung von Tokens ohne langfristige Sitzungen zu unterbrechen
• Normalisierung der Fehlerantworten in etwas, mit dem Clients tatsächlich umgehen können

Die interessante Arbeit bestand nicht im Webserver. Es war die Kompatibilitätsschicht. Ein Proxy wie dieser hat nur Erfolg, wenn die Clients vergessen können, welcher Anbieter upstream sitzt.

Warum es wichtig ist

Dieses Projekt handelt wirklich von der lokalen Entwicklererfahrung und der Protokolldisziplin. Wenn ein Tool für jeden Anbieter neu konfiguriert werden muss, oder wenn das Streaming jedes Mal anders funktioniert, bricht die Akzeptanz auseinander. Der Wert von AuthGate liegt darin, dass lokale Tools mehrere Anbieter als eine stabile Grenze behandeln können.

Das macht es nützlich für:

• Editor-Integrationen
• Lokale Agenten-Laufzeiten
• Interne Evaluierungsskripte
• Teams, die über mehrere Modellanbieter experimentieren

Für mich ist es ein starkes Beispiel für sorgfältig durchgeführte Abstraktion: die Schnittstelle vereinfachen, aber die operationale Realität nicht darunter verstecken.