TOON: ¿puede reemplazar realmente a JSON para los LLM?

En la era de los grandes modelos de lenguaje, o LLMs, los tokens se han convertido en una nueva unidad de coste, rendimiento y escalabilidad. Los formatos de datos tradicionales, como JSON, fueron diseñados para ser legibles y universales, no para ser eficientes en términos de tokens.

Ahí entra TOON, siglas de Token-Oriented Object Notation, un nuevo formato open-source diseñado específicamente para flujos de trabajo con IA y LLMs. Su promesa: usar entre un 30% y un 60% menos de tokens que JSON, manteniendo al mismo tiempo una sintaxis legible para humanos y fácil de parsear.

Veamos con más detalle qué es TOON, por qué existe, cuándo funciona, cuándo no, y si realmente puede tener futuro dentro del ecosistema de ingeniería de datos e inteligencia artificial.

Qué es TOON

Visión general

TOON es un formato de serialización de datos basado en texto y optimizado para reducir el uso de tokens en contextos con LLMs.

Es open-source, con licencia MIT, y está alojado en GitHub bajo el repositorio toon-format/toon. Cuenta además con una especificación activa, en su versión v1.4 a noviembre de 2025.

Características principales

TOON introduce varias decisiones de diseño orientadas específicamente a reducir redundancia cuando se envían datos estructurados a un modelo de lenguaje.

Sintaxis tabular para arrays uniformes: los nombres de los campos se definen una sola vez y después cada fila se escribe como valores separados por comas.
Indentación basada en espacios para objetos anidados: similar a YAML, pero más estricta y más fácil de parsear.
Eliminación de llaves y comillas repetidas: reduce caracteres y, por tanto, tokens.
Longitudes explícitas de arrays: por ejemplo, [2], lo que ayuda a validar estructuras y a guiar el parseo por parte del modelo.
Diseño pensado para LLMs, no para APIs: la prioridad es el coste en tokens y la legibilidad para modelos, no la compatibilidad histórica.

Por ejemplo, en TOON podríamos representar una lista de usuarios así:

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

En JSON, la misma información tendría una estructura más repetitiva:

{
  "users": [
    {
      "id": 1,
      "name": "Alice",
      "role": "admin"
    },
    {
      "id": 2,
      "name": "Bob",
      "role": "user"
    }
  ]
}

La idea central

Cada carácter o patrón de los datos que enviamos a un modelo se divide en tokens mediante su tokenizador. JSON contiene muchas estructuras repetitivas: llaves, comillas, comas y claves repetidas una y otra vez. Todo eso incrementa el número de tokens.

TOON reduce esa redundancia simplificando la sintaxis. Al eliminar elementos repetidos y representar mejor los datos tabulares, puede reducir el número de tokens y, por tanto, el coste de inferencia.

La idea de TOON no es sustituir JSON en todas partes, sino reducir el coste de representar datos estructurados cuando esos datos van a ser consumidos por un LLM.

Los benchmarks oficiales afirman reducciones de entre el 30% y el 60% frente a JSON en datos tabulares típicos.

Comparativa: TOON frente a otros formatos

Para entender mejor dónde encaja TOON, conviene compararlo con otros formatos de datos habituales.

Formato	Legible para humanos	Estructura	Eficiente en tokens para LLMs	Caso de uso ideal
JSON	Alta	Modelo completo de objetos	No	APIs e intercambio general de datos
CSV / TSV	Alta	Solo tablas planas	Muy eficiente	Datos tabulares y analítica
YAML / JSON5 / TOML	Alta	Flexible	No	Archivos de configuración
MessagePack / CBOR / BSON	No, son formatos binarios	Modelo completo de objetos	Compactos a nivel binario	APIs, almacenamiento, no LLMs
TOON	Moderada	Optimizado para arrays uniformes	Sí, en contextos LLM	Payloads de prompts y datos para LLMs

Dónde encaja TOON

TOON ocupa un nicho muy concreto:

Es textual, por lo que resulta adecuado para modelos de lenguaje.
Es compacto, por lo que puede ser más barato de procesar.
Es suficientemente estructurado como para conservar significado.

No está pensado para reemplazar JSON en todas partes. Su utilidad aparece en escenarios donde la eficiencia en tokens importa de verdad.

Cuándo funciona TOON y cuándo no

Escenarios donde TOON encaja mejor

TOON funciona especialmente bien cuando los datos tienen una estructura uniforme y tabular.

Datos tabulares uniformes: catálogos de productos, métricas analíticas, logs, datasets de evaluación o cualquier estructura con campos consistentes.
Optimización de prompts: cuando se envían grandes bloques de datos estructurados a un LLM y el coste en tokens no es trivial.
Pipelines RAG o inferencia batch: permite ahorrar espacio de contexto y meter más información relevante dentro de la misma ventana.
Entornos controlados de codificación y decodificación: por ejemplo, flujos del tipo JSON → TOON → LLM → JSON.

Escenarios problemáticos

TOON no es una solución universal. De hecho, en algunos casos puede no aportar ventajas o incluso empeorar el resultado.

