brainlid/langchain: LLM-Aufrufe in Elixir-Anwendungen ohne Python-Nebenstapel

Welches Problem die Bibliothek aus Elixir-Sicht löst

Ein Elixir-Dienst, der einen LLM aufrufen soll, stand bisher vor einer unangenehmen Wahl: entweder einen Python- oder Node-Dienst daneben betreiben und über HTTP ansprechen, oder den Aufruf von Hand mit Req gegen die jeweilige Anbieter-API schreiben. Der erste Weg zieht einen zweiten Sprachstapel, eigene Deployment-Artefakte und eine weitere Fehlerquelle in die Infrastruktur. Der zweite Weg ist bei einem einzelnen Anbieter vertretbar, wird aber bei mehreren Anbietern, Streaming, Tool-Aufrufen und Prompt-Caching schnell zu verstreutem Code ohne gemeinsame Abstraktion. Genau diese Lücke adressiert brainlid/langchain: laut README ermöglicht es Elixir-Anwendungen, KI-Dienste und selbst gehostete Modelle einzubinden, und deckt dabei Anthropic Claude, OpenAI, xAI Grok, Google Gemini, Vertex AI, DeepSeek, Ollama, Mistral, Perplexity, Cloudflare Workers AI sowie Bumblebee und ReqLLM ab. Die Zielgruppe sind damit Elixir-Teams, die bereits eine Anwendung mit OTP-Supervision betreiben und den Modellaufruf als weiteren Prozess behandeln wollen, nicht als externen Dienst.

Warum es kein Port von LangChain Python ist

Das README ist an dieser Stelle ungewöhnlich deutlich: Das Projekt strebt keine Parität mit den JavaScript- und Python-Varianten an. Zwei Gründe werden genannt. Erstens sind JavaScript und Python objektorientiert, Elixir ist funktional, und die Autoren wollen kein Design erzwingen, das nicht passt. Zweitens entstanden die JS- und Python-Versionen vor der Zeit konversationeller LLMs und investierten viel Aufwand darin, Gesprächsverlauf zu bewahren, obwohl das Modell ihn noch nicht unterstützte. Diese Arbeit wird hier nicht wiederholt. Für die Bewertung heißt das: Wer aus einem Python-Projekt migriert, findet keine Eins-zu-eins-Entsprechung der Klassen und Ketten. Wer neu anfängt, bekommt dafür einen kleineren Begriffsapparat. Die Abstraktionen sind laut README in Komponenten (Abstraktionen für die Arbeit mit Sprachmodellen plus Implementierungen) und vorgefertigte Chains (strukturierte Zusammenbauten für konkrete Aufgaben) geteilt. Komponenten lassen sich einzeln verwenden, ohne den Rest des Frameworks zu übernehmen.

Anbindung und Konfiguration in der Praxis

Die Installation ist ein normaler Mix-Eintrag mit der Vorgabe Elixir 1.17 oder höher. Das README zeigt `{:langchain, "~> 0.9.0"}` in der deps-Liste, während die letzten veröffentlichten Versionen bei v0.13.1 liegen. Diese Abweichung im Beispiel gegenüber den Release-Tags ist ein Detail, das man beim Kopieren beachten sollte. Die Konfiguration läuft über `config/runtime.exs`, wobei die Bibliothek laut README intern Req für die API-Aufrufe nutzt. Für OpenAI sind die Schlüssel `openai_key` und `openai_org_id`, für Anthropic `:anthropic_key`, für xAI `:xai_api_key`. Secrets lassen sich direkt setzen, über `System.fetch_env!` aus der Umgebung ziehen oder indirekt auflösen, entweder als Tupel `{MyApp.Secrets, :openai_api_key, []}` oder als Funktion `fn -> System.fetch_env!("OPENAI_API_KEY") end`. Das ist der Punkt, an dem die Bibliothek ihre Elixir-Herkunft zeigt: Die Auflösung zur Laufzeit passt zu Releases, bei denen Konfiguration erst beim Start der Anwendung feststeht. Für fly.io nennt das README die konkreten Befehle `fly secrets set OPENAI_API_KEY=...`, `ANTHROPIC_API_KEY` und `XAI_API_KEY`.

