Use case
The best API for translation and localisation
Translation is the rare workload where input and output are roughly the same size, so the output rate carries about half the bill instead of a footnote of it, and the model to pick is the one with the flattest output-to-input ratio you can accept — in this catalogue that is DeepSeek V4 Pro, whose output rate sits closest to its input rate among the reasoning-capable models.
Every other workload here is lopsided. Translation is not: a thousand tokens of source become roughly a thousand tokens of target, which means a model's output rate is applied to as many tokens as its input rate. A model that is cheap on input and expensive on output — the common shape — loses its advantage entirely on this page.
That makes the in-to-out spread, not the headline input rate, the thing to compare. Two models with identical input rates can differ several times over on a balanced workload purely because one charges a large multiple for output, and that difference is invisible on any pricing page that leads with the input number.
What actually matters here
- Output-to-input rate spread
- With output tokens roughly matching input tokens, a model charging a large multiple for output is charging that multiple on half the workload. This ratio decides the bill more than either rate alone.
- Terminology consistency
- A localisation pipeline must render the same product name and UI string identically across every locale and every rerun. Drift is not a quality problem you notice in one string — it is one you notice across a whole release.
- Language pair coverage
- Open-weight models are uneven across pairs in a way benchmarks average away. The pair you actually ship decides this, and the only honest test is your own strings.
- Placeholder and markup fidelity
- Translated copy usually carries interpolation tokens, HTML or ICU plurals. A model that mangles them produces output that is linguistically fine and functionally broken, which costs an engineering pass to find.
What it costs, at a localisation pipeline, ~420M source tokens/month
Worked from this catalogue’s published rates at 420M input and 400M output tokens a month. Your figure will differ; the arithmetic will not.
| Model | Input | Output | Per month | At official rates |
|---|---|---|---|---|
| DeepSeek V4 Pro37% | $0.28/M | $0.55/M | $337.60 | $530.70 |
| DeepSeek V4 Flash36% | $0.090/M | $0.18/M | $109.80 | $170.80 |
| GLM-5.242% | $0.82/M | $2.55/M | $1,364.40 | $2,348.00 |
Excludes cached-input savings, which on a repeated-prefix workload typically reduce the input column substantially. Cached rates are published per model on the pricing page.
Questions
- Why does the strongest general model cost so much more here?
- Because it charges a much larger multiple for output than for input, and this workload produces almost as many output tokens as input tokens. On an agent workload that multiple is applied to a rounding error; on translation it is applied to half the volume. Compare the two rate columns in the table above and the gap explains itself.
- Should I translate string by string or document by document?
- Document by document wherever the format allows, because a string in isolation loses the context that decides gender, register and pronoun choice. It also amortises the instruction prefix across more content rather than resending it per string.
- Does a glossary help the bill or just the quality?
- Both, indirectly. A glossary in the system prompt is cacheable and cheap, and it removes the most common reason to rerun a translation — inconsistent terminology — which is a rerun you would otherwise pay for at full rate.
- Can I mix models across locales?
- Yes, and it is often the right call. Pin the pairs where quality is the constraint to a stronger model and run the rest on the cheapest one that passes review, sending an explicit model id per call so nothing is substituted underneath you.