Vor wenigen Tagen ist das TSCG-Paper von Furkan Sakizli auf arXiv erschienen. TSCG steht für Token-Context Semantic Grammar (Untertitel des Papers: „Causal Prompt Optimization in Large Language Models"). Ich arbeite seit Monaten mit Furkan zusammen — und dieses Paper ist der Moment, auf den wir gewartet haben: erstmals ist die Forschung hinter TSCG als peer-ready Publikation öffentlich zugänglich.
Was drin steht, ist in meinen Augen relevanter für den Unternehmensalltag als die meisten KI-Papers, die gerade erscheinen.
Das Problem, das kaum jemand benennt
Wenn du heute einen KI-Agenten in Produktion betreibst — egal ob mit OpenAI, Anthropic oder einem lokalen Modell — passiert im Hintergrund etwas Unbeachtetes: Jede Anfrage enthält eine vollständige Liste aller verfügbaren Werkzeuge im JSON-Format. Diese Werkzeug-Schemas wurden für Maschinen entworfen, nicht für Sprachmodelle. Furkan nennt das den Protocol Mismatch.
Bei großen Frontier-Modellen wie GPT-5 oder Claude Opus fällt das kaum auf — die sind robust genug, um sich trotzdem zurechtzufinden. Bei kleineren Modellen (4B bis 14B Parameter) ist dieser Mismatch die häufigste Fehlerursache bei Tool-Use in produktiven Katalogen.
Das ist ein Problem, das direkt messbar ist.
Was TSCG macht — und was es nicht ist
TSCG ist kein weiteres Fine-Tuning-Framework. Es ist kein Wrapper, der ein Modell durch ein anderes schickt. Es ist auch keine Cloud-API, die deine Daten verarbeitet.
TSCG ist ein deterministischer Compiler: Er nimmt JSON-Schemas und wandelt sie in token-effiziente strukturierte Texte um — mit 8 kausal begründeten Operatoren, ohne Modellzugriff, ohne GPU, in unter einer Millisekunde. 1.200 Zeilen TypeScript, null externe Abhängigkeiten.
Das Ergebnis: Die Schemas werden auf eine Darstellungsform gebracht, die Sprachmodelle tatsächlich verstehen — statt sie mit maschinenlesbaren JSON-Blöcken zu überfordern.
Die Zahl, die mich aufgeweckt hat
Phi-4 14B, ein lokales Modell, das viele KMU für datenschutzkonforme On-Premise-Setups nutzen: Tool-Accuracy bei 20 Werkzeugen ohne TSCG: 0 %. Mit TSCG: 84,4 %.
Bei 50 Werkzeugen: 90,3 %.
Das ist kein marginales Verbesserung. Das ist der Unterschied zwischen einem Agenten, der nicht funktioniert, und einem, der es tut — ohne ein einziges Gewicht neu zu trainieren.
Was der BFCL-Benchmark zeigt
Furkan hat das Paper nicht nur auf lokalen Modellen evaluiert. Das BFCL-Benchmark (Berkeley Function Calling Leaderboard) ist der Industriestandard für Tool-Use-Evaluation. In der externen BFCL-Validierung erreicht TSCG auf Claude Sonnet 4 einen ARR von 108 % bei gleichzeitig 46,8 % Token-Einsparung.
Der Begriff ARR (Accuracy Retention Rate) misst das Verhältnis der TSCG-Accuracy zur Accuracy der unkomprimierten Baseline (TSCG-Accuracy / Baseline-Accuracy). Über 100 % bedeutet: Du sparst Token und die Präzision liegt sogar über der Baseline. Das ist der entscheidende Punkt — es gibt hier keine Qualitäts-Kosten für die Kompression.
Warum das für lokale KI-Agenten besonders wichtig ist
Cloud-Anbieter wie Anthropic und OpenAI haben Prompt-Caching: Ab dem zweiten Request werden gleiche Präfixe gecacht, das dämpft die Kosten. Bei lokalen Modellen mit Ollama gibt es das nicht — jeder Token wird vollständig prozessiert, jeder Token kostet Rechenzeit auf deiner eigenen Hardware.
Für KMU, die KI-Agenten lokal betreiben wollen — sei es aus Datenschutzgründen, DSGVO-Anforderungen oder weil sie keine Cloud-Abhängigkeit wollen — ist jede Einsparung direkte GPU-Entlastung, kürzere Antwortzeiten und mehr Kontext im gleichen Fenster.
Die Token-Einsparung fällt je nach Modell und Szenario unterschiedlich aus – von rund 6 % bei manchen Frontier-Konfigurationen bis zu 75 % bei reinen Tool-Beschreibungen; bei Claude Sonnet 4 sind es etwa 50 %. Bei lokalen Setups ist das nicht nice-to-have. Es ist der Unterschied zwischen einer produktiv nutzbaren Session und einer, die nach 10 Schritten das Kontextfenster sprengt.
Was das mit ScaleWise zu tun hat
Ich habe gemeinsam mit Furkan das Plugin pi-tscg entwickelt — eine direkte Integration der TSCG-Engine in den Pi Coding-Agent. Pi gibt dem Plugin vollen Zugriff auf alle Datenflüsse, was zwei zusätzliche Kompressionsebenen ermöglicht: Output-Filter für Werkzeug-Antworten (der eigentlich größte Token-Fresser in produktiven Sessions) und automatisches Provider-Caching.
Die gemessenen Einsparungen in echten Sessions liegen bei 49–62 %. Bei einem Team von 10 Entwicklern mit je 100 Sessions/Monat über Claude Opus: rund 850 € monatliche Kostenersparnis — ohne Qualitätsverlust.
Das Plugin ist Open Source unter MIT, eine Installation: pi install npm:pi-tscg.
Fazit
Das TSCG-Paper ist für mich kein akademisches Dokument in einem Elfenbeinturm. Es ist die wissenschaftliche Grundlage für etwas, das direkt in Produktivsystemen messbar wirkt — und das für die Art von KMU-Setups relevant ist, mit denen ich täglich arbeite.
Dass Furkan das jetzt auf arXiv veröffentlicht hat, bedeutet: Die Grundlage ist dokumentiert, reproduzierbar und öffentlich zugänglich. arXiv ist ein Preprint-Server – ein formales Peer-Review steht damit noch aus –, aber die Methode ist ab jetzt zitierbar und nachvollziehbar dokumentiert. Das ist der Moment, ab dem man das ernsthaft referenzieren kann.
Zum arXiv-Paper: arxiv.org/abs/2605.04107
Zur Forschungsseite mit allen Benchmark-Daten: scalewise.de/ki-forschung
pi-tscg auf GitHub: github.com/Nick-Wolf-HLK/pi-tscg
ScaleWise ist Forschungspartner von Furkan Sakizli (SKZL-AI). Nick Wolf hat das pi-tscg Plugin entwickelt, das TSCG in den Pi Coding-Agent integriert.