How much more does Turkish cost in tokens? I measured it on my own site

The Turkish and English copy on mcalab.com.tr is the same length in characters. Run it through a tokenizer and Turkish comes out 39% heavier. Here is the full measurement.

Bu yazının Türkçesi: Türkçe sürüm.

A suspicion had been nagging at me for a while: does writing prompts in Turkish cost more than writing them in English? Everyone says "agglutinative language, it eats tokens" and nobody produces a number. So I used my own site as the test subject.

Here is the lucky part. mcalab.com.tr was built as a bilingual single-page site: the same HTML carries a data-lang="tr" block and a data-lang="en" block side by side. Which means I own a real parallel corpus that I wrote myself. Not machine translation — sentences composed by hand in two languages, saying the same thing.

Method

I wrote a small script that pulls the data-lang pairs out of the site and strips the HTML. After dropping duplicates (the nav labels appear on every page) I was left with 24 unique Turkish/English pairs. Then I pushed them through two tokenizers:

• cl100k_base — the tokenizer of the GPT-3.5 and GPT-4 era
• o200k_base — used from GPT-4o onward, and by the GPT-5 family

Tool: the gpt-tokenizer npm package, version 4.0.0. Measured on 19 August 2026.

Result

First, notice this coincidence, which I did not engineer — it just fell out:

Same information, same number of characters. On the modern tokenizer Turkish costs 39% more tokens. On the older one the gap was 80%.

Look at the word count too. Turkish says the same thing in 19% fewer words — "kaydedebilirsiniz" is one word, "you can save it" is four. But per word Turkish burns 2.16 tokens against English's 1.26. So Turkish wins on brevity and loses on billing anyway.

Why

Tokenizers are trained on corpora dominated by English. Frequent English words land on a single token; Turkish suffixes get shredded. I ran a few words individually:

That last line made me laugh. My own game's name is three tokens: Z, ı, pla. The dotless ı, a letter specific to Turkish, eats an entire token by itself. We manage to be expensive without even leaving the Latin alphabet.

There is one nice exception: Türkiye is a single token. Proper nouns that appear often enough make it into the vocabulary. So the problem is not "non-ASCII characters", it is frequency. A tokenizer makes cheap whatever it has seen a lot of.

What the tokenizer upgrade gave non-English

This is the cheerful part of the measurement. Across the same 24 pairs, Turkish went from 1,014 tokens on cl100k to 770 on o200k. That is a 24% reduction. English went from 563 to 554 — essentially unchanged.

Almost all of the new tokenizer's efficiency gain went to languages other than English. Nobody put "Turkish got 24% cheaper" in a launch post, but that is the number.

Turning it into money

At 19 August 2026 prices, Anthropic's pricing page lists Claude Opus 5 input at $5 per million tokens. Using the characters-per-token ratios above:

In a one-off chat the difference is rounding error. But if you run a product in production, being Turkish costs you a three-figure dollar amount every month. That belongs in your pricing model.

There is a second consequence that costs no money but hurts more: the context window is also denominated in tokens. A one-million-token window holds roughly 4.55 million English characters but only about 3.26 million Turkish ones. So the "1M context" on the box quietly shrinks by about 28% for a Turkish user.

What I changed

Three things, after the measurement:

1. I write system prompts in English. Asking the model to answer in Turkish is one thing; writing my instructions to it in Turkish is another. The instruction goes out on every single call, so it is the most expensive part of the payload. Translating it to English made it visibly smaller. I did not notice a quality difference — but that is an impression, not a measurement.
2. I don't use Turkish JSON keys or field names. This was the dumbest loss I found. When you ask for structured output, every key in the schema ships on every call. Writing username instead of kullanici_adi saves a couple of tokens by itself, but multiply by a twenty-field schema and thousands of daily calls and it shows up. Keep the text the user sees in Turkish; keep the keys the machine sees in English.
3. I leave the user's Turkish text alone. Translating what a user wrote before handing it to the model loses meaning, and the translation call costs money of its own. I accept the token bloat there.
4. I cache long, static prompts. A cache read on Anthropic costs a tenth of the base input rate. That does not remove the bloat, it just lowers the multiplier sitting on top of it — which is the cheapest fix available.

Limits of this measurement

Let me be honest: this is not an academic study.

• 24 pairs is a small sample, and all of it is my voice: product copy, short sentences. Legal text or chat transcripts would give a different ratio.
• The tokenizer I measured is OpenAI's. Claude's tokenizer is not open source and I don't have it. Anthropic's own docs say Claude 4.7 and later use a new tokenizer that produces roughly 30% more tokens for the same text — but that is a different phenomenon, a version difference, not a language difference. Don't conflate the two.
• I did not measure Gemini's tokenizer at all.

So "Turkish is 39% more expensive" means exactly this: in text written in my style, on the o200k_base tokenizer, 39%. Another corpus would give you 1.3, or 1.5.

What I am confident about is this: the gap is real, it is not small, and nobody tells you about it. "$5 per million tokens" looks language-neutral on a pricing page. It isn't. As a developer working in Turkish, you get less work out of the same dollar.

If you want to repeat this with your own text, the method takes ten minutes: take the same content in two languages, call the o200k_base encoder from the gpt-tokenizer package, divide the lengths. Your own number beats trusting mine.

← All posts