How Much Does AI Translation Actually Cost? Benchmarking 6 LLMs Against DeepL and Google Translate

What we are measuring

The question is mundane, which is exactly why it is so rarely answered properly: how much does it actually cost to translate a piece of content with a large language model, and are the traditional machine translation engines still price-competitive.

This is a study of translation cost in general. Polish-to-English is the worked example – one source language, one target language, one text – but the methodology and most of the conclusions transfer directly to any language pair. Where a finding is specific to Polish, or to translating out of a morphologically rich language, it is flagged as such.

Test setup

All translations were produced through the LATW AI Translator for WPML plugin running on WordPress, so these are not synthetic API calls in isolation but the same code path a real site uses to localise content – with an identical prompt, payload format and request parameters across every model, leaving only the model and its reasoning effort as variables.

That path shapes the numbers in ways worth stating up front: WPML does not treat a page as continuous prose, it segments it into discrete translatable strings, and the plugin sends those as a single JSON object keyed by string ID with a system prompt instructing the model to return the same structure with everything non-textual (keys, HTML tags, attributes, URLs) preserved verbatim. This article came out as 37 segments, from 4 to 1,666 characters, median 337, a quarter of them under 60. So the model never sees flowing prose but a bag of fragments; not everything billed as input is translatable text, since keys, braces and the prompt all cost tokens; and the output is JSON too, meaning output tokens are not pure translation either and a structurally malformed response is a total loss rather than a partially useful one.

Source material

The source text is the Polish Wikipedia article Kawa (coffee), truncated to its first three sections – the lead, Nazwa (Etymology) and Historia (History). That comes to 13,339 characters.

The choice was deliberate. Wikipedia is CC BY-SA 4.0, so both the source and every generated translation can be republished, which is what makes the benchmark reproducible. The article is also neutral by editorial policy and mixes registers – botany, etymology, history, economics – rather than being uniformly technical or uniformly casual.

What the request actually contains

This is the correction that most benchmarks skip, and it changes the numbers:

Component	Characters	Share of input
Translatable text (the 37 segments)	13,339	86.8%
JSON scaffolding (keys, braces, quotes)	1,194	7.8%
System prompt	841	5.5%
Total input string	15,374	100%

Only 86.8% of what gets billed as input is content you wanted translated. The remaining 13.2% is protocol. DeepL and Google Translate bill for the 13,339 characters and nothing else; LLMs bill for all 15,374. Any comparison that ignores this understates LLM cost and, worse, corrupts any per-character tokenizer analysis.

Scope

Category	Systems tested
Budget models	gemini-3.5-flash-lite, gemini-3.7-flash, GPT-5.6 Luna, Claude Haiku 4.5
Frontier models	GPT-5.6 Sol, Claude Opus 5
Traditional MT	DeepL, Google Translate (phrase-based)

Models exposing a reasoning-effort control were run at low / medium / high. Claude Haiku 4.5 was run in its default mode without extended reasoning.

What exactly gets measured

Three quantities, all read directly from the API response rather than estimated:

1. Input tokens – how many tokens the same 15,374-character request consumed at each provider.
2. Output tokens – how many tokens each provider billed for the response, including reasoning tokens where applicable.
3. Cost – usage multiplied by pricing frozen as of the test date.
   The core methodological problem: LLMs bill per token, DeepL and Google Translate bill per character. These units are not directly comparable, so every result is normalised to cost per million characters of translatable content – the 13,339 figure, not the 15,374 figure. That is deliberate. It is the unit budgets are planned in, and it correctly charges the LLMs for their protocol overhead rather than hiding it in the denominator.

What this benchmark does not measure

Translation quality. This is a cost study and should be read as one. The cheapest model here is not therefore the best model – it is the cheapest. Quality evaluation (automatic metrics against a human reference plus blind manual review) is a separate layer, outlined at the end. Only both layers together support a recommendation.

---

Token consumption

Before the money, the raw usage – because that is where most of the surprises live.

Input: the same text, four different sizes

Every model received the identical 15,374-character request. The number of tokens they turned it into differs by more than half:

Provider / tokenizer	Input tokens	Characters per token	Overhead vs. best
Gemini (3.5-flash-lite, 3.7-flash)	4,868	3.16	–
GPT-5.6 (Luna, Sol)	4,938	3.11	+1.4%
Claude Haiku 4.5	5,484	2.80	+12.7%
Claude Opus 5	7,497	2.05	+54.0%

Note that these characters-per-token figures describe the whole request, not the Polish prose alone. The prompt and the JSON scaffolding are ASCII and tokenize considerably more efficiently than inflected Polish, so the true rate on the text itself is worse than the table suggests. Isolating it would require running each vendor’s tokenizer against the two components separately, which is a worthwhile follow-up but not something the API usage figures alone can tell you. What the table does support is the relative comparison, since every model received byte-identical input.

