How Much Does It Cost to Translate a Book with an LLM API?

Translating a 100,000-word English book through an LLM API costs from under $0.10 to about $4.20 in API fees on the models priced below, depending on the model, the target language, and whether you pay for a second checking pass. That range comes from the worked examples in this article, using list prices we checked on October 17, 2026.

The per-token price is the number everyone compares. It is rarely the number that surprises people. The bill moves with four things most calculators skip: how many tokens your target language needs, how much context you resend with every chunk, whether the model bills thinking tokens as output, and whether one oversized request pushes you into a higher price tier. This guide measures the first, puts numbers on the others, and gives you a formula you can rerun with your own book.

The Short Answer: Budget the Ceiling, Not the Average

For a 100,000-word English novel, our worked examples land here (single translation pass, then with a QA pass and a 10% retry buffer):

Two conclusions follow. First, the API bill is not what decides whether this is a good idea. Even the most expensive row is a few dollars. Second, the right-hand number is the one to budget. A plan that only covers one clean pass will be wrong as soon as a chunk fails, a check fails, or the model spends tokens thinking.

All token counts here come from OpenAI's o200k_base tokenizer. Other providers count differently, so treat the non-OpenAI rows as estimates until you count a sample chapter with that provider's own tool (more on that below). The full calculation is in the budget CSV.

What We Measured: The Same Text in 13 Languages

The usual rule of thumb, "about 1.3 tokens per word," describes English. It says nothing about your translation's output, and output tokens cost 4–6 times more than input tokens on every model in the table above.

To see how much the target language matters, we took one text that exists in parallel translations: the Universal Declaration of Human Rights, from the Unicode UDHR corpus (commit 547ac2b). We extracted the title and paragraph text from each language's XML file, normalized it to Unicode NFC, and counted tokens with tiktoken 0.14.0 on October 17, 2026. The token-ratio CSV lists file hashes and both encodings, and the counting script reruns it.

What this shows:

• The same meaning costs up to about twice as many output tokens. The Thai and Japanese versions of the text used 1.8–2× the tokens of the English original. The Portuguese and Chinese versions used about 1.2×.
• The tokenizer matters as much as the language. The older cl100k_base encoding needed 5.6× the English token count for Hindi; o200k_base needs 1.67×. A cost estimate copied from an older article, or from a model with a different tokenizer, can be off by a large factor for non-Latin scripts.
• This is one text. The UDHR is formal legal prose with repeated phrasing. Dialogue-heavy fiction or technical writing will produce different ratios. Use the table to pick a planning multiplier, then measure your own book.

The Vietnamese Surprise: Same Text, 2.25× the Tokens

The Vietnamese file in the corpus is stored partly decomposed: many accented letters are a base letter plus separate combining marks, rather than one precomposed character. Counted as stored, it came to 6,950 tokens. After NFC normalization, which changes no visible character, it came to 3,093.

That matters if your source text came out of a PDF or OCR tool. Text extracted from files can carry decomposed characters, ligatures, and other invisible oddities (see why PDF text copies out wrong). Normalize to NFC before you count tokens or send the text. It is one line of code, and on this file it more than halved the token count.

The Budget Formula

A book translation has three cost blocks. Write them down separately so you can see which assumption drives your bill.

source_tokens  = words × tokens_per_word          (English ≈ 1.15 with o200k_base on our sample)
chunks         = source_tokens ÷ chunk_size
input_tokens   = source_tokens + chunks × (instructions + glossary + carried context)
output_tokens  = source_tokens × target_ratio     (from the table above, or your own sample)
qa_input       = source_tokens + output_tokens + chunks × instructions
qa_output      = output_tokens × correction_rate
budget         = (input × input_price + output × output_price
                  + qa_input × input_price + qa_output × output_price) × (1 + retry_rate)

Our worked examples use these assumptions. Change any of them in the CSV:

With those numbers, a 100,000-word book becomes 115,000 source tokens, 58 chunks, and 207,800 input tokens for a single pass. Notice that chunk overhead added 81% to the input side. That is the hidden cost of keeping names and terms consistent across chapters, and it is the reason terminology consistency has a price.

Four Things That Change the Bill More Than the Model Does

1. Thinking tokens are billed as output

Google's Gemini pricing page lists output prices "including thinking tokens." DeepSeek's models and pricing page shows thinking mode as the default for its current models. If a model reasons before it answers, those tokens are charged at the output rate, the expensive one.

