Choosing a Data Format

Section 3 established that format choice is a token decision and demonstrated five encodings of the same data. This section takes the next step and answers the practical question: given a payload, which format should carry it? The short answer is that the shape of the data decides, and preference has almost nothing to do with it.

7.1 Five Shapes, and Only Five #

Nearly every payload an agent reads falls into one of five shapes. Identifying the shape is the whole of the decision, since each shape has a format that fits it and several that do not.

The third row is the one that trips people up. A trace containing HTTP spans, database spans and cache spans is not one table and it is not schema-less either. It is several schemas interleaved, and that shape has its own answer.

7.2 Schema Hoisting: TRON #

TOON (§3.1) attacks repetition by declaring a field list once and streaming rows beneath it. That works beautifully for one uniform array, and it works less well the moment a payload carries several different schemas.

TRON attacks the same repetition from the other direction. Instead of grouping rows under a table header, it hoists each repeated schema into a class definition at the top of the document and then instantiates it inline, which leaves the original record order intact.¹⁶

class H: kind,method,path,status,ms
class D: kind,table,op,rows,ms
class C: kind,key,hit,ms

[H("http","GET","/v1/items/0",200,12),
 D("db","items","select",40,3),
 C("cache","items:0",true,1),
 H("http","GET","/v1/items/1",200,13), ...]

The format is a superset of JSON, so any valid JSON document is already valid TRON, and adoption can therefore be incremental.¹⁶ The published claim is a 20 to 40 percent token reduction against JSON through schema hoisting alone.¹⁶

Measuring that trace payload at eighteen interleaved records—the four shown above continued in the same rotation, elided here for space—gives the following, in characters:

TOON is smaller, and it achieves that only by regrouping the records into three separate tables by kind. For a trace, where the interleaving is the information, that regrouping destroys the thing you were sending. TRON is larger and keeps the sequence. TOON can keep it too, in the list form it falls back to when an array fails the tabular test, and that form forfeits the saving the row above is measuring.

That is the actual trade-off in the heterogeneous case, and it is not a token comparison at all. It is a question of whether record order carries meaning.

7.3 The Selection Table #

Two entries deserve their caveats. CSV wins the first row on size alone, and it surrenders types, nesting, and any unambiguous null to get there (§3.1); where those matter, the TOON overhead of roughly six percent buys them back. And the fifth row is the one practitioners resist, since a format adopted for its savings tends to get applied everywhere. On deeply nested data TOON loses to compact JSON outright, by eleven percent on configuration trees—620 tokens against 558—and twenty percent on semi-uniform event logs, 154,084 against 128,529.⁴ That benchmark evaluates TOON, JSON, YAML, compact JSON, XML and CSV; it does not evaluate TRON, so read the row as a measured result for TOON and a reasonable expectation for TRON, which hoists schemas and has correspondingly less to hoist here. Measure it before relying on it.

7.4 What the Agentic Evidence Actually Shows #

Everything above concerns size. Size is the easy half, and it is the half every vendor benchmark measures. The harder question is whether these formats hold up inside an agent loop, where the model must not only read the payload but also generate structured calls back.

Independent work published in 2026 evaluated both TOON and TRON across four agentic benchmarks and five configurations of four open-weight models—Qwen3-32B appears twice, with thinking enabled and disabled—deliberately separating input compression from output compression so that comprehension and generation could be measured apart.¹⁷ Four findings from it should govern any adoption decision.

The paper’s own conclusion is measured, and its shape carries more than its words: it identifies TRON as a defensible drop-in for JSON in token-sensitive agentic systems, which is an endorsement bounded by two qualifiers.¹⁷

7.5 Input Format and Output Format Are Different Decisions #

This is the central distinction here, and the one most often collapsed.

Asking a model to read a compact format is a comprehension task. The formats were designed for it, the benchmarks measure it, and the models are broadly capable of it.

Asking a model to write a compact format is a generation task in a notation that appeared rarely or never in training. Separate work found the picture materially less favorable for generation than for comprehension.⁵

The safe default follows from the lane arithmetic: compress what the model reads, and let it write JSON. Input compression captures most of the available token reduction, since input outnumbers output twenty to twenty-five times in agentic work (§4.2). Whether it captures most of the spend is a different question, and the answer moves with your cache-hit rate: at Sonnet 5’s $0.20 cached read against $10.00 output, twenty-five cached input tokens come to half the charge of the one output token beside them. §21.4 is that inversion in full. Output compression captures the smaller share while carrying the generation risk above.

One qualifier belongs with that default, and it is the reason step five of the procedure below is measurement rather than trust. Reading a compact format is the safer half and it is not a free one: the 27 to 44 point collapses in §7.4 were measured with compact input and JSON output, which is exactly the configuration this rule recommends.

7.6 A Decision Procedure #

Steps five and seven are the ones that often get skipped. Unfortunately, they are the two that separate a saving from a regression.

7.7 A Note on Format Churn #

TOON, TRON, ZON, and several others emerged within roughly a year of each other, all making broadly similar claims against JSON. That churn is itself information. The category is young, the specifications are moving, tooling maturity varies by an order of magnitude between them, and independent evaluation is thin and recent.

None of that argues against adoption. It argues for a particular posture: keep JSON as the representation in your code, treat any of these as an encoding applied at the prompt boundary, and make sure the encoder is a function you can remove easily. §3.1 called TOON a translation layer, and the same framing protects you here. A translation layer can be swapped when a better one arrives, or deleted when the claimed savings fail to appear on your traffic.

7.8 Failure Modes #

• Choosing on published percentages. The dominant pattern is per-benchmark, not per-format.¹⁷
• Asking the model to generate the compact format. Comprehension and generation are different tasks, and generation in an unfamiliar notation measures worse.⁵
• Applying one format everywhere. TOON loses to compact JSON on deeply nested data, measurably; TRON is untested there (§7.3).⁴
• Regrouping records to fit a tabular format. Where order carries meaning, that is data loss disguised as compression.
• Adopting without re-running evals. A format change is a prompt change (§34.8).
• Treating CSV as a general option. It cannot carry nesting, types, or an unambiguous null, and it fails silently on all three.