When LLMs process structured data, the serialization format directly affects cost and context utilization. Standard JSON wastes tokens repeating key names in every row of a tabular array--overhead that scales linearly with row count. This paper presents JTON (JSON Tabular Object Notation), a strict JSON superset whose main idea, Zen Grid, factors column headers into a single row and encodes values with semicolons, preserving JSON's type system while cutting redundancy. Across seven real-world domains, Zen Grid reduces token counts by 15-60% versus JSON compact (28.5% average; 32% with bare_strings). Comprehension tests on 10 LLMs show a net +0.3 pp accuracy gain over JSON: four models improve, three hold steady, and three dip slightly. Generation tests on 12 LLMs yield 100% syntactic validity in both few-shot and zero-shot settings. A Rust/PyO3 reference implementation adds SIMD-accelerated parsing at 1.4x the speed of Python's json module. Code, a 683-vector test suite, and all experimental data are publicly available.
Figures & tables
Rows
JSON Pretty
JSON Compact
Zen Grid
Zen Bare
Δ vs Compact
5
168
88
75
64
− 14.8%
10
335
175
142
119
− 18.9%
25
836
436
343
284
− 21.3%
50
1,671
871
678
559
− 22.2%
100
3,342
1,742
1,349
1,109
− 22.6%
250
8,351
4,351
3,358
2,759
− 22.8%
Table 1: Token counts by format and dataset size (employee records, 4 columns).
Figure 1: Token count scaling for employee records (4 columns, o200k_base tokenizer). Zen Grid savings increase with row count, converging to ∼ 23% at scale.
Dataset
Rows
Cols
JSON Tokens
Zen Tokens
Savings
Employees
100
4
1,742
1,349
− 22.6%
Employees
500
4
8,702
6,709
− 22.9%
Products
100
5
2,764
2,273
− 17.8%
Products
500
5
13,838
11,347
− 18.0%
Metrics
100
4
2,694
2,301
− 14.6%
Metrics
500
4
13,472
11,479
− 14.8%
Table 2: Token savings across different data shapes (100 and 500 rows).
Figure 2: Token savings (%) versus JSON formats converge rapidly with row count, reaching 23% versus compact and 59% versus pretty-printed by 1,000 rows.
Figure 3: Zen Grid token savings across different data shapes. Savings range from 15% (number-heavy metrics) to 23% (string-heavy employees).
Dataset
Rows
JSON Compact
Zen Bare
Δ Compact
Δ Pretty
Twitter (API)
20
3,673
1,422
− 61.3%
− 65.9%
GitHub (Events)
20
968
780
− 19.4%
− 43.8%
CITM (Ticketing)
20
871
612
− 29.7%
− 52.6%
Financial (Trades)
20
1,358
1,041
− 23.3%
− 48.5%
Weather (Stations)
25
1,911
1,316
− 31.1%
− 52.3%
Healthcare (Lab)
20
1,349
936
− 30.6%
− 53.3%
Table 3: Token counts and savings across seven real-world datasets (20–25 rows each, o200k_base tokenizer, Zen Grid with bare_strings=True ).
Figure 4: Token counts across seven real-world datasets. Zen Grid (green) consistently uses fewer tokens than both JSON compact and JSON pretty-printed. Savings range from 15% (GitHub) to 60% (Twitter) versus compact, and up to 61% with bare_strings .
Figure 5: Zen Grid token savings by dataset domain. Savings correlate with key name length and column count–datasets with longer, more descriptive keys achieve higher savings.
Dataset
JSON (ms)
JTON (ms)
Speedup
Twitter
0.090
0.058
1.55 ×
GitHub
0.043
0.036
1.20 ×
CITM
0.055
0.037
1.50 ×
Financial
0.083
0.059
1.40 ×
Weather
0.106
0.070
1.53 ×
Healthcare
0.088
0.056
1.58 ×
Table 4: Parse speed: jton.loads() vs json.loads() on real-world datasets (5,000 iterations, averaged).
Figure 6: Left: parse speedup per dataset. Right: absolute parse latency comparison. JTON achieves 1.2–1.6 × speedup across all real-world datasets.
Model
Family
JSON
Zen Grid
Δ
n
GPT-5.1-codex
OpenAI
74.3%
71.4%
− 2.9 pp
35
GPT-5.1
OpenAI
71.4%
62.9%
− 8.6 pp
35
GPT-5-mini
OpenAI
71.4%
71.4%
0.0 pp
35
Gemini 3 Pro
Google
68.6%
68.6%
0.0 pp
35
Kimi K2
Moonshot
62.9%
68.6%
+5.7 pp
35
Qwen3 32B
Alibaba
60.0%
57.1%
− 2.9 pp
35
Table 5: LLM accuracy (%) on real-world data across 10 models (7 datasets × 5 questions per format, n =35 each unless noted). Models sorted by JSON accuracy.
Question Type
JSON
Zen Grid
Δ
Lookup
95.7%
95.7%
0.0 pp
Filtering
52.9%
51.4%
− 1.4 pp
Count
51.4%
48.6%
− 2.9 pp
Comparison
48.6%
50.0%
+1.4 pp
Aggregation
47.1%
51.4%
+4.3 pp
Overall
59.1%
59.4%
+0.3 pp
Table 6: Accuracy (%) by question type on real-world data (all 10 models combined).
Family
Models
JSON
Zen Grid
Δ
OpenAI (GPT-5.x)
3
72.4%
68.6%
− 3.8 pp
Google (Gemini)
1
68.6%
68.6%
0.0 pp
Moonshot (Kimi K2)
1
62.9%
68.6%
+5.7 pp
Alibaba (Qwen3)
1
60.0%
57.1%
− 2.9 pp
Meta (Llama)
3
46.7%
49.5%
+2.9 pp
Open-source (GPT-OSS)
1
42.9%
45.7%
+2.9 pp
Table 7: Accuracy (%) by model family.
Figure 7: LLM accuracy on real-world datasets: JSON vs Zen Grid across 10 models. Four models improve with Zen Grid (green annotations), three are neutral, and three regress slightly. Overall: +0.3 pp.
Figure 8: Accuracy by question type on real-world data (10 models combined). Lookup remains perfectly robust (95.7%/95.7%); aggregation shows the largest improvement (+4.3 pp).
Figure 9: Accuracy by dataset domain. Performance varies by domain complexity–Twitter and GitHub (shorter values) show higher accuracy than financial and healthcare (complex numeric data).
Figure 10: Token savings: synthetic scaling trend (green line) versus real-world datasets (red diamonds). Real-world data achieves higher savings due to longer, more descriptive key names in production schemas.
Dataset
JSON Pretty
JSON Compact
CSV
Markdown
YAML
Zen Grid
Twitter
4,166
3,673
1,303
1,430
1,916
1,653
GitHub
1,388
968
688
792
1,185
968
Financial
1,023
643
408
505
840
516
Table 8: Token counts across six serialization formats on real-world data. Zen Grid achieves competitive token efficiency while preserving JSON’s type system.
Figure 11: Token counts (left) and savings vs JSON compact (right) across six serialization formats. CSV achieves the fewest tokens but loses type information. Zen Grid preserves JSON’s full type system while achieving substantial savings.
Rank
Format
Total Tokens
vs JSON Compact
JSON-compat.
1
JTON
144,159
− 20.2%
Yes
2
TOON
146,113
− 19.2%
No
3
JSON compact
180,725
–
Yes
4
YAML
220,129
+21.8%
No
5
JSON pretty
282,332
+56.2%
Yes
6
XML
332,171
+83.8%
No
Table 9: Overall token efficiency ranking across 6 datasets and 7 formats (total tokens, o200k_base ).
Model
Family
Few-shot
Zero-shot
GPT-5-mini
OpenAI
100%
100%
GPT-5.1
OpenAI
100%
100%
GPT-4o
OpenAI
100%
100%
Claude Sonnet 4
Anthropic
100%
100%
Claude 3.5 Haiku
Anthropic
100%
100%
Claude 3 Haiku
Anthropic
100%
100%
Table 10: Zen Grid generation validity (%) by model and prompting strategy. All 12 models achieve 100% validity in both modes.
Figure 12: Cost–accuracy tradeoff across 10 LLMs. Each model appears twice: as a red point (JSON) and green point (Zen Grid), connected by an arrow. Models that move left without moving down achieve a Pareto improvement (lower cost, same or better accuracy).
Rows
Size
Parse (MB/s)
Speedup
Serialize (MB/s)
(KB)
stdlib
JTON
stdlib
JTON
100
5.5
34.5
49.9
1.44 ×
51.8
98.4
500
27.8
27.7
13.4
0.48 ׆
29.5
32.1
1,000
55.6
18.4
21.4
1.16 ×
18.1
25.5
5,000
282.6
35.0
45.4
1.30 ×
41.0
83.6
Table 11: Parsing and serialization throughput on synthetic employee records.
File
Size (KB)
stdlib (MB/s)
JTON (MB/s)
Speedup
canada.json
2,198
16.0
29.7
1.85 ×
citm_catalog.json
1,687
41.9
66.1
1.58 ×
twitter.json
617
48.5
50.4
1.04 ×
github.json
55
128.9
98.7
0.77 ×
Table 12: Parsing speed on standard JSON benchmark files.
Figure 13: Parsing and serialization throughput. JTON achieves 1.2–1.9 × parse speedup on large files and up to 3.7 × serialization speedup with Zen Grid output.
Rows
stdlib JSON (MB/s)
JTON JSON (MB/s)
JTON Zen Grid (MB/s)
100
51.8
98.4
88.3
500
29.5
32.1
75.4
1,000
18.1
25.5
30.3
5,000
41.0
83.6
149.9
Table 13: Serialization throughput: JSON vs Zen Grid output.
Serialization formats designed for document interchange impose structural overhead that becomes prohibitive when large language models consume operational data at scale. A modest dataset of 1,000 IoT sensor readings serialized as JSON requires approximately 80,000 tokens - the majority spent on repeated field names, nested braces, and structural punctuation rather than semantic content. We present ONTO (Object Notation for Token Optimization), a columnar notation that declares field names once per entity and arranges values in pipe-delimited rows with indentation-based hierarchy. This schema-once, data-many design eliminates per-record key repetition while preserving human readability and nested structure support. Evaluation across three synthetic operational datasets demonstrates 46-51% token reduction versus JSON, with stable scaling from 100 to 1,000 records. Controlled inference benchmarks on Qwen2.5-7B show corresponding 5-10% latency improvement. Comprehension validation confirms no material degradation in LLM task accuracy across lookup, counting, extraction, and aggregation operations when format context is provided. Ablation analysis reveals that key repetition accounts for the majority of JSON overhead, with indentation costs in nested structures explaining the 4-percentage-point gap between flat and hierarchical data. ONTO occupies a previously unfilled position in the serialization landscape: columnar efficiency with hierarchical structure, optimized for LLM context windows rather than document interchange. Code and specification are available at https://github.com/harsh-aranga/onto.
Large language models in Agentic AI systems consume tool schemas and execution results and emit tool invocations as structured data. The default language for that exchange, JSON, was designed for application-to-application interchange rather than token efficiency, so its structural elements impose substantial token overhead. Recent work proposes token-optimized alternatives such as TOON (Token-Oriented Object Notation) and TRON (Token Reduced Object Notation) as more compact replacements, but these formats have been evaluated only on isolated comprehension or generation tasks. Whether their token reductions hold inside end-to-end agentic loops therefore remains an open question. We evaluate TOON and TRON on four agentic benchmarks (BFCL, MCPToolBenchPP, MCP-Universe, StableToolBench) and five open-weight LLMs, decoupling input compression from output compression to measure comprehension and generation independently. TRON reduces tokens by up to 27% with accuracy within 14pp of the JSON baseline. TOON achieves up to 18% reduction at a similar 9pp accuracy cost, but additionally cascades on multi-turn parsing failures and collapses parallel tool-call output for most models. The code is available at: https://github.com/lkutschka/notation-matters
Lorenz Kutschka, Bernhard Geiger
Know Center Research GmbH / Sandgasse 34, A-8010 Graz · Signal Processing and Speech Communication, Graz University of Technology / Inffeldgasse 16c, A-8010 Graz · Graz Center for Machine Learning // A-8010 Graz
The LLM-based generation of machine-readable outputs such as JSON has attracted significant attention for integration with external systems. However, existing approaches cannot strictly enforce the maximum number of tokens to be generated, leading to infinite generation or truncated outputs that cause a system malfunction. To address this limitation, we propose TruncProof, a novel grammar-constrained generation method that enables LLMs to produce grammatically valid JSONs while adhering to a predefined token limit. By leveraging the properties of LL(1) parsers, TruncProof efficiently approximates the minimum number of tokens required to complete a grammatically valid output at each decoding step. Experiments on the Text-to-JSON instruction tasks demonstrate that TruncProof successfully generates syntactically correct outputs even under strict token constraints. Furthermore, we show that TruncProof can be effectively combined with advanced decoding strategies, resulting in outputs that are not only grammatically valid but also semantically accurate. The source code is public at https://github.com/Yosshi999/TruncProof