A widely-cited claim suggests that dynamic, concise languages like Clojure and J are more "token-efficient" for AI coding agents — requiring fewer tokens to express the same logic. The implication: if token cost is the bottleneck for AI-assisted development, we should all be writing in the most token-dense languages.
But a new analysis by Dan Luu shows this claim falls apart under scrutiny.
The original claim goes like this: LLMs process code as tokens, and some languages express the same logic in fewer tokens than others. A dynamically typed language like Python omits type declarations, making code more compact. An array language like J can express complex operations in a fraction of the tokens needed in C or Java.
One widely-cited comparison found a 2.6x gap between C (the least token-efficient) and Clojure (the most efficient). J was even more extreme at just 70 tokens average, nearly half of Clojure's 109.
If token cost is the dominant factor in AI coding, this would suggest a radical shift: abandon verbose static languages in favor of concise dynamic ones. Why pay for 260 tokens of C when 70 tokens of J could express the same logic? Lu's analysis reveals the fundamental flaw: the problems used to test token efficiency are trivially simple. A problem that can be solved in 70 tokens in J and 109 in Clojure isn't much of a problem at all — it's the kind of thing that takes a human 30 seconds regardless of language.
When you move to real problems — the kind that actually matter for software engineering — the extreme ratios disappear. Lu tested AI agents on a complex task: implementing a complete zstd decoder from the RFC specification. The agents were given the RFC and errata, placed in a container without internet access, and told to build a working decoder.
The results? The token efficiency advantage of dense dynamic languages evaporated. More popular languages produced more correct and cheaper solutions. This is the opposite of what the token efficiency hypothesis predicts.
The reason is straightforward: LLMs are trained on vastly more code in popular languages. Python, JavaScript, Go, and Java have enormous repositories on GitHub, extensive documentation, and millions of Stack Overflow answers. When an AI agent writes Python, it draws from a massive training corpus. When an AI agent writes J, it draws from a tiny training corpus.
This means the agent is more likely to:
In obscure languages, the agent is more likely to hallucinate syntax, invent non-existent library functions, and produce subtly broken code — even if each token is "cheaper."
Token cost is only one factor in the total cost of AI-assisted development. The real cost includes:
If a concise language saves 50% on token cost but doubles the number of iterations needed (because the AI keeps getting the syntax wrong), the total cost is higher, not lower. Lu's data shows this pattern clearly. In the zstd decoder task, popular languages like Python and Go produced working code in fewer iterations. Dense languages like J required more attempts, more tokens overall (due to retries), and often still produced broken code.
What about the broader claim that dynamically typed languages are more token-efficient than statically typed ones?
Lu's analysis suggests this is "at best vaguely directionally true and not really relevant to any particular case." The difference exists but is too small to matter in practice, and it's confounded by the larger effect of training data availability.
Moreover, statically typed languages offer a benefit that doesn't show up in token counts: compile-time verification. When an AI agent hallucinates a field in Go or Rust, the compiler catches it immediately. In Python or JavaScript, the error might not surface until production — costing far more than the tokens saved by omitting type declarations.
The practical takeaway is clear: if you're choosing a language for AI-assisted development, token efficiency should not be your primary concern. The dominant factor is how well the AI model knows the language — which is a function of how much training data exists for that language.
This means:
The token efficiency hypothesis isn't wrong about tokens — it's wrong about what matters. In AI-assisted development, the cheapest code is the code that works the first time. And that's most likely to happen in languages the AI has seen millions of times before.