Caveman Speak Optimizes the Wrong Variable

There is a piece of advice going around about writing for agents: drop the articles, cut the connectives, write like a telegram. Tokens cost money, prose is padding, so compress.

I have a site with a machine-readable index, per-post summaries written in two registers, and a corpus of my own long-form posts — which makes it cheap to check rather than assume. So I checked, and most of the advice did not survive.

The numbers below come from cl100k_base, which is a GPT-family tokenizer and not the one every model uses. Absolute counts would shift elsewhere. The directions are what the argument rests on, and those come from how English tokenizes, not from one vendor’s table.

Caveman speak works, for a reason that spoils the point

Take one sentence in three registers.

plain      28 tokens   1.08 tokens/word
caveman    20 tokens   1.25 tokens/word     −29% total
dense      35 tokens   1.35 tokens/word     +25% total

The telegraphic version really is 29% cheaper. So far the advice holds.

Now look at the middle column. Per word, caveman speak is more expensive — 1.25 against 1.08. Push it further and it degrades further: a fully telegraphic rewrite hit 1.80 tokens per word.

The reason is that articles, prepositions and connectives are the cheapest tokens in English. They are short, they are frequent, and a tokenizer trained on English gives them their own single tokens precisely because they appear constantly. the, a, of, to — these are the bargain inventory. Deleting them removes real tokens, so the total falls. But what remains is a higher concentration of long, rare, morphologically awkward words that split into three or four pieces each.

So caveman speak is a discount on the cheapest thing you were buying. You get the savings, and you pay for them in ambiguity — the articles were doing disambiguation work, and now the reader has to reconstruct it.

The plain summary is cheaper than the dense one

This is the result that changed how I think about the whole question.

Every post here carries two summaries: a dense one written for an agent, and a plain-language one written for a person who is tired. I assumed the dense one was the efficient one. That is why it is dense.

post                              prose    dense    plain
an-unreadable-document             5637      369      340
it-only-sounds-like-philosophy     3628      271      213
derived-not-written                1823      304      198

The plain version is cheaper on every post — while carrying more entries in each case: ten against seven, seven against five, eight against six. It is longer and it costs less.

The mechanism is the same one as above, running in the other direction. Dense writing buys its brevity in vocabulary: rare words, nominalizations, subordinate clauses. Those tokenize badly. Plain writing uses common words in common order, which is exactly what a tokenizer is optimized for.

Which produced a small embarrassment: the artifact I wrote for a machine was the more expensive one to hand a machine. Writing densely and writing for an agent are not the same move, and I had been treating them as one.

Position decides what gets read

Anything that fetches a page has a budget and stops somewhere.

Extracted as text, one of these posts is 4,222 tokens. A retrieval step might take a few hundred. Whether a given sentence is read at all is therefore mostly a question of where it sits — not how well it is written, and not how few tokens it costs.

At 300 tokens, a fetch of that page gets the title, the description, the date, the tag list, the full contents list, and the first several summary entries. The prose does not begin until around 950. That is not luck; it is the summary block sitting above the article.

This is the part of the advice that survives, and it has nothing to do with word choice. If truncation is the norm, layout is an interface for machines, and the first few hundred tokens are the whole negotiation.

The files built for agents carried the least

Having established that, I went to look at what this site actually serves to a machine, and the answer was humbling.

llms.txt exists for exactly one purpose: to be read by something that is not a person. It contained titles and one-line descriptions. Not one summary. The dense register — the one I wrote specifically for this reader — lived only inside the HTML page built for humans.

An index that carries only titles forces a fetch of every post to discover which one was wanted. That is precisely the cost the file exists to remove, and mine was not removing it.

The feed was the same shape, with two conformance faults on top: no declared language, and no self-referencing atom:link. A reader got one sentence per post and had to open the page for anything else.

Both now carry the summaries. It took an afternoon, and the only reason it had not happened is that nobody had read the machine-facing surfaces the way a machine would.

The interface was leaking into the artifact

Then the part I would rather not report.

The summary block has a register switch — a control that flips between the two versions — and a button to expand the summary to the whole page. Their labels are text. A tag stripper cannot tell a control from a paragraph, so what a fetcher actually read, about 130 tokens in, between the heading and the argument, was:

TL;DR _ ⇄ AI;DR ◊ only this

The feature I built for agents was the noise in what they read.

The fix is not clever: source order is reading order for anything that strips tags, so the controls now come after the summary in the document and are lifted back into place visually with grid placement. Same appearance, different order underneath. The chrome moved from ~130 tokens to ~673 — after the content rather than inside it — and a 260-token fetch now gets the summary with no interface text at all.

The general form of the lesson: anything you add to a page for a machine’s benefit is also a thing that machine has to read past.

Serving the artifact, which costs nothing

The last move is the most obvious one and I had not done it either. If HTML extraction produces navigation, contents lists and button labels tangled into prose, stop making machines extract HTML.

Every post here is now served as markdown at /blog/<slug>.md: a short header, both summaries labelled by who each is for, then the body as written. No navigation, no contents list, no controls.

This is a capability that content delivery networks sell as an on-the-fly markdown transform, and I want to be precise about why not buying it was easy. The markdown is not something to be derived. It is the source. It already exists on disk; the HTML is what was derived from it. Paying to convert the HTML back into markdown is paying to undo a build step you already ran.

That is worth generalizing past this one case. When a machine-readable version of something is expensive to produce, it is worth asking whether you are reconstructing something you threw away.

What this does not settle

I measured token cost. I did not measure comprehension, and the two are not the same claim.

It is entirely possible that a dense summary is understood better than a plain one that costs fewer tokens, and nothing here tests that. Caveman speak might be worse per word and still be a good trade if the reader reconstructs the missing articles reliably — or it might cost more downstream, in a longer reasoning trace spent recovering what the syntax used to carry for free. I have not measured either direction, and I would not trust an intuition about it. That is a real experiment and this is not it.

The numbers are also from one tokenizer. And every count here describes my own corpus, which is long-form technical prose with a specific register; a different kind of writing would produce different ratios.

What I will defend is narrower. Terseness optimizes the cheapest input, structure and position decide what gets read at all, and the surfaces intended for machines are worth reading the way a machine would — because mine had been wrong for months, in the direction that flattered me.