TOON: Ein Datenformat für Sprachmodelle

tl;dr: Im Oktober 2025 veröffentlichte ich ein neues Datenformat: Token-Oriented Object Notation, kurz TOON. Als Beispiel: ein Wetterbericht darin kostet 74 Tokens statt 161 als JSON.

location:
  city: Berlin
  country: DE
  units: metric
alerts[2]: frost,wind
forecast[3]{day,temp{min,max},condition,rainChance}:
  Mon,-2,4,snow,80
  Tue,1,7,cloudy,20
  Wed,3,11,sunny,5

Tokens sind die Bausteine, in die ein Sprachmodell Text zerlegt, bevor es ihn liest – und die Einheit, in der die Inferenzanbieter abrechnen. Derselbe Datensatz als JSON:

{
  "location": {
    "city": "Berlin",
    "country": "DE",
    "units": "metric"
  },
  "alerts": ["frost", "wind"],
  "forecast": [
    { "day": "Mon", "temp": { "min": -2, "max": 4 }, "condition": "snow", "rainChance": 80 },
    { "day": "Tue", "temp": { "min": 1, "max": 7 }, "condition": "cloudy", "rainChance": 20 },
    { "day": "Wed", "temp": { "min": 3, "max": 11 }, "condition": "sunny", "rainChance": 5 }
  ]
}

In forecast wiederholen sich dieselben sechs Feldnamen für jeden Tag – day, temp, min, max, condition, rainChance. TOON schreibt sie einmal in die Kopfzeile, darunter bleiben nur die Werte. Dazu kommt die Syntax selbst: geschweifte Klammern, Anführungszeichen, Doppelpunkte, Kommas.

Bei großen, gleichförmigen Datensätzen braucht TOON gegenüber JSON 40 bis 60 Prozent weniger Tokens.

Eine Sache kostet dabei sogar Tokens: die Zahl in der Klammer. forecast[3] kündigt drei Zeilen an, bevor die erste kommt. Beim Lesen muss das Modell die Menge nicht erschließen, beim Schreiben hat es eine Vorgabe, gegen die es sich prüfen kann.

Das Nebenprodukt eines Proof of Concept bei Finanzfluss

Mitte 2025 initiierte mein Chef Thomas Kehl den täglichen News-Podcast im Loop gemeinsam mit Mary Abdelaziz-Ditzow. Von Montag bis Freitag wollten Mary und ihr Team der Frage nachgehen, welche Nachrichten des Tages für Deutschland und seine Wirtschaft relevant sind.

Damit die Redaktion morgens Schwerpunkte für die Episode setzen konnte, musste vorher jemand zusammentragen, was in den letzten 24 Stunden in sieben Weltregionen geschehen war. Schnell stand fest: Von Hand war dieses tägliche Pensum nicht zu schaffen.

Gepackt von der Podcast-Idee baute ich für Mary und ihr Team den Briefing-Generator, von Beginn an als Proof of Concept in Produktion. Der Workflow läuft als Web-App, die jeden Morgen Meldungen aus rund 270 Nachrichten-Feeds einsammelt und sie in mehreren Schritten von Sprachmodellen verarbeiten lässt:

• Zuerst sichtet der Workflow die Meldungen je Region und ordnet jede einer von vier Kategorien zu: Wirtschaft, Politik, Finanzen, Geopolitik. Aus mehreren Mikroereignissen verschiedener Quellen leitet er das übergeordnete Makroereignis ab.
• Im zweiten Schritt kann die Redaktion ein oder mehrere Makroereignisse auswählen, die eine tiefere Betrachtung bekommen sollen.
• Am Ende liest er die Artikel, die über das Makroereignis berichten, und generiert daraus das Briefing.

Das Ergebnis ist Rohmaterial, kein fertiges Skript.

Der Ablauf steht bis heute, aber die eigentliche Frage war damals: Trägt die Idee überhaupt, aus Hunderten Einzelmeldungen die großen Themen eines Tages herauszuarbeiten? In der Findungsphase des Tools bekam die Redaktion den fertigen Prompt zu sehen und konnte ihn anpassen, bevor er abgeschickt wurde. Für sie war das Kontrolle, für mich Feedback. Ein Mensch musste in dem Format also auch schreiben können.

In den einzelnen Aggregations- und Auswertungsschritten wurde eine ganze Menge Daten als JSON kodiert an Sprachmodelle gesendet – was den Großteil der Prompts ausmachte. Das war unleserlich und obendrein tokenökonomisch ineffizient.

