Skip to content
Gordon GeraghtyGet in touch
Selected work

Marketing · Empire Amplify

XRON — open source

Up to 80% fewer LLM tokens

An open-source, lossless data serialization format built in TypeScript that cuts JSON LLM token consumption by up to 80%.

  • TypeScript
  • Open source
  • LLM

XRON is a lossless data serialisation format that reduces JSON LLM token consumption by up to 80 per cent. It's open source and written entirely in TypeScript.

The problem

JSON was designed for parsers and people, not per-token pricing. Every repeated key, brace, and quote mark costs tokens that carry zero new information for the model. In agent systems that pass structured data through a model many times per task, that overhead compounds into real cost and exhausted context windows.

The format

XRON keeps every byte of information--lossless is the operative word--while stripping the redundancy. It's lightweight and fast, built to optimise context-window usage and slash GPT and Claude costs for agents operating over long conversations.

The repository is public on GitHub. For anyone running multi-step LLM workflows over structured data, the maths is simple: the exact same information, at a fraction of the token cost.

XRON, live

XRON is an open-source serialisation format built to cut the LLM tokens a JSON payload costs while decoding back to exactly what went in. That second half is the whole claim, so this page tests it rather than asking you to take it on trust: the published library runs in your browser — no network call, no client data — on whatever you paste, and the encoding, the level and the round-trip check all recompute as you type.

Compression level

519 characters

After — XRON Level 3 (auto picked this level)

@v3
@C a8ccdfc1
@S A: event, channel, value, currency, consented?b
@D: paid_search
@X:
@N4 A
purchase	$0	128.5	AUD	1
add_to_cart	~	64	~	~
purchase	paid_social	96.25	~	0
begin_checkout	organic	210	~	1

199 characters

62% fewer characters than the JSON on the left.

The library’s own read of this payload: Schemas + dictionary encoding beneficial (est. ~80% reduction). No sequential numeric columns for delta encoding. It advises Level 2 here, while auto mode wrote Level 3 — the advisory and the encoder don’t always agree, and the label above reports what was actually written.

Round-trip check: decoded back through XRON.parse and compared to your input — identical.

  • Reduction estimates are heuristic (char-based). Actual token savings depend on the BPE tokenizer used.
  • Small payloads: XRON header lines (@v, @S) add a fixed token cost. For payloads under ~500 bytes, the net token saving may be under 10%.
  • Thin dictionary: only a few values qualify for dictionary encoding. The @D header adds overhead that partially offsets the savings.

Encoded by xron-format itself, not a re-implementation. Characters are exact; no token count is shown here because an honest one needs the GPT-4o BPE tables and a guess dressed as a measurement is worse than no number. The measured token figures are below. The caveats above are the library’s own.

Short, medium, long

XRON doesn’t apply one fixed transform at one fixed rate. It reads the shape of the payload and picks a level: extract a schema, add a dictionary for values that recur, add delta encoding for numbers that climb in a straight line. Below is the same encoder over three payloads of different size and shape, with the level it chose for each and what that actually bought.

Choose a payload size

A nested configuration object. No object shape repeats, so there are no keys to write once and reuse — XRON’s main lever never engages.

XRON chose Level 1. No repeating object shapes found. Schema extraction (L2/L3) would add header overhead with no key-compression benefit.

Before — JSON