We did not measure thinking overhead, because it varies by model, setting, and text. Translation of plain prose usually does not need it. Turn reasoning off or set it to the lowest level your model allows, then compare one chapter with and without it. If it doubles your output tokens, it roughly doubles that part of the bill.

2. One giant request can cross a price tier

Sending the whole book in a single prompt looks efficient. On some models it moves you to a higher rate:

• Claude Haiku 5.5 costs $0.10 / $0.50 per million tokens for prompts up to 100,000 tokens, and $0.50 / $2.50 for prompts over that. A 115,000-token book in one prompt pays five times the rate for the whole request.
• Gemini 3.1 Pro Preview doubles its input price above 200,000 prompt tokens ($2.00 → $4.00) and raises output from $12.00 to $18.00.

Chunking keeps every request under these thresholds. It also limits the damage when one response fails.

3. Token counts are not portable between providers

Anthropic states that Claude 4.7 and later models use a tokenizer that "produces approximately 30 percent more tokens for the same text" than its earlier models (pricing documentation). That is a comparison between Claude generations, not between Claude and OpenAI, but it shows how much a tokenizer change moves the count.

Our table measures only OpenAI's o200k_base. Before you commit to another provider, count one representative chapter with that provider's own token-counting tool and replace the source_tokens and target_ratio values in the CSV.

4. Batch and off-peak pricing halve the rate

If you can wait for results, the batch APIs from OpenAI, Anthropic, and Google list prices at half the standard rate. DeepSeek's off-peak rates are also half its peak rates; peak hours on its pricing page are 01:00–04:00 and 06:00–10:00 UTC on weekdays. A book translation is rarely urgent, so this is the cheapest lever you have.

Two dates to watch: Gemini 3.6 Flash's listed prices run through December 31, 2026, and the page shows them doubling to $1.50 / $7.50 from January 1, 2027. Recheck any price in this article before you budget.

A Worked Example: English to Japanese on gpt-6.1-sol

Here is one row of the CSV in full, so you can follow the arithmetic.

The QA pass reads more input than the translation itself, because it needs both the source and the draft. It still costs less than the translation output, because input is cheap. If you are going to cut something, cut reasoning tokens before you cut the checking pass.

What the API Price Leaves Out

The API fee is a few dollars. The work around it is not:

• Getting clean text in. A PDF or EPUB has to be extracted, cleaned, and split without losing headings, footnotes, or reading order.
• Getting a usable file out. The model returns text. Rebuilding a formatted EPUB, DOCX, or PDF from translated chunks is a separate job, and often the hardest one (see translating a PDF while keeping its format).
• Consistency across chunks. You need a glossary, carried context, and checks for names that drift between chapters.
• Failure handling. Truncated responses, skipped paragraphs, and wrong-script characters have to be detected and retried. Our DeepSeek translation notes list the failures we see most in a production pipeline.
• Review. For anything you will publish, budget human review separately. Our comparison of AI and human book translation covers when that is needed and what it costs.

If you are a developer who enjoys building that pipeline, the API is the cheapest route by a wide margin. Pick a model with the LLM translation comparison, measure one chapter, and use the CSV to set a ceiling.

If you would rather not build it, BookTranslator handles text extraction, translation of the whole file in context, and the rebuild of PDF, EPUB, and DOCX files. For EPUB and DOCX tasks you can also turn on an auto glossary to keep names and terms consistent. It prices a task by the file's word count and shows the final price before you pay, so token ratios, retries, and reasoning settings don't change what you are charged. Upload the file, read the price, and compare it with the ceiling you calculated: against a budget model the raw API fee will usually be lower, against a premium model the two can be close. Either way, the comparison is not API fee versus product price. It is API fee plus the pipeline you would build, versus a finished file.

How to Check Your Own Number in 15 Minutes

1. Pick one chapter that is typical of the book: not the title page, and not the chapter full of tables.
2. Normalize it to NFC and count its tokens with your provider's counting tool.
3. Translate it once with your real prompt, glossary, and reasoning setting. Record input and output tokens from the API response.
4. Divide output tokens by source tokens. That is your target_ratio.
5. Divide the book's word count by the chapter's word count, and multiply.
6. Put the numbers into the budget CSV, keep the QA pass and the retry buffer, and treat the result as your ceiling.

One measured chapter is worth more than any table in this article, including ours.