Für eine reine Tabelle hätte CSV gereicht. Um die Meldungen herum lag jedoch Kontext, mehrere Ebenen tief verschachtelt, was CSV nicht abbilden kann. Ich brauchte eine Mischung aus CSV und YAML – Einrückung für das Verschachtelte, eine Tabelle für das Gleichförmige; in einem Dokument.

Ein viraler Repost auf X

Am 22. Oktober 2025 legte ich das Experiment auf GitHub an: Encoder und Decoder in TypeScript, dazu eine README. Letztere verglich an acht Beispieldatensätzen, wie viele Tokens JSON und TOON kosten, gezählt mit dem GPT-Tokenizer: 61 Prozent weniger. Ohne Erwartungen veröffentlichte ich das Format:

Johann Schopplich

@jschopplich

JSON is token‑expensive for LLMs – just like @mattpocockuk frequently mentions.

Meet TOON, the Token‑Oriented Object Notation.

💸 40–60% fewer tokens than JSON
📐 readable & tokenizer-aware

Wrap your JSON with encode to save half the token cost: github.com/toon-format/toon

448 Retweets 3500 Likes

Matt Pocock teilte den Post. Völlig unerwartet ging er viral. Täglich erreichten mich Dutzende Kommentare; der Star-Counter auf GitHub stand nach einem Monat bei über 20k. Mit so viel Aufmerksamkeit umzugehen fiel mir schwer.

Die Resonanz erfasste mich wie eine Welle, und auf ihrer Schaumkrone standen zwei Extreme. Auf der einen Seite Hype-Posts, die TOON zum JSON-Killer erklärten. Auf der anderen Rants, Memes und die Frage, ob ich schon mal von CSV oder YAML gehört hätte. Beides griff zu kurz und schadete damit der Idee. Und beides säte Zweifel in mir: Trägt die Idee wirklich?

Einen Teil des CSV-Vorwurfs hatte ich mir selbst eingebrockt. Das Beispiel, mit dem ich das Format vorstellte, war eine Liste von Nutzern mit id, name und role. Flach, gleichförmig, drei Spalten. Wer nur das sah, sah eine CSV-Tabelle mit einer Kopfzeile davor. Dass TOON Verschachtelung genauso kann, stand in der README, aber hängen blieb das schlecht gewählte Beispiel. Daher ging ich in den ersten Wochen täglich mehrere Stunden auf Kommentare, Reposts und Shitposts ein. Ich rückte Halbwissen gerade und versuchte, den Rants den Wind aus den Segeln zu nehmen.

Verstehen Modelle ein unbekanntes Datenformat?

Unter den ersten Kommentaren stand eine Frage, auf die ich bis dato keine Antwort hatte: Versteht ein Modell TOON überhaupt? Gemessen hatte ich die Tokenreduktion. Ob ein Sprachmodell aus einem Format, das es so noch nie gesehen hatte, zuverlässig Daten herausliest, war ungeprüft.

Also legte ich ein Retrieval-Benchmark nach: dieselben Datensätze in jedem Format, dieselben Fragen, ausgezählt, wie viele Antworten stimmten. Ich verglich TOON mit CSV, XML, YAML, kompaktem und formatiertem JSON.

Das Ergebnis fiel besser aus, als ich zu hoffen gewagt hatte: 69,2 Prozent richtige Antworten gegen 65,4 bei JSON, bei 46,3 Prozent weniger Tokens über die Benchmark-Datensätze. TOON wurde verstanden, und häufig sogar genauer ausgelesen als JSON. Das griff auch Theo auf:

Theo - t3.gg

@theo

Crazy how much more informed you can be by just reading the README file on the repo.

Armin is wrong here, the training data doesn't matter. TOON makes most models more accurate for lookup.

28 Retweets 642 Likes

In einem Video probierte er das Format an eigenen Daten durch. Die Schwäche fand er von allein – bei verschachtelten, ungleichförmigen Daten verlor es gegen kompakt geschriebenes JSON. Trotzdem kam er am Ende dahin, es selbst einsetzen zu wollen: Wer einem Modell Hunderte Zeilen gleichförmiger Daten hinwirft, fährt damit besser als mit JSON.

Der Kampf gegen Ökosystem-Fragmentierung

Wenige Tage nach meinem Tweet sprossen Implementierungen in anderen Sprachen aus dem Boden: Java und Swift, dann Go, Rust, Dart, .NET und Julia; allein ein halbes Dutzend Python-Projekte.

