Kostet jede komplexe Frage ein Vermögen an Tokens?

„Und wenn ich die KI etwas frage, das über alle Mandanten geht, zahle ich mich dann dumm?" Berechtigte Frage. Tokens sind die Abrechnungseinheit von Sprachmodellen und wer schon einmal eine API-Rechnung gesehen hat, entwickelt einen gesunden Respekt davor. Trotzdem: Nein. Komplexe Fragen müssen nicht teuer sein. Ob sie es sind, entscheidet nicht die Frage, sondern die Architektur dahinter.

Wo Tokenkosten wirklich entstehen

Ein Sprachmodell rechnet über alles ab, was durch sein Kontextfenster fließt: die Frage, die Antwort und vor allem alles, was man ihm als Material mitgibt. Der teure Fehler ist deshalb immer derselbe: rohe Datenmengen ins Modell kippen und es dort suchen lassen. Wer für eine Auswertung die Buchungsdaten von hunderten Mandanten in den Kontext lädt, bezahlt jeden einzelnen dieser Datensätze, bei jeder Frage aufs Neue.

Der Punkt, der dabei oft untergeht: Das ist nicht nur teuer, es macht die Antworten auch schlechter. Die Forschung ist da deutlicher, als vielen lieb sein dürfte. Der Forschungsbericht „Context Rot" (Chroma, 2025) hat 18 führende Modelle getestet und zeigt, dass die Zuverlässigkeit mit wachsender Eingabelänge sinkt, selbst bei simplen Suchaufgaben. Schon 2023 wies die Studie „Lost in the Middle" nach, dass Modelle Informationen aus der Mitte langer Kontexte deutlich schlechter nutzen als vom Anfang oder Ende. Mehr Kontext ist also kein Qualitätsgarant, sondern ab einem gewissen Punkt das Gegenteil.

Suchen gehört in die Datenbank, nicht ins Modell

Die Lösung ist ein altes Datenbankprinzip in neuem Gewand: Die Arbeit wandert dorthin, wo sie billig ist. Der offene MCP-Standard, über den moderne KI-Anbindungen laufen, ist genau dafür gebaut. Seine Tool-Spezifikation nennt Datenbankabfragen ausdrücklich als Kernanwendungsfall, inklusive Beispiel für ein SQL-Werkzeug. Das heißt konkret: Die Frage „Welche Mandanten haben offene Forderungen über 90 Tage?" wird nicht beantwortet, indem das Modell 500 Mandantenbestände liest. Sie wird zu einer einzigen aggregierenden Abfrage, die das Werkzeug in der Datenbank ausführt, und zurück ans Modell gehen nur die Ergebniszeilen.

Wie groß der Unterschied ist, hat Anthropic in einem Engineering-Beitrag an einem Beispiel-Workflow vorgerechnet:

Ansatz	Tokens im selben Workflow
Zwischenergebnisse fließen durchs Modell	150.000
Ausführung im Werkzeug, nur das Ergebnis geht ans Modell	2.000 (98,7 Prozent weniger)

Dieselbe Design-Leitlinie steht in Anthropics Empfehlungen für Tool-Entwickler:

„In the same vein, tool implementations should take care to return only high signal information back to agents." (Anthropic Engineering)

Also gefiltert und begrenzt statt roh und vollständig.

Genau nach diesem Muster bauen wir die SOFI-Werkzeuge und davon gibt es einige: Allein aus dem DATEV Arbeitsplatz sind rund 300 Werkzeuge angebunden. Suchen, Filtern und Aggregieren passiert bei jedem davon auf der Datenseite, das Modell bekommt Treffer statt Bestände. Bei der Microsoft-365-Anbindung geht das so weit, dass die Suche selbst gar kein Token-Guthaben kostet: Gesucht wird auf der Microsoft-Seite, erst der Treffer geht ins Modell. Und damit die Kostenseite kalkulierbar bleibt, wird bei SOFI der monatliche Nutzerpreis in etwa gleicher Höhe als persönliches Token-Guthaben gutgeschrieben; die Details stehen auf der Preisseite.

Der faire Blick auf den anderen Weg

Es gibt eine zweite Schule: den Bestand vorab aufzubereiten, zu vektorisieren und in einem eigenen Index zu halten. Das hat einen echten Vorteil, nämlich schnelle semantische Suche über große unstrukturierte Bestände, also Treffer nach Bedeutung statt nur nach Wortlaut. Den Vorteil soll man nicht kleinreden.

Ein Index will allerdings gepflegt sein: Er wird regelmäßig mit dem Quellbestand abgeglichen und gehört in dasselbe Rechte- und Löschkonzept wie der übrige Bestand. Ein kleiner Zeitversatz ist dabei normal und im Kanzleialltag unproblematisch; auch die großen Plattformen aktualisieren ihre Indizes asynchron. Das gilt für jeden Anbieter, der Bestände für die Suche aufbereitet, uns eingeschlossen. Technisch schließen sich beide Welten ohnehin nicht aus; Volltext, strukturierte Abfragen und semantische Suche lassen sich kombinieren und für Dokumentbestände ist Semantik ein sinnvolles Werkzeug.

Für die Kostenfrage zählt am Ende nicht, wie die Daten vorgehalten werden, sondern wo gesucht wird: in der Datenbank statt im Kontextfenster. Buchungen, Stammdaten und Fristen sind strukturierte Daten und eine aggregierende Abfrage beantwortet sie schneller und günstiger als jedes Kontext-Vollstopfen. Wie der kontrollierte Zugriff mit Rechten und Protokoll aussieht, steht in unseren Beiträgen zum DATEV MCP Server und zum Datenzugriff als Engpass.

Kurz gesagt: Wenn komplexe Fragen bei einem Anbieter spürbar ins Geld gehen, ist das kein Naturgesetz. Es ist ein Architekturhinweis.

---

Quellen

• „Code execution with MCP", Anthropic Engineering, anthropic.com, abgerufen am 30.07.2026.
• „Writing effective tools for AI agents", Anthropic Engineering, anthropic.com, abgerufen am 30.07.2026.
• Model Context Protocol: Tools (Spezifikation und Konzepte), modelcontextprotocol.io, abgerufen am 30.07.2026.
• „Context Rot: How Increasing Input Tokens Impacts LLM Performance", Chroma Research, trychroma.com, abgerufen am 30.07.2026.
• Liu et al., „Lost in the Middle: How Language Models Use Long Contexts", arxiv.org, abgerufen am 30.07.2026.