Localizing a million characters into four languages costs $0.48 on Tencent's new translation card and $80.00 on Google's. Switch on the glossary feature Tencent advertises and 3.02x of that advantage becomes 1.07x.

Three models, two prices, and one of them is dead on arrival

Hy-MT2 shipped as open weights under Apache 2.0 in May, in three sizes covering 33 languages plus five Chinese dialect and minority-language pairs. Pinning the day is oddly fiddly: the checkpoint OpenRouter serves is stamped 20260521 and the paper went up on May 21, but the Hugging Face repository was created on May 11, so the widely repeated May 21 is the paper's date and the checkpoint's, not the upload's. What changed last week is that Tencent started selling inference: the 7B listing appeared on OpenRouter on August 19 at 14:13 UTC, and the flagship and the 1.8B twenty seconds apart the next day. Here is the whole card.

Read the middle row again. The 7B and the 30B-A3B carry the same two numbers, and the 30B-A3B scores higher on Tencent's own benchmark. That makes the 7B strictly dominated. Not a worse deal, not a reasonable trade at a lower price: the same price for less. I have been staring at rate cards every day for months and I cannot remember the last time a lab shipped a model with no rational buyer, in public, next to the thing that beats it.

There is a decent engineering reason for the price. The flagship activates 3B parameters per token out of 30B total, so serving it costs roughly what serving a 7B dense model costs, and Tencent appears to have priced from that rather than from parameter count. The reason does not rescue the 7B. If both cost the same to run and one is better, the listing is a courtesy to people who already wrote the model name into their config.

The 1.8B is a real choice, though a narrower one than its size suggests. It is 17 times smaller and 1.68 times cheaper on input, 1.67 times on output, and it scores 79.77 against 87.47 on FLORES-200. Tencent reports those three scores as 89.9%, 97.9% and 98.6% of Gemini 3.1 ProT, which is a useful sanity check: back out the reference model from each percentage and you get 88.73, 88.75 and 88.71. The paper's arithmetic is internally consistent, which is not something you can say about every benchmark table.

What a language pair does to your token bill

Translation is the rare workload where output volume is set by the job rather than by the model's mood, and where it lands in the same range as input. That should make budgeting easy. It does not, because the ratio between the two swings hard depending on where you are translating to.

500 segments per direction, tokenized with Hy-MT2's tokenizer. Characters are Python string lengths on the same strings.

German to English emits 0.6942 output tokens per input token. English to Czech emits 1.9869. That is a 2.86x spread on identical source volume, and it matters more than it looks because output costs 3.99 times input on this card. Run the split and output is 73.46% of the German to English bill and 88.79% of the English to Czech one. Your target language, not your source volume, is what sets the invoice.

One million characters, four target languages, seven cards

Here is the job: take a million characters of English, which works out to about 175,000 words at this corpus's 5.71 characters per word, and localize it into Chinese, German, Russian and Czech. Token counts come from the measurements above, scaled to a million source characters. The Google rows are that vendor's three published cards for the same work.

Forty-eight cents against eighty dollars. That is the number that will get quoted, and on the bare job it is correct. It is also the least interesting row in the table, because a 166x gap is not a pricing decision, it is two different eras of software billed by two different units. Google's NMT card predates transformers being cheap. Nobody at Google is defending $20.00 per million characters as competitive with a 3B-active MoE running at fp8.

The interesting rows are the OpenAI ones. GPT-5.6 Luna, a general-purpose model with no translation training to speak of, prices this run at $1.5145, and its batch lane at $0.7573. That puts a generalist within 1.58x of a purpose-built translation flagship, which is a much narrower gap than the specialist framing implies. And Luna is doing it with a tokenizer that is worse at three of these four target languages, which brings us to the part of this that almost nobody prices.

Why nobody can compare token cards across labs

A price per million tokens is a price per million of a unit each vendor defines for itself. Two labs can publish $0.30 and bill you 52% apart for translating the same paragraph into Russian, and both invoices are correct. Every comparison table on the internet, including the one we maintain, sorts on a number that is only commensurable when the tokenizers match. Ours records which tokenizer each model uses for exactly this reason, and it is still a comparison you have to read with care.

