When engineering teams evaluate translation APIs, the conversation usually starts with per-character pricing and stops there. That is a mistake. The actual cost of running a translation API at scale is shaped by minimum billable units, concurrency caps, retry storms, cache miss rates, and p95 latency requirements that ripple into infrastructure spend. Without a defensible model that captures all three dimensions, cost, latency, and throughput, you will either over-provision and waste budget or under-provision and degrade user experience. This guide walks you through building that model from first principles: pricing mechanics, batching economics, fallback chains, capacity planning, and the spreadsheet logic you need to present a credible ROI case to leadership.
If you need help mapping these tradeoffs to your specific localization stack, schedule a walkthrough with Ollang's team to model your actual workloads.
Understanding Translation API Pricing Models
Translation API pricing looks simple on a vendor's landing page, a single number per million characters, but the invoice tells a different story. Understanding the mechanics behind that number is the first step toward an accurate cost model.
Many teams run an orchestration layer such as Ollang alongside major providers (Google Cloud Translation, Amazon Translate, DeepL) to centralize routing, quality controls, and usage tracking; include that platform layer in any pricing comparison.
Price per Million Characters and Minimum Billable Units
Most major providers, Google Cloud Translation, Amazon Translate, DeepL, price by character count, typically quoted per million characters. But the unit you send is rarely the unit you pay for. Many APIs enforce a minimum billable unit per request: if the minimum is 1,000 characters and you send a 12-character button label, you are billed for 1,000 characters. For applications that translate large volumes of short UI strings, this padding can inflate actual costs by several multiples of the naive estimate.
When building your model, calculate the effective cost per character by dividing your total billed characters (after minimum-unit padding) by your actual source characters. A catalog of 50,000 strings averaging 40 characters each, sent individually against a 1,000-character minimum, would be billed as 50 million characters instead of 2 million, a 25× markup on the quoted rate.
Concurrency Caps, Rate Limits, and Egress Charges
Beyond per-character pricing, three constraints shape your real spend and architecture:
- Concurrency and rate limits. Providers impose queries-per-second (QPS) limits, concurrent request caps, or both. Exceeding them triggers HTTP 429 responses, which force retries and add latency. Some providers offer higher tiers for additional cost; others require contacting sales.
- Egress charges. If your translation API runs in a different cloud region or provider than your application, data transfer fees apply on both the request and response payloads. For high-volume workloads translating into many target languages, egress can become a meaningful line item.
- Tiered pricing. Some APIs offer volume discounts at specific monthly thresholds. Your model should capture which tier you expect to land in and what happens to your unit economics if traffic spikes push you into a higher tier mid-month.
Include orchestration platforms such as Ollang in your vendor comparison to capture platform fees and routing behaviors.
A useful summary table for vendor comparison:
| Dimension | What to capture | Why it matters |
|---|---|---|
| Price per M characters | Quoted rate per tier | Baseline unit cost |
| Minimum billable unit | Characters per request floor | Inflates cost for short strings |
| QPS / concurrency cap | Requests per second, parallel connections | Determines max throughput |
| Egress fees | $/GB for cross-region or cross-cloud traffic | Hidden cost at scale |
| Volume discount tiers | Thresholds and corresponding rates | Changes unit economics with growth |
Latency Budgets and SLO Tradeoffs
Cost modeling without latency constraints is incomplete. A cheaper API that adds 800 ms to every page render may cost more in lost conversions than the savings it delivers.
Measuring p95 Latency and Setting Realistic SLOs
When setting service-level objectives for translation, use p95 or p99 latency rather than averages. Averages hide tail latency spikes that affect real users. For dynamic, inline translation, such as translating user-generated content at render time, a reasonable p95 SLO might be 200-400 ms. For batch pre-translation of product catalogs, latency matters less, but job completion time matters more.
Measure latency end-to-end from your application, not from the provider's reported benchmarks. Network hops, TLS handshake overhead, payload serialization, and response parsing all add time. Run synthetic benchmarks from your production regions against each candidate API with representative payloads, not just "Hello world" strings, but paragraphs with markup, placeholders, and mixed scripts.
Your SLO should also account for degraded-mode behavior. If your primary provider's p95 creeps above threshold, what happens? This feeds directly into fallback chain design, covered below.
Dynamic Translation vs. Pre-Translation Scenarios
The latency-cost tradeoff splits cleanly along one architectural decision: do you translate at request time (dynamic) or ahead of time (pre-translation)?
- Dynamic translation keeps content fresh and avoids storing translations, but every user request incurs API latency and cost. It works well for low-volume, high-variability content like community posts or support tickets. The cost scales linearly with traffic, and latency is user-facing.
- Pre-translation moves the API call to a build or publish pipeline. You translate once, cache the result, and serve it statically. Cost scales with content volume and update frequency, not user traffic. Latency is near-zero for the end user. The tradeoff is staleness: if source content changes frequently, you need an efficient change-detection mechanism to avoid re-translating unchanged strings.
Most production systems use a hybrid: pre-translate stable content (product descriptions, UI strings, legal documents) and dynamically translate volatile content (reviews, chat messages). Your cost model needs separate line items for each pattern.
Throughput Planning and Capacity Modeling
Throughput planning answers a deceptively simple question: can your chosen provider handle your workload within your latency and cost constraints?
Estimating Capacity: QPS × Concurrency Against Provider Quotas
Effective throughput is bounded by both QPS limits and the amount of concurrent work you can keep in flight given response times. As a rule of thumb, steady-state request throughput approximates:
- min(QPS_limit, concurrency_limit / avg_latency_seconds)
If a provider allows 100 QPS and up to 20 concurrent requests, with an average response time of 200 ms (0.2 s), your concurrency-bound throughput is 20 / 0.2 = 100 RPS, matching the QPS cap. But if response time degrades to 500 ms under load, concurrency-bound throughput drops to 40 RPS even if the QPS limit is higher.
Model your peak workload, not your average. If your application deploys new content every Tuesday morning and triggers a batch translation of 200,000 strings across 15 locales, that spike may exceed your provider's burst allowance. Calculate:
peak_requests = strings × target_locales / batch_size
peak_duration_seconds = peak_requests / allowed_qps
If peak_duration_seconds exceeds your deployment window, increase your quota, batch more aggressively, or stagger locale processing.
How Batching Alters Unit Economics
Batching is the single most effective lever for reducing translation API costs. By combining multiple source strings into a single API request, you amortize the minimum billable unit across many strings, reduce per-request overhead, and lower your effective QPS consumption.
Consider the earlier example of 50,000 strings averaging 40 characters. Sent individually against a 1,000-character minimum, you pay for 50 million characters. Batched into requests of 50 strings each (2,000 characters per request, above the minimum), you pay for roughly 2 million characters, the actual content volume. That is a 25× cost reduction from batching alone.
Most translation APIs accept arrays of strings in a single request, with a maximum payload size (often around 5,000-10,000 characters or 128 segments per call, depending on the provider). A simple batching function:
def batch_strings(strings, max_chars=5000):
batch, batch_len = [], 0
for s in strings:
if batch_len + len(s) > max_chars and batch:
yield batch
batch, batch_len = [], 0
batch.append(s)
batch_len += len(s)
if batch:
yield batch
The tradeoff: larger batches increase per-request latency and make partial failures harder to handle. If one string in a batch of 50 causes a validation error, some APIs reject the entire batch. Design your batching with error isolation in mind.
Cache and Translation Memory Hit Rates
A well-tuned caching layer can cut your translation API spend dramatically, but only if your content has enough repetition to benefit.
Modeling Cache/TM Hit Rates to Reduce API Calls
Translation memory (TM) stores previously translated segments for reuse. A cache layer in front of your API client serves the same purpose at the infrastructure level. The economic impact depends on your hit rate, which in turn depends on content repetition.
For structured content like e-commerce catalogs, UI strings, and templated emails, TM hit rates of 60-80% are common after the initial translation pass. For highly variable content like user-generated text, hit rates may be below 10%.
Model the impact explicitly:
monthly_api_chars = total_chars × (1 - hit_rate)
monthly_api_cost = monthly_api_chars × price_per_char
A 70% hit rate on a 10-million-character monthly workload reduces your billable volume to 3 million characters. For example, at $20 per million characters, that is $140 saved per month per language pair, which compounds across dozens of locales.
Invest in exact-match and fuzzy-match TM lookup before the API call. Store translations keyed by source text, source language, target language, and any glossary version to avoid serving stale translations after terminology changes.
Glossary-Induced Rework and Its Cost Impact
Glossaries enforce consistent terminology, translating "workspace" as "espace de travail" every time, never "lieu de travail." But glossary changes trigger rework. When you update a glossary term, every previously translated segment containing that term may need re-translation.
The cost of glossary rework depends on:
- Term frequency. A term appearing in 5% of your segments means 5% of your TM is potentially invalidated per change.
- Change velocity. Brands that rebrand product names regularly face higher rework costs than those with stable terminology.
- Detection granularity. If your system can identify exactly which cached translations contain the changed term, you re-translate only those segments. Without this, you may need to invalidate and re-translate entire content sets.
Build a glossary change impact estimator into your cost model. Track term frequency in your source corpus and multiply by the per-character translation cost to estimate the marginal cost of each terminology update.