100 Queries, 100 Runs, identisches Modell GPT-4.1-mini, identische Embeddings, identischer Retriever. Im AImultiple-Benchmark von 2025 erzeugt LangChain 2,40k Token pro Query. Haystack: 1,57k. LlamaIndex: 1,60k. Das sind 53 Prozent mehr Token-Overhead bei einer Aufgabe, in der nichts variiert außer dem Framework. Die reine Framework-Latenz misst die Studie ebenfalls: LangChain 10 Millisekunden, Haystack 5,9, LangGraph 14.
Diese Zahl liest sich erstmal wie ein Ranking. Sie ist eigentlich ein Datum. Sie markiert den Punkt, an dem LangChain aufhörte, ein Beschleuniger zu sein, und zu technischer Schuld wurde.
LangChain wurde gross, weil die APIs primitiv waren
Erinnere dich, wie der Stand 2022 war. OpenAIs Chat-Completion-API hatte keine Tool-Calls, keine Structured Outputs, kein Streaming-of-Tools, keinen nativen Retrieval-Mechanismus. Wer einen Agenten bauen wollte, der ein Tool aufruft, eine Antwort verarbeitet und einen weiteren Schritt plant, musste die Logik komplett selbst schreiben: Prompt-Templates, Output-Parser, Memory, Tool-Routing, Retry-Loops. Genau dafür ist LangChain entstanden. Das Framework hat aus zehn rohen API-Bausteinen ein zusammenhängendes Programmiermodell gemacht, und es hat tausende Entwickler in die Lage versetzt, in einem Wochenende einen Agent-Prototyp zu bauen, der vorher Wochen gedauert hätte.
Das Problem 2026 ist, dass die Anbieter-SDKs genau diese Schicht selbst bekommen haben. Das OpenAI Agents SDK, erschienen im März 2025, liefert Handoff zwischen Agenten, Guardrails, Tracing und MCP-Integration nativ. Das Claude Agent SDK, erschienen im September 2025, bringt Extended Thinking, Tool-Calls und Memory-Primitive direkt in den Client. Was LangChain als Framework-Mehrwert verkauft hat, ist 2026 in zwanzig Zeilen offiziellem SDK-Code abrufbar. Ohne den 53-Prozent-Overhead.
Was Octomind 12 Monate später gelernt hat
Die Engineering-Notiz von Octomind vom 13. Juni 2024 gehört zu den meistgelesenen Texten zu diesem Thema, und sie ist immer noch gültig. Octomind ist ein Münchner KI-Testing-Startup, das KI-Agenten für Playwright-Tests baut. Zwölf Monate liefen ihre Produktions-Agenten auf LangChain. Im Juni 2024 wurde migriert: weg vom Framework, hin zu direkten LLM-Client-Aufrufen.
Der Auslöser war keine Performance-Frage. Der Auslöser war Debugging-Zeit. In den Worten des Teams: Die Stunden, die in das Verstehen von LangChain-Internas flossen, hatten die Stunden für eigene Feature-Entwicklung erreicht. Konkret blockierte LangChains Abstraktion drei Dinge, die Octomind in Produktion brauchte: dynamische Tool-Availability (Tools, die je nach Zustand verschwinden oder auftauchen), externes Monitoring des Agent-States (für Observability) und Sub-Agenten-Spawning aus laufenden Agenten heraus.
Jede einzelne dieser Anforderungen lässt sich gegen einen rohen API-Client direkt schreiben. In LangChain musste das Team an mehreren Stellen Wrapper auspacken, vererben, monkeypatchen. Das ist die strukturelle Form, in der ein Framework von Beschleuniger zu Reibung kippt: Wenn deine Anforderungen über das hinausgehen, wofür die Abstraktion gebaut wurde, zahlst du den Preis der Abstraktion plus den Preis, sie zu umgehen.
Die MCP-Zahlen, die zeigen, wohin die Schicht wandert
Wer messen will, wie schnell sich der Standard-Layer für Agent-Tools verschiebt, schaut auf MCP. Das Model Context Protocol ist der Provider-übergreifende Mechanismus, mit dem Agenten Tools, Daten und Services anbinden. Es besetzt den Layer, den LangChain mit Tools und Toolkits historisch innehatte. Laut mcpmanager.ai (April 2026) ist der Katalog von 1.200 Servern in Q1 2025 auf über 9.400 in April 2026 gewachsen. Das ist ein Wachstum von rund 18 Prozent pro Monat.
Wichtiger als die absolute Zahl ist der Adoptionspfad. In einer CTO-Befragung aus Q1 2026 (zitiert auf mcpmanager.ai) nennen 67 Prozent MCP als künftigen Standard für Agent-Tool-Integration. Nicht „eine Option”, sondern „den Standard”. OpenAI, Anthropic, Google und Microsoft haben MCP zu unterschiedlichen Zeitpunkten in 2025 nativ in ihre Plattformen aufgenommen. Was bedeutet: Wenn du heute ein Tool gegen LangChains Tool-Abstraktion schreibst, schreibst du gegen ein zweites, paralleles Schema neben dem Schema, das die Anbieter selbst gerade kanonisieren.
Auf dieser Linie ergibt es Sinn, was LangGraph als überlebensfähigen Teil der LangChain-Welt unterscheidet. LangGraph ist eine State-Machine für Multi-Agent-Graphen mit Checkpointing. Dafür gibt es bei OpenAI und Anthropic kein direktes Pendant. Wer komplexe, persistente Agent-Workflows mit Verzweigung, Replay und Human-in-the-Loop braucht, hat in LangGraph eine echte Schicht in der Hand. Alles unterhalb davon (die klassische LangChain-Abstraktion über LLM-Aufrufe, Prompt-Templates, Tool-Routing, simples Memory) ist der Teil, der gerade in die Anbieter-SDKs absorbiert wird.
Das Lock-in-Argument, und warum es 2026 bricht
Das gängige Gegenargument für LangChain in 2026 lautet: Du vermeidest damit Provider-Lock-in. Wenn du deinen Agenten gegen die LangChain-Abstraktion schreibst, kannst du morgen von OpenAI zu Anthropic wechseln, ohne deinen Code anzufassen. Dazu kommt LangSmith, das im LLMOps-Markt für Observability, Evaluation und Prompt-Versionierung weiterhin marktführend ist.
Beide Punkte stimmen abstrakt. In der konkreten Praxis brechen sie an einer überraschenden Stelle: dem Caching-Layer.
Anthropic Prompt Caching reduziert die Input-Token-Kosten um bis zu 90 Prozent, indem cache_control-Marker im Message-Objekt das Modell dazu bringen, einen Prefix wiederzuverwenden. Das funktioniert nur bei Anthropic. Andere Anbieter kennen den Marker nicht und schlagen mit Validierungsfehler fehl, wenn er auftaucht.
LangChain liefert dafür AnthropicPromptCachingMiddleware. Genau dort sitzt der Bug, der das Lock-in-Argument zerlegt. Im LangChain GitHub Issue #33709 vom Oktober 2024 ist dokumentiert: Wenn deine Pipeline einen Fallback auf ein Nicht-Anthropic-Modell hat (genau das Szenario, für das du angeblich LangChain einsetzt), dann bleiben die cache_control-Marker im Message-Objekt, das die Middleware injiziert hat. Der Fallback-Aufruf scheitert. Der Workaround unsupported_model_behavior='ignore' löst es nicht. Das Issue ist offen, der Marker bleibt im Objekt.
Wer Prompt Caching mit echtem Provider-Fallback kombinieren will, muss in der LangChain-Variante die Middleware deaktivieren und den Caching-Layer manuell schreiben. Ab diesem Punkt ist der Abstraktionsvorteil exakt null. Du hast die Komplexität von LangChain plus die Komplexität, deine Caching-Logik selbst zu schreiben. Genau das wolltest du mit dem Framework vermeiden.
LangSmith bleibt davon unberührt. Wer Observability und Evaluation ernst nimmt, kann LangSmith ohne LangChain einsetzen. Die SDK-Bibliothek langsmith funktioniert als reiner Tracing-Client gegen jeden LLM-Anbieter. Das ist die saubere Trennung: Observability ja, Framework nein.
Was du jetzt anders machen solltest
Direkte SDKs für alles unter dem Multi-Agent-Graphen. Das OpenAI Agents SDK und das Claude Agent SDK liefern die 80 Prozent, für die LangChain historisch zuständig war: Tool-Calls, Handoff, Guardrails, Tracing, MCP-Anbindung. Wer einen Single-Agent baut, der ein paar Tools aufruft und eine Aufgabe abschließt, hat im SDK weniger Code, weniger Token-Overhead und weniger Indirektion zum Debugging.
LangGraph nur dort, wo die State-Machine real existiert. Komplexe Multi-Agent-Workflows mit persistentem State, Verzweigung, Replay, Checkpointing. Das ist die Nische, in der LangGraph Substanz hat und für die es kein direktes SDK-Pendant gibt. Alles andere ist Overkill: Ein einfacher Tool-Use-Loop ist kein Graph, auch wenn er sich als einer ausdrücken liesse.
Tools gegen MCP schreiben, nicht gegen LangChain-Schemas. Wenn du heute ein Tool gegen ein Schema schreibst, schreibe es gegen MCP. Du bekommst die OpenAI-, Anthropic-, Google- und Microsoft-Reichweite gratis und schreibst nicht gegen ein Schema, das parallel zum kanonischen Standard existiert.
LangSmith trennen vom Rest. LangSmith ist der Teil der LangChain-Welt, der ohne den Framework-Overhead funktioniert. Wer Observability braucht, holt LangSmith als reine Tracing-Schicht. Ohne langchain als Dependency.
Die nüchterne Lesart
LangChain ist nicht „falsch” gewesen. Es war 2022 und 2023 das Werkzeug, das den Markt erst geöffnet hat. Aber Frameworks haben einen Lebenszyklus. Sie entstehen, wenn die darunterliegenden Primitive zu primitiv sind. Sie verfallen, wenn die Primitive das nachholen, was sie ursprünglich abstrahiert haben. Genau diesen Punkt haben die Anbieter-SDKs 2025 erreicht. Der 53-Prozent-Token-Overhead aus dem AImultiple-Benchmark ist nicht das eigentliche Problem. Das eigentliche Problem: Dieser Overhead war 2022 ein Preis, den man gerne gezahlt hat, weil das Framework etwas konnte, was sonst niemand konnte. 2026 ist es ein Preis ohne Gegenwert.
Ein neuer Agent 2026 hat eine klare Wahl: Framework, das gerade von einem kanonischen Standard überholt wird, oder SDK-Schicht, die der Anbieter selbst pflegt. Von aussen sieht das wie eine Tool-Entscheidung aus. Es ist eine Entscheidung über technische Schulden, die du in zwölf Monaten zurückzahlen musst.
Wer die nächsten Verschiebungen in dieser Schicht beobachtet (welche LangChain-Komponenten in welche SDK-Versionen einwandern, wie sich MCP-Adoption real entwickelt, wo neue Brüche an Caching- und Streaming-Schichten auftauchen), findet im KI-Syndikat Newsletter jede Woche eine Einordnung mit Quellen statt Marketing.