| Fair enough. Let me clarify the use case: ISON isn't meant to replace JSON in your application. Your JS/TS code still uses JSON objects internally. ISON is specifically for the LLM context window. The flow:
App (JSON) → serialize to ISON → inject into prompt → LLM reasons → response → your app You're right that nesting is lost. But for LLM reasoning, flat structures often work better. LLMs struggle with deeply nested JSON - they lose track of parent-child relationships 4+ levels deep. On "tokens are getting cheaper":
True for API costs. But context windows are still limited. When you're stuffing RAG results, memory, agent state, and user history into 128K tokens, every byte matters. It's not about saving money - it's about fitting more context. On "wrong optimization":
I ran the benchmark. Same data, same task. ISON: 88.3% accuracy. JSON: 84.7%. The LLM actually performed better with the tabular format, not just "equivalent for fewer tokens." ## BENCHMARK STATS: TOKEN EFFICIENCY:
ISON: 3,550 tokens
JSON: 12,668 tokens ISON vs JSON: 72.0% reduction
LLM ACCURACY (300 Questions):
ISON: 265/300 ( 88.3%)
JSON: 254/300 ( 84.7%)EFFICIENCY (Acc/1K):
ISON: 24.88
JSON: 6.68
ISON is 272.3% MORE EFFICIENT than JSON! But I hear you - if your data is deeply nested and that nesting carries semantic meaning the LLM needs, JSON might be the right choice. ISON works best for relational/tabular data going into context. |