ZON, el “anti-JSON” pensado para IA: menos tokens, menos coste y menos ruido

Por Alan Sonny

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

JSON lleva años siendo el idioma universal de los datos en la web… pero nadie lo diseñó pensando en modelos de lenguaje. Ahora que cada llamada a una API de IA se paga en tokens, su verbosidad empieza a doler: llaves, comillas, nombres de campo repetidos una y otra vez.

Ahí es donde entra ZON (Zero Overhead Notation): un formato de datos compacto, legible y optimizado específicamente para LLMs, que promete reducciones de 30–50 % de tokens frente a JSON (en algunos casos hablan de hasta un 58 % menos de tokens de media) sin perder ni un solo bit de información.

¿Qué es ZON exactamente?

ZON es básicamente “JSON adelgazado para modelos de lenguaje”:

Mantiene el mismo modelo de datos que JSON (objetos, arrays, números, booleanos, null, etc.).
Es 100 % reversible y sin pérdida: lo que codificas en ZON se puede decodificar a JSON idéntico.
Cambia la sintaxis para que sea:
- Más compacta (menos caracteres ⇒ menos tokens).
- Más estructurada para los LLM (cabeceras explícitas, menos ambigüedad).
- Más amigable al streaming (se puede parsear sobre la marcha, sin esperar a cerrar mil llaves).

Piensa en ZON como una mezcla entre CSV y JSON: usa ideas tabulares cuando tiene sentido (arrays de objetos uniformes) y, aun así, soporta estructuras anidadas complejas.

El problema de JSON visto desde un LLM

Un ejemplo típico:

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin", "active": true },
    { "id": 2, "name": "Bob",   "role": "user",  "active": true },
    { "id": 3, "name": "Carol", "role": "guest", "active": false }
  ]
}

Para un modelo de lenguaje:

Cada comilla, llave, nombre de campo y coma suma tokens.
El campo "id" aparece en cada fila, igual que "name", "role", "active".
En contextos grandes (perfiles de usuarios, logs, catálogos, configs…) JSON se convierte en ruido repetitivo que hace más caro el prompt y come contexto útil.

ZON ataca justo ese desperdicio.

Cómo se ve ZON en la práctica

La misma estructura anterior, en ZON, se escribiría algo así:

users:@(3):active,id,name,role
T,1,Alice,admin
T,2,Bob,user
F,3,Carol,guest

Claves del formato:

users: → nombre del campo.
@(3) → número de filas (3 usuarios).
:active,id,name,role → cabeceras de columnas, declaradas una sola vez.
Cada línea siguiente es una fila de datos, sin repetir nombres de clave.

Beneficios inmediatos:

El LLM sabe que está leyendo una tabla con 3 filas y 4 columnas.
No hay comillas ni llaves ni nombres de clave repetidos.
La estructura es obvia y muy fácil de recorrer mentalmente (y para un parser).

Para configuraciones o estructuras anidadas donde una tabla no encaja tan bien, ZON puede usar una sintaxis más “objetual”, pero igual de compacta, por ejemplo:

config:"{database:{host:db.example.com,port:5432},features:{darkMode:T}}"

Sigue siendo texto, sigue siendo legible, pero con mucha menos grasa que JSON.

Por qué importa tanto la reducción de tokens

Cada llamada a un modelo de lenguaje tiene dos límites claros:

Límite de contexto (máximo de tokens de entrada/salida).
Coste por token (precio de uso del modelo).

Si puedes serializar tus datos de forma que:

En vez de 15 000 tokens ocupen 10 500…
O en vez de 200 000 tokens ocupen 140 000…

… automáticamente:

Reduces costes de inferencia (un 30–50 % menos en prompts pesados es mucho dinero).
Metes más contexto útil en la misma ventana (más usuarios, más logs, más histórico).
Bajas la latencia, porque el modelo tiene menos texto que “leer”.

Los autores de ZON reportan:

Ahorros típicos de 30–40 % frente a JSON.
Mejores resultados que otros formatos compactos como TOON (4–15 % menos tokens adicionales, y hasta 25–35 % menos en datasets grandes).

Precisión de recuperación: no solo es comprimir, es no liarla

Comprimir texto está bien, pero si el modelo luego se confunde al leerlo, no sirve de nada. Según las pruebas que describen:

ZON mantiene 100 % de precisión en recuperación de datos en sus benchmarks (24/24 preguntas correctas) con distintos modelos (GPT-4o, Claude, Llama).
Se ha probado contra otros formatos (JSON, TOON, YAML, CSV, XML) en:
- Objetos simples.
- Estructuras anidadas.
- Arrays de objetos.
- Casos extremos (valores vacíos, caracteres especiales).

La clave es que la sintaxis es:

Autoexplicativa (las cabeceras de tabla dejan claro qué es cada columna).
Determinista (una única forma de representar una misma estructura).
Libre de ambigüedades típicas de YAML o CSV cuando la cosa se complica.

Ventajas técnicas interesantes

Más allá del ahorro de tokens, hay varios detalles que gustarán a quien vive metido en código:

Streaming-native
ZON está pensado para parsearse byte a byte, ideal cuando el modelo va generando la respuesta por streaming. El parser puede ir construyendo objetos sin esperar a cientos de líneas más adelante.
Números canónicos
Sin notación científica: 1000000 en vez de 1e6. NaN e infinitos se convierten en null, para evitar rarezas en los modelos y en las librerías que lo consumen.
Límites de seguridad incorporados
El formato define límites (por ejemplo, tamaño máximo de documento, nº máximo de arrays, nº máximo de claves) para reducir riesgos de ataques tipo DoS por datos disparatadamente grandes.
Librería en TypeScript
Hay paquete npm (zon-format) para: import { encode, decode } from 'zon-format'; const data = { /* objeto JS/JSON */ }; const encoded = encode(data); // -> ZON const decoded = decode(encoded); // -> JSON otra vez

¿Sustituirá ZON a JSON?

A corto plazo, no. JSON sigue siendo:

Estándar de facto en APIs web.
Compatible con prácticamente todo (navegadores, librerías, BDs, etc.).
Suficiente para infinidad de casos donde el coste por token no es un problema.

Pero en el contexto muy concreto de flujos de trabajo con LLMs, ZON encaja como anillo al dedo:

Prompts largos, con mucha estructura repetitiva.
Agentes que manejan estados, perfiles, historiales, configs complejas.
Pipelines de alta frecuencia, donde cada token ahorrado es dinero a final de mes.

La fotografía actual podría resumirse así:

JSON: estándar universal, pero caro en tokens y verboso.
TOON: primer intento de compactar datos para LLMs, mejora clara sobre JSON.
ZON: evolución sobre TOON, con codificación tabular, sintaxis mínima y foco total en eficiencia + precisión.

En resumen

Sí, JSON te está costando más tokens de los que debería en tus flujos con modelos de lenguaje.
ZON propone una alternativa: misma información, menos ruido, menos coste.
Para cargas intensivas de IA, puede suponer decenas de miles de tokens ahorrados por día y prompts más claros tanto para la máquina como para la persona que los depura.

Y lo más interesante quizá no es solo el formato en sí, sino lo que anuncia: estamos entrando en una era en la que diseñamos formatos de datos pensando primero en cómo los “leen” los modelos de IA, no solo los humanos o los navegadores. JSON fue el lenguaje de la web clásica; ZON y compañía están peleando por ser el lenguaje nativo de la web de los modelos de lenguaje.