Helicone: Gateway und Observability für LLM-Aufrufe im eigenen Betrieb

Ein Proxy zwischen Anwendung und Modellanbieter

Helicone setzt sich nicht als Bibliothek in den Anwendungscode, sondern als Zwischenschicht vor den Modellaufruf. Im Quick-Start-Beispiel des README ändert sich genau eine Zeile: Die baseURL des OpenAI-Clients zeigt auf https://ai-gateway.helicone.ai, als apiKey dient der Wert aus process.env.HELICONE_API_KEY. Der Aufruf selbst bleibt unverändert, das Modell wird weiterhin als String übergeben, im Beispiel gpt-4o-mini. Der Datenfluss läuft damit über die Helicone-Infrastruktur oder, beim Selbstbetrieb, über den eigenen Worker-Dienst.

Das erklärt, warum das Projekt sich selbst als AI Gateway und Observability-Plattform beschreibt und nicht als SDK. Der Nutzen entsteht an der Netzwerkgrenze: Jede Anfrage passiert einen Punkt, an dem sich Metadaten, Kosten und Latenz abgreifen lassen, ohne dass jeder Aufrufpfad im Code instrumentiert werden muss. Der Preis für dieses Design ist, dass der Proxy ein zusätzlicher Ausfallpunkt ist. Fällt er aus, fallen die Modellaufrufe aus, sofern die Anwendung nicht auf eine direkte baseURL zurückfallen kann.

Die Zielgruppe benennt das README indirekt selbst: AI Engineers, die Agenten, Chatbots und Dokumentenpipelines betreiben. Wer einzelne Skripte mit einem Anbieter schreibt, gewinnt wenig. Wer mehrere Anbieter mischt und Kosten pro Feature zuordnen muss, gewinnt mehr.

Fünf Dienste, die beim Selbstbetrieb mitkommen

Das README listet die Architektur explizit auf. Es sind fünf Komponenten: Web als NextJS-Frontend, Worker als Proxy-Logging auf Cloudflare Workers, Jawn als Express-plus-Tsoa-Server zum Sammeln der Logs, Supabase als Anwendungsdatenbank und Authentifizierung, ClickHouse als Analytikdatenbank sowie Minio als Objektspeicher für Logs. Gezählt werden im README fünf Services, aufgeführt sind sechs Einträge, weil Supabase, ClickHouse und Minio getrennt genannt werden. Diese Unschärfe im Text ist ein kleiner Hinweis darauf, wie stark der Betriebsaufwand von der gewählten Deployment-Variante abhängt.

Die Aufteilung ist inhaltlich nachvollziehbar. ClickHouse trägt die analytischen Abfragen über Kosten und Latenz, für die eine relationale Datenbank mit Zeilenorientierung schnell an Grenzen stößt. Minio nimmt die Rohlogs auf, die nicht in die Analytikdatenbank gehören. Supabase liefert Auth und Anwendungszustand. Das sind drei verschiedene Speicher- und Konsistenzmodelle in einem Stack, und genau daraus entsteht der Betriebsaufwand: Backups, Upgrades und Ausfallverhalten müssen für alle drei getrennt betrachtet werden.

Wer Helicone selbst hostet, betreibt damit faktisch eine kleine Datenplattform. Das ist keine Kritik an der Architektur, sondern eine Konsequenz daraus, dass Observability-Daten ein anderes Zugriffsmuster haben als Anwendungsdaten.

Installation über docker-compose und was danach fehlt

Der README gibt für den lokalen Einstieg einen konkreten Ablauf vor. Zuerst wird das Repository geklont und in das Verzeichnis docker gewechselt, dann wird .env.example nach .env kopiert, anschließend startet ./helicone-compose.sh helicone up die Dienste. Für Produktionslast verweist das README auf ein Helm-Chart, das nicht im Repository liegt, sondern per E-Mail an enterprise@helicone.ai angefordert werden muss. Eine manuelle Installation wird ausdrücklich nicht empfohlen, mit Verweis auf eine separate Dokumentationsseite.

Diese Verteilung ist der wichtigste praktische Punkt. Der quelloffene Pfad führt über Docker und ist damit reproduzierbar. Der produktionsnahe Pfad führt über ein Chart, das an eine Kontaktaufnahme gebunden ist. Wer Helicone ausschließlich selbst betreiben und keine Vertragsbeziehung eingehen will, muss also klären, ob das Chart ohne diese Beziehung erhältlich ist. Aus dem vorliegenden Material geht das nicht hervor, und die Dokumentation zum Selbst-Deployment wurde hier nicht eingesehen.