Two findings survive that caveat intact.

Tokenizers differ substantially across model generations from the same vendor. Claude Haiku 4.5 and Claude Opus 5 come from the same provider, ran on the same input, through the same plugin, with the same prompt – and Opus counted 36.7% more tokens for a byte-identical request. This was verified against the other test texts and is not a measurement artifact. Whatever changed in the tokenizer between those generations costs over a third more input tokens on this content, before a single price-list difference is applied.

This is the most under-modelled variable in LLM cost planning. Everyone compares price lists. Almost nobody checks what the price list is being multiplied by. Across the four tokenizers here the spread is 54% – wider than the gap between several competing price tiers, and it compounds in the direction that hurts, making expensive models look closer to cheap ones than they are.

The general lesson for non-English content: a rate quoted “per million tokens” buys a different amount of actual text at every vendor, and the gap widens as the source language gets more inflected. Polish, Finnish, Hungarian, Turkish and Czech all pay this tax; English does not.

Output: where the bill actually explodes

The translated JSON is, unsurprisingly, roughly constant in size – the English response runs about 3,500–3,800 tokens, keys and structure included. Everything above that figure is reasoning, billed at the output rate.

Model	low	medium	high	Growth low → high
gemini-3.5-flash-lite	3,720	11,878	12,141	×3.26
gemini-3.7-flash	3,724	–	12,508	×3.36
GPT-5.6 Luna	3,477	3,517	3,763	×1.08
GPT-5.6 Sol	3,516	–	3,968	×1.13
Claude Opus 5	5,480	–	5,504	×1.00
Claude Haiku 4.5	3,802 (default mode)

This is the most consequential usage finding in the study. The “reasoning effort” control behaves completely differently at every vendor:

• Gemini takes it literally. Going from low to medium triples output tokens. The subsequent step to high adds only about 2%, so the entire jump happens at the first increment. The model generates roughly 8,000 reasoning tokens on top of a response that is only about 3,700 tokens long.
• OpenAI effectively ignores it on this task. Luna grows 8%, Sol 13% – noise, not a change of strategy.
• Opus 5 does not react at all (+0.4%), but starts from a higher baseline – 5,480 tokens against an expected ~3,700 – which suggests a fixed reasoning overhead already present at low.
  The reasonable reading: translation is not a task that benefits from extended reasoning. It is a text transformation, not a problem to be solved. The segmented format reinforces this – the model is filling in values in a fixed structure, which leaves very little for deliberation to improve. Models that nonetheless emit thousands of reasoning tokens are doing work billed at the most expensive rate on the price list, with no guarantee that it improves anything.

Output-to-input ratio

Across every run without inflated reasoning, the ratio of output to input tokens sits consistently at 0.69–0.80. Two effects combine here: the English text is genuinely shorter than the Polish original, and it tokenizes better. The JSON keys are identical on both sides and therefore neutral.

This has a direct budgetary consequence that generalises. When translating out of a poorly-tokenized language, most of your billed volume sits on the input side, which is 4–6× cheaper than output. Translating into that language inverts the ratio and the same word count costs materially more. Pricing is not symmetric with respect to translation direction – a bidirectional localisation pipeline cannot be budgeted with a single figure.

---

Cost

Full results

The test cost covers a single request carrying 13,339 characters of translatable content. The “per 1M chars” column scales that by ×74.97 into the planning unit, and includes the prompt and JSON overhead the LLMs are billed for.

System	Effort	Pricing (in / out per 1M tokens)	Tokens in	Tokens out	Test cost	Per 1M chars
GPT-5.6 Luna	low	$0.20 / $1.20	4,938	3,477	$0.0052	$0.39
GPT-5.6 Luna	medium	$0.20 / $1.20	4,938	3,517	$0.0052	$0.39
GPT-5.6 Luna	high	$0.20 / $1.20	4,938	3,763	$0.0055	$0.41
gemini-3.5-flash-lite	low	$0.30 / $2.50	4,868	3,720	$0.0108	$0.81
gemini-3.7-flash	low	$0.75 / $3.75	4,868	3,724	$0.0176	$1.32
Claude Haiku 4.5	–	$1.00 / $5.00	5,484	3,802	$0.0245	$1.84
gemini-3.5-flash-lite	medium	$0.30 / $2.50	4,868	11,878	$0.0312	$2.34
gemini-3.5-flash-lite	high	$0.30 / $2.50	4,868	12,141	$0.0318	$2.38
gemini-3.7-flash	high	$0.75 / $3.75	4,868	12,508	$0.0506	$3.79
GPT-5.6 Sol	low	$4.00 / $20.00	4,938	3,516	$0.0901	$6.75
GPT-5.6 Sol	high	$4.00 / $20.00	4,938	3,968	$0.0991	$7.43
Claude Opus 5	low	$5.00 / $25.00	7,497	5,480	$0.1745	$13.08
Claude Opus 5	high	$5.00 / $25.00	7,497	5,504	$0.1751	$13.13
Google Translate (phrase-based)	–	$20 / 1M chars	13,339 chars	–	$0.2668	$20.00
DeepL (volume rate)	–	$27.50 / 1M chars	13,339 chars	–	$0.3668	$27.50
DeepL (sub-1M plan)	–	$32.50 / 1M chars	13,339 chars	–	$0.4335	$32.50

