Where AI Translation Costs Actually Come From — And How to Control Them

If your team already runs translation, evaluation, or post-editing through generative AI models, you've probably run into the question every localization lead eventually asks: what is this actually costing in tokens, and can it be brought down without touching quality? Token consumption is a real operating cost now, on par with delivery timelines or linguistic quality. Unlike those two, it's one most teams haven't built a system around yet.

Why token consumption is no longer just a technical detail

The real answer starts upstream, with how source files get parsed in the first place, because that determines what needs to be sent to the models, how much can be batched instead of repeated, and which model actually needs to see a given segment. Visibility is what makes those savings manageable: knowing exactly where the tokens go. The sections below each unpack one of those pieces.

Every call to a language model, whether to translate a text, evaluate a translation, or generate a post-edit, carries a direct cost tied to the number of tokens processed. Multiply that across thousands of TransUnits, projects, and clients, and the gap between a workflow that's been tuned for this and one that hasn't shows up as a very different number on the invoice by the end of the month.

For anyone leading localization strategy and operations, that creates two concrete needs:

Visibility: knowing exactly how many tokens are being consumed, in which process (translation, evaluation, or post-editing), and with which model.

Control: being able to act on that consumption without sacrificing quality or speed.

Four strategies that actually move the number

Start with four concrete strategies, all implemented through technology:

• Batch what belongs together. Grouping translation units into batches instead of firing one model call per segment cuts the fixed overhead you pay on every request: the same instructions and context served once for many segments instead of once per segment.

This saving happens independently of which AI model you use: it's a function of termbase's own processing layer, applied before any request ever reaches the provider. Take a 10,000-word document split into roughly 200 translatable segments, with about 5,000 tokens of instructions and context sent alongside each one: The saving compounds with how the major providers themselves price batch processing. As of September 2026, asynchronous batch APIs (Anthropic's Message Batches API among them) run at roughly half the cost of the equivalent real-time calls, on top of whatever the batching itself already saves in repeated context.

• Retrieve what's needed, not everything you have. How a system decides what terminology and context to feed the model (its retrieval, or RAG, configuration) has a direct effect on prompt size. Pulling in the handful of termbase entries actually relevant to a segment costs a fraction of what stuffing in the whole termbase does. It also tends to produce more consistent output besides.
• Match the model to the task. A straightforward, low-risk segment doesn't need the same model as a nuanced or high-stakes one, whether the call is translating it, evaluating it, or generating a post-edit. And the price gap between those two choices is not small: as of September 2026, the major providers' own public pricing shows a flagship model can run roughly 10 to 25 times more per token than their lightest one, depending on the provider and which two models you compare. Routing by language pair, content type, or a confidence threshold (cheaper/faster models for the routine volume, stronger models and post-editing reserved for what genuinely needs them) is one of the more direct ways to bring the average cost per word down without touching quality where it matters.
• Keep the option to run your own models. An open interface that connects to models from the major providers as well as self-hosted ones means the calculation isn't fixed. Once you know exactly which processes you want to run this way (translation, evaluation, post-editing), you can work out whether self-hosting changes the economics for your volume. Implementing your own models also buys resilience by protecting you against price increases from providers and keeps your cost structure in your hands.

There's usually more room than those four strategies suggest

Those four strategies cover what most teams can act on right away. Whether there's more room beyond them depends on something upstream of all of it: how the source file gets parsed in the first place, meaning what counts as one translatable segment, what metadata travels with it, and what gets stripped out before any of it reaches a model. A generic, off-the-shelf filter library sends whatever it was built to send by default: maybe unused translation-memory metadata, terminology entries that have nothing to do with the segment at hand, formatting instructions repeated across every unit in a batch instead of stated once. Building that parsing layer in-house means deciding, at the level of the data flow itself, what actually needs to reach the model in the first place. That's what keeps surfacing further token-reduction room over time, room a generic third-party parser was never built to expose, because stripping out the unnecessary wasn't part of its design brief.

You can't manage what you can't see

Every one of the four strategies above depends on the same precondition: knowing where the tokens are actually going. Per-model, per-project, per-document-type consumption has to be visible and traceable, or “optimizing” is just a guess. That visibility is also what makes routing decisions defensible later. You can point to why a given segment went to a given model, not just that it did.

That's the governance layer we've built into termbase.io: batching, configurable retrieval, engine routing, and an open interface to your model of choice, built on a parsing layer we developed ourselves rather than licensed off the shelf, all of it measured and traceable rather than hidden inside a black box. Not “use less AI.” Use the right model, for the right task, and know exactly why.

Terms used in this article

A few terms used throughout this article, defined:

A few questions this tends to raise

Can we see token consumption broken down by project or client? Yes. It's the same visibility described above: consumption tracked by project, task type, and model, not just as one aggregate number at the end of the month.

Do we have to switch AI providers to cut costs? Not necessarily. A well-designed integration allows you to optimize consumption with your current provider, as well as evaluate alternatives such as self-hosted models if volume justifies it.

Does any of this affect translation quality? Not when these strategies are implemented as described here. Batching, retrieval, and model routing all target tokens that weren't doing useful work in the first place, not the segments that need care. The risk isn't in the approach, it's in applying it carelessly, like routing everything to the cheapest model regardless of what's at stake, which is a different mistake and an avoidable one.

Pricing and batch-discount figures as of September 2026, per Anthropic's API pricing, Anthropic's batch processing docs, and OpenAI's API pricing.

See how termbase.io makes token consumption visible and gives your team control over parsing, retrieval, routing and model choice.

Explore the platform → www.termbase.io