Datos muy anidados o irregulares: si los objetos tienen campos distintos, la eficiencia de TOON cae rápidamente y puede llegar a usar más tokens que JSON.
Comunicación general entre APIs: JSON sigue siendo el estándar de facto y cuenta con mejor soporte en lenguajes, herramientas y plataformas.
Modelos no familiarizados con TOON: los modelos actuales han sido entrenados masivamente con JSON, por lo que TOON podría reducir ligeramente la comprensión si no se proporcionan ejemplos.
Sobrecarga operativa: añadir pasos de conversión puede neutralizar el ahorro en sistemas de bajo volumen.

TOON es más interesante cuando el volumen de datos estructurados es alto, el formato es homogéneo y el coste por token importa.

Ahorro de tokens verificado

Los datos disponibles muestran que los beneficios de TOON son reales para estructuras planas o uniformes, aunque no universales.

Dataset	Tokens en JSON	Tokens en TOON	Reducción	Fuente
Daily Analytics	~10.977	~4.507	−58,9%	GitHub de TOON
User List	150	82	−45%	Artículo en Dev.to
Nested Example	250	266	+6%, peor que JSON	Artículo en Dev.to

La interpretación es clara: TOON puede ahorrar muchos tokens cuando los datos son planos o uniformes. Sin embargo, no debe asumirse que siempre será mejor que JSON.

La recomendación práctica es probarlo siempre con el tokenizador real del modelo que se vaya a utilizar.

Ecosistema y herramientas

Implementaciones disponibles

TOON cuenta con una implementación oficial y varias implementaciones comunitarias.

Oficial: JavaScript y TypeScript, mediante el repositorio toon-format/toon.
Comunidad: Python, mediante python-toon, además de PHP y adaptadores tempranos en otros lenguajes.
Conversores: existen herramientas como jsontoon.com y toonifyit.com, aunque no están oficialmente verificadas ni auditadas desde el punto de vista de seguridad.

Herramientas de tokenización

Los benchmarks de TOON utilizan gpt-tokenizer con tokenizadores modernos de OpenAI, como o200k_base, equivalente al usado por GPT-4o.

Los resultados de tokenización pueden variar entre proveedores, por ejemplo Anthropic Claude, Google Gemini u otros modelos.

Integración práctica

Un flujo típico con TOON en un sistema basado en LLMs podría ser el siguiente:

Exportar datos estructurados desde JSON o desde el resultado de una consulta SQL.
Convertir esos datos a TOON usando toontool encode o una llamada de librería.
Pasar el resultado como entrada del prompt al modelo.
Convertir la salida estructurada del modelo de vuelta a JSON si es necesario.

Consideraciones técnicas y operativas

Coste de codificación y decodificación

Reducir tokens solo es valioso si el coste de serialización no elimina el ahorro. Codificar y decodificar TOON añade pasos computacionales adicionales. Normalmente este coste será despreciable, pero puede ser relevante en casos de baja latencia.

Tolerancia a errores

Los formatos sensibles a espacios, como YAML o TOON, son propensos a errores humanos. TOON intenta mitigar este problema con tamaños explícitos de arrays y una gramática estricta, pero aun así requiere buenas herramientas: linters, formatters y validadores.

Compatibilidad con modelos

Como los LLMs actuales han sido entrenados mayoritariamente con JSON, existe un pequeño riesgo de pérdida de precisión al usar TOON en prompts.

Un hilo de Reddit sobre TOON lo resume bien:

“Los modelos entienden JSON profundamente. TOON puede ahorrar tokens, pero podría reducir la precisión salvo que el modelo lo aprenda.”

La forma más sencilla de reducir este riesgo es envolver TOON dentro de una instrucción de sistema, indicando al modelo qué representa ese formato. Por ejemplo:

Los datos siguientes están en formato TOON. Interprétalos como una tabla equivalente a JSON.

Lecciones de formatos anteriores

TOON no es el primer intento de “arreglar” JSON. Antes han existido muchos formatos alternativos, cada uno con un objetivo concreto.

Formato	Objetivo	Por qué no sustituyó a JSON
YAML	Ser una alternativa más legible a JSON	Demasiada complejidad, loaders inseguros y errores por indentación
JSON5 / HJSON / TOML	Ofrecer una sintaxis más flexible	Soporte limitado y bajo incentivo de migración
BSON / MessagePack / CBOR	Compactar JSON en binario	Muy útiles para almacenamiento y APIs, pero no para LLMs basados en texto
Amazon Ion	Combinar JSON, esquema y doble modo binario/texto	Adopción principalmente empresarial y tracción limitada fuera de ese entorno

La lección es clara: las notaciones alternativas solo triunfan cuando dominan un nicho concreto. JSON sigue siendo el estándar por defecto en casi todo lo demás.

El nicho realista de TOON es la serialización de datos para prompts en LLMs: un nicho nuevo, en crecimiento y donde las ineficiencias de JSON sí importan.

Recomendaciones prácticas para equipos de datos

1. Medir antes de adoptar

