Most Token Efficient AI Coding: Price Per Byte, Not Token

The most token efficient ai coding setup is not decided by the rate card, and the rate card is the only thing most comparisons read. We counted the same eight files from this repository twice — once as Claude Code billed them, once through OpenAI's published tokeniser — and got 162,409 tokens against 134,707 for identical bytes. That is a 1.206x difference in the unit itself, before a single price is compared. This article shows the measurement, the number that does convert, and the two layers that cost far more than either — the seat-and-allowance half of the same purchase is in what the seats and allowances cost.

Key takeaways

• A token is a vendor-specific unit. The same 385,226 bytes are 162,409 tokens on Anthropic's tokeniser and 134,707 on OpenAI's, a 1.206x gap with a per-file range of 1.139x to 1.246x.
• Comparing $/MTok across vendors compares prices quoted in different units. Converted to money per megabyte of source, the gap between these two cards widens from 2.857x to 3.445x — the sticker comparison understates it by 20.6%.
• Only OpenAI lets you count before you pay. Probed on 2026-08-20, its merge table downloads with no key, Anthropic's count_tokens answers 401 and Google's countTokens answers 403.
• The tokeniser is the smallest of three layers. A session floor of 31,979 tokens and a two-turn question that billed 65,080 input tokens both cost more than the unit does.
• Token efficiency is a property of your files, not of a model. JSON measured 2.213 bytes per token and a TypeScript module 3.719 on the same tokeniser, a wider spread than the gap between vendors.

The short answer

Rank on money per byte of your own source, not on dollars per million tokens. On the two cards this repository can verify, that is $2.1080 per megabyte for Claude Opus 5 against $0.6119 for GPT-5.3 Codex — a 3.445x gap where the rate cards show 2.857x.

Then ignore both numbers until the loop is fixed, because an agent that re-reads your repository three times costs more than any card difference recovers. The pricing comparison pillar covers the seat-and-allowance side of this decision; this article is about the unit those allowances are denominated in.

A token is not a shared unit

Every vendor trains its own tokeniser, and the tokeniser decides how many billable units a file becomes. Nothing forces two vendors to agree, and they do not. So the $/MTok column that every "cheapest coding model" roundup ranks on is three prices quoted in three different units, presented as one axis.

The correction is not complicated. It needs the same bytes counted both ways, which is harder than it sounds for exactly one reason: only one of the three major vendors publishes a tokeniser you can run.

The same files, two tokenisers

scripts/check-token-efficiency.mjs does both halves and refuses to print a comparison when they are not looking at identical bytes:

npm run check:tokens

The Anthropic column is measured, not computed. Ten headless Claude Code runs — one with empty stdin, nine with a file piped in — give the file's token count by subtraction, because the session floor is identical across the runs and cancels. That is the method our context-window measurement established, and this script reuses its numbers rather than re-billing the same probe.

The OpenAI column is computed, not measured. o200k_base ships as a plain merge table of 199,998 entries, so the count reproduces offline: apply the published pre-tokenising pattern, then merge byte pairs in rank order. Both halves land on the same eight files:

Across all eight — 385,226 bytes — Claude counts 162,409 tokens and GPT counts 134,707. That is 1.206x, and it holds from a 620-token config file to a 115,230-token lockfile, which is the evidence that it is a property of the tokenisers rather than an artifact of some fixed per-run overhead.

Two guards make the count trustworthy. Every file is rejoined from its pre-tokenised pieces and compared byte for byte with the input, so a pattern that dropped a character would fail rather than undercount. And on 2026-08-20 the implementation was checked against gpt-tokenizer, an independent JavaScript port of the same table, which returned identical counts on all nine files.

Dollars per megabyte is the comparable number

Bytes are the unit you own. Converting both cards into money per megabyte of source is one multiplication, and it is the only comparison in this category that survives a change of tokeniser:

Rates read from each vendor's own pricing page on 2026-08-19. Excluding the lockfile, which is 80% of the bytes and is not code anyone writes, the figures are $1.4944 against $0.4474 and the ratio is 3.340x.

The sticker comparison understates the real gap by 20.6%. That is not a rounding error and it runs in one direction: the vendor whose tokeniser splits your source more finely bills more units for the same work, and its rate card never mentions it. For a full-session cost comparison including cache behaviour, the three-way teardown prices one measured session on all three cards and finds the ranking changes hands on session duration.

Layer two: what the harness spends before you type

The unit is the smallest of three layers, and the second one is free to measure. In the same fixture, the empty-stdin run — no file, a four-word prompt — reports 31,979 tokens. That is the system prompt, the tool definitions and the project's CLAUDE.md, and you pay it on every turn.

