If you've priced out a localization vendor recently, you've probably noticed the math doesn't make sense. Your team ships 40 times a month, the string file changes daily, and somewhere on a sales call someone is asking you to forecast your "per-word volume for FY2026."

Per-word billing was built for an era when companies translated a marketing brochure once a quarter and called it done. That era ended a long time ago. Most software teams are stuck retrofitting modern release cycles onto a pricing model from the late 90s.

In 2026 that's finally breaking. Here's what's replacing it.

What "usage-based" actually means for localization

Usage-based pricing charges you for what you actually move through the system: API calls, characters processed, string updates, or live requests served. The closest analogy is how you already pay for Stripe or a CDN. You pay when something happens, not when a quarterly contract says you should.

A few things this gets you that flat per-seat or per-word doesn't:

• Costs track real release velocity instead of forecasted volume
• Translation memory hits cost less than fresh translations, the way they should
• You don't lose money on the months where your product was quiet
• Finance can actually trace spend back to specific projects or locales

The trade-off is real. You give up the false comfort of a predictable annual line item. In exchange you get something that scales with the business instead of against it.

Why this is happening now

Per-word stuck around so long because translation used to be the bottleneck. You paid a human translator $0.15 per word because a human had to read every word.

Modern pipelines inverted that. The raw translation is close to free. What costs you is the surrounding work: deciding when to use machine translation versus an LLM versus a human reviewer, feeding the model enough context that the output isn't generic, catching the strings that need cultural adaptation rather than a literal translation.

Charging per word here is like charging per character for a database query. The unit you're billing is no longer the unit that drives cost.

Two practical things follow. The platforms still selling per-word are usually doing it because their cost structure is human-translation-heavy. That's not bad per se, but you should know which kind of vendor you're buying. The platforms that re-architected around AI tend to surface usage in different units — translation memory hits, AI runs, runtime requests served — and they bill on those.

What engineering leaders are actually looking at

A few things come up consistently when engineering leaders evaluate localization platforms in 2026.

Integration depth comes up first. Does the platform hook into your existing CI/CD pipeline, or does it expect you to use its own dashboard as the source of truth? Anything that lives outside the engineering workflow tends to get abandoned within a year.

Runtime delivery is the next question. Can translations update without redeploying the app? Teams that ship multiple times a day find bundle-based localization stops working pretty quickly.

Cost transparency closes the loop. If the platform can't tell you which feature launch cost you the most in translation, the billing model isn't really usage-based. It's just a different invoice.

This is roughly the lens General Translation was built around: AI translation tightly coupled to engineering workflows, runtime delivery, and usage-based billing with visibility down to the request. But the broader point is that the whole category is moving this direction regardless of which platform a team picks.

Where this is going

The honest read is that localization is starting to look less like a vendor relationship and more like an infrastructure dependency. You don't sign a per-word contract with your CDN. You don't pay per-seat for error monitoring. In a few years it's going to feel just as strange that you ever did it for translation.

If you're picking a platform right now, the most useful thing you can do is ignore the pricing page for a minute and look at how the vendor talks about their own product. Are they describing a translation service, or a piece of infrastructure? The answer usually tells you what you need to know.