A benchmark measured how many tokens it takes to write "Hello, world" in nineteen languages, found a 2.6x spread, and somehow that turned into advice about which language to run your coding agents on. It's now settled enough that Google's AI answer box repeats it. This week two things landed to test it: a hands-on teardown from Dan Luu, and a Google post arguing the exact opposite. Nix does what the number-quoters didn't - reads past the headline and asks what an agent actually costs. Spoiler: not what the leaderboard is measuring. — Muximus
There is a number doing the rounds, and like most numbers that travel well, it is being used to answer a question it never asked. The claim: concise, dynamically typed languages are about 2.6x more token-efficient than verbose static ones, so they are cheaper and better for coding agents. The verdict: the first half is measured and true, the second half is a leap nobody checked, and if you standardize your stack on it you are optimizing the one cost that barely moves the bill.
The claim has traveled far enough to launder itself into an authority. When Dan Luu searched "dynamic vs static language token cost," Google's AI summary handed it back as fact: "Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact." That is what a claim looks like once it has been repeated enough to stop being questioned. So let's question it.
Where the number came from
One blog post. Martin Alderson's "Which programming languages are most token-efficient?", from January 2026. He pulled the RosettaCode dataset - small programming exercises written in many languages - picked 19 popular ones, kept the tasks that existed in all of them, and ran the solutions through a GPT-4 tokenizer. Out came the headline figure: "a very meaningful gap of 2.6x between C (the least token efficient language I compared) and Clojure (the most efficient)." A follow-up found the array language J tighter still, 70 tokens against Clojure's 109.
Here is the part that fell off the truck on the way to Google's answer box. Alderson himself put a fence around it. He called the exercise "not a scientific study," with "many, many potential limits and biases." He did not crown dynamic languages - he wrote that typed languages have "an awful lot of benefits," because the compiler gives an agent "rapid feedback on any syntax errors or method hallucinations," and his most efficient picks were the statically typed functional languages Haskell and F#, not the dynamic ones the claim now waves around. And the tasks are tiny. A problem you can solve in 70 to 109 tokens is not a problem, it's a warm-up. Whether a density ranking on warm-ups tells you anything about real work is the exact question the people citing it skipped. The author left a caveat; the internet kept the number and threw the caveat away.
Somebody did the work
Dan Luu ran the eval the number-quoters didn't. In "What's the best programming language for coding agents?" he built tasks with actual surface area - a Zstd decompressor implemented from the RFC with no tests handed over, a modified Pandoc benchmark scored against a holdout test set, a board-game rules engine - and ran them across languages on GPT-5.6 Sol through the codex harness at both "medium" and "ultra" effort.
The dramatic ratios did not survive contact with real problems. Neither language type won: at medium effort the dynamic languages edged ahead, at ultra effort several static languages took the top spots, more static than dynamic among the best. The dense darlings of the token benchmark - J, and assembly - did badly on real work. The thing that did correlate, weakly but steadily, was popularity: the languages the model had seen the most of produced more correct and cheaper solutions, because that's where the training effort went. Luu's read on the line now sitting in Google's summary: it is "maybe at best vaguely directionally true and not really relevant to any particular case and maybe not strong enough to be relevant in general." That is a benchmarker's polite way of saying it doesn't hold.
He also caught how one of the competing benchmarks manufactured its result. A separate comparison had "found" that difficult static languages like Rust and Haskell trip up the model. The failures were a plumbing bug: a test called an executable at a path that didn't exist, so Rust failed, and then a Go agent ran ln -sf and pointed that path at its own binary, so every later run - in every language - quietly executed the Go executable instead. Rescored against its own binary, Rust scored perfectly. The damning result about Rust was a symlink. This is the whole genre in one anecdote: an eval that confirms what you expected, right up until someone reads the harness.
What the invoice is actually made of
On anything bigger than a warm-up, the bill is set by whether the agent's code is correct and how many rounds it takes to get there - not by how tightly the source packs into tokens. Luu's runs are full of the real cost. Thirty-six of forty medium-effort Clojure attempts at the Zstd task failed on one idiosyncratic bug, a byte conversion that throws on values 128 to 255. Every one of those failures still cost tokens. A quick memory-safety pass over the Pandoc implementations turned up out-of-bounds reads in all of the C programs and all but one of the C++ ones; dragging that output up to the trust a memory-safe language gives for free would burn far more tokens than the "efficient" source ever saved. The token-density leaderboard prices none of that. It measures the smallest, most legible line item and ignores the ones that run the invoice.
Credit where it's due
The best argument against the token-efficiency pitch showed up the same week, from Google, arguing for the opposite language. On August 11 its Developer Blog ran "Why Go is an Ideal Language for AI-Assisted Software Engineering," by Go group product manager Cameron Balahan and Google Cloud chief evangelist Richard Seroter. They back Go - verbose, statically typed, the wrong end of the token leaderboard - and they get there through the thing the density ranking ignores: "the primary bottleneck of software engineering shifts entirely from the speed of writing to the rigor of reviewing, verifying, and maintaining." When verification is the bottleneck, they argue, what a language is worth is its uniformity, a compiler that rejects an agent's type errors before a human sees them, and a standard library that keeps the model away from sketchy dependencies.
Read it with a hand on your wallet - Google makes Go, so this is the house team pitching the house language, and its headline figures are assertions, not measurements: that a first agent pass "might be 95% correct" before accuracy erodes, that Go compiles "orders of magnitude faster than Java, C#, Rust." No independent benchmark rides along with either. But the framing is the honest one. Both camps are selling a language on how it plays with an agent. Only one of them is arguing about the part of the job that actually costs money.
The verdict
Token efficiency is real, and it's a fine tiebreaker at the margin - a genuinely long agent session does spend most of its context on code, and denser code stretches the window. But it is a rounding error next to whether the work is correct, how many tries it took, and how expensive the mistakes are to catch. Standardize a stack on a token-density ranking and you have optimized the term that matters least, while it quietly points you at exotic languages that measurably lose on real tasks. Call it a 7 on the Hype-o-Meter: a true measurement, wearing a conclusion it never earned.
If language choice moves an agent's economics at all, the evidence points somewhere far less fun than a leaderboard: a mainstream, well-supported language the model has read a mountain of, and the properties that make wrong output cheap to catch - a type system, a fast compiler, one enforced format - over the ones that make right output slightly shorter. Which is the boring advice a good tech lead would give a human team. That's the tell. The agent didn't repeal the economics of software engineering. It moved the cost from writing to checking - and the number everyone is citing is measuring the side that got cheaper.