Ein junges Open-Source-Projekt kann an diesem Punkt schnell zerfasern. Jede Implementierung legt die Details etwas anders aus, sodass nach ein paar Monaten das Format überall gleich heißt, sich aber anders verhält. Ich nahm Kontakt mit Autoren der verschiedenen Repositories auf und lud sie in eine gemeinsame Diskussion ein. Aus johannschopplich/toon wurde toon-format/toon, eine Organisation mit einer offiziellen Implementierung pro Sprache.

Damit stellte sich die Frage, woran genau sie sich ausrichten sollten. Das Format selbst stand im Code: Meine TypeScript-Bibliothek war selbst die Definition von TOON. Am 2. November 2025 legte ich daher eine Spezifikation in einem eigenen Repository nach, dazu eine Conformance-Test-Suite. Die Testfälle sind reine JSON-Dateien – Eingabe gepaart mit erwarteter Ausgabe. So konnte jede Implementierung ihren eigenen Encoder und Decoder gegenchecken.

Moderieren des Community-Feedbacks

Mit der Bekanntheit kamen Vorschläge, TOON zu verbessern. Von AI Slop bis durchdachte Spec-Fixes war alles dabei. Was davon gehört ins Format, was bläht es nur auf?

Ich ließ mich verleiten, einen davon einzubauen: Key Folding. Die Idee: Wenn ein Objekt nur einen einzigen Schlüssel enthält, der wieder nur einen einzigen enthält, lässt sich die Kette zu einem Pfad zusammenziehen. Aus drei eingerückten Zeilen wird data.metadata.items. Klingt auf den ersten Blick vernünftig, da es Zeichen spart. Ich baute es ohne weitere Benchmarks auf Encoder- und Decoder-Seite ein.

Rückblickend brachte das Feature Komplexität ohne Mehrwert. Auf allen sechs Benchmark-Datensätzen sparte Key Folding exakt 0,00 Prozent – Ketten aus lauter Ein-Schlüssel-Objekten kommen in echten Daten praktisch nicht vor. Schwerer wog, was es dafür kostete: den Round-Trip. Ein Objekt mit dem Schlüssel a.b.c und eine zusammengezogene Kette ergeben dasselbe Dokument, Byte für Byte – welches von beidem gemeint war, ließ sich beim Dekodieren nicht mehr entscheiden.

Dazu kamen drei Optionen, mit denen sich Falten und Entfalten an- und abstellen ließen. Einstellen lässt sich bei TOON auch das Trennzeichen, nur steht das dann in der Kopfzeile: items[2|]. Meine drei standen nirgends. Wer die Einstellung nicht kannte, konnte das Dokument nicht zurücklesen.

Version 4: Cleanups und Finalisierung des Formats

Im Juli 2026 war das Entfernen von Key Folding der Commit, mit dem TOON Version 4 begann. Für diese Version ging ich alle offenen Issues und Pull-Requests auf GitHub durch. Ich strich doppelte Regeln aus der Spezifikation, schrieb Fehlerfälle fest, die bis dahin unausgesprochen geblieben waren, und härtete Encoder und Decoder mit neuen Testfällen ab. TOON unterstützt jetzt auch Kommentarzeilen – das älteste Issue der Spezifikation. Eine Zeile, die mit # beginnt, wirft der Decoder weg, bevor er irgendeine andere Regel anwendet; der Encoder schreibt selbst nie eine.

Zum ersten Mal seit der ersten Spezifikation kamen zwei neue Formen dazu. Beide gegen die Schwäche, die Theo im Video gefunden hatte: Sobald Daten verschachtelt waren, fiel TOON auf reine Einrückung zurück.

Die erste ist die verschachtelte Feldgruppe. Wenn eine Spalte einer Tabelle selbst wieder ein Objekt enthält, und zwar in jeder Zeile dasselbe, wandert dieses Objekt mit in die Kopfzeile und die Zeilen bleiben flach. Das Beispiel ganz oben ist genau deshalb ein Wetterbericht:

forecast[3]{day,temp{min,max},condition,rainChance}:
  Mon,-2,4,snow,80
  Tue,1,7,cloudy,20
  Wed,3,11,sunny,5

Die zweite ist die keyed-tabellarische Form, für Objekte, deren Werte alle gleich gebaut sind – Konfigurationen nach Umgebung, Feature-Flags nach Namen, Datensätze nach ID. Ein Doppelpunkt hinter der Länge markiert sie, und jede Zeile trägt ihren Schlüssel vorne:

