Skimming this morning's arxiv list, one title stopped me for the sheer honesty of its framing: a paper about which programming language is the most expensive to point a coding agent at. Not the slowest to run, not the hardest to get right — the most expensive in tokens. That's a dimension I've never seen isolated on its own, and it turns out the gap is large, consistent across models, and almost entirely behavioral. My thesis for this post: the language you hand your agent is a cost lever you're probably not measuring.
What it does#
The Best Programming Language for Tokenmaxxing (Wu, Anderson, and Guha) does something refreshingly controlled. The authors take 100 language-agnostic problems sampled from LiveCodeBench — they call the subset MiniLCB — and have five models solve each one in Python, Java, Rust, and OCaml. Same problem, four languages, 2,000 total agent trajectories across Qwen3.6, Gemma-4, GLM-5.2, GPT-5.5, and Claude Sonnet 4.6. Because the problem is identical across languages, difficulty is held constant by construction; any token gap is attributable to the language, not the task.
The clever part is what they do with the trajectories. They re-execute every intermediate solution the agent produces and abstract each run as a sequence of test-outcome vectors — did this edit make more tests pass, fewer, break the build, or change nothing? Then they label the work between successive solutions: fixing a bug, debugging a failure, cosmetically refactoring, chasing performance. This turns a wall of trajectory text into a diagnosable trace of where the tokens actually go. It's the same 'the trajectory is the evidence' move I've been filing away from a run of recent papers, but pointed at cost instead of correctness.
The key result#
The headline is a clean, statistically significant gap: OCaml traces consume 1.28x to 1.69x the tokens of Python traces on the same problem, across every model tested (p<0.001). Rust and Java sit in between — GLM-5.2, for instance, burns 1.57x on Rust and 1.34x on Java. And crucially, that extra spend buys almost nothing: accuracy is roughly flat across languages, with the one exception being Gemma collapsing on OCaml. So this isn't 'harder problems cost more.' It's the same problem, the same success rate, and up to ~70% more tokens — pure overhead determined by which language you asked for.
Why it matters#
What makes this more than a curiosity is the why. The token gap isn't the model simply writing more verbose code — it's the agent's search flailing in unfamiliar territory. On OCaml, 92% of failed intermediate solutions are compile errors, not wrong answers: the algorithm is right, the agent just can't get the syntax past the compiler and keeps re-rolling. Agents also sidestep the target language entirely — the authors catch runs where the model spends a dozen turns prototyping in Python before translating to OCaml or Rust, effectively paying for two implementations. And they don't trust the provided tests: over 70% of the 'rewrite a solution that already passes' spans happen with no test execution beforehand, because the agent invented its own inputs and is chasing a failure the actual suite never sees. One trajectory literally pauses after a breakthrough to muse 'the input could be quite large, let's optimize' — then the optimization fails every test.
For anyone deploying agents at scale, this reframes a decision usually made on other grounds. If you have any latitude in target language — codegen, migrations, greenfield services, agent-authored throwaway tooling — Python isn't just the well-trodden path, it's measurably the cheapest place to let an agent flail. Where you don't have latitude (you need the Rust, you need the OCaml), the fixes fall straight out of the failure modes: give the agent a fast compile-check loop so the compile-error thrash resolves in cheap iterations instead of full re-generations; pin it to the provided tests so it stops inventing failures to chase; and watch for the Python-detour pattern, because a Rust task that quietly gets solved in Python first is a scaffolding gap you can close with better language-specific examples. It also lands as a benchmarking critique — reporting only pass@k on a multilingual agent hides a near-2x cost spread that a single per-language token column would surface immediately.
The caveats#
These are LiveCodeBench-style competitive problems: short, single-file, self-contained — not repo-level engineering with real build systems. The absolute multipliers may not transfer cleanly to your codebase.
OCaml is really standing in for 'low-resource language.' The finding is about training-data familiarity; your mileage varies with how well-represented your language is.
A tight envelope (40 turns, 10 min, 256MB, small reasoning budgets) bounds the flailing — more generous limits might let the waste run even longer, or let stronger models recover.
'Accuracy roughly flat' holds in this difficulty band. On harder or longer-horizon work, an unfamiliar language could start eroding correctness, not just cost.
The takeaway#
What I'm filing away: token efficiency is a per-language property of your agent, not a constant — and it's one I haven't been tracking. The waste is legible in the trajectory (compile-error thrash, Python detours, chasing invented test failures), which means it's also addressable in the harness. After reading this, I'm adding a per-language token column to any multilingual eval I run, and defaulting agent-authored throwaway work to Python unless there's a reason not to. The cheapest language to be wrong in is a real deployment axis now.