AxonHub: ein Go-Gateway, das OpenAI- und Anthropic-SDKs gegeneinander übersetzt

Welches Problem AxonHub adressiert

Eine Anwendung, die gegen die OpenAI-API geschrieben ist, lässt sich nicht ohne Weiteres auf Claude umstellen. Die SDKs unterscheiden sich in Nachrichtenformat, Rollenmodell, Streaming-Events und Fehlercodes. Wer mehrere Anbieter parallel nutzen will, schreibt entweder Adapter für jeden davon oder akzeptiert, dass die Anwendung an genau einen Anbieter gebunden bleibt. AxonHub setzt an dieser Stelle an: Der Gateway nimmt die Anfrage in der Form entgegen, die das verwendete SDK sendet, und wandelt sie in das Format des Zielanbieters um. Das README formuliert das als Ziel, mit dem OpenAI SDK Claude aufzurufen oder mit dem Anthropic SDK GPT, jeweils ohne Codeänderung.

Die Zielgruppe lässt sich aus den Themen des Repositories ablesen: agent, agents, claude-code, codex, opencode. Es geht also weniger um eine einzelne Chat-Anwendung als um Werkzeuge, die selbst schon einen API-Client mitbringen und deren Endpunkt man per Umgebungsvariable umbiegen kann. Dazu kommt der Betriebsaspekt: Failover, Lastverteilung, Ausgabenkontrolle und Tracing sind Dinge, die man in jedem Projekt neu baut, wenn kein Gateway davorsteht.

Protokollübersetzung als Kern, Kanäle als Routing-Einheit

Die Architektur besteht laut Repository aus zwei Teilen: dem Gateway, das Anfragen annimmt und umschreibt, und einer Verwaltungsoberfläche, über die Kanäle, Modelle, Nutzer und Kosten konfiguriert werden. Ein Kanal ist dabei die Einheit, die einen Anbieterzugang beschreibt, also Endpunkt, Zugangsdaten und die dahinter verfügbaren Modelle. Das Load-Balancing und das Failover arbeiten auf dieser Ebene: Ist ein Kanal nicht erreichbar, wird die Anfrage auf einen anderen Kanal mit passendem Modell umgeleitet.

Das Tracing ist als Thread-Ebene beschrieben, das heißt, zusammengehörige Aufrufe werden über eine gemeinsame Kennung verknüpft und als Zeitlinie dargestellt. Für Agenten, die in mehreren Schritten Werkzeuge aufrufen, ist das der praktischere Zuschnitt als ein flaches Request-Log. Die Kostenverfolgung erfasst laut Feature-Tabelle Eingabe-, Ausgabe- und Cache-Token getrennt. Das ist die Voraussetzung dafür, dass eine Budgetgrenze überhaupt sinnvoll greifen kann, denn Cache-Token werden von den Anbietern anders bepreist.

Eine Einschränkung steckt in der Natur der Sache: Übersetzung zwischen zwei Protokollen ist verlustbehaftet, sobald ein Anbieter Felder kennt, die der andere nicht hat. Wer anbieterspezifische Parameter nutzt, sollte damit rechnen, dass sie auf der anderen Seite nicht ankommen.

Inbetriebnahme: Container, SQLite oder PostgreSQL

Das Repository liefert ein Dockerfile und eine docker-compose-Datei. Der übliche Weg ist, den Container mit einem Volume für die Datenbank zu starten und die Verwaltungsoberfläche anschließend im Browser aufzurufen. Für den Datenbankzugriff nennt das Projekt zwei Varianten: SQLite für den schnellen Einstieg, PostgreSQL für den Mehrbenutzerbetrieb. Die genauen Umgebungsvariablen stehen in der Konfigurationsdokumentation; im README selbst sind sie nicht ausgeschrieben, und ich habe sie nicht verifiziert.

Der Ablauf danach ist in der Oberfläche angesiedelt: Anbieterzugänge als Kanäle anlegen, Modelle zuordnen, einen API-Schlüssel für die eigene Anwendung erzeugen. Die Anwendung zeigt dann auf den Gateway statt auf den Anbieter. Der Hinweis, dass die Änderung nur in der Konfiguration liegt, ist der Kern des Versprechens. Für Coding-Agents bedeutet das konkret, die Basis-URL und den Schlüssel in der jeweiligen Werkzeugkonfiguration zu ersetzen.

Wer die Kostenverfolgung nutzen will, muss die Preisangaben der Modelle hinterlegen. Ohne gepflegte Preise bleiben die Auswertungen leer. Das ist kein Fehler, sondern eine bewusste Entscheidung: Preise ändern sich, und ein Gateway, das sie fest eingebaut hat, wäre schnell falsch.

Der unstable-Branch und was Beta hier bedeutet

Der Standardbranch des Repositories heißt unstable. Das ist eine Aussage über die Erwartung an die Stabilität, und sie deckt sich mit der Versionsnummer: Die letzten Releases tragen die Kennung v1.0.0-beta8 bis v1.0.0-beta10, veröffentlicht im Abstand von wenigen Tagen Anfang September 2026. Eine so kurze Taktfolge spricht für aktive Arbeit, aber auch dafür, dass sich Details zwischen zwei Versionen ändern können.

Für den Betrieb heißt das: Ein Upgrade ist kein trivialer Vorgang, solange die Beta-Phase läuft. Wer AxonHub einsetzt, sollte die Version pinnen und vor dem Wechsel die Release Notes lesen. Besonders bei einem Gateway, das Zugangsdaten für mehrere Anbieter verwaltet, ist ein ungeplanter Wechsel unangenehm.