Ebenso offen bleibt, welche Werte in .env tatsächlich gesetzt werden müssen. Der README nennt die Datei, aber keine Schlüssel. Wer den Selbstbetrieb plant, sollte die verlinkte Seite zum Docker-Deployment lesen, bevor der Aufwand eingeschätzt wird.

Kosten, Sessions und Prompt-Versionierung als eigentliche Funktionen

Der Kern des Produkts liegt nicht im Weiterleiten, sondern in der Auswertung. Das README nennt Kosten- und Latenzverfolgung, Sessions zum Debuggen von Agenten und Chatbots, Qualitätsmetriken sowie einen Export nach PostHog, der laut README mit einer Zeile auskommt. Die Kostenberechnung wird in einem eigenen FAQ-Abschnitt behandelt, was darauf hindeutet, dass sie modellabhängig ist und nicht einfach aus Token-Zahlen folgt.

Bemerkenswert ist die Prompt-Verwaltung. Prompts lassen sich versionieren, und laut README werden sie über das Gateway deployt, ohne dass Code geändert werden muss. Der Text hält ausdrücklich fest, dass die Prompts unter eigener Kontrolle bleiben und jederzeit zugänglich sind. Das ist eine direkte Antwort auf die Sorge, die bei gehosteten Prompt-Tools naheliegt: dass der Prompt-Bestand im Tool gefangen ist. Ob diese Zusicherung auch für den Selbstbetrieb in vollem Umfang gilt, lässt sich aus dem Material nicht ableiten.

Der Playground dient dem Testen von Prompts, Sessions und Traces in der Oberfläche. Zusammen mit den Datasets und dem Verweis auf Fine-Tuning-Partner OpenPipe und Autonomi ergibt das einen Arbeitsablauf, der von der Beobachtung über die Änderung bis zum erneuten Test reicht. Wer diesen Kreislauf nicht braucht, nutzt einen großen Teil des Funktionsumfangs nicht.

Wo Helicone das falsche Werkzeug ist

Der Proxy-Ansatz hat eine klare Grenze: Er sieht nur, was durch ihn hindurchgeht. Modellaufrufe, die direkt an einen Anbieter gehen, etwa aus einem Cronjob, einem Notebook oder einem fremden Dienst, tauchen nicht auf. Die Kostenübersicht ist damit nur so vollständig wie die Disziplin, mit der alle Aufrufpfade auf die Gateway-baseURL umgestellt wurden. Das README nennt für nicht abgedeckte Fälle asynchrones Logging über OpenLLMetry für JS/TS und Python, aber diese Integrationsmethode steht im README in einer Zeile, die offensichtlich fehlerhaft formatiert ist: Der Python-Verweis zeigt auf das npm-Paket @helicone/helicone. Wer diesen Weg plant, muss die Dokumentation prüfen, nicht die Tabelle.

Ein zweiter Fall: Wer bereits eine vollständige Tracing-Pipeline für Anwendungen außerhalb von LLMs betreibt, baut mit Helicone eine zweite Beobachtungsschicht daneben. Die Verknüpfung zwischen einem HTTP-Request und einem LLM-Aufruf muss dann manuell hergestellt werden, etwa über Session-IDs, die das README als Feature nennt, aber nicht in ihrer Herkunft erklärt.

Drittens ist der Selbstbetrieb für kleine Teams oft unverhältnismäßig. Fünf Dienste, drei davon mit eigenem Zustand, bedeuten Betriebsarbeit, die in keinem Verhältnis zum Nutzen steht, wenn nur ein Anbieter und wenige hundert Aufrufe pro Tag anfallen.

Langfuse als Alternative mit anderem Ansatz

Langfuse ist ein weiteres quelloffenes Observability-Werkzeug für LLMs und verfolgt einen anderen Integrationsweg: Tracing über SDKs und OpenTelemetry statt über einen Proxy vor dem Anbieter. Der Unterschied ist nicht kosmetisch. Beim SDK-Ansatz bleibt der Modellaufruf direkt beim Anbieter, und die Instrumentierung sitzt im Anwendungscode. Beim Proxy-Ansatz bleibt der Anwendungscode fast unverändert, dafür läuft der Verkehr über eine fremde Komponente.

Für die Fehlersuche ist das relevant. Ein SDK kann Spans über Funktionsgrenzen hinweg verschachteln und auch Nicht-LLM-Arbeit sichtbar machen. Ein Proxy sieht genau einen HTTP-Aufruf und dessen Antwort. Helicone begegnet dem teilweise mit Sessions und Agent-Tracing, aber die Granularität hängt davon ab, was die Anwendung zusätzlich meldet.

