Why the second run costs less

Two separate mechanisms reduce what you pay. They are easy to confuse, because both amount to "we did not call the model for that one", but they work at different scales.

Duplicate detection, within one upload

When a batch is parsed, every unit is fingerprinted by its source text. Identical sources form a group, one member is translated, and the result is applied to the whole group.

This is what makes a first run cheaper than its unit count suggests. Sites repeat themselves far more than people expect: navigation labels, calls to action, product boilerplate, the same footer sentence on every page.

Matching is exact. "Book now" and "Book Now" are two different strings and cost two translations.

Caching, across runs

Every translation is stored, keyed by the source text, the target language and the kind of content it is. Upload the same page again next month and its unchanged paragraphs are answered from that store instead of being translated again.

The practical shape: a first run of a site is close to a full-price run. Re-running it after editing three paragraphs bills you for roughly three paragraphs.

What the cache belongs to

Cached translations are scoped to a project. Each project is a distinct website with its own voice and its own protected terms, so a translation cached for one project is never served to another. Two projects translating the same sentence each get their own answer.

What stops a cached translation being reused

• The source text changed. Any edit counts, punctuation included - it is a different string.
• A different target language.
• The text is used differently. The same words as a heading and as a meta description are cached separately, because they are translated under different constraints.
• You asked for fresh translations. Re-running a job and retranslating a single unit both bypass the cache on read, while still storing the new result for next time.

What does not invalidate it

Changing your brand voice or your glossary does not retroactively re-translate what is already cached. This is a deliberate trade: it keeps costs predictable and re-runs fast. If you have made a significant voice change and want it applied to existing content, re-run the job with fresh translations turned on and accept that you are paying for the work again.

Seeing the effect before you commit

Before a batch starts you get an estimate with an upper and a lower bound. The lower bound already accounts for the cache: it is what you pay if every predicted hit lands. The gap between the two is, roughly, what your existing translations are saving you.

What this means in practice

• Translate a site once, then keep it in sync cheaply.
• Do not split one website across several projects unless they really are different sites. You would be paying for the same translations twice.
• Small, frequent updates are the cheap path. Rewriting everything is the expensive one, and that is simply the cost of work that is genuinely new.