Nobody asked what LLMs can skip. That’s 85% of your tokens.

“The best instruction is the one you don’t have to write.”

Everyone is teaching LLMs what to do. Nobody asked what they can skip.

The experiment

I sent the same instruction to Claude Code twice. Once as JSON. Once as something else.

JSON (230 tokens):

{"type":"project_session_state",
 "project_name":"obsidian-pomo",
 "project_type":"obsidian-plugin",
 "language":"typescript",
 "build_tool":"esbuild",
 "completed_features":[
   {"name":"basic-timer","status":"complete","files":["src/timer.ts"],"tests":"passing"},
   {"name":"statusbar-display","status":"complete","files":["src/statusbar.ts"],"tests":"passing"},
   {"name":"settings-tab","status":"complete","files":["src/settings.ts"],"tests":"passing"},
   {"name":"completion-notice","status":"complete","files":["src/notice.ts"],"tests":"passing"}
 ],
 "work_in_progress":{
   "feature_name":"daily-note-log","status":"in_progress",
   "target_files":["src/daily-log.ts"]
 },
 "recently_fixed_bugs":[{
   "description":"Completion notice was not firing when timer reached zero",
   "fix_applied":"Changed condition to timer <= 0 in timer.ts line 42"
 }],
 "environment":{"obsidian_api_version":"1.5.0","node_version":"18.17.0","typescript_version":"5.3.3"}}

The other thing (35 tokens):

{"_type":"session","project":"obsidian-pomo",
 "done":["timer","statusbar","settings","notice"],
 "wip":"daily-note-log",
 "bug-fixed":"notice not firing at timer=0"}

Same project. Same state. Same output from the LLM.

One costs 85% less.

What’s missing — and why it works

Look at what the 35-token version doesn’t say:

• "language":"typescript" — The LLM knows Obsidian plugins are TypeScript.
• "build_tool":"esbuild" — The LLM knows the standard build tool.
• "files":["src/timer.ts"] — The LLM can infer file paths from feature names.
• "obsidian_api_version":"1.5.0" — The LLM has this in its training data.
• "status":"complete" — If it's in the "done" array, it's complete. Obviously.

Every piece of missing information is something the LLM already knows. Sending it again is like introducing yourself to your coworker every morning. “Hi, I’m the TypeScript developer using esbuild.” They know. They’ve always known.

This is not compression

TOON reduces JSON syntax — removes braces, deduplicates keys. That’s syntactic compression. Same information, fewer characters.

This is different. This is semantic compression. It doesn’t reduce the message size. It reduces the message itself.

The difference matters. Syntactic compression has a floor — you can’t compress below the information content. Semantic compression has no such floor, because you’re not compressing information. You’re omitting it. The LLM’s world knowledge acts as the decompression dictionary.

It gets better over time

Session 1: 35 tokens. Full project state. Session 10: 12 tokens. Only what changed since last time. Session 50: 3 tokens. {"wip":"export"}

The LLM already knows the project from accumulated context. You only send what’s new.

JSON stays at 230 tokens. Every time. Session 1 or session 50. It doesn’t learn. It can’t learn. It was designed for a parser that has no memory.

Over 50 sessions:

JSON:  50 × 230 = 11,500 tokens
This:  35 + 30 + 25 + ... + 3 ≈ 400 tokens

That’s a 30x difference. And the gap keeps growing.

Both humans and LLMs can read it

Here’s the strange part. When you compress to the intent level, the result is optimal for both readers.

A human looks at {"done":["timer","statusbar","settings","notice"],"wip":"daily-note-log"} and knows the project status in 10 seconds.

An LLM receives 35 tokens and fully restores project context.

No other format does both. Spec documents are readable for humans but verbose for LLMs. Config files are precise for machines but cognitively expensive for humans. This sits in the middle — intent-level data that both sides read at their natural speed.

The architecture is three layers

Specification (controls quality) → .lndf (carries intent) → LLM (expands meaning)

The format itself does nothing. It’s a transparent pipe. The specification layer (skill files, presets, project history) controls output quality and variance. The LLM expands intent into full implementation using its world knowledge.

Each layer has exactly one job. The format doesn’t control variance — the specification does. The format doesn’t interpret meaning — the LLM does. If you blame the format for bad output, you’re blaming the pipe for the water quality.

The six principles

1. Intent over Data — Carry only what the LLM cannot infer.
2. Omit What the Parser Knows — If it’s in the training data, don’t send it.
3. Defaults Are Silence — Unspecified values aren’t errors. They’re delegations.
4. Differential Expression — After the first session, send only what changed.
5. Timelessness Through Abstraction — No device-specific values. The LLM’s knowledge updates; the format doesn’t.
6. Human-LLM Dual Readability — Intent-level data is optimal for both readers.

Why nobody did this before

Every data format in history was designed for a parser with zero world knowledge. JSON, XML, YAML, Protocol Buffers — all of them assume the parser is ignorant. Every value must be stated. Every relationship must be declared. Ambiguity is an error.

LLMs changed the parser. For the first time, the thing reading your data actually understands it. But everyone kept sending JSON. Like handing a university professor a children’s textbook and asking them to read every word.

I think the reason is cultural. Programmers are trained to be explicit. “Explicit is better than implicit” is literally in the Zen of Python. Omitting information feels like a bug. Trusting the parser feels reckless.

But the parser isn’t ignorant anymore.

I trust LLMs

At least as conversation partners, I can — now.

I’m not a professional programmer. I’ve been building apps for about four months, all through LLM collaboration. I don’t carry the 25 years of “data must be explicit” training that professional developers do.

When I started omitting things and the LLM still understood, I didn’t feel reckless. I felt efficient. The LLM knows TypeScript. The LLM knows Chrome Extensions. The LLM knows esbuild. Why would I tell it again?

That question led to a philosophy, six principles, a file format, and a working implementation.

LNDF wasn’t planned. It came out of a conversation. That’s what trust gives you — not just answers, but discoveries.

Try it

The philosophy is published: github.com/moncface/lndf

A working implementation ships with Mon CLI: mon ld distills your project state into a .lndf file. mon lv displays it. mon lc copies it to your clipboard for pasting into any LLM session.

The SKILL.md that teaches LLMs to interpret .lndf files is included. It works with Claude Code, OpenCode, Codex, Gemini CLI, Cursor, and anything that supports the Agent Skills standard.

You’ve been paying for 230 tokens when 35 would do. In some cases, 3.

The LLM already knows. Let it.

Hiroaki Tachibana (pen name) / moncface March 2026