Umgekehrt hat der Proxy einen Vorteil, den ein SDK nicht hat: Er kann Anfragen umleiten. Das README nennt intelligentes Routing und automatische Fallbacks über mehr als 100 Modelle hinweg. Wer Anbieter wechseln oder Ausfälle abfedern will, bekommt das ohne Codeänderung. Langfuse ist in dieser Hinsicht ein Beobachtungswerkzeug, Helicone zusätzlich ein Vermittler. Die Wahl hängt davon ab, ob man die Verkehrsführung abgeben will.

Lizenz, Wartung und Aktualisierung

Helicone steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Änderung und Weitergabe, verlangt aber die Beibehaltung von Copyright- und Lizenzhinweisen und enthält eine ausdrückliche Patentgewährung sowie eine Beendigungsklausel bei Patentstreitigkeiten. Was Apache-2.0 nicht regelt, ist der Betrieb: Wer eine geänderte Version als Dienst anbietet, muss keine Änderungen offenlegen. Das ist ein Unterschied zu Copyleft-Lizenzen und für viele Teams der Grund, Apache-2.0 zu wählen. Rechtsberatung ist das nicht, und die endgültige Bewertung gehört zu einer Rechtsabteilung.

Zur Wartung lässt sich aus dem Material nur wenig Belastbares sagen. Die letzten Releases liegen dicht beieinander: v2025.08.20, v2025.08.21 und v2025.08.21-1, alle im August 2025. Ein Release mit dem Suffix -1 am selben Tag deutet auf eine Korrektur direkt nach der Veröffentlichung hin. Das Muster spricht für häufige, kleine Veröffentlichungen, was beim Selbstbetrieb bedeutet, dass Upgrade-Pfade regelmäßig geprüft werden müssen. Ob es dokumentierte Migrationsschritte zwischen Versionen gibt, geht aus dem vorliegenden Material nicht hervor.

Ein Kostenfaktor, der leicht übersehen wird: ClickHouse und Minio wachsen mit dem Logvolumen. Wer Rohlogs dauerhaft in Minio behält, muss eine Aufbewahrungsstrategie festlegen, und die gehört in die eigene Konfiguration, nicht in das Projekt.

Für wen sich der Aufwand lohnt

Die Entscheidung hängt an zwei Fragen. Erstens: Laufen die Modellaufrufe über mehrere Anbieter oder sollen sie es künftig? Wenn ja, ist der Gateway-Ansatz mit automatischen Fallbacks ein Argument, das ein reines Tracing-SDK nicht liefert. Zweitens: Ist der Selbstbetrieb eine Anforderung oder eine Präferenz? Wenn Prompt-Inhalte das eigene Netzwerk nicht verlassen dürfen, bleibt nur der Selbstbetrieb, und dann sind ClickHouse, Supabase und Minio Teil des Deals.

Wer die gehostete Variante nutzt, sollte vor dem Rollout klären, welche Daten das Gateway speichert und wie lange. Das README nennt SOC 2 und GDPR-Konformität, ohne Details zu Aufbewahrungsfristen oder Datenstandorten. Der kostenlose Tarif umfasst laut README 10.000 Anfragen pro Monat ohne Kreditkarte, was für einen Test ausreicht, aber keine Aussage über Produktionslast erlaubt.

Wer nur einen Anbieter nutzt, wenige Aufrufe hat und bereits Logs in einer bestehenden Plattform sammelt, findet hier mehr Betriebsfläche als Nutzen. Wer dagegen Prompt-Versionierung, Kostenaufteilung pro Feature und Routing zwischen Anbietern in einem System braucht, hat im Repository eine nachvollziehbare Grundlage, um den Selbstbetrieb zu evaluieren.

Redaktionelles Fazit

Wer LLM-Aufrufe zentral protokollieren und mehrere Anbieter hinter einer Schnittstelle bündeln will, findet in Helicone ein Apache-2.0-lizenziertes System, dessen Selbstbetrieb jedoch ClickHouse, Supabase und Minio mitbringt. Wer ausschließlich Tracing für einen einzelnen Anbieter braucht, sollte zuerst prüfen, ob die eigene Infrastruktur diese fünf Dienste überhaupt rechtfertigt. Vor dem Rollout ist zu klären, ob die Weitergabe der Prompt-Inhalte an eine gehostete Instanz datenschutzrechtlich zulässig ist und ob das Helm-Chart, das der README nur auf Anfrage per E-Mail nennt, ohne Vertragsbeziehung verfügbar ist.

Offizielle Quellen

1. Helicone/helicone on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases