TOON is terrible, so I invented a new format (TRON) to prove a point
Posted by No-Olive342@reddit | LocalLLaMA | View on Reddit | 76 comments
There's been a lot of noise around TOON lately. This so-called "Token oriented" object notation is only useful when serializing an array of unnested objects. But lets face it, most practical use cases involve nested objects - a structure that almost always makes TOON less token efficient than JSON. Just look at the response payload for [listing MCP tools for GitHub](https://gist.github.com/didier-durand/2970be82fec6c84d522f7953ac7881b4) for instance.
I've noticed that most people posting about TOON are comparing its token count with indented JSON. That's CHEATING. If you're going to compare token count, you gotta compare with compressed JSON.
However, I do admit that there is some token inefficiencies with (compressed) JSON such as the repeating property names for common object structures. However, I didn't want to complain about TOON without providing my own suggestion so I invented this data format called TRON (Token Reduced Object Notation) as a feasible alternative.
Specifications: https://tron-format.github.io/
Playground: https://tron-format.github.io/#/playground
JavaScript SDK: https://github.com/tron-format/tron-javascript
Feel free to check out the Playground to try out TRON on your data.
(P.S. I already spent more time than I'd like coming up with this format and creating the website and JavaScript SDK. Maybe this catches on, maybe not. But for now, unless there is passion in the community to push this forward, I will refrain from spending additional time on this)
MrSomethingred@reddit
TOON and TRON both suck, I am proud to announce, "Good Object Oriented Notation" - GOON
stingraycharles@reddit
People seem to forget that LLMs are trained extremely well and extensively on XML and JSON, a benefit you’ll lose when using weird NIH-like formats.
I’d argue even YAML is better than TOON or any alternatives.
Equivalent_Cut_5845@reddit
I think yaml will be way better than any of these weird alternatives. The yaml rule is clearly defined and trained, and transfering from json to yaml is easy
egomarker@reddit
Yeah GOON baby
No-Olive342@reddit (OP)
This is actually a good idea. Hopefully, this syntax is not confusing for llms
egomarker@reddit
vs. already outdated TRON
galvinw@reddit
Turning the most dedicated localLLaMa into gooners might be easier than you think
TomieNW@reddit
make this happen <3 I will support you.
lasizoillo@reddit
GOONies is the serializer for boomers
Lyuseefur@reddit
GOON Fleet member checking in. I’m ready to GATE camp.
Mediocre-Method782@reddit
I think you've got the "can't stop, won't stop" edge with this one
o5mfiHTNsH748KVq@reddit
Google, you have a chance to do something hilarious.
No-Olive342@reddit (OP)
Haha, go for it! Honestly, I don't think it's that hard to come up with something more token efficient than TOON for practical use cases. Better GOON getting traction than TOON
MrSomethingred@reddit
I'm just shitposting, I don't actually have anything lol
Eyelbee@reddit
To be frank I never knew TOON existed but apparently it could have saved a lot of dollars for me in the past. I'd look into options like this if I knew.
No-Olive342@reddit (OP)
I think TOON has only existed for around a month so you're not that late? Be sure to test your use case first (such as in my playground link), as TOON ends up being worse than JSON (in token efficiency) in a lot of real world cases
Eyelbee@reddit
Yeah, I will certainly look into it next time. Btw I can totally see TRON catching up too, there might be some more headroom but this is totally useable and great for a start.
devshore@reddit
Missed opportunity to call it Troon
garloid64@reddit
Is there actually any point to these projects? LLMs weren't trained on this weird crap, obviously demanding output or providing input in a format like this will degrade performance. Unless you can get OpenAI on board and have them convert everything in their training data...
lordpuddingcup@reddit
lol if you give an example of simple formats like this the AI can use them perfectly fine the issue is they aren’t actually useful as csv tends to outperform almost every other format for density for flat data and for more complex data there already tons of low verbosity formats pretty sure yaml is less verbose than json json is just the easy punching bag
selund1@reddit
Most times yes, it matters more on larger scales where failures pop up more often. Like let's say in context learning works 99% of the times and you have 10k requests that's 100 failures. Dial it up and it gets worse etc. Depends on your economy of scale.
Take coding as an example: reading 10k lines of code is nothing, then add 99% reliability on top and you lose context on 100 lines of code (naively). If those 100 lines it's gonna degrade the accuracy of your model even more so.
Hence my advice here: if you can afford to lose context go for it, if you can't then don't. It's not perfect and we should be mindful of it's limitations and impact depending on how we use it.
Similarly as to when you use compression to compress any other type of data. You don't by default use compression for example on every piece of data to save space on your disk, only when you can't afford to store it in full etc etc
cobbleplox@reddit
I highly doubt anything based on in-context learning can be as reliable as something based on actual pre-training data. I would even say the same if it was "only" finetuned on it. Sure there is the question of what works well enough, but still.
selund1@reddit
saves $ at the cost of accuracy. Spot on re training data, these LLMs have been fine-tuned like crazy on json to be better at coding & api management. If you care about accuracy you shouldn't be using any compression at all imho. If you care about $/token spend then you should, but it'll cost you in accuracy
das_war_ein_Befehl@reddit
If you’re using it to feed context, then training on it or not shouldn’t matter…?
The training bit becomes more important in output or shit like tool use (they don’t use your weird mcp server unless it was trained on it)
garloid64@reddit
I wouldn't be so sure about that, the shape of JSON in itself conveys meaning. It's a sure indicator of data structured in a particular way. I'd need to see some benchmarks to know how much difference it makes.
Lyuseefur@reddit
TOON is actually good for code docs
XMasterDE@reddit
Thank you for saying that. You have no idea how annoyed I am at people trying to re-invent some prompting formats, while none of the models were ever trained on them.
ExchangeObjective866@reddit
Toon is terrible for autoregresive models like LLM. Also tron standards do not get it. Saving tokens is NOT enough. Good format should aim for accuracy and helping LLM produce better results
my_name_isnt_clever@reddit
I don't have data to back it up, but I swear XML is more easily understood by LLMs despite being more token heavy.
In my experience when the tags have a newline before the content, the tags break into two tokens each:
<|document>and<\|document>. This means thedocument>token is the exact same ID and is present at the start and end of that content, it's really clear the first one is "start of document" and the second is "end of document".This is compared to formats like JSON where it has to figure out what part of the data the closing braces or quotes are referring to in an ocean of braces and quotes. Here, the model can't just make the direct correlation between two of the same token IDs wrapping the content, and instead has to rely on it's smarts to figure out which closing quote/brace is the right one.
I feel like this would benefit smaller models more than larger ones. I should put together an eval about this so it's not just a hunch.
ExchangeObjective866@reddit
You are right, xml is the easiest for LLM, especially when no escaping is needed. Many already switched to xml
valdev@reddit
The leading theory on why that is, is due to the vast amount of HTML data LLMs are trained on.
my_name_isnt_clever@reddit
Makes sense. Sounds like something we can take advantage of, rather than a new format like this they've never seen before.
sleepingsysadmin@reddit
I exclusively use VSC instead of TRON.
Balance-@reddit
Quick comparison
I like that it reads like Python.
ALIEN_POOP_DICK@reddit
You say TOON is terrible but provide absolutely no benchmarks for TRON's performance.
At least the TOON devs tested LLM understanding and retrieval accuracy across a few models.
To me that's way more important than saving a few tokens.
kwokhou@reddit
TOON is pretty bad and deeply nested data
No-Olive342@reddit (OP)
Come to think of it, I shouldn't be the one creating the accuracy benchmark. It should be created by a third party with no bias.
Hot-Employ-3399@reddit
Picking one's nose is more important than picking up abandonware-on-birth project to see if it proves what it claims or not.
Especially in a world of people with csv and other things to do.
No-Olive342@reddit (OP)
"abandonware-on-birth" might be a little extreme. I'm kind of testing the waters to see if there is any interest in the community, and go from there. Just no active plans currently
Hot-Employ-3399@reddit
"I will refrain from spending additional time on this" is hard to read other way. If you refrain from spending additional time, you are refraining from using it yourself. If it is good at solving actual problems community feedback is meaningless.
No-Olive342@reddit (OP)
"unless there is passion in the community to push this forward, I will refrain from spending additional time on this"
colin_colout@reddit
Toon has an accuracy benchmark in their github repo. They assessed themselves and found accuracy to be 100%
No-Olive342@reddit (OP)
Yeah, that's fair. I had to put this aside for other commitments and didn't have time to do an accuracy benchmark (would be interesting to see if there's anyone in the community that wants to test this).
Anyways, this is part of the reason why I made the syntax look like Python (for llm interpretability).
pier4r@reddit
new benchmark idea for LLMs.
Come up with such formats, they have to beat a ubiquitous but not efficient format (say YAML), without replicating a known format.
PlusIndication8386@reddit
No-Olive342@reddit (OP)
Haha yeah, this is why I was conflicted whether to making this reddit post. As I said in the P.S., I'm no longer pushing for this unless there is real interest. Just wanted to let the world know that TOON isn't the answer.
ComingInSideways@reddit
Honestly coming from any language which uses class declarations this structure makes a lot of sense and will only gain in size advantages as size of data goes up. But really you had me at being able to add comments. :) The one thing I would add for much better sizes on large lists of items is a something, like lets call it a “Class Group”, so instead of:
——-
You have something like:
Not a big reduction in this but in situations where you have hundreds of “Products”, you save quite a bit, plus you really don‘t reduce readability.
All in all I like this format.
egomarker@reddit
Every object in the list can be different tho.
ComingInSideways@reddit
Sure, but for runs of list objects you can group them. You could just as easily have two successive groups of different objects.
Lyuseefur@reddit
IMHO, XKCD should be the only CS course in college. It legit covers every point.
BudgetDevv@reddit
Ngl this is the first thing I thought of
shotbyadingus@reddit
For a second there I thought you were going to lie about what you first thought!
Cool-Chemical-5629@reddit
This is a good meme.. oh wait a minute, what's this: "SEE: A/C CHARGERS, CHARACTER ENCODINGS, INSTANT MESSAGING, ETC."? We need to make one universal standard meme that covers everyone's use cases.
egomarker@reddit
Why not just use javascript for your data then.
No-Olive342@reddit (OP)
Good question. I essentially took a subset of Python syntax and trimmed it down to remove the boilerplate for definition classes without type annotation. Unlike Python, TRON is restricted to just a header section (for class definitions) and data section. I didn't want to bloat it with too many rules so that people coming from any programming language can easily understand it.
I did have to make some new rules though. For instance, with TRON you can enclose property names in quotes if it is not alphanumeric with underscores. This makes it fully interoperable with any JSON data (such as easily translating to and from JSON payloads provided by API services with one line of code).
guesdo@reddit
At what point using plain TypeScript is just better?
Mundane_Ad8936@reddit
SERAX is not only extremely token efficient but it also adds data types that can be checked with normal code checks. It uses uncommon special characters as smart delineators which adds a lot of checkpoints for code based QA checks.
If the field is supposed to be an integer it will be declared in the delineator. It also supports complex types so if a field is supposed to be a email address you can easily check that.
We use it for fine-tuning models using using a rust based custom validation, to ensure data generation quality is as accurate as possible.
Chromix_@reddit
There was a TOON hype, then people came up with "improvement" like LoraTokens or Tauq. What they have in common is a one-dimensional benchmark: How short can it get. TOON at least has some retrieval benchmarks, even with statistically non-significant results and cherry-picking.
The interesting part is how much accuracy you really lose when you switch to one of those formats. The TRON format is code-like. LLMs are good with that, so much that there's the new "replace MCP with code" approach. Thus, it might actually be interesting here to see some accuracy benchmark results.
Recent-Success-1520@reddit
What's wrong with YAML?
lordpuddingcup@reddit
Except for the fact for flat data csv is still best format has been shown many times
Former-Ad-5757@reddit
For larger non-flat data you can also use csv within csv by just changing the deliminator for each level ;) Better llm's will still understand it.
__some__guy@reddit
I guess simply adding an R after the T would not have been allowed on Github.
Trojan_Horse_of_Fate@reddit
This seems really cool and I'm very impressed but I'm going to stick to using JSON
Googulator@reddit
Time to inteoduce the Format Unburdened by Conventional Konstraints.
Mayion@reddit
SQL's long lost son
quantum_splicer@reddit
I am not going to lie it's 3 am here I am so confused.... I thought I was up to date with everything now I have even more to read up on
blbd@reddit
I mean... if you don't want to repeat common columns there's always CSV. 😈
Single-Blackberry866@reddit
TOON reinvented CSV. TRON reinvented CTON which reinvented OOP.
Repulsive-Memory-298@reddit
Really there should be a standard for how the interference provider handles tool results, or really really that should be part of the models specs
Sudden-Lingonberry-8@reddit
toon has prettier output
AleksHop@reddit
ALS Specification (The Theoretical Limit)
1. The Core Innovations (Why it beats CTX)
2. The Comparison (The "Holy Grail" Efficiency)
Scenario: A list of 100 orders.
JSON (Approx. 2,500 Tokens)
TRON (Approx. 900 Tokens)
CTX (Approx. 250 Tokens)
(CTX fails here because it still lists every single value.)
ALS (9 Tokens - 27,000% Better)
AleksHop@reddit
do you really want to try to replace json? good luck
o5mfiHTNsH748KVq@reddit
json isn't great for LLMs to make sense of
No-Olive342@reddit (OP)
I'm not pushing for this (at least not for the forseeable future). Just wanted to share my thoughts since this new format called TOON is gaining traction because it's being heavily marketed when it's not a practical format at all.
Background_Essay6429@reddit
Your benchmark conflates encoding efficiency with parsing speed. JSON's verbosity isn't the bottleneck—it's tokenization overhead in the model itself. Are you controlling for schema complexity? TRON might win on uniform arrays but explode on deeply nested heterogeneous objects. Did you test with realistic API payloads?
No-Olive342@reddit (OP)
Not sure what you mean about parsing speed (the image shows token count), but I agree that the llm tokenizer is part of the issue. Formats like TOON (and TRON) wouldn't exist (and shouldn't exist) if the tokenizer was more efficient working with JSON and didn't treat every identical property name as different tokens.
And yeah, all the preset datasets in the playground are from realistic API payloads. I included sources for them on the page.