Study 1 of 527 September 2026Croxio Ltd240 messages, five forms, two models
Does writing a handover as a line save tokens, and can a model still read it?
Yes to both, with a catch. The same handover costs about 29% fewer tokens as a line than in English, and about 59% fewer in a very tight form where every fact sits in a fixed position. Every message survived being turned into data and back. A strong model read every form perfectly. A small model lost its place in the tight form in one run of two.
The catch is that the saving is small: 20 to 40 tokens a message. A hundred handovers a day save less than one resend of a system prompt. So tokens are not the reason to write handovers as lines. The reason, which the next four studies test, is that a program can check a line and cannot check a paragraph.
- The question
- How much does a fixed-vocabulary line save over English and JSON, does it lose anything on the way, and does a model reading it make the same decisions as it would from English?
- The material
- 240 made-up handover messages between agents working on a knowledge graph: one agent asking another to score, enrich or retire a record, with a deadline, a priority and a note. Spread evenly across the six things the receiver might decide to do.
- Compared
- Five ways of writing the same message: plain English, JSON, a keyed line (
key=value, the form that became rogerwilco), a glyph form where every code is a single symbol, and a tight positional form with an optional checksum. - Measured
- Tokens (two tokenizers), whether the message survives a round trip into data and back, what happens when a line is corrupted, and decision parity: whether a model that has never seen the format makes the same call from it as from English.
- Models
- Claude Haiku 4.5 (two runs) and Claude Sonnet (one run) as the blind readers.
- Graded by
- Code. Tokens and round trips are counted; the readers' decisions are scored against a six-rule policy applied in code.
Why we did it
The starting idea was a common one: agents talking to each other in English is wasteful, so they should have their own language. There are three ways to do that. Let the agents invent a code under pressure. Pass hidden model states instead of text. Or give both sides a fixed codebook, written by people, that a program can also read. Only the third runs on a hosted model API and stays readable by a human, so that is the one we tested.
Before building anything else on it we wanted three facts: how much a codebook form saves against English and JSON, whether anything is lost on the way, and whether a model reading the compact form decides the same way it would from a paragraph. We agreed those three as the test before writing the code.
What we tested
A small codec turns a data record (who is handing over, to whom, which item, what state it is in, what is wanted, by when) into one line and back. From one set of 240 records we produced five renderings of every message:
- English. A sentence or two, generated from templates with varied phrasing, so it is tidier than real agent prose.
- JSON. The record as an object with full field names.
- Keyed line. Every fact as
key=value, optional fields left out, so it can be read cold. This is the shape rogerwilco kept. - Glyph. Every key and code replaced by a single Unicode symbol, to test the idea that a denser-looking line is a cheaper one.
- Tight. Every fact in a fixed position, a dash for an absent one, and an optional three-character checksum. The shape of a METAR weather report.
The same message in all five forms, with its token count on the right:
The names in the example are the roles in the test corpus: Ideator, Strategist and Triage are agents, Adam is the person they report to.
The reader's job in the parity test was a six-rule policy of the kind a receiving agent would follow: for example, if the item is blocked, wait; if it has stalled for 14 days or more and matters enough, escalate; if it is done, close it. Each message has one right answer under the policy, so a reader's answers can be marked by a program.
How we ran it
- Generated 240 handover records from one schema, 40 for each of the six outcomes the policy can produce, and rendered each record in the five forms.
- Counted the tokens of every rendering with two public tokenizers (OpenAI's o200k and cl100k). Claude's own tokenizer is not public, so two were used to show which effects depend on the tokenizer. The absolute numbers are proxies; the ordering is the claim.
- Round trip: encoded every record to a line and decoded it back, in the keyed form and in the tight form with and without the checksum, and checked the result equalled the original.
- Corruption: mutated roughly 700 lines per form and counted how many the decoder refused and how many it accepted silently with a wrong value. For the keyed form the mutations were a dropped field, an unknown code or key, a bad number, a truncated line and a duplicated field; for the tight form a dropped, swapped or inserted field and a single changed digit.
- Parity: took 60 of the messages (10 per outcome) in each of the five forms and gave each batch to a fresh model that had not seen the codec, with the format's legend and the six-rule policy, and asked what it would do with each message. It was told to read, not to run code. Haiku read every form twice, Sonnet once. Answers were scored in code against the policy.
- Delta: measured one more thing on the side, a message that reports only what changed since the last state read, to see how far a repeated read can shrink.
What happened
Mean tokens per message (o200k)
| Form | Tokens (o200k) | vs English | Tokens (cl100k) | vs English | Legend, once | Pays back after |
|---|---|---|---|---|---|---|
| English | 68.9 | 71.2 | 0 | |||
| JSON | 64.5 | −6.4% | 66.3 | −7.0% | about 0 | |
| Keyed line | 48.9 | −29.0% | 49.7 | −30.2% | 435 | 22 messages |
| Glyph | 42.2 | −38.8% | 47.6 | −33.1% | 752 | 28 messages |
| Tight | 28.0 | −59.3% | 28.1 | −60.5% | 271 | 7 messages |
Table 1. Mean tokens per message over the 240 handovers, on two tokenizers. The legend is the one-off cost of teaching a reader the format; the last column is how many messages it takes to earn that back against English.
In words: the same message costs 69 tokens in English, 65 in JSON, 49 as a line, 42 in symbols and 28 in the tight form. A line saves about 20 tokens a message; the tight form about 40. Teaching a reader the keyed form costs 435 tokens once, which 22 messages pay back.
Where the saving comes from is instructive. In the keyed form 35% of the tokens (o200k) are the separators: each |, =, > and + costs a token of its own. The tight form wins by removing them, not by shortening words: a short code preceded by a space is usually one token on both vocabularies, so ACT and action cost the same. Abbreviation on its own buys almost nothing. The delta message, which sends only identity plus what changed, took a repeated state read from 43 tokens to 21.
Round trip and corruption. Every message came back equal to its record: 240 of 240 in the keyed form, 480 of 480 in the tight form with and without the checksum. Under corruption the forms differ by design. The keyed decoder refused 629 of 697 mutated lines (90%); of the 68 it accepted, 58 were a dropped optional field, which a keyed format cannot see is missing. The tight decoder without a checksum accepted 185 of 698 mutations silently (27%), 170 of them a single changed digit; the checksum version accepted none of 699. A changed digit is exactly the fault no unchecked format can catch, and the keyed test did not include digit flips, so the 90% and the 27% are not like for like.
| Form | Haiku, run 1 | Haiku, run 2 | Sonnet |
|---|---|---|---|
| English | 100 | 100 | 100 |
| JSON | 91.7 | 91.7 | 100 |
| Keyed line | 90.0 | 100 | 100 |
| Glyph | 100 | 100 | 100 |
| Tight | 58.3 | 91.7 | 100 |
Table 2. Decision parity: the percentage of 60 messages the blind reader routed correctly under the six-rule policy.
In words: the strong model read every form right every time, so for it the choice of form is about cost and checking, not understanding. The small model read English and the symbol form right every time, got one message in twelve wrong in JSON, read the keyed line right in one run and 90% in the other, and in the tight form got four in ten wrong in one run and one in twelve in the other.
The small model's errors fall into three kinds. Losing its place. In its first tight-form run, 20 of its 25 errors were telling an unblocked item to wait: fourteen fixed positions with dashes for the empty ones, and it read the number in a neighbouring column as a blocker. The second run did not repeat it, which says the form is fragile at this tier rather than unreadable. A loud word beating the rule order. Across JSON, keyed and tight, an item whose stage was DONE was closed even when an earlier rule should have fired first. It never happened in English, where "stage done" sits inside a sentence. A two-part numeric rule missed. In JSON only, both runs, "stalled 14 days or more and important" was read as "accept". Full field names did not help.
One code collided with a decision: the status WAIT was spelled the same as the answer WAIT. It explains only 2 of the 20 column errors, so it is not the cause, but it is a hygiene fault and cheap to fix.
What it means
Lossless compression of a typed message this size tops out at 29% to 60%. That matches what the published structural compression format TOON reports against JSON, and it is the ceiling, not the floor: the English here was tidy template prose, so real handovers would widen the gap a little.
At 20 to 40 tokens saved per message, the handover channel was never where the cost is. The delta result points at where it is: repeated reads of the same state, where sending only what changed halves the message.
The symbol form was half right. It saved tokens on one tokenizer and both models read it perfectly, so "unreadable" was wrong. But the saving is tokenizer-dependent (4% over the keyed line on the other vocabulary), the legend is 1.7 times larger, and a glyph is usually two tokens where a three-letter code is one. Density on the page is not density in tokens.
The tight form is the cheapest and the most fragile. With a checksum it is the only form that catches a corrupted digit, but a small model miscounted its columns in one run of two. It belongs where a program is the reader, not a model.
The keyed line decodes to the same record as every other form, a human can read it cold, and the codebook is a document anyone can load. That is the answer to "agents need their own language": a governed dialect, not an invented one. Agents left to invent their own codes under budget pressure drift into forms nobody can audit, as the GlossoGen study of Claude and GPT agents showed in September 2026.
What we decided
- The rogerwilco line is the keyed form:
key=value, in any order. - The small model read it at 90% to 100% and miscounted the positional form's columns in one run of two. The positional form was not carried into the protocol.SPEC section 2, wire format. The study's line used pipes between fields and put the sender, receiver and item in fixed positions; the protocol uses spaces, makes those three keyed slots, and adds a version token and a message id.
- Codes are short words and letters, not symbols.
- The symbol saving depended on the tokenizer, its legend cost 1.7 times more, and it bought no comprehension.SPEC section 4, core vocabulary.
- A corrupted digit is caught by a digest on the readback, not by a checksum on the line.
- The one thing the tight form could do that the keyed line could not was catch a changed digit. rogerwilco does it with
h=, a digest of the message as received, carried on the readback.SPEC section 5.1, tier 2. - A code may not be spelled like an answer the receiver can give.
- The
WAITcollision. The status becameHOLD. This is a rule for whoever writes a profile; the codec does not enforce it.profiles/pform.json. - No agent-invented codes and no hidden-state channels.
- Invented codes drift and cannot be audited; hidden states need access to model weights that a hosted API does not give.
- Tokens are not the reason to use lines. Checking is.
- 20 to 40 tokens a message is not worth a protocol. The next study asks whether a readback checked by a program catches a misunderstanding before the work is done.Study 2, the readback pilot.
What this does not show
- The English was generated from templates, so it is more regular and easier to parse than real agent prose. Real handovers would likely widen the token gap and could narrow the parity gap.
- Token counts are from public tokenizers, not Claude's. The ordering of the forms is unlikely to change; the absolute numbers will.
- Parity samples are small: 60 messages per form, two runs for the small model and one for the strong one. The tight-form result (58% then 92%) shows how large the variance is. Treat Table 2 as a screen, not a measurement.
- The readers were asked to read rather than compute, but nothing enforced it. None reported running code; one made a stray tool call and confirmed on query that it had decoded by hand.
- The receiver policy is six crisp rules. Real decisions are less crisp, which favours English more than these numbers suggest.
Sources
- Token-Oriented Object Notation (TOON), specification and benchmarks. github.com/toon-format/toon
- GlossoGen: Emergent Language in Complex Multi-Agent LLM Interactions, September 2026. arXiv 2609.01491
- Enabling Agents to Communicate Entirely in Latent Space (Interlat), ACL 2026. arXiv 2511.09149
- Jiang et al., LLMLingua, Microsoft Research, 2023.
Where everything is
Corpus, codec, token measurements, corruption tests, the five reader prompts, every reader answer and its score: research/wire-study in the rogerwilco repository (measure.py, parity_prep.py, results/measure.json, results/parity.json). The original working paper is report.html in the same folder. The study ran under the protocol's working name, formcore, and the raw files keep it.
Study 1 of 5 · 27 September 2026 · 240 synthetic handovers · tiktoken o200k_base and cl100k_base · readers Claude Haiku 4.5 (two runs) and Claude Sonnet (one run) · graded in code