The Same Message in Chinese and English

By J. Wren · Published 2026-10-26

Counts taken on 2026-10-21; rates as synced on 2026-10-26; see the change log for changes since.

Pricing English and Chinese by the character leaves something out: the same message has a different number of characters in each. The earlier article on Gemini and GPT token counts priced input per character. This one prices a whole message, request and reply, from tokens counted on the same content in three versions. In the ten exchanges used here the English text runs to 6,840 characters. The Traditional Chinese version runs to 2,510. The Simplified Chinese version runs to 2,511. Either Chinese version has 0.367× the English character count.

Tokens are what gets billed. On OpenAI's o200k_base tokenizer the Traditional Chinese version came out at 1.298× the English token count, and on Gemini's at 1.052×. The Simplified Chinese version came out at 1.103× and 0.978×. Priced as input plus output, one thousand exchanges in Traditional Chinese cost between 1.2868× and 1.2875× of the English price on the five GPT rows (priced on o200k_base, which is assumed for these models and not checked; see the scope note below) and between 1.043× and 1.044× on the four Gemini rows. In Simplified Chinese the ranges are 1.0929× to 1.0935× on the GPT rows and 0.971× to 0.972× on the Gemini rows. These figures describe the ten exchanges below. They are not a rate for Chinese in general.

Why characters are the wrong unit

The earlier article's per-character table answers one question: what does a million characters of this kind of text cost. A message that says the same thing in two languages is not a million characters in each, and a per-character price has no way to show what happens when the character count itself changes. Its English and Chinese samples were not written to say the same thing, so they cannot supply the missing ratio.

This article fixes the content instead. There are ten exchanges, each a request and a reply: polite email rewrite, explain a text-editor setting, three troubleshooting steps for slow Wi-Fi, two-sentence product summary, unit conversion with the calculation shown, difference between two spreadsheet functions, meeting time across three cities, scale a recipe from 4 to 6 servings, explain a disk-space error message, can headphones still be returned. Each exists in English, Traditional Chinese and Simplified Chinese, written to match sentence for sentence, with the same facts, numbers and units. The sample conversations were drafted by an AI model for this article and were not sent to any of the models being priced. I reviewed three of the ten Traditional Chinese sets and edited one sentence (in both Chinese versions); the Simplified Chinese text has not been reviewed by a native speaker. No professional translator was involved and nothing was back-translated. The Simplified versions are re-worded with mainland terms, not converted glyph by glyph; the word substitutions are listed per exchange in the results file.

The replies are longer than the requests by design; the output side section comes back to that.

Counting the tokens

The GPT side is cl100k_base and o200k_base, run offline with tiktoken; of the two, only o200k_base is used to price the GPT rows. The Gemini side is the countTokens endpoint, called once per segment on each of the four Gemini ids on the price list, with the empty-string count subtracted, as in the earlier article. All four ids returned identical counts for all sixty segments, so they share one column below.

Characters and tokens for the same content

Table 1 gives the counts for all ten exchanges together, split into requests and replies. Figure 1 plots each Chinese version against the English one, which is the baseline of 1, and Table 2 holds the same ratios with the request and reply sides separated.

Table 1 — characters and tokens, ten exchanges together. Gemini is one column; all four ids gave the same counts.

Figure 1 — Chinese relative to English: characters, o200k_base tokens and Gemini tokens

Table 2 — ratio to the English version, which is the baseline: characters, and tokens on the request side, the reply side and in total.

A token ratio is the character ratio multiplied by English characters per token and divided by Chinese characters per token; that is arithmetic, not a finding. In every row of Table 2 the token ratio is larger than the character ratio, so the Chinese text uses more tokens per character than the English text on all three tokenizers. The thing to look at in Table 2 is the gap between the request column and the reply column: the request side is the higher of the two in every Chinese row, for example 1.340× against 1.284× for Traditional Chinese on o200k_base. Where a bill lands between those two figures depends on how much of it is input and how much is output.

Against the earlier article, which used different texts, English on o200k_base came out at 4.168 characters per token here and 5.224 there, about a fifth lower here, while Traditional Chinese (1.178 and 1.181) and Simplified Chinese (1.387 and 1.401) barely moved. On Gemini all three are lower here: English 3.920 against 5.175, Traditional 1.368 against 1.550, Simplified 1.472 against 1.657. Density depends on the text, so read the ratios here as belonging to this text. How Traditional and Simplified text of the same content compare with each other was measured in Table 2 of that article; the two Chinese versions here are reported against English.

From tokens to money

The price of the ten exchanges is the request tokens at the input rate plus the reply tokens at the output rate. The table reports the price of one thousand exchanges, which is the ten multiplied by a hundred; that scaling is exact arithmetic, not an assumption.

tokens_in  = sum of request tokens, per language and tokenizer
tokens_out = sum of reply tokens, per language and tokenizer
cost       = (tokens_in * input rate + tokens_out * output rate) / one million
price per thousand exchanges = cost * 100
ratio      = price in Chinese / price in English, from unrounded values

GPT rows use the o200k_base counts and Gemini rows use their own model's counts. The reply is priced as the fixed text it is, as if a model had produced exactly that text; a real bill also carries reasoning tokens, system prompts, tool definitions and earlier turns, none of which are here. No prompt in this data is near a long-context threshold; the higher rates that apply there are covered in the context window article.

Figure 2 — USD per one thousand exchanges, input and output, nine models, English and the two Chinese versions

Table 3 — price of one thousand exchanges (USD), the rates used (USD per million tokens), and the ratio to English. Claude rows are not measured.

