JSON nos ha acompañado dos décadas como el lingua franca de las APIs. Pero en la era de los modelos de lenguaje con contextos gigantes, cada carácter cuenta… y JSON resulta sorprendentemente caro en tokens. Ahí es justo donde aparece ZON (Zero Overhead Notation), un formato pensado específicamente para hablar con LLMs sin malgastar contexto.
ZON no intenta reinventar el modelo de datos: sigue representando objetos, arrays y primitivos como JSON, pero cambia radicalmente cómo los escribe para que los modelos lo lean con menos ruido y más señal.
Qué es ZON y qué problema intenta resolver
ZON es un formato de texto, legible por humanos, que serializa los mismos datos que JSON, pero con tres objetivos muy claros:
- Minimizar tokens consumidos por un LLM.
- Eliminar ambigüedades de parseo para que el modelo no “se invente” estructura.
- Ser streaming-friendly, es decir, fácil de generar y procesar en flujo.
Según sus propios benchmarks, ZON consigue ahorros de alrededor del 30–40 % de tokens frente a JSON, manteniendo el mismo contenido.
Y cuando se compara con otros formatos optimizados para IA como TOON, llega a ahorrar un 25–35 % adicional en conjuntos de datos grandes.
Para aplicaciones que envían grandes volúmenes de contexto a modelos (perfiles de usuarios, catálogos de productos, logs, configs…), ese recorte se traduce en menos coste, más velocidad y más espacio útil para instrucciones y razonamiento.
Cómo comprime tanto: tablas, menos sintaxis y diseño “para modelos”
La clave de ZON está en cómo representa datos que, en JSON, son muy verbosos.
1. Arrays tabulares en vez de repetir claves
El caso típico: un array de objetos con la misma estructura, por ejemplo usuarios:
[
{ "id": 1, "name": "Alice", "active": true },
{ "id": 2, "name": "Bob", "active": false }
]
Lenguaje del código: JSON / JSON con comentarios (json)En JSON, las claves "id", "name", "active" se repiten en cada fila. ZON lo convierte en una tabla:
users:@(2):active,id,name
T,1,Alice
F,2,Bob
users:es el nombre del bloque.@(2)indica cuántas filas vienen.active,id,nameson las columnas, declaradas una sola vez.- Cada línea siguiente es una fila con los valores en orden.
Para un LLM, esto es mucho menos texto, pero igual de autoexplicativo.
2. Sintaxis mínima, sin ruido innecesario
ZON reduce al máximo corchetes, llaves y comas. En lugar de:
{ "config": { "env": "prod", "debug": false } }
Lenguaje del código: JSON / JSON con comentarios (json)usa algo de este estilo:
config:"{env:prod,debug:F}"
Lenguaje del código: CSS (css)Los objetos anidados se representan con una sintaxis compacta entre llaves, pero sin comillas redundantes y con booleanos de un solo carácter (T/F).
Menos signos de puntuación significa menos tokens para el modelo.
3. Pensado para streaming
ZON está diseñado para parsearse byte a byte, sin necesidad de esperar “cierre de llaves” al final de un gran bloque. Esto encaja muy bien con:
- Respuestas en streaming desde un LLM.
- Pipelines donde se procesan logs, eventos o filas de forma incremental.
Su estructura permite reconstruir objetos sobre la marcha, algo mucho más incómodo con JSON si se quiere ser estricto.
Ahorro real: tokens y precisión con LLMs
Los creadores de ZON han medido el formato contra JSON, TOON, YAML, CSV y XML con distintos modelos (GPT-4o, Claude 3.5, Llama 3…), midiendo dos cosas:
- Tokens consumidos.
- Precisión al recuperar datos concretos (por ejemplo: “¿cuál es el email del usuario 17?”).
Los resultados que publican:
- ZON consigue 30–40 % menos tokens que JSON en los tests agregados.
- En datasets grandes y anidados, es 25–35 % más eficiente que TOON.
- Tanto ZON como TOON logran 100 % de aciertos en las pruebas de recuperación de valores: no se pierde información al comprimir la estructura.
Dicho de otra forma: mismos datos, mismos resultados, pero con mucho menos contexto consumido.
ZON frente a otros formatos: la foto de conjunto
Aquí va una tabla orientativa comparando ZON con otros formatos habituales en flujos con LLMs:
| Formato | Modelo de datos | Eficiencia de tokens (vs JSON) | Legibilidad humana | Facilidad para LLMs | Casos de uso típicos |
|---|---|---|---|---|---|
| JSON | Objetos, arrays, primitivos | Base 100 (referencia) | Alta, estándar de facto | Buena, pero muy verboso y repetitivo | APIs, configs, payloads web tradicionales |
| ZON | Mismo modelo que JSON | ~30–40 % menos tokens que JSON; ~25–35 % menos que TOON en grandes datasets | Media-alta (un poco de curva inicial) | Muy alta: estructura explícita, sin ambigüedad, diseñado para LLM | Contexto para modelos, prompts con muchos registros, logs, analítica, datos tabulares complejos |
| TOON | Orientado a tablas y objetos | ~10–20 % menos tokens que JSON en general, pero menos eficiente que ZON en datos grandes | Media | Alta, también pensado para LLM | Casos similares a ZON donde ya se use TOON como formato intermedio |
| YAML | Igual que JSON, con azúcares | Normalmente algo peor que JSON en tokens (más palabras clave e indentación) | Alta, muy cómodo para humanos | Media: el sangrado e interpretación pueden confundir a modelos | Configuración humana (DevOps, Kubernetes, etc.) |
| CSV | Tablas simples | Muy eficiente para datos 100 % tabulares | Baja para estructuras complejas | Media: bien para filas simples, mal para anidado | Exports sencillos, datasets planos, hojas de cálculo |
Nota: Las cifras de ahorro son aproximadas y basadas en los benchmarks públicos de ZON; el impacto real depende del tipo de datos que se envíen.
Cuándo merece la pena plantearse ZON
Algunas situaciones donde ZON tiene mucho sentido:
- Sistemas que empujan el límite de contexto
Ejemplo: enviar cientos de tickets de soporte, eventos o perfiles de usuario a un modelo para resumen o clasificación. - Aplicaciones donde el coste de tokens duele
Si cada llamada a la API de tu modelo arrastra 10 000–50 000 tokens de contexto estructurado, reducir un 30 % la carga puede tener un impacto claro en la factura mensual. - Agentes y pipelines con mucho ida y vuelta de datos estructurados
Coordinadores, herramientas, funciones… donde JSON empieza a ocupar demasiado espacio frente a las instrucciones y el razonamiento. - Casos con muchas filas “parecidas”
Arrays de objetos con la misma estructura (usuarios, productos, logs…) son donde ZON brilla gracias a su codificación tabular.
Y los “peros”: adopción, tooling y ecosistema
No todo es gratis:
- Es un formato nuevo
Aunque la especificación está publicada y el diseño se considera estable, los propios autores dejan claro que ZON sigue evolucionando y no está “congelado” como estándar formal. - Ecosistema aún pequeño
Hoy hay librerías oficiales para TypeScript y Python, más algunas herramientas de línea de comandos y playgrounds web, pero ni de lejos el ecosistema masivo de JSON. - Curva de aprendizaje para el equipo
Los desarrolladores tienen que acostumbrarse a leer bloques tabulares y a la sintaxis compacta. No es complicado, pero requiere un mínimo de formación y buenas herramientas de visualización.
Por eso, ZON no sustituirá a JSON en todas partes. Tiene más sentido como formato interno “para hablar con modelos”, manteniendo JSON hacia fuera (APIs públicas, integraciones, etc.).
En resumen
- JSON sigue siendo rey en la web, pero resulta muy caro en tokens cuando se usa como formato bruto para alimentar modelos de lenguaje.
- ZON propone una alternativa minimalista y orientada a LLMs, que:
- Mantiene el mismo modelo de datos.
- Comprime agresivamente arrays de objetos.
- Elimina sintaxis redundante.
- Los benchmarks públicos muestran ahorros del orden del 30–40 % vs JSON y hasta 25–35 % adicionales vs TOON en conjuntos de datos complejos, manteniendo 100 % de precisión en la recuperación de valores.
Si tu aplicación empieza a sentir el cuello de botella del contexto —o tu CFO empieza a mirar con lupa la línea de “AI tokens”—, merece la pena experimentar con ZON como formato intermedio. Menos ruido, más señal… y la misma información de siempre.
