TOON: JSON für LLM-Prompts kompakter kodieren

Das Problem: Struktur kostet Tokens

Jede geschweifte Klammer, jedes Anführungszeichen und jeder wiederholte Feldname in einem JSON-Prompt wird als Token abgerechnet. Bei einem einzelnen Objekt fällt das kaum auf. Bei einer Liste von hundert Datensätzen mit identischen Feldern wiederholt sich die Feldliste hundertmal, obwohl sie einmal genügen würde. TOON setzt genau dort an: Das Projekt nennt sich selbst eine kompakte, menschenlesbare Kodierung des JSON-Datenmodells, die Tokens minimiert und die Struktur für Modelle leichter nachvollziehbar macht. Adressiert sind damit Teams, die JSON programmatisch erzeugen und dasselbe JSON als Prompt an ein LLM übergeben. Die README beschreibt die Rolle als Übersetzungsschicht: JSON bleibt das Arbeitsformat im Code, TOON wird daraus für die Eingabe ins Modell erzeugt. Das ist kein neues Datenmodell, sondern eine andere Schreibweise desselben Modells.

Vier Formen, automatisch aus der Datenform gewählt

TOON kennt vier Formen, und welche zum Einsatz kommt, ergibt sich aus der Gestalt der Daten. Die erste ist die Inline-Form: `alerts[2]: frost,wind` schreibt ein Array aus Primitiven auf die Kopfzeile. Die zweite ist die tabellarische Form. Im Beispiel der README steht `forecast[3]{day,temp{min,max},condition,rainChance}:`, gefolgt von einer Zeile pro Element. Die Feldliste wird einmal deklariert, danach fließen die Werte zeilenweise. Bemerkenswert ist die Gruppe `temp{min,max}`: gleichförmig verschachtelte Objekte werden in die Kopfzeile gefaltet, während die Zeilen flach bleiben. Die dritte Form ist die keyed tabular Form für Objekte, deren Werte uniforme Objekte sind. Das Doppelpunkt nach der Länge, also `[2:]`, markiert sie, und jede Zeile trägt ihren eigenen Schlüssel: `production: eu-central-1,6,false`. Alles, was in keine dieser Formen passt, etwa gemischte Typen oder uneinheitliche Objekte, fällt auf die vierte Form zurück, die Listenform mit einem `- ` Eintrag pro Element. Laut README decken diese vier Formen die vorkommenden Datenformen ab.

Installation und der schnellste Einstieg

Der kürzeste Weg führt über npx und benötigt keine Installation: `cat data.json | npx @toon-format/cli --stats`. Die CLI gibt die TOON-Ausgabe zusammen mit der Ersparnis aus. Für das Wetterbeispiel der README nennt sie rund 117 Tokens für JSON gegen rund 66 für TOON, was einer Einsparung von etwa 43,6 Prozent entspricht. Diese Zahlen stammen aus dem Repository, nicht aus einem unabhängigen Nachbau, und sie beziehen sich auf einen Tokenizer, den die README nicht benennt. Wer die Ersparnis für das eigene Modell wissen will, muss den eigenen Tokenizer anlegen. Für die programmatische Nutzung ist das Paket unter dem Namen `@toon-format/toon` auf npm veröffentlicht, das SDK ist in TypeScript geschrieben. Die README verweist zusätzlich auf eine vollständige Spezifikation im Repository toon-format/spec, auf die sich die Implementierungen beziehen.

Längenangaben als Prüfregel

Die eckigen Klammern sind nicht nur Notation. `[N]` deklariert, wie viele Zeilen folgen, und `{fields}` deklariert, wie breit eine Zeile ist. Das Projekt bezeichnet das in der README als Guardrails für LLMs: Wenn ein Modell die Ausgabe abschneidet oder eine Zeile verliert, wird der Fehler an der Deklaration sichtbar, statt still durchzugehen. In JSON gibt es keine entsprechende Selbstbeschreibung. Ein abgeschnittenes Array bleibt dort ein gültiges, kürzeres Array. Ob ein Modell diese Deklarationen tatsächlich nutzt, um seine Ausgabe zu prüfen, hängt vom Prompt und vom Modell ab, und die README belegt das nicht mit Messwerten. Der Mechanismus ist aber im Format selbst angelegt und nicht erst nachgelagert in Validierungscode.