Each row's ratio is a weighted mean of its tokenizer's request ratio and reply ratio, weighted by the input and output shares of the English bill, which the row's output-to-input price multiple sets. The five GPT rows share one set of token counts and differ only in rates, with multiples from 5× to 6.25×. Their Traditional Chinese ratios run from 1.2868× (GPT-5.4 nano) to 1.2875× (GPT-5.6), inside the interval from the reply ratio 1.284× to the request ratio 1.340×. With identical counts and multiples that differ little, output carries nearly the same share of the English bill on each of these rows, and the ratios land close together. The four Gemini rows share their own counts, with multiples from 5× to 8.333×; their ratios run from 1.043× (Gemini 3.5 Flash-Lite) to 1.044× (Gemini 3.6 Flash), between 1.042× and 1.081×. In both groups the lowest multiple has the highest ratio. Nothing here says rows on one tokenizer must agree; a different multiple would weight the two sides differently.

For Simplified Chinese the GPT rows run from 1.0929× to 1.0935× and the Gemini rows from 0.971× to 0.972×. Those Gemini rows are the only ones in Table 3 where a Chinese version comes in under the English price.

Ten exchanges is a small sample, so Table 4 prices each exchange on its own and divides the Chinese price by the English price, on GPT-5.6 Terra and Gemini 3.1 Pro (preview), which both charge 6× as much for output as for input. On the GPT row the Traditional Chinese exchanges run from 0.977× to 1.448× of the English price, and one of the ten, meeting time across three cities, comes in under it. On the Gemini row the Simplified Chinese exchanges run from 0.806× to 1.104×, and six of the ten are under the English price. The other two columns run from 0.856× to 1.210× (GPT row, Simplified Chinese, one of the ten under the English price) and from 0.852× to 1.129× (Gemini row, Traditional Chinese, two under). For the GPT row's Traditional Chinese column, the spread between exchanges is far wider than the spread between the GPT rows in Table 3: in this data the text moves the ratio more than the choice of GPT row does.

Table 4 — price of each exchange in Chinese divided by its price in English, input and output, per exchange.

The output side

Output tokens are the larger part of every bill in this data, and that is a property of how the exchanges were drafted. The replies run to 2.983× the length of the requests in tokens (English, o200k_base). At that length, output is 94% to 96% of the English bill across the nine rows. For the Traditional Chinese version the share is 93% to 96%. For the Simplified Chinese version it is 93% to 96%. Both the length and each model's output-to-input price multiple set that share. With a reply as long as its request it would be 83% to 89%.

With output carrying that much of the bill, each row's ratio sits close to its tokenizer's reply ratio in Table 2. A workload of short replies to long prompts would shift the weights toward the request side.

Applying the ratios to your own bill

A bill's ratio is a weighted mean: its English input share times the request ratio in Table 2, plus its output share times the reply ratio. Take the ratios from the Table 2 row for your model's tokenizer, and use the shares of the conversation text itself, not of the whole bill: system prompts and tool definitions that stay in English, and reasoning tokens, are not covered by these ratios. Suppose output is 60% of an English bill and input 40%, a mix with longer prompts than the exchanges here and one this article did not measure. Applying this sample's request and reply ratios to it, the Traditional Chinese ratio on o200k_base is 1.306×, which would turn an English bill of $500 a month into about $653; on Gemini the same shares give 1.057×, or about $529. For Simplified Chinese the ratios would be 1.111× and 0.983×, or about $555 and $491.

For these ten exchanges taken together, no choice of shares moves the ratio outside the interval between the reply ratio and the request ratio: 1.284× to 1.340× for Traditional Chinese on o200k_base and 1.042× to 1.081× on Gemini. A single exchange can fall well outside it (Table 4 goes down to 0.977× on the GPT row and 0.852× on the Gemini row, both for Traditional Chinese), so treat these as a description of this sample, not as bounds for your text. To price your own text, count it with the token counter first, then price the volume with the cost calculator.

Limits of this sample

This is ten exchanges, all drafted for this article, so the ratios belong to this text. Table 4 shows how far the priced ratio moves from one exchange to the next, from 0.977× to 1.448× on the GPT row for Traditional Chinese; another writer, register or domain can land elsewhere. The replies are fixed texts, not output from the models priced here, and the output side of a real bill depends on how long the model chooses to answer. Nothing here compares the quality of an answer in one language with another. The prices are the standard rates on this site's price list, without caching, batch or priority pricing or any regional surcharge. Claude is absent for the reason given above. Rates move, so the dollar figures date from the sync noted at the top.

Re-running it

The script and its output are published next to the earlier ones: measure_same_message_cost.py and measure_same_message_cost.results.json. The original wording of all sixty segments is in the results file, under corpus.pairs[].per_lang.<language>.<request|reply>.text, where <language> is en, zh_tw or zh_cn; this site's pages are checked to be English-only, so the Chinese text is in the file rather than on this page. How the conversations were drafted is under corpus.provenance_note. The script holds the corpus as constants at its top, which you can replace with your own text.

pip install tiktoken google-genai
set GEMINI_API_KEY=...          # export on macOS and Linux
python measure_same_message_cost.py
python measure_same_message_cost.py --offline    # reuse the stored counts, re-read pricing.json

The script reads ../pricing.json (the same file the calculators use), so keep it in a folder whose parent holds that file, or pass --pricing PATH. For --offline, put the results file next to the script: it is read from there and overwritten in place, with no API call. The live run stops without writing anything if any internal check fails. The results file also carries the figures quoted in the prose under display, the per-exchange ratios under per_pair, and the earlier article's numbers under summary.crosscheck_vs_g1.

For the per-character view of the same tokenizers, see the Gemini vs GPT token-count guide and whether 4 characters equal 1 token. For changes to the rates themselves, see the pricing change log.