At Claude Opus 5 input rates, 31,979 tokens is $0.16 uncached and $0.016 on a cache read. It is also 16% of a 200,000-token window occupied before the first character of your prompt, which is the version of this number that actually bites — what fills a context window has the full accounting, and the model-and-harness split shows the same overhead buying you the tool loop that makes an agent work at all.

The floor is the cheapest layer to shrink and the one people attack last: a shorter project instruction file moves it directly, and nothing about the model changes.

Layer three: the loop is where the tokens go

The third layer dwarfs both. Asking this repository a one-line question — how many .mdx files are under content/ — took two turns and one Glob call, and billed:

65,080 input tokens and $0.0146 for a question whose answer is 55. Nothing about that is a tokeniser problem. The agent re-sent its context to get one number, and it would have re-sent it again for a second question. Two extra turns cost more than the entire 1.206x unit difference does on a file the size of lib/mdx.ts.

That ordering is the practical finding of this article: loop, floor, unit — in decreasing order of what they cost and increasing order of how much attention they get.

We later attributed 20,168 billed turns inside a single tool by usage field and the same ordering held at a scale this one question cannot show: 98.7% of the input side was context being re-read, and everything typed over three weeks came to 0.0011% of it. That measurement is where a Claude Code bill actually comes from — this article prices a token, that one attributes yours.

Only one vendor lets you count

Counting tokens before paying for them is a transparency question, and the three vendors answer it three different ways. Probed on 2026-08-20:

Neither Anthropic nor Google publishes a downloadable tokeniser, so there is no honest way to put a Gemini row in the per-megabyte table above from public data. We left it out rather than estimating it, which is the same treatment the Python evidence count gave a dataset that answered 401.

This is also why the Anthropic column here is a measurement of the product rather than a call to an API: the only way to learn what Claude thinks a file costs is to send it and read the bill.

How to actually reduce the bill

• Cut turns before you cut models. One avoided round trip on this repository is worth more than the entire tokeniser gap on a mid-sized source file. Ask for the whole task in one prompt rather than discovering it in five.
• Shrink the floor once, benefit on every turn. 31,979 tokens is paid per turn forever. A project instruction file that is half the size pays back on every request for the life of the repository.
• Price per megabyte when comparing vendors, and use your own file mix. Run npm run check:tokens against your repository rather than inheriting this one's 2.372 bytes per token.
• Feed the agent source, not artifacts. package-lock.json alone is 139,640 tokens — 86% of this repository's measured total, for a file no model needs to read. A .gitignore-shaped discipline about what enters context is worth more than any rate card.
• Choose the smaller model for the mechanical half. The Sonnet and Opus ratio is a flat 2.5x on identical token shapes, which makes model choice the one lever that scales with everything else you have already done.

Common mistakes chasing token efficiency

• Ranking on $/MTok across vendors. Tempting because it is the only number both cards print. The symptom is a "cheapest coding model" that bills more than the expensive one on your repository. The fix is the per-megabyte conversion, which takes one multiplication once you have a byte-per-token figure.
• Using four characters per token. Tempting because every explainer repeats it. The symptom is a context budget that runs out early — the constant undercounts source code, and this repository's JSON measures 2.213 bytes per token, not 4.
• Optimising the prompt while the loop runs wild. Tempting because the prompt is the part you can see. The symptom is a carefully trimmed request that still bills 65,000 tokens because the harness re-sent everything else.
• Comparing a cached session to an uncached one. We nearly published a version of this mistake. A cold first turn writes the cache instead of reading it, so any before-and-after subtraction against it is wrong — the fix is a discarded warm-up turn, and every probe in this repository now takes one.

What we are not claiming

No model is ranked on quality here. This article measures units and prices. Which model writes better code needs a fixed task set and a grader, neither of which exists in this repository.

One tokeniser is measured and one is computed, and they are not the same kind of evidence. The Anthropic figures are Claude Code 2.1.234 billing nine files on 2026-08-18; the OpenAI figures are the published o200k_base table applied on 2026-08-20. If Anthropic changed its tokeniser between those dates, this comparison would not know.

One file was excluded and the script says so. content/guides/swe-bench-explained.mdx was 19,829 bytes when Claude Code read it and is 20,117 now, because a retro-link pass edited it a day later. Comparing the old count to a new encoding would have been the easiest way to publish a wrong ratio, so the check refuses that row and fails outright on any drift it has not been told about.

Conclusion

If you are choosing between cards today, convert them to money per megabyte of your own source first — on this repository that turns a 2.857x gap into a 3.445x one, and the correction always favours the vendor whose tokeniser is coarser. Then leave the card alone and go count turns, because the loop is where the money is. Run npm run check:tokens on your own repository before you trust either number here; the whole point of a published merge table is that you do not have to take ours.

Frequently asked questions

Muhammad Kashif

Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.