Your Model Bill Is Two Numbers Multiplied, and the Vendor Controls One Silently

TV
Thiago Victorino
7 min read
Your Model Bill Is Two Numbers Multiplied, and the Vendor Controls One Silently

A model’s bill is two numbers multiplied together: the price per million tokens, and the number of tokens your work becomes. Procurement negotiates the first number down to the third decimal. Almost nobody governs the second, and the second is where the money actually leaks. The vendor sets it, keeps it unpublished, and it lands differently at every vendor for the exact same input.

Ruslan Ianberdin at Playcode ran the measurement everyone assumes someone else already ran. He fed one identical TypeScript file, 2,888 characters, into each vendor’s own tokenizer endpoint and counted. GPT turned that file into 681 tokens. Claude, on Sonnet 5 and Opus 4.8, turned the same file into 1,178 tokens. That is 1.73 times more tokens for byte-identical input, before a single word of output is generated.

The second number is invisible by design

List price is the number the vendor wants you to compare on, because it is the number the vendor can win on. Opus 4.8 advertises $5 per million input tokens and $25 per million output. Clean, competitive, easy to put in a slide. Then the tokenizer segments your codebase into 1.73x more pieces than the competitor’s tokenizer does, and the effective price you pay behaves like $7.50 in and $37.50 out. The sticker never changed. The bill did.

The measurement is reproducible, which is the part that matters. Ianberdin used each vendor’s published tokenizer, not an estimate, not a proxy. Anyone can rerun it against their own files. Treat it as a method you can verify on your own repository, not as one vendor’s verdict about another. Your codebase is not his TypeScript sample. Run it on yours.

The gap also moves with content type. On English prose the same comparison narrows to roughly 1.40x, still material but milder. Code is where segmentation punishes you hardest, because code is dense with the punctuation, brackets, and identifiers that a tokenizer splits aggressively. The workloads with the highest token spend, coding agents chewing through large files, are exactly the workloads where the hidden multiplier is largest.

The multiplier drifts inside a single vendor

This is not only a between-vendor problem. It moves between releases of the same model family. Anthropic’s newer tokenizer produces around 30% more tokens than its predecessor for the same input. A workflow you priced and approved last quarter can cost a third more this quarter with no change to your code, no change to the list price, and no line item explaining why. The invoice went up. The dashboard shows more tokens consumed. Nothing tells you the segmentation rule changed underneath you.

If your cost model assumes tokens-per-file is a constant, your cost model is measuring a moving target with a stationary ruler. The character count of your code is stable. The token count is a vendor-controlled variable that shifts on the vendor’s release schedule, not yours.

The other number you actually control

The tokenizer sets the multiplier on the way in. There is a second lever on the volume side, and this one is entirely yours: how much work you route through a general model at all.

Vivek Haldar documented the case cleanly. He took an agent skill that had stabilized, a procedure the model performed the same way every time, expressed in natural language and executed by a general agent burning tokens on every run. He compiled it into deterministic code. The natural-language skill became a function. Token use dropped 94%. Latency dropped 87%. Output quality held.

That result is not a prompt optimization. It is a category move. A stabilized procedure does not need a probabilistic reasoner to re-derive it on every call. Once the steps stop changing, the reasoning is waste, paid for in tokens at the inflated per-token rate, on every single execution. Compiling it converts a recurring metered cost into a fixed one you pay to write once.

The discipline is knowing which skills have stabilized. A procedure still being discovered belongs in natural language, where the model’s flexibility earns its cost. A procedure that has run the same way a hundred times is a function wearing a prompt costume. The 94% is not exotic. It is what you recover the moment you stop paying a reasoning engine to execute a decision tree that no longer branches.

Both levers sit upstream of the dashboard

Notice where both of these live. The tokenizer multiplier is decided at procurement and architecture time, when you choose which vendor and model segments which workload. The compile-the-skill lever is decided at design time, when you choose what runs as reasoning versus what runs as code. Neither is visible in a monitoring dashboard, because a dashboard reports tokens after they are spent. By the time the number lands in the chart, both decisions were already made, silently, by the tokenizer and by the architecture.

This is the correction to how most teams treat AI cost. The instinct is to buy observability, watch the burn, and alert on spikes. Observability tells you that you spent. It does not tell you that a competitor’s tokenizer would have made the same output 42% cheaper, or that a third of your spend is a general agent re-deriving a procedure that stopped changing months ago. Those are architecture facts, and they are settled before the first token flows.

Do this now

Two actions, both upstream, both this week.

First, benchmark the tokenizers on your own code. Take a representative file from your actual repository, not a sample, and run it through each candidate vendor’s tokenizer endpoint. Count. If one vendor segments your code 1.7x heavier, that is a 70% effective price premium on your highest-volume workload, and it belongs in the procurement comparison next to the list price, not discovered on the invoice three months later. The list price is the first number. The token count is the second. You are buying the product of both.

Second, inventory your agent skills and mark the stable ones. Any natural-language procedure that has run the same way for weeks is a compile candidate. Pick the highest-frequency one and turn it into deterministic code. Haldar’s 94% is the ceiling; even a fraction of it, multiplied across every execution, compounds faster than any per-token discount you will ever negotiate. Cost is an architecture decision made once, not a number you watch go up.


This analysis synthesizes The real price of frontier models (Playcode, July 2026), Compiling an AI agent skill (Vivek Haldar, July 2026).

Victorino Group helps teams turn AI cost from a monthly surprise into an upstream design decision. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation