Look at the bill before you build a language AI prefers

Code text is 0.8% of an agent bill. Erase every line a human can actually touch and 6% remains. I put the same bug in a 7-file repo and a 202-file repo and ran the same prompt at each: input tokens rose 18% while the repo grew 29x.

Building a new language aims at that 0.8%. The rest of the bill goes up again every turn.

Decomposing the bill

"Token Reduction Is Not Cost Reduction" (arXiv 2607.12161, 2026-07) breaks down 1,212 Claude Code sessions and 11,773 requests by component. By cost, not by token count.

Those six rows are everything a human can touch. Code sits at the bottom.

That table is an empirical average over a specific workload, priced with Claude Code and Haiku 4.5. The paper says so itself: "These are empirical averages from the coding-agent workloads evaluated in this study, not industry averages." Change the model or the harness and the ratios move. The ordering, with code at the bottom, still points the same way as my own measurement (29x to 18%).

A harness prompt is billed again every turn. Code is read once and done, but the system prompt and tool schemas go up 200 times across 200 turns.

The arithmetic comes from the same table. Cutting turns by 10% does about 18x more than halving the code. Halving your code with a new language is touching the rounding error on the bill.

The 29x experiment

Quoting was not enough, so I ran it. The same bug went into a 7-file repo and a 202-file repo, with the same prompt at each.

The first pass ran five at a time in parallel.

The smaller repo took longer. The cause was not the repo but the run order: I ran the five small-repo trials first and the five large-repo trials second, so queue time overlapped the condition completely.

I re-ran them one at a time.

The difference is 1.0 turn, with a 95% confidence interval of -1.92 to +3.92 turns, p=0.38 (Welch t=1.00, df=3.54, d=0.71). Zero sits inside the interval, so "no difference" is the right reading.

The same repo and the same task took 40 turns in parallel and 7 turns alone. The "+50%" and "-86%" before that were both noise.

Tokens came out like this.

The file count is 29x larger; input tokens are 1.18x. The rest comes from turn count. Across the 8 sequential runs, input per turn ranged from 14,710 to 21,092 tokens. Fixing a one-line bug still meant resending that much every turn. Cache reads were 54.5% of billed tokens (50.6-59.7% per run), which means the same conversation was resent every turn.

However you shape the code, most of the bill is not code.

Compression costs more

Compressing the syntax should make things cheaper. There is a direct refutation.

"Beyond Human-Readable" (arXiv 2604.07502, 2026-04):

aggressive compression increased total session cost by 67% despite reducing input tokens by 17%

Input tokens fell 17% and the session bill rose 67%, because the model reasons more while decoding the compressed form. The authors' conclusion is "semantic density optimization", not "minimum tokens".

Other compression experiments price out just as badly.

That trades 12 percentage points of solve rate for 42% of the tokens. The knowledge-graph version cut tokens tenfold and quality fell 9 points.

Tokenizers have converged

Maybe a syntax that tokenizes favorably would help. That has been measured too.

Tokka-Bench (arXiv 2610.08794) measures 20 programming languages and concludes:

programming-language efficiency has converged among recent tokenizers

Across recent tokenizers, the spread between cl100k and o200k is about -1.4% to +2.4%. Anthropic's newest tokenizer produces roughly 30% more tokens for the same text. The trend runs against new-language designers.

Language explains 16%

This is not an argument that language is meaningless. Measured properly:

The other 84% is model, task, and prompt. Even that 16% turns on how much the model has thought in that language, not on the language being better. The paper's phrase is "process cost is not surface cost".

Faced with an unfamiliar language, models prototype in Python first and translate. Give them a new language and they do not think in it; they think in a familiar one and port the result. Translation cost eats the syntax savings immediately.

The levers sit outside the language

Ordered by effect for the same spend. None of these require changing language.

Rank 4 is the telling one. Aider left the language alone, switched the edit format to unified diff, and tripled the success rate. The paper is titled "Unified diffs make GPT-4 Turbo 3X less lazy", and its diagnosis is precise.

GPT is terrible at working with source code line numbers … choose an edit format that GPT is already familiar with

A format that matches the training distribution wins. That is the same reason a new language loses, diff wins, and code mode wins.

Do not expect self-correction without a verifier. "LLMs Cannot Self-Correct Reasoning Yet" (arXiv 2310.01798, ICLR 2024) reports that without external feedback, performance can get worse.

If you are evaluating a new language

Measure these four before building anything.

1. Measure total session cost. Not input tokens. Input can fall while cost rises (-17% to +67%).
2. Make turn count the dependent variable. Code compression ratio is not a metric. Compress perfectly and, if turns hold, so does the bill.
3. Suspect the harness first. Count how much system prompt, tool schemas, and memory injection go up every turn. In my runs that was 14k-21k input tokens per turn, with 54.5% of billed tokens as cache reads.
4. Change the format first. Switching edit format is 3x cheaper than switching language.

Limits

• My measurement is n=4. Four sequential runs each, 8 total. The no-effect conclusion holds for this sample; I am not claiming no larger effect exists.
• The parallel pass was a failed experiment. Condition and queue order overlapped. I re-measured sequentially and report both here.
• I did not reproduce the cited papers. The 0.8%/74.7% from 2607.12161, Aider's 20% to 61%, and VeriHarness's 14/50 to 36/50 are the papers' reported values. The only thing I re-ran is the repo-size experiment.
• "10% fewer turns → 7.5% savings" is arithmetic. It follows from 74.7% being rebilled every turn; it is not a cited experiment.
• This post originally had an arithmetic error of mine. I wrote that "98.7% of billed tokens are cache reads." Since billed = input + cacheRead + output matches exactly across all 8 runs, those two are separate additive terms. Dividing by the remainder was wrong, and the correct figure is 54.5%. A number check before publication caught it.

The direction holds. The harness is three quarters of the bill and code is under one percent, from two independent measurements, and my own (29x to 18%) points the same way.