Antes de incorporar TOON a un flujo real, conviene medir el ahorro con el tokenizador exacto del modelo utilizado. Para GPT puede usarse tiktoken; para otros proveedores puede ser necesario usar herramientas equivalentes.

2. Hacer un piloto con un dataset

Una buena prueba inicial consiste en convertir un payload JSON tabular a TOON y medir tanto el ahorro de coste como el comportamiento del modelo.

3. Automatizar las conversiones

Si TOON se adopta, la conversión no debería ser manual. Debe integrarse en pipelines Python, procesos batch o librerías internas. La librería Python de TOON puede facilitar esta parte.

4. Monitorizar la precisión del modelo

El ahorro de tokens no sirve de nada si el modelo interpreta peor los datos. Es necesario validar que la calidad de las respuestas no cae.

5. Documentar los patrones de uso

Debe quedar claro cuándo usar TOON y cuándo no. Por ejemplo: “usar TOON solo para datos tabulares homogéneos”.

6. Auditar conversores de terceros

No conviene enviar datos sensibles a conversores online salvo que su código sea público, revisado y aceptable desde el punto de vista de seguridad.

7. Mantener una alternativa en JSON

TOON debería introducirse como una capa de optimización, no como una dependencia rígida. Mantener soporte dual permite volver a JSON si TOON falla en algún caso.

Cuantificando el ahorro potencial

Podemos ilustrarlo con un ejemplo aproximado usando GPT-4o:

Métrica	JSON	TOON	Ahorro
Tamaño medio del prompt	15 KB	7 KB	53%
Tokens con `o200k_base`	3.000	1.400	53% menos
Coste por 1.000 tokens	$0.01	$0.01	Misma tarifa
10.000 prompts mensuales	$30	$14	~$16 de ahorro mensual

De forma individual, no parece un cambio radical. Pero en sistemas de gran escala, plataformas RAG o pipelines con millones de prompts, el ahorro puede volverse considerable.

¿Tiene futuro TOON?

Razones por las que podría tener éxito

El ecosistema LLM necesita formatos textuales más eficientes en tokens, especialmente a medida que los prompts se vuelven más complejos.
Es open-source, ligero e independiente del lenguaje.
Está empezando a generar tracción en la comunidad, con múltiples implementaciones, más de 100 estrellas en GitHub e interés creciente.

Razones por las que podría estancarse

La dominancia y madurez del ecosistema JSON son enormes.
Si los proveedores de LLMs mejoran la tokenización interna de JSON, la ventaja de TOON se reduce.
La falta de datos de preentrenamiento en TOON podría afectar a la comprensión por parte de los modelos.
Una nueva sintaxis introduce riesgo de error humano y fricción operativa.

Resultado probable

[Inferencia] TOON no sustituirá a JSON de forma global, pero puede convertirse en un miniestándar de facto para prompt engineering y serialización de datos en IA, especialmente en escenarios donde cada token cuenta.

Es una respuesta inteligente y práctica a un problema moderno. Incluso si permanece como una solución de nicho, puede inspirar nuevos formatos optimizados específicamente para LLMs.

Ejemplo práctico con Python

El siguiente ejemplo muestra cómo codificar datos en TOON y comparar el número de tokens frente a una representación equivalente en JSON.

from toon import dumps, loads
from tiktoken import get_encoding

data = [
    {"id": 1, "name": "Alice", "role": "admin"},
    {"id": 2, "name": "Bob", "role": "user"}
]

# Encode to TOON
toon_text = dumps(data)
print("TOON format:\n", toon_text)

# Token comparison (OpenAI o200k_base)
enc = get_encoding("o200k_base")
json_tokens = len(enc.encode(str(data)))
toon_tokens = len(enc.encode(toon_text))

print(f"JSON tokens: {json_tokens}")
print(f"TOON tokens: {toon_tokens}")
print(f"Saved: {100*(1 - toon_tokens/json_tokens):.2f}%")

Conclusión

TOON es uno de los primeros intentos serios de repensar cómo serializamos datos para LLMs, no para APIs.

Su sintaxis es compacta, legible y consciente del coste en tokens. Los benchmarks muestran ahorros relevantes, a menudo entre un 30% y un 60% menos de tokens, especialmente en datasets tabulares y estructurados.

Sin embargo, conviene mantener ciertas cautelas:

JSON sigue siendo imbatible en ubicuidad y tooling.
Los beneficios de TOON dependen mucho del caso de uso.
Su adopción dependerá del crecimiento del ecosistema, la facilidad de integración y de si los modelos aprenden a “hablar TOON” de forma nativa.

Para ingenieros de datos y profesionales de IA, TOON merece ser probado. No como sustituto universal de JSON, sino como una capa especializada de optimización en pipelines LLM donde los tokens equivalen a dinero.

Referencias

TOON GitHub – repositorio oficial.
TOON Spec v1.4, 2025-11-05.
Dev.to – “TOON: the smarter, lighter JSON for LLMs”.
Discusión sobre TOON en Hacker News.
Implementación Python de TOON.
Documentación de tokenización de OpenAI.