El ecosistema de modelos de lenguaje lleva tiempo buscando maneras de meter más datos en menos tokens. JSON es el estándar de facto para representar estructuras complejas, pero también es ruidoso, repetitivo y caro cuando se envía a un LLM. Sobre ese problema se apoya TOON (Token-Oriented Object Notation), un formato abierto pensado específicamente para prompts de Inteligencia Artificial que promete reducir el coste de tokens y mejorar la comprensión de los modelos sin renunciar a la estructura de JSON.
El proyecto, publicado como software libre bajo licencia MIT, llega con especificación propia, benchmarks detallados y un SDK en TypeScript. La idea es sencilla: seguir usando JSON en el código… y traducirlo a TOON justo antes de enviarlo al modelo.
De JSON verboso a TOON compacto
El punto de partida es conocido. Un objeto de usuarios en JSON se ve así:
{
"users": [
{ "id": 1, "name": "Alice", "role": "admin" },
{ "id": 2, "name": "Bob", "role": "user" }
]
}
Lenguaje del código: JSON / JSON con comentarios (json)YAML reduce algo de ruido sintáctico:
users:
- id: 1
name: Alice
role: admin
- id: 2
name: Bob
role: user
TOON lleva esa idea un paso más allá:
users[2]{id,name,role}:
1,Alice,admin
2,Bob,user
En una sola cabecera declara:
- El nombre de la colección (
users). - El número de elementos (
[2]). - Las claves que tendrá cada fila (
{id,name,role}).
Debajo, cada línea es una fila de datos separada por un delimitador (coma, tabulación o barra vertical). Para un LLM, esta representación es más corta y, al mismo tiempo, más fácil de seguir: el modelo sabe cuántas filas esperar, qué campos habrá en cada una y en qué orden.
Qué es exactamente TOON
TOON es, en esencia, una forma alternativa de serializar JSON optimizada para prompts:
- Usa indentación al estilo YAML para la estructura de objetos anidados.
- Adopta un formato tabular para arrays uniformes de objetos (las típicas tablas de “registros”).
- Mantiene el modelo mental de JSON: las conversiones entre ambos son pérdida cero.
- Reduce al mínimo la sintaxis: menos llaves, corchetes y comillas.
Su “zona dulce” son los arrays uniformes de objetos: colecciones grandes donde todos los elementos comparten la misma estructura. En esos casos, los autores del formato reportan ahorros de entre un 30 y un 60 % de tokens frente a JSON formateado y una mejora clara en la capacidad de los modelos para recuperar datos.
En estructuras muy anidadas o poco uniformes, en cambio, el propio proyecto reconoce que JSON (especialmente en versión compacta/minificada) puede seguir siendo más eficiente.
Dónde no conviene usar TOON
Los responsables del proyecto son bastante explícitos con las limitaciones:
- Configuraciones profundamente anidadas o con campos muy heterogéneos: el formato tabular deja de aplicar y TOON pierde parte de sus ventajas.
- Arrays semiestructurados, con solo un 40–60 % de “elegibilidad tabular”: el ahorro de tokens respecto a JSON se reduce y la complejidad no siempre compensa.
- Datos puramente tabulares y planos: CSV sigue siendo más compacto. TOON añade un ligero overhead (≈ 5–10 %) a cambio de aportar estructura y validación.
- Escenarios ultra sensibles a la latencia: menos tokens no siempre significa menor tiempo de respuesta; conviene medir en cada despliegue concreto.
La filosofía es pragmática: TOON no pretende sustituir a JSON o CSV en todos los contextos, sino ocupar un nicho muy concreto donde la relación entre tokens, estructura y fiabilidad favorece claramente a este nuevo formato.
Qué dicen los benchmarks: menos tokens, más aciertos
El repositorio de TOON incluye un conjunto de benchmarks con 209 preguntas de recuperación de datos sobre distintos conjuntos y cuatro modelos diferentes. El ranking de “eficiencia” se calcula combinando precisión y coste de tokens.
Eficiencia global por formato
(precisión por 1.000 tokens en el conjunto completo)
| Formato | Precisión | Tokens usados | Índice de eficiencia |
|---|---|---|---|
| TOON | 73,9 % | 2.744 | 26,9 |
| JSON compacto | 70,7 % | 3.081 | 22,9 |
| YAML | 69,0 % | 3.719 | 18,6 |
| JSON | 69,7 % | 4.545 | 15,3 |
| XML | 67,1 % | 5.167 | 13,0 |
El dato más llamativo es que TOON logra un 73,9 % de aciertos frente al 69,7 % de JSON, usando un 39,6 % menos de tokens en estos experimentos.
Por modelos individuales, el patrón se mantiene:
- En modelos ligeros como claude-haiku o grok-4-fast, TOON lidera la tabla o empata con JSON compacto, con varios puntos extra de precisión.
- En modelos más potentes, como gemini-2.5-flash o gpt-5-nano, TOON se sitúa en la parte alta:
- gpt-5-nano alcanza un 90,9 % de acierto con TOON y JSON compacto, por encima de JSON clásico (89,0 %).
- gemini-2.5-flash escala hasta el 87,6 % con TOON, por encima de JSON y YAML.
En el “track” de estructuras mixtas (anidadas y semiestructuradas), TOON reduce el recuento de tokens frente a JSON en torno a un 21,8 % en total, aunque JSON compacto sigue siendo algo más pequeño en ciertos datasets muy poco tabulares. En el “track” plano, CSV es aún el rey en tamaño, pero TOON se queda solo un 6 % por encima ofreciendo mucha más estructura.
Sintaxis: menos ruido, misma información
La especificación de TOON introduce varias ideas pensadas para facilitar la vida a los modelos:
- Longitud de arrays explícita:
items[3]indica de antemano cuántas filas debe ver el modelo. - Cabeceras de campos para arrays tabulares:
items[2]{sku,qty,price}:declara la estructura una vez. - Delimitador configurable: coma, tabulación (
\t) o barra vertical (|), lo que permite ajustar aún más la tokenización. - “Key folding” opcional: cadenas de un solo campo anidado pueden colapsarse en rutas con puntos (por ejemplo,
data.metadata.items[2]: a,b) para reducir indentaciones sin perder la capacidad de reconstruir el JSON original. - Reglas de comillas inteligentes: solo se cita lo estrictamente necesario; las cadenas que parecen números, booleanos o
nullse fuerzan entre comillas para evitar malas interpretaciones.
El resultado es un formato que se lee casi como una mezcla de YAML y CSV, pero con garantías claras de ida y vuelta a JSON.
Implementaciones y herramientas: listo para usar
TOON llega ya con un CLI oficial y una librería TypeScript:
- Conversión rápida desde línea de comandos:
# JSON → TOON npx @toon-format/cli data.json -o data.toon # TOON → JSON npx @toon-format/cli data.toon -o data.jsonSe puede elegir delimitador, ver estadísticas de ahorro de tokens (--stats) o activar el plegado de claves (--key-folding safe). - SDK en TypeScript/JavaScript:
import { encode, decode } from '@toon-format/toon' const data = { users: [ { id: 1, name: 'Alice', role: 'admin' }, { id: 2, name: 'Bob', role: 'user' } ] } const toon = encode(data) const backToJson = decode(toon)
Además, ya hay implementaciones (algunas en desarrollo, otras comunitarias) en .NET, Go, Python, Rust, Java, Kotlin, Ruby, PHP, Swift, entre otros lenguajes, lo que facilita integrarlo en pipelines existentes.
Cómo usar TOON con modelos de lenguaje
La recomendación práctica es:
- Para entrada (input): encapsular los datos TOON en un bloque de código, por ejemplo:
```toon users[3]{id,name,role}: 1,Alice,admin 2,Bob,user 3,Charlie,userEl modelo puede navegar la tabla y responder preguntas de recuperación de datos con mayor fiabilidad. - Para salida (output): mostrar al modelo un ejemplo de cabecera y especificar reglas claras: número de filas, delimitador, indentación y ausencia de texto fuera del bloque. De este modo, la generación de tablas estructuradas resulta más predecible.
¿Sustituirá TOON a JSON?
La propuesta de sus autores es más pragmática que rompedoramente revolucionaria: TOON no quiere reemplazar JSON en APIs, bases de datos o ficheros de configuración, sino actuar como una capa de traducción optimizada para prompts.
Para quienes trabajan con grandes contextos, RAG, analítica de datos o tablas extensas en prompts, TOON ofrece tres ventajas claras:
- Menos tokens para la misma información.
- Estructura más explícita y validable, que reduce errores al leer o generar datos.
- Mejor equilibrio entre compacidad y legibilidad humana frente a JSON minificado o CSV puro.
En un momento en que cada token cuenta —por coste, por velocidad y por claridad de contexto—, es probable que muchos equipos al menos prueben a añadir TOON como una pieza más de su caja de herramientas para trabajar con modelos de lenguaje.
Preguntas frecuentes sobre TOON
¿Qué ventajas ofrece TOON frente a JSON en prompts de modelos de lenguaje?
TOON reduce el ruido sintáctico y la repetición de claves, especialmente en arrays grandes y uniformes. Eso se traduce en menos tokens consumidos y en una estructura más fácil de seguir para el modelo, con longitudes de arrays y cabeceras de campos explícitas. Los benchmarks publicados muestran mejoras de precisión de varios puntos porcentuales frente a JSON, usando bastantes menos tokens.
¿Cuándo es mejor seguir usando JSON o CSV en lugar de TOON?
JSON sigue siendo preferible en estructuras muy anidadas, configuraciones complejas y datos poco uniformes, donde el formato tabular de TOON deja de aplicarse. CSV, por su parte, continúa siendo el formato más compacto para tablas totalmente planas sin anidamiento. TOON ocupa el punto intermedio: algo más grande que CSV, pero con suficiente estructura como para que los LLM gestionen y validen mejor la información.
¿Cómo se integra TOON en una aplicación existente que ya usa JSON?
La integración típica consiste en mantener JSON como formato interno y de API, y convertir a TOON justo antes de llamar al LLM. Con el CLI o el SDK de TypeScript se puede automatizar la conversión JSON → TOON y TOON → JSON, añadiendo opciones como delimitadores personalizados o plegado de claves. Así se aprovechan las ventajas en prompts sin tocar la lógica principal de la aplicación.
¿Es TOON adecuado como formato de almacenamiento o para diseñar APIs?
El propio proyecto desaconseja usar TOON como sustituto de JSON en almacenamiento persistente o interfaces públicas. Está pensado para comunicación con modelos de lenguaje, donde la tokenización y la legibilidad para el modelo importan más que la compatibilidad de herramientas. Para bases de datos, APIs REST o mensajes entre servicios, JSON, Protobuf o formatos similares siguen siendo opciones más estándar.
Más información en github.com.