{"property":{"id":"G-XXXXXXX","name":"Sample property","timezone":"Australia/Sydney"},"collectio
n":{"serverSide":true,"endpoint":"sgtm.example.com","consentMode":"advanced"},"conversions":{"pu
rchase":"primary","qualified_lead":"primary","newsletter":"secondary"},"attribution":{"model":"d
ata-driven","lookbackDays":90}}

After — XRON Level 1

@v1
@C cc0ffc1f
{property: {id: G-XXXXXXX, name: Sample property, timezone: Australia/Sydney}, collection: {serverSide: true, endpoint: sgtm.example.com, consentMode: advanced}, conversions: {purchase: primary, qualified_lead: primary, newsletter: secondary}, attribution: {model: data-driven, lookbackDays: 90}}
GPT-4o tokens
75 to 8716% more
Characters
319 to 3122% fewer
Decoded back to the input
Byte-identical

This is the case worth showing. The payload got 2% shorter in characters and 16% longer in tokens: nothing repeats, so there are no keys to write once, and the format’s header lines are pure overhead. A compression format that only ever gets shown its best case isn’t being demonstrated.

  • Reduction estimates are heuristic (char-based). Actual token savings depend on the BPE tokenizer used.
  • Small payloads: XRON header lines (@v, @S) add a fixed token cost. For payloads under ~500 bytes, the net token saving may be under 10%.
  • No repeating object shapes: XRON's biggest saving (key elimination) only activates when the same object shape appears ≥2 times.

30 rows sharing one shape, with a handful of channel names that recur and a timestamp that advances by one hour.

XRON chose Level 3. Full compression stack beneficial: schemas + dictionary + delta encoding (est. ~85% reduction).

Before — JSON

[{"ts":"2026-06-01T00:00:00.000Z","channel":"paid_search","sessions":1200,"conversions":18,"devi
ce":"mobile"},{"ts":"2026-06-01T01:00:00.000Z","channel":"paid_social","sessions":1237,"conversi
ons":19,"device":"desktop"},{"ts":"2026-06-01T02:00:00.000Z","channel":"organic","sessions":1274
,"conversions":20,"device":"tablet"},{"ts":"2026-06-01T03:00:00.000Z","channel":"email","session
s":1311,"conversions":21,"device":"mobile"},{"ts":"2026-06-01T04:00:00.000Z","channel":"direct",
"sessions":1348,"conversions":22,"device":"desktop"},{"ts":"2026-06-01T05:00:00.000Z","channel":
… 28 more lines

After — XRON Level 3

@v3
@C 20c5c9f6
@S A: ts, channel, sessions, conversions, device
@D: paid_search, paid_social, mobile, desktop, tablet, organic, email, direct
@X: 0, 2, 3
@N30 A
… 30 more lines
GPT-4o tokens
1,095 to 58047% fewer
Characters
3,191 to 77676% fewer
Decoded back to the input
Byte-identical

Note the gap: 76% fewer characters but only 47% fewer tokens. Character counts are the easy number to quote and the wrong one to budget against — a tokeniser doesn’t charge by the character, and shortening text it already packed efficiently wins less than the character count suggests.

  • Reduction estimates are heuristic (char-based). Actual token savings depend on the BPE tokenizer used.

500 event rows sharing one shape, with a sequential id, a value that climbs by a constant step, repeated labels, and a templated client id.

XRON chose Level 3. Full compression stack beneficial: schemas + dictionary + delta encoding (est. ~85% reduction).

Before — JSON

[{"id":1,"event":"purchase","channel":"paid_search","client_id":"cid-1000-au","value":4000,"cons
ented":false,"ts":"2026-06-01T00:00:00.000Z"},{"id":2,"event":"add_to_cart","channel":"paid_soci
al","client_id":"cid-1001-au","value":4025,"consented":true,"ts":"2026-06-01T01:00:00.000Z"},{"i
d":3,"event":"begin_checkout","channel":"organic","client_id":"cid-1002-au","value":4050,"consen
ted":true,"ts":"2026-06-01T02:00:00.000Z"},{"id":4,"event":"view_item","channel":"email","client
_id":"cid-1003-au","value":4075,"consented":true,"ts":"2026-06-01T03:00:00.000Z"},{"id":5,"event
… 734 more lines

After — XRON Level 3

@v3
@C c5308186
@S A: id, event, channel, client_id, value, consented?b, ts
@D: begin_checkout, add_to_cart, view_item, paid_search, paid_social, purchase, organic, email, direct
@X: 0, 4, 6
@T 3: cid-1{}-au
… 501 more lines
GPT-4o tokens
25,203 to 10,59258% fewer
Characters
71,028 to 13,22981% fewer
Decoded back to the input
Byte-identical

Note the gap: 81% fewer characters but only 58% fewer tokens. Character counts are the easy number to quote and the wrong one to budget against — a tokeniser doesn’t charge by the character, and shortening text it already packed efficiently wins less than the character count suggests.

  • Reduction estimates are heuristic (char-based). Actual token savings depend on the BPE tokenizer used.

Size is not what decides the saving — shape is. What XRON removes is repeated key text, so the win scales with how much of a payload is field names rather than values. On a deliberately favourable shape — a thousand rows, thirty long column names, values drawn from a three-item vocabulary — the same encoder takes 330,003 GPT-4o tokens down to 59,290. That is an 82% cut in tokens, and it decodes back byte-identical. The three payloads above are ordinary shapes rather than that one, so read 80% as the ceiling and these as the middle of the range.

Encoded by xron-format, the published library, at the level its own recommend() selected — not a re-implementation. Token counts are real GPT-4o (o200k_base) counts, measured at build time by scripts/xron-scales.mjs, which also decodes every payload back through XRON.parse and refuses to publish these figures if any of them fails to match its input. The caveats above are the library’s own, reported by recommend(). All three payloads are synthetic sample data.

View the repoRead: “Why JSON wastes LLM tokens, and the lossless fix”

View source

Frequently asked questions

Where can I find and install XRON?
The XRON format is open source and published on NPM. You can install it via npm i xron-format. The source code is available at https://github.com/gordongeraghty/XRON.
Is XRON lossless?
Yes, XRON is built to be lossless. The format accurately serializes and deserializes data structures while reducing LLM token cost.

Related reading Why JSON wastes LLM tokens, and how to fix it without losing data

More in Marketing

View all