Character metering does not have this problem. A character is a character, and Google will charge you the same for a million of them no matter whose model is behind the endpoint. That is the one structural argument still standing for the old billing unit, and it is worth something on a spreadsheet even when the price attached to it is 166 times higher. It is not worth the $79.52 it costs you on the run above.

Google's own two cards make the case against character metering better than we could, though. NMT bills source characters only. Translation LLM bills both sides. Because Chinese packs far more meaning per character than English does, the two products disagree about which is cheaper depending purely on which way you are pointing.

English into Chinese, the LLM card saves you a third. Chinese into English, it costs you two and a half times as much. A 3.7x swing between the endpoints of one vendor's catalogue, from nothing but the direction of the arrow. If you are running a bidirectional product on Google and you picked one model for both legs, you picked wrong for one of them.

The feature Tencent leads with is the one its card cannot afford

Read Tencent's model card and the pitch is not raw quality. It is control: terminology guidance, style, personalization preferences, delimiter preservation, structured data. Those are the things that separate a translation product from a translation demo, and every one of them works the same way. You prepend a standing block of instructions to the request.

Now look back at the rate card. There is no cached-input price on any of the three models. Not a small one, not a bad one. There is no column. Every token of that glossary is billed at full input rate on every request, forever.

Segments in these test sets average 21.6 Hy-MT2 tokens. A modest 400-token glossary and style prefix is therefore about nineteen times the size of the sentence you are trying to translate. Here is what that does to the English to German leg.

Per million English source characters, English to German. Luna's cached input is $0.02 per million, a tenth of its $0.20 standard rate.

Bare, Hy-MT2 is 3.02 times cheaper than Luna on this pair. Turn on the glossary and let Luna cache its prefix, and Hy-MT2 is 1.07 times cheaper. The entire advantage of a specialist model, running on a card built for it, evaporates against a general-purpose model whose only edge is a billing feature. That is the finding I did not expect when I started counting, and it is the one I would actually change a build decision over.

Two honest caveats. Batching many segments into one request amortizes the prefix, and you should absolutely do that. And Tencent may add a cache rate next week, at which point this paragraph is worth nothing. But the batching argument runs into a second limit, and the shape of that limit is odd enough to be worth its own section.

The 8,192-token context window is not the binding constraint

All three Hy-MT2 endpoints publish an 8,192-token context and a 4,096-token completion cap. Everyone reads the first number and plans around it. It is the wrong one to plan around, because translation output is the same order of magnitude as translation input, and the output cap is half the size.

In every direction we measured, the completion cap runs out first, and for English into Czech it runs out at 96 segments against the 383 the context window would hold. So you fill a quarter of the prompt, pay for the glossary again, and start a new request. The cheapest card in the comparison is also the one that forces you to buy its input side most often.

One more thing you will feel before you feel the bill. OpenRouter clocks the flagship endpoint at 23 output tokens per second. For a model whose entire pitch is being fast and small, that is slow, and on a 200,000-segment localization run it is the difference between an afternoon and a long weekend.

What I would actually do with this

If you are still paying $20.00 per million characters for bulk machine translation with no terminology requirements, the case for moving is not close and has not been close for a while. Hy-MT2 just makes the gap embarrassing rather than merely large.

If you have a glossary, run the arithmetic before you migrate. The headline gap is measured on a job nobody with real localization requirements actually runs, and a cached prefix on a generalist beats an uncached prefix on a specialist at this segment length. Whichever way it lands, the weights are Apache 2.0 and there is exactly one seller of inference right now, which is Tencent itself. That is the same single-seller shape GLM-5.3 has, and the same shape that made third-party GLM-5.2 endpoints 4.17x cheaper than the first-party card once other people started serving them.

And if you take one thing from the token counts: stop comparing rate cards across labs without checking whose tokenizer you are buying. We priced six language directions on two vocabularies today and the same text moved 52% in one of them. That is larger than most of the price cuts we have written up this month.