Prompt-Caching als Kostenhebel bei langen Eingaben

Das README enthält einen eigenen Abschnitt zu Prompt-Caching und stellt fest, dass ChatGPT, Claude und DeepSeek präfixbasiertes Caching anbieten, was bei längeren Prompts Kosten- und Leistungsvorteile bringen kann. Der Mechanismus dahinter ist bei allen drei Anbietern derselbe: Ein identischer Präfix am Anfang des Prompts wird serverseitig zwischengespeichert, sodass nur der wechselnde Teil neu verarbeitet wird. Für Elixir-Anwendungen ist das relevant, weil Systemanweisungen, Werkzeugbeschreibungen und statische Kontextblöcke typischerweise genau diesen Präfix bilden, während die Nutzerfrage am Ende steht. Die Bibliothek unterstützt das laut README namentlich für DeepSeek und erwähnt die Caching-Fähigkeit im Zusammenhang mit ChatGPT und Claude. Wie die Verdrahtung im Einzelnen aussieht, ob als eigener Parameter pro Anfrage oder als Teil der Nachrichtenstruktur, lässt sich aus dem vorliegenden Material nicht ableiten. Wer das nutzen will, muss die Moduldokumentation auf hexdocs prüfen, bevor er die Prompt-Reihenfolge in der Anwendung festlegt.

Selbst gehostete Modelle und der ReqLLM-Weg

Zwei Einträge in der Anbieterliste verdienen eigene Betrachtung. Bumblebee erlaubt laut README selbst gehostete Modelle über Nx, genannt werden Llama, Mistral und Zephyr. Damit läuft die Inferenz im selben BEAM-Prozess wie die Anwendung, ohne externen API-Aufruf und ohne Datenabfluss an einen Anbieter. Der Preis ist der Betrieb: Modellgewichte, Speicherbedarf und Startzeit liegen dann in der eigenen Verantwortung, und die Bibliothek hilft dabei nicht. Der zweite Eintrag ist ReqLLM, ein Multi-Provider-Adapter über die gleichnamige Bibliothek, der Anthropic, OpenAI, Gemini, Groq, Ollama und AWS Bedrock abdeckt. Das ist insofern bemerkenswert, als die Anbieterliste der Bibliothek dadurch nach oben offen wird: Neue Anbieter müssen nicht im Kern von langchain implementiert werden, solange ReqLLM sie kennt. Für Teams, die mehrere Anbieter vergleichen wollen, ist das der günstigere Weg als für jeden Anbieter einen eigenen Adapter zu pflegen.

Wo die Bibliothek nicht die richtige Wahl ist

Die Lizenzangabe des Repositories lautet NOASSERTION. Das bedeutet, dass die automatische Erkennung keine standardisierte Lizenz identifizieren konnte, und es ist die wichtigste offene Frage vor einem produktiven Einsatz. Wer die Bibliothek in einem kommerziellen Produkt verwendet, muss die LICENSE-Datei im Repository selbst lesen und gegebenenfalls rechtliche Klärung einholen. Eine Aussage über die tatsächlichen Bedingungen lässt sich aus dem vorliegenden Material nicht treffen. Ein zweiter Punkt betrifft die Reife: Die Versionsnummer steht bei v0.13.1, und die letzten Releases v0.12.0, v0.13.0 und v0.13.1 liegen innerhalb weniger Wochen im August 2026. Diese Taktung deutet auf eine Bibliothek in aktiver Bewegung, in der sich APIs zwischen Minor-Versionen verschieben können. Wer eine stabile Oberfläche über Jahre braucht, sollte die Abhängigkeit hinter einer eigenen Fassade kapseln. Drittens: Wer Agenten mit komplexen Graphen, Zustandsmaschinen und Dutzenden Werkzeugen baut, findet hier laut README keine Parität zu den Python-Werkzeugen, und das ist eine bewusste Entscheidung der Autoren, keine Lücke, die sich mit einem Update schließt.

