TOON

Jedes Token, das du an ein LLM schickst, kostet Geld, und JSON, der Standardweg, strukturierte Daten in einen Prompt zu geben, geht damit verschwenderisch um. Jedes Objekt wiederholt seine Feldnamen, Klammern und Anführungszeichen häufen sich, und eine Tabelle mit hundert Zeilen bezahlt dieselben Schlüssel hundertmal. Je größer die Kontextfenster werden und je mehr Daten in Prompts wandern, desto deutlicher wird dieser Overhead als realer Kostenpunkt. TOON, kurz für Token-Oriented Object Notation, ist ein Serialisierungsformat, das genau für dieses Problem gebaut wurde. Es kodiert dasselbe Datenmodell wie JSON, also Objekte, Arrays und Primitive, mit deterministischen, verlustfreien Round-Trips, ordnet die Bytes aber so an, dass ein Tokenizer weniger davon zählt. Das Projekt formuliert es schlicht: JSON im Code behalten und nur an der Grenze zum Modell nach TOON kodieren.

TOON verbindet zwei Ideen. Für verschachtelte Strukturen nutzt es YAML-artige Einrückung statt Klammern und lässt die meisten Anführungszeichen weg. Für uniforme Arrays von Objekten, der wichtigste Teil, wechselt es auf eine CSV-artige Tabelle: Es deklariert die Array-Länge und die Feldnamen einmal und gibt dann jeden Datensatz als Zeile mit kommagetrennten Werten aus. Ein hikes-Array wird zu einer Header-Zeile plus drei Datenzeilen statt zu drei voll wiederholten Objekten. Längenmarker und Feld-Header sind dabei nicht nur Kompression, sie dienen zugleich als Schema, gegen das das Modell prüfen kann, weshalb das Projekt sie als Guardrails gegen Abschneiden oder fehlende Felder einsetzt. Das Format kommt mit einer formalen Spezifikation, einem CLI für die JSON-TOON-Konvertierung mit Token-Statistik, SDKs für TypeScript, Python, Go, Rust, .NET, Java und Swift, einer VS-Code-Erweiterung und einer Tree-sitter-Grammatik.

Die natürliche Zielgruppe sind alle, die große, regelmäßige Datensätze in Prompts geben und auf die Token-Rechnung schauen. Man denke an Suchergebnisse, Datenbankzeilen, Produktkataloge, Event-Logs, Zeitreihen-Tabellen oder Listen von GitHub-Repos: Daten, bei denen dieselben Felder über viele Datensätze hinweg wiederkehren. Eine RAG-Pipeline, die fünfzig Bestelldatensätze einspeist, oder ein Agent, der ein hundertzeiliges Query-Ergebnis in den Kontext kippt, ist genau der Fall, in dem sich das tabellarische Layout auszahlt. Da die Ersparnis auf Format-Ebene entsteht, ist sie modellunabhängig und braucht keinen Proxy und kein SDK auf der Inferenz-Seite, lässt sich also in bestehenden Prompt-Code einklinken, egal welchen Anbieter du aufrufst. Die breite Sprachabdeckung und das Editor-Tooling senken die Hürde für Teams, die sich darauf festlegen wollen, und der mitgelieferte MCP-Proxy deutet auf Tool-Call-Antworten von Agenten als Ziel hin, wo verboses JSON ein wiederkehrender Kostenfaktor ist.

Der Ehrlichkeitstest liegt in den Einschränkungen, und das Projekt benennt sie erfreulich offen. TOON gewinnt nur bei uniformen Arrays von Objekten. Bei tief verschachtelter Konfiguration, unregelmäßigen oder halb-uniformen Daten oder überwiegend Freitext schrumpfen oder verschwinden die Vorteile, und das README zeigt, dass JSON bei einem tief verschachtelten Konfigurationsbeispiel besser abschneidet. Für rein tabellarische Daten ist reines CSV kleiner, da TOON rund fünf bis zehn Prozent Overhead für seine Struktur-Metadaten hinzufügt. Es gibt auch einen Latenz-Vorbehalt: weniger Tokens heißt nicht immer schneller, und quantisierte lokale Modelle verarbeiten kompaktes JSON unter Umständen flotter. Zwei praktische Hürden bleiben. Die Einführung braucht Zustimmung von Produzent und Konsument der Daten, und die Genauigkeits- und Token-Zahlen, inklusive der Schlagzeile von 76 Prozent bei rund 40 Prozent weniger Tokens, sind die eigenen Benchmarks des Projekts, also eher ein Ausgangspunkt zum Nachprüfen als ein Beweis.

Ehrlich gesagt hat TOON keine einzelne kommerzielle Alternative, denn sein eigentlicher Konkurrent ist JSON selbst, dazu CSV für flache Tabellen und Prompt-Komprimierungsdienste, die auf einer anderen Ebene ansetzen. Gegenüber JSON ist TOON eine gezielte Optimierung, kein Ersatz: Du setzt es genau dort ein, wo du wiederholt für uniforme Array-Struktur bezahlst, und behältst JSON überall sonst, auch in der Anwendungslogik. Sinnvoll ist der Griff dazu, wenn die Token-Kosten für tabellarische Prompt-Daten ein realer und wiederkehrender Aufwand sind und du die Ersparnis an deinen eigenen Payloads und deinem Tokenizer messen kannst. Zu früh oder schlicht das falsche Werkzeug ist es, wenn deine Daten überwiegend verschachtelt, unregelmäßig oder Freitext sind, wenn CSV deine flachen Tabellen bereits abdeckt, oder wenn Latenz statt Token-Zahl die bindende Beschränkung ist. Erst benchmarken, dann entscheiden.