Notes on the table:

• Google Translate includes 500,000 characters per month at no charge; the $20/M rate applies to the overage.
• DeepL and Google are billed on the 13,339 translatable characters only. The LLM figures include the prompt and JSON overhead, which is the correct comparison – that overhead is not optional in an LLM pipeline.
• Every LLM row reconciles exactly against usage × price list. There are no unexplained charges.

Findings

1. Traditional MT engines are the most expensive option in the study.

This is the counterintuitive headline. DeepL ($27.50 per million characters at the volume rate, $32.50 on a small plan) and Google Translate ($20.00) cost more than every LLM tested, frontier models included. Against GPT-5.6 Luna the gap is 51× for Google and 71× for DeepL. Against Claude Haiku 4.5, roughly 11–15×. These price lists were written when the alternative was a human translator, and they have not tracked the collapse in inference cost.

The caveat is real. DeepL and Google sell determinism, low latency, an SLA, and – relevant to the JSON format used here – no risk of a structurally malformed response that discards the entire batch. Their pricing is also indifferent to batching, which is not true of any LLM. And Google’s free 500k characters per month means that at low volume the actual cost is zero, which beats any per-token rate. The traditional engines lose on unit price and win on predictability.

2. Reasoning effort on translation is pure waste.

On Gemini, moving from low to medium nearly triples the bill – flash-lite goes from $0.81 to $2.34 per million characters, flash from $1.32 to $3.79 – while producing a response of identical length. Since no output content was added, the entire difference is reasoning.

The default for translation workloads should be the lowest available effort setting, and raising it should require hard evidence from the quality layer, not the intuition that more thinking must be better. Note that this lever only exists at some vendors: on the OpenAI and Anthropic models tested, the same control barely moved usage at all, so the tuning advice is provider-specific rather than universal.

3. The spread is 34×, and model choice dominates every other optimisation.

From $0.39 (Luna low) to $13.13 (Opus 5 high) for the same million characters. Batching, prompt trimming and caching are each worth tens of percent; the model choice is worth an order of magnitude. For high-volume workloads – catalogue localisation, documentation, WordPress content – the model decision is the first-order budget decision and everything else is a second-order correction.

4. The tokenizer is a hidden price multiplier.

Claude Haiku 4.5’s input rate is 3.3× flash-lite’s, but the real cost gap is wider, because Haiku turns the same request into 12.7% more tokens. For Opus 5 the overhead reaches 54% against Gemini and 37% against Haiku from the same vendor. For non-English content, compare effective cost per character on your own payload, not headline cost per token. The price list alone can mislead by tens of percent.

5. Roughly an eighth of every LLM input is protocol, not content.

The prompt and JSON scaffolding accounted for 13.2% of the input string here, and the prompt’s share is inversely proportional to batch size. This is invisible in every price list and in most benchmarks, but it is money, and it is partially controllable: batch aggressively, keep the system prompt short, and – where the provider supports it – cache the prompt so the fixed portion is billed at a discount. The traditional engines have no equivalent overhead, which narrows their disadvantage somewhat, though nowhere near enough to close a 51× gap.

6. Frontier models have no economic case here until the quality layer produces one.

GPT-5.6 Sol costs 17× more than Luna from the same provider. Opus 5 costs 34× more than Luna. Justifying that requires a dramatic quality difference. This study does not measure quality, but the magnitude sets the bar very high. At a 34× price gap, the sensible architecture is almost always translate with a budget model and selectively review with a frontier model where the stakes justify it – not run the entire corpus through the most expensive option available.

Practical recommendation

For a typical high-volume localisation pipeline: a budget model at the lowest reasoning effort, with segments batched aggressively into as few requests as the context window allows, and pricing verified on a per-character basis against your own payload rather than the vendor’s headline rate. Reserve traditional MT for cases where determinism or a hard SLA is worth the premium, or where the free tier covers your volume outright. Reserve frontier models for critical content, applied to fragments rather than to the whole corpus.