Alternative: eine eigene Req-Schicht

Die naheliegende Alternative ist, auf die Bibliothek zu verzichten und direkt mit Req gegen die Anbieter-APIs zu arbeiten. Der Unterschied liegt nicht in den Bytes auf der Leitung, sondern in der Abstraktion. Eine eigene Req-Schicht bedeutet: volle Kontrolle über Header, Retry-Verhalten, Timeouts und Fehlerform, aber auch die Pflicht, Streaming-Formate, Tool-Aufruf-Schemata und die Unterschiede zwischen Anthropic-, OpenAI- und Gemini-Nachrichtenstrukturen selbst nachzuziehen. brainlid/langchain bündelt genau diese Unterschiede hinter gemeinsamen Komponenten und liefert die Anbieterauswahl über Konfiguration statt über Code. Für ein Projekt mit einem einzigen Anbieter und einem einzigen Aufrufmuster ist die eigene Schicht oft die ehrlichere Wahl, weil sie weniger Code enthält als die Abhängigkeit. Sobald mehrere Anbieter, Prompt-Caching oder lokale Modelle über Bumblebee ins Spiel kommen, kippt das Verhältnis. Die Entscheidung hängt also nicht an der Frage, ob die Bibliothek gut ist, sondern daran, wie viele Anbieter und Aufrufvarianten die Anwendung tatsächlich braucht.

Wartung, Upgrades und was vorher zu prüfen ist

Die Wartungslast liegt bei einer Bibliothek dieser Art an zwei Stellen. Erstens die Anbieter-APIs selbst: Wenn Anthropic oder OpenAI Nachrichtenformate ändern, muss der Adapter nachziehen, und die kurze Release-Folge im August 2026 zeigt, dass das Projekt das tut. Zweitens die eigene Anwendung: Ein Minor-Sprung wie von v0.12.0 auf v0.13.0 kann Konfigurationsschlüssel oder Modulnamen berühren, weshalb die Abhängigkeit in mix.exs mit einer engen Versionsgrenze gepinnt werden sollte, statt automatisch auf die neueste Version zu ziehen. Die Lizenzfrage bleibt der Punkt, der vor jedem Deployment zu klären ist, und zwar durch Lesen der LICENSE-Datei, nicht durch Rückgriff auf die NOASSERTION-Kennzeichnung. Für den Einstieg nennt das README ein separates Demo-Projekt unter github.com/brainlid/langchain_demo, das sich herunterladen und lesen lässt. Das ist der sinnvollste erste Schritt: das Demo-Projekt lokal starten, einen der konfigurierten Anbieter gegen die eigene Umgebung laufen lassen und dabei beobachten, wie sich die Bibliothek bei einem ungültigen Schlüssel oder einer abgebrochenen Verbindung verhält. Erst danach lohnt die Entscheidung über den produktiven Einsatz.

Redaktionelles Fazit

Für Teams, die bereits Elixir und OTP betreiben und LLM-Aufrufe als normale Prozesse behandeln wollen, ist die Bibliothek der passende Einstieg, sofern sie die Lizenzfrage vor dem ersten Produktiv-Deployment klären. Wer tiefe Agenten-Graphen mit Dutzenden Werkzeugen braucht oder eine dokumentierte API-Stabilitätszusage erwartet, sollte zuerst prüfen, ob eine eigene dünne Req-Schicht nicht billiger ist. Vor dem Einsatz würde ich das Verhalten bei abgebrochenen Streams und die tatsächliche Fehlerform der Adapter in einem Wegwerf-Projekt nachstellen, statt mich auf die Modulbeschreibungen zu verlassen.

Offizielle Quellen

1. brainlid/langchain on GitHub
2. Issues
3. Project website
4. README
5. Releases