Ein zweiter Punkt betrifft die Lizenz. Die Metadaten melden NOASSERTION, das heißt, die automatische Erkennung konnte keine Standardlizenz zuordnen. Das ist kein Urteil über die Lizenz selbst, aber es bedeutet, dass man die Lizenzdatei im Repository lesen muss, bevor man den Code weiterverbreitet oder in ein Produkt einbettet. Wer AxonHub nur als Container betreibt, hat ein anderes Risiko als jemand, der Teile des Codes übernimmt. Eine rechtliche Bewertung kann dieser Text nicht liefern.

Wo ein Gateway dieser Bauart schadet

Ein Gateway fügt einen Netzwerksprung und einen Übersetzungsschritt hinzu. Bei Streaming-Antworten bedeutet das, dass die Events durch eine weitere Komponente laufen, bevor sie die Anwendung erreichen. Für Werkzeuge, die auf feine Unterschiede im Streaming-Protokoll reagieren, ist das eine zusätzliche Fehlerquelle, und die Fehlersuche verteilt sich auf zwei Stellen statt auf eine.

Schwerer wiegt der Fall, in dem die Anwendung anbieterspezifische Funktionen nutzt, die keine Entsprechung auf der anderen Seite haben. Ein Gateway kann ein Feld nicht übersetzen, das der Zielanbieter nicht kennt. Wer solche Funktionen braucht, ist mit einem direkten SDK-Zugriff besser bedient, weil er dort die Fehlermeldung des Anbieters im Original sieht.

Auch die Kostenverfolgung hat eine Grenze: Sie ist nur so genau wie die hinterlegten Preise und die Zuordnung der Modelle zu den Preisen. Bei Anbietern, die eigene Abrechnungsmodelle verwenden, weicht die Gateway-Rechnung von der Anbieterrechnung ab. Wer die Zahlen für die Buchhaltung braucht, sollte sie gegenprüfen, statt sie zu übernehmen.

Was LiteLLM anders macht

Der naheliegende Vergleich ist LiteLLM, ein Proxy, der ebenfalls viele Anbieter hinter einer OpenAI-kompatiblen Schnittstelle bündelt. Der Unterschied liegt im Ausgangspunkt. LiteLLM ist als Python-Paket gewachsen und in Python-Projekten als Bibliothek nutzbar, ohne dass ein separater Dienst laufen muss. AxonHub ist ein eigenständiger Dienst in Go mit einer Verwaltungsoberfläche und einer Datenbank.

Daraus folgen unterschiedliche Betriebsmodelle. AxonHub lässt sich als Container mit SQLite starten und über die Oberfläche konfigurieren, ohne dass jemand die Konfigurationsdatei anfassen muss. Das ist für Teams angenehm, in denen nicht alle Beteiligten YAML schreiben wollen. LiteLLM lässt sich dagegen in eine bestehende Python-Anwendung einbetten, was den zusätzlichen Netzwerksprung spart. Wer eine reine Python-Umgebung betreibt und keinen separaten Dienst will, hat dort weniger bewegliche Teile.

Für beide gilt: Die Qualität der Übersetzung hängt davon ab, wie sorgfältig die Anbieterunterschiede gepflegt werden. Das ist laufende Arbeit, kein einmaliges Setup.

Wartungsaufwand und Versionierung

Die Release-Historie zeigt drei Beta-Versionen innerhalb von sechs Tagen. Wer diesem Takt folgt, investiert Zeit in Upgrades. Wer ihn ignoriert, arbeitet mit einer Version, für die es möglicherweise keine Fehlerkorrekturen mehr gibt. Ein Mittelweg ist, auf eine feste Version zu setzen und nur bei sicherheitsrelevanten Änderungen zu wechseln.

Hinzu kommt die Pflege der Kanaldaten. Neue Modelle, geänderte Preise, abgelaufene Zugangsdaten: All das liegt in der Gateway-Konfiguration und nicht mehr in der Anwendung. Das verlagert Arbeit, beseitigt sie aber nicht. Der Vorteil ist, dass die Änderung an einer Stelle geschieht und nicht in jedem Agenten separat.

Für die Lizenz gilt weiterhin der Vorbehalt aus dem Lizenzabschnitt: Solange die Metadaten NOASSERTION melden, ist die Datei im Repository die maßgebliche Quelle. Das Repository meldet als letzte Aktivität September 2026 und ist nicht archiviert, es wird also weiterentwickelt. Ob dieser Zustand anhält, lässt sich aus den vorliegenden Angaben nicht ableiten.

Redaktionelles Fazit

Wer mehrere Coding-Agents oder SDKs gegen wechselnde Anbieter laufen lässt und die Routing- und Kostenlogik nicht selbst bauen will, findet in AxonHub ein passendes Stück Infrastruktur. Wer einen stabilen, semantisch versionierten Vertrag für eine Produktionsanwendung braucht, sollte die Beta-Phase abwarten. Vor dem ersten echten Rollout zu prüfen: das Verhalten der installierte Version unter /admin/channels, die tatsächliche Lizenzdatei im Repository und ob der Tracing-Speicherbedarf zur eigenen Aufbewahrungsfrist passt.

Offizielle Quellen

1. Issues
2. looplj/axonhub on GitHub
3. Project website
4. README
5. Releases