Every time you send structured data to a language model, you're paying a tax you didn't agree to.
It's hidden inside the curly braces. It's in the quotation marks wrapping every key. It's in the commas, the brackets, the indentation, and the repeated field names across every object in an array. None of it means anything to the model. All of it costs tokens.
JSON was designed in 2001 for humans. We've spent the last several years feeding it to AI systems as if that's just how things are. AISL is a bet that it doesn't have to be.
The Problem Is Structural, Not Incidental
When a language model reads this:
{"user": {"name": "Alice", "age": 32, "active": true}}
it processes somewhere around 43 tokens. The actual information — Alice, 32, active, true — takes maybe 8 of them. The other 35 are punctuation and syntax the model needs to parse the structure but doesn't get semantic value from.
Multiply that across an API pipeline that passes hundreds of records per request. Multiply it across thousands of requests per day. Multiply it across every product that sends structured context to a model. The overhead isn't a rounding error. It's a structural inefficiency baked into the format itself.
AISL (Artificial Intelligence Serialization Language) was built to address this at the format level, not the application level. The same record in AISL:
record:user|name=Alice|age:int=32|active:bool=true%
Approximately 15 tokens. Same data. Same fidelity. No information lost.
What AISL Actually Changes
The design choices behind AISL are worth understanding because they explain why the savings are real and not just cosmetic.
No quotes around strings. In JSON, every key and most values are wrapped in double quotes. AISL treats unquoted strings as the default. Quotes are only needed — and only used — when a value contains a reserved character. No braces or brackets. Nesting is expressed through dot-notation key paths. Instead of a nested address object inside a contact object inside a user object, you getcontact.address.city=Boston. Flat structure, zero nesting tokens.
Record-level delimiters instead of object delimiters. A pipe | separates fields. A percent % terminates a record. That's the structural vocabulary for an entire record. Two characters, versus the open-brace, close-brace, comma, colon, and quote characters JSON requires for the same job.
Type hints only where needed. AISL assumes string by default. You add :int, :bool, :float, or :null only when the type is ambiguous or important to preserve. For most fields in most records, the hint is optional.
The result is a format where the tokens carry meaning instead of scaffolding. An AI reading AISL spends its context window on data, not syntax.
What This Looks Like at Scale
Token count comparisons can feel abstract. The concrete version is context window capacity.
A context window that fits 50 JSON records fits roughly 100 AISL records. An API call that previously required splitting a dataset across two requests fits in one. A retrieval pipeline that was truncating records to stay under a limit stops truncating.
The efficiency gain isn't just about cost — though at scale the cost reduction is real. It's about what becomes possible when your format stops competing with your content for space. More records per call. Richer context per request. Fewer round trips. Systems that were previously bottlenecked on context window size get headroom back.
AISL Is Not Trying to Replace JSON
This is worth stating clearly because it's easy to read "better than JSON for AI" as a claim to universal superiority. It isn't.
JSON is excellent at what it was designed for: human-readable data interchange. It's the right format for REST APIs that developers will read, for configuration files that teams will edit, for data that lives in version control and needs to be reviewed in pull requests. None of that changes.
AISL is optimized for a different use case: AI-to-AI communication, structured context passed to language models, and pipelines where the primary consumer of the data is a model rather than a human. In those contexts, the properties that make JSON good for humans — explicit quoting, clear nesting, familiar syntax — become overhead.
The format question should follow the consumer question. Who is reading this data? If the answer is a model, AISL is worth a serious look. If the answer is a developer or a human-facing interface, JSON is probably still right.
Deterministic Parsing as a Feature
One aspect of AISL that gets less attention than the token efficiency angle is what it means for parsing reliability.
JSON has flexibility built in — optional whitespace, multiple valid representations of the same data, type coercion behavior that varies by parser. That flexibility is fine when a human or a well-tested library is doing the parsing. When a language model is doing the parsing, flexibility introduces ambiguity, and ambiguity increases the probability of errors.
AISL's syntax has exactly one valid interpretation for any given document. No optional commas. No flexible indentation. No ambiguous type coercion. Every record follows the same structure. Every field uses the same assignment syntax. Every array uses the same element marker.
For AI systems, predictability isn't a constraint — it's a feature. A model that has seen thousands of AISL records can parse the format reliably because the format doesn't surprise it. The same model parsing JSON has to handle whitespace variations, nested object depth, optional fields, and edge cases that the format technically allows. Fewer edge cases means fewer parsing errors, which means more reliable system behavior downstream.
The Timing Question
It's fair to ask why this matters now, specifically. Serialization formats have existed for decades. AI systems have been consuming JSON for years.
The answer is context windows. As models have become more capable, the bottleneck in many AI systems has shifted from model intelligence to context capacity. The question is no longer whether the model can reason about your data — it's whether you can fit enough data into the context window for the model to reason about usefully.
When context windows were small, format efficiency was a footnote. When a request could only hold a few hundred tokens of data regardless, shaving 50% off the format overhead didn't change much. Now that context windows are measured in hundreds of thousands of tokens and real-world use cases involve passing substantial structured datasets to models, format efficiency becomes a meaningful design variable.
AISL is a response to a problem that has gotten materially more important as AI systems have gotten more capable. The format question, which was easy to ignore when context was scarce and use cases were simple, is worth revisiting now that both have changed.
Getting Started
AISL has a JSON-to-AISL converter available at [aisl-web.github.io/AISL](https://aisl-web.github.io/AISL/) for anyone who wants to test it against their actual data. The token count comparison is worth running on a representative sample from your own pipeline — the savings vary by data shape, but for structured records with multiple fields, the gap is typically substantial.
The format is MIT licensed, the specification is public, and the conversion is lossless in both directions. Any AISL document can be converted back to JSON without data loss, which means adoption doesn't require a permanent commitment or a wholesale migration.
For teams building pipelines where structured data flows into language models, it's a low-friction experiment with a potentially significant payoff.
AISL is in experimental phase
The context window is the resource. Format is a choice. AISL is the argument that we made the wrong one by default — and that it's not too late to change.