Token-Oriented Object Notation (TOON) for reducing Tokens.

[DirtyHamster]

@Wendy-Nam This is a different notation format that supposedly saves on tokens beyond what I mentioned before, and it works well with LLMs: https://github.com/toon-format/toon

From their examples for the same small data set:

JSON would be like:
{
"context": {
"task": "Our favorite hikes together",
"location": "Boulder",
"season": "spring_2025"
},
"friends": ["ana", "luis", "sam"],
"hikes": [
{
"id": 1,
"name": "Blue Lake Trail",
"distanceKm": 7.5,
"elevationGain": 320,
"companion": "ana",
"wasSunny": true
},
{
"id": 2,
"name": "Ridge Overlook",
"distanceKm": 9.2,
"elevationGain": 540,
"companion": "luis",
"wasSunny": false
},
{
"id": 3,
"name": "Wildflower Loop",
"distanceKm": 5.1,
"elevationGain": 180,
"companion": "sam",
"wasSunny": true
}
]
}

YAML would be like:
context:
task: Our favorite hikes together
location: Boulder
season: spring_2025
friends:

• ana
• luis
• sam
  hikes:
• id: 1
  name: Blue Lake Trail
  distanceKm: 7.5
  elevationGain: 320
  companion: ana
  wasSunny: true
• id: 2
  name: Ridge Overlook
  distanceKm: 9.2
  elevationGain: 540
  companion: luis
  wasSunny: false
• id: 3
  name: Wildflower Loop
  distanceKm: 5.1
  elevationGain: 180
  companion: sam
  wasSunny: true

TOON is like this:

context:
task: Our favorite hikes together
location: Boulder
season: spring_2025
friends[3]: ana,luis,sam
hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}:
1,Blue Lake Trail,7.5,320,ana,true
2,Ridge Overlook,9.2,540,luis,false
3,Wildflower Loop,5.1,180,sam,true

At any rate hope you're doing ok and thought you might like this as we briefly touched on conserving token usage and using YAML to do some of that, but this markup happens to be even more compact and remains fairly easy to read.

[Wendy-Nam]

@DirtyHamster

Wow, this is such an innovative approach! Thank you for sharing it. I’m doing well, too.

I’ve been having difficulty finding an engineering role, and as the gap grew longer, I started working in healthcare sales temporarily to cover living expenses. Because of that, my response is a bit late.

I hope to revisit the project soon and actively update this repository again. Thank you for continuing to share such great insights!

[DirtyHamster]

@Wendy-Nam Good to hear that you're doing well. No-problem on the late response, and I can completely understand. Not getting in the field you want first is sometimes lucky though, such as experiencing how sales in healthcare works could be useful later in an engineering role in the same industry. Something like that can give you a leg up on someone that doesn't have the same expanded background sometimes.

I rather like their approach too, it's smoothly compact while retaining what's really necessary for structured data. I've been looking at this within the pipeline of RAG and CAG system pipelines for long-term memory too. From what I gathered understanding wise this could either be used as the drop-in replacement for those other notation file types or used post query to store the query data before sending off to the LLM. Either should still save on token costs just from the reduction in extra characters.

There was a paper from a few years ago that you might find interesting similarly looking at the issues with db usage for memory retention in LLMs: https://www.ischool.berkeley.edu/projects/2024/llm4llm-longer-lasting-memory-llms
This one example uses a standard db but a vector db would also work and might work better for lore type of context, where structure is kind of lesser resource over natural language in bulk. If you look at their results: https://kdai11830.github.io/ll-dm/#performance there is a definitive accuracy gain in retention even over something simple like quantity of item in a player's inventory.

I've also been looking at MCP servers for handling various smaller RPG dungeon master type of tools along with the long-term memory. I think in the earlier posts I showed you some for randomized themed character naming, town generators and similar. This might be the topic of my next post to your project if I get into a deeper dig. As long as the smaller program can output to the same notation type file, in the structure needed it should function and might be able to automate some of the set up that you're currently manually doing setup. These types of small programs could be interchangeable too which is kind of similar to what I meant when I said explore building it as independent systems that can be reused and replaced. i.e. elf name generator is the same as dwarf name generator with some rules swapped out why not use both. Some examples: https://github.com/procload/dnd-mcp?tab=readme-ov-file or https://mcpservers.org/servers/study-flamingo/gamemaster-mcp So in stages you might do DnD 5e to open D to whatever rule set your doing where lore and rules get segregated and incorporated separately on input into the context set.

I hope you get a chance to revisit it too; it's an interesting project. Contributing also helps me; I get to redigest and discus some of these topics that aren't necessarily geared towards the gaming aspects that I'm often looking to use them for. I often wonder if it's the right rabbit hole I'm jumping into when looking at this stuff especially with pipeline flows lol (feels very mario-ish with pipes).

All fun stuff right :)