environments[2:]{region,replicas,debug}:
  production: eu-central-1,6,false
  staging: eu-central-1,2,true

Am unteren Ende der Modellskala

Immer wieder schnappte ich über X auf, wo TOON etwas brachte. Jake Casto betrieb es bei Layers in Produktion, mit Amazon Nova Micro:

Jake Casto

@0x15f

Yes I did. I’m using it in production w/ Amazon Nova Micro and it is performing better. We serve a ridiculous amount of ecomm traffic daily and have observed a clear drop in token usage and a decrease in ttfb from bedrock. The model did not perform well with CSVs or XML and did not even handle large compressed JSON well. For this model it is a win across the board

Der Gewinn war dort am größten, wo Modelle am schwächsten waren; dasselbe Modell scheiterte bei Jake an CSV und an XML. Wie weit nach unten das trägt, hatte ich nicht gewusst – meine eigenen Benchmarks liefen gegen vier Modelle großer Labore. Veröffentlicht hatte ich TOON, weil Tokens Geld kosten. Wer es in Produktion behielt, tat es, weil die Antworten stimmten.

Eine E-Mail aus Marokko

Am 17. November 2025 erreichte mich eine E-Mail aus Marokko. Khadija Ahaidous von der EMSI in Casablanca wollte TOON wissenschaftlich prüfen und erfragte meine Messdaten. Dass ein Paper über TOON etwas hergibt, bezweifelte ich in diesem Moment noch.

Sechs Wochen später lag ihr Entwurf vor. Die Wissenschaft war ihre Arbeit, das Format meine: Ich prüfte, ob stimmt, was darin über TOON steht, und bestand darauf, den Interessenkonflikt zu nennen – ich bin der Autor des Formats, das hier bewertet wird.

Dieses Jahr ist das Paper in IEEE Access erschienen. Ich stehe als Dritter von fünf Autoren darunter. Dahinter stecken 5.016 Einzelmessungen: sechs Formate, vier Modelle, sieben Tokenizer-Familien, 209 Fragen an Datensätze von flach bis tief verschachtelt, gemessen an der Version vor dem Umbau.

Es sind dieselben Zahlen wie in meiner README, diesmal mit Konfidenzintervallen. Drei Befunde nahm ich mit:

• Der Vorsprung hängt am Modell. Bei GPT-5-nano, dem damals stärksten Modell im Test, lagen TOON und kompaktes JSON gleichauf. Bei Gemini 2.5 Flash waren es 87,6 gegen 77,0 Prozent.
• Auf verschachtelten Daten verlor TOON. 6 bis 20 Prozent mehr Tokens als kompaktes JSON. Der Rat im Paper lautet entsprechend, vor dem Einsatz zu prüfen, wie tabellarisch die eigenen Daten überhaupt sind.
• Fehlende Zeilen bemerkte kein Modell. Wurden am Ende drei entfernt, fiel es in keinem einzigen Fall auf. Bei zu vielen Zeilen schlug es in drei von vier Fällen an.

Der Befund traf das Modell, nicht das Format. Ein strenger Decode bricht bei der ersten Abweichung ab, seit es den Decoder gibt – wer sich auf Vollständigkeit verlassen muss, lässt den Decoder prüfen, nicht das Modell.

Als ich TOON veröffentlichte, gab es diese Unterscheidung noch: Reasoning-Modelle, die vor dem Antworten nachdenken, und solche, die direkt antworten. Damals waren die schnellen, günstigen Modelle noch überwiegend die ohne. Heute ist die Trennung bei den Frontier-Modellen praktisch verschwunden; bei manchen lässt sich das Reasoning nur noch auf ein Minimum herunterregeln.

Das verschiebt die Rechnung. Reasoning-Tokens werden als Output abgerechnet, und Output kostet ein Vielfaches des Inputs. Wie viele es werden, entscheidet das Modell. Die Ersparnis am Input fällt damit weniger ins Gewicht als noch 2025. Bleibt der zweite Grund: Modelle lesen aus explizit strukturierten Daten zuverlässiger. Auch das schrumpft, je besser die Modelle werden. In meinem aktuellen Benchmark liegen TOON und JSON in der Genauigkeit gleichauf. Fehlende Zeilen bemerken die Modelle dort inzwischen selbst – in TOON, während sie in JSON und YAML darüber hinweglesen. Wo Modelle klein und schnell sein müssen, bleibt der Unterschied.

Vor einem Jahr schrieb ich auf X: „If it turns out the idea is bad, it'll die in public too.“