[Startseite](https://codefionn.eu/de/) · [Projekte](https://codefionn.eu/de/projects/) · [Über mich](https://codefionn.eu/de/about/) · [GitHub](https://github.com/codefionn)
---
# Das schlechte Design von LLM-APIs
> Was mir die Entwicklung eines LLM-Gateways über den Stand von KI beigebracht hat
*Veröffentlicht am 2026-10-04 · [View as HTML](https://codefionn.eu/das-schlechte-design-von-llm-apis/) · [Read in English](https://codefionn.eu/the-bad-design-of-llm-apis/)*
---
Ich entwickle zurzeit viele verschiedene KI-Anwendungen und habe dafür
[llmleaf](https://github.com/codefionn/llmleaf) gebaut, einen KI-Gateway-Proxy,
der alle möglichen LLM-API-Anbieter vereinheitlicht und mit zusätzlichen
Informationen anreichert.
Dabei hatte ich einige Probleme mit diesen Schnittstellen und manchmal auch mit
ihren Informationen. Dieser Artikel behandelt die Probleme, die die KI-Anbieter
irgendwie ignorieren.
## SSE
Wie würdest du ein bidirektionales Kommunikationsprotokoll umsetzen? Einzelne
Anfragen? Ein selbst erstelltes Binärprotokoll? Vielleicht WebSockets?
Die Antwort der Branche war natürlich
SSE. Das ist ein Webstandard, um Events
vom Server zum Client zu streamen, was gut ist. Entscheidend ist aber, dass es
nicht in die andere Richtung streamt, und das ist schlecht. Vielleicht war das
in den frühen ChatGPT-Tagen eine gute Entscheidung, aber die Zeit nach Opus 4.8
braucht etwas anderes.
Das führt zu zwei Problemen. Wenn der Client Nachrichten an den Server
zurückschicken muss, und im Zeitalter agentischer Entwicklung sind das viele
Tool-Call-Ergebnisse, muss ein komplett neuer Request an den Server gehen.
Verschlimmert wird das dadurch, dass Prompt-Caching aus Kostengründen Pflicht
ist und Thinking versteckt oder verschlüsselt wird.
Wenn der neue Request einen Tool-Call beantwortet, muss die API die letzte
Server-Antwort aus dem Kontext ableiten, vermutlich über Hashing. Sobald sie
gefunden ist, funktioniert das Caching richtig und der Nutzer zahlt hoffentlich
weniger für Tokens, die schon verarbeitet wurden. Der Entwickler muss dafür
sorgen, dass die gesendeten Nachrichten als dieselben erkannt werden, die schon
vorher gesendet wurden.
Es gibt sogar spezielle API-Funktionen, die versuchen, das zu umgehen, z. B.
`cache_control` von Anthropic oder `previous_response_id` von OpenAI.
Dieses ständige Neuverbinden kostet Latenz, die eine vernünftige Umsetzung nicht
hätte. Wer das selbst erleben will, nutzt einfach Codex mit dem
OpenAI-Abonnement. Das verwendet bereits WebSockets.
Mit SSE bedeutet jeder Tool-Call einen neuen Request mit dem ganzen VerlaufMit einem WebSocket bleibt die Verbindung offen und nur neuer Input wird geschickt
## MCPs
Die bisherigen MCP-Spezifikationen
waren so schlecht, dass die Spezifikation vom 2026-07-28 sie reparieren musste.
Zur Info: Die bisherigen Spezifikationen haben zustandsbehaftete Verbindungen
verlangt. Das hat Dinge wie den Zugriff der Agenten deiner Kunden auf deine
Dokumentation über MCP viel schwieriger und ressourcenhungriger gemacht als
nötig. Die Spezifikation vom 2026-07-28 macht MCP endlich zustandslos.
Ein weiteres Problem war, dass mit den bisherigen Spezifikationen jede
Agenten-Session ihre eigenen MCP-Verbindungen aufbauen musste. Mit einigen
größeren MCP-Servern wurden dadurch schon drei oder mehr Agenten sehr teuer.
## Der List-Endpunkt
KI-Anbieter haben Endpunkte, die die unterstützten Modelle auflisten. Das
Problem: Sie liefern oft nicht die nötigen Informationen. Im schlimmsten Fall
bekommst du nur Modell-IDs, Namen und Veröffentlichungsdaten.
Die Modellliste von OpenAI: kein Kontextfenster, keine Preise, keine Fähigkeiten