Wo TOON die falsche Wahl ist

Die README benennt die Grenzen selbst, und sie sind eng. Bei tief verschachtelten oder uneinheitlichen Strukturen, wenn die Eignung für die tabellarische Form gegen null geht, gewinnt kompaktes JSON deutlich. Bei halbwegs uniformen Arrays mit etwa 40 bis 60 Prozent Eignung schrumpft die Ersparnis, und wer bereits eine JSON-Pipeline betreibt, sollte dort bleiben. Bei rein tabellarischen Daten ist CSV kleiner; die fünf bis zehn Prozent Aufschlag, die TOON laut README kostet, kaufen deklarierte Längen, Feldlisten und eine abgegrenzte Trennzeichenlogik, also Verlässlichkeit statt Größe. Der unangenehmste Punkt ist die Latenz. Die README schreibt, dass manche Umgebungen, namentlich lokale oder quantisierte Modelle, kompaktes JSON trotz höherer Tokenzahl schneller verarbeiten. Das heißt: Eine Token-Ersparnis kann sich in der Wanduhrzeit nicht auszahlen. Die README liefert dazu keine Zahlen und verweist ausdrücklich darauf, dass TTFT und Gesamtzeit auf der eigenen Umgebung zu messen sind.

CSV und YAML als Vergleich

Der Vergleich mit CSV ist der aufschlussreichste. CSV ist bei flachen, vollständig uniformen Daten kleiner, kann aber verschachtelte Strukturen nur durch verlustbehaftetes Flachklopfen abbilden. Deshalb trennt die README ihre Benchmarks in zwei Spuren: eine Mixed-Structure Track für verschachtelte und halb-uniforme Datensätze, in der CSV ausgeschlossen ist, und eine Flat-Only Track für flache, vollständig tabellarisch geeignete Daten, in der CSV als fairer Konkurrent antritt. Diese Trennung ist ehrlicher als eine einzelne Gesamtzahl, weil sie den Vergleich auf vergleichbare Fälle begrenzt. Gegenüber YAML liegt der Unterschied in der Deklaration: YAML kennt keine Längenangabe und keine Feldliste in der Kopfzeile, die Struktur ist also nicht gegen Abschneiden abgesichert. Gegenüber JSON ist der Unterschied rein syntaktisch, das Datenmodell bleibt identisch, was Roundtrips verlustfrei macht.

Reifegrad, Lizenz und Pflegeaufwand

Das Projekt steht unter MIT-Lizenz, was die Nutzung und Weitergabe im eigenen Code ohne Copyleft-Auflagen erlaubt; das ist eine Einordnung, keine Rechtsberatung. Der Stand ist aktiv: Die letzte Veröffentlichung ist v4.1.1 vom August 2026, der letzte Push ins Repository datiert auf September 2026. Die Versionshistorie zeigt mit v4.0.0 im Juli 2026 einen Sprung der Hauptversion innerhalb weniger Wochen, was auf eine noch junge, sich bewegende Spezifikation hindeutet. Die README formuliert das selbst: Das Format sei stabil, aber auch eine Idee im Werden, nichts sei in Stein gemeißelt. Wer TOON einsetzt, muss also damit rechnen, dass sich die Spezifikation weiterentwickelt und ein Upgrade auf eine neue Hauptversion Anpassungen verlangt. Die Existenz einer separaten Spezifikation und eines gemeinsamen Konformitätstestsatzes für die Implementierungen spricht dafür, dass die Sprachportierungen nicht auseinanderlaufen. Ein Kostenpunkt beim Umstieg entsteht nicht durch die Lizenz, sondern durch die Bindung an ein Format, das noch nicht in jedem Werkzeug steckt.

Redaktionelles Fazit

Wer LLM-Prompts mit vielen uniformen Objekten füllt (Konfigurationsmaps, Datensätze mit gleichen Feldern), sollte TOON mit einem eigenen Datensatz prüfen: `cat data.json | npx @toon-format/cli --stats` zeigt die Token-Ersparnis, bevor irgendetwas in eine Pipeline wandert. Wer tief verschachtelte oder uneinheitliche Strukturen überträgt, sollte bei JSON bleiben. Vor dem Produktiveinsatz ist die Latenz auf dem eigenen Modell zu messen, denn dazu liefert das Repository keine Zahlen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. toon-format/toon on GitHub