Budgeting a multilingual support bot in Berlin

Fare watch EN2026-10-28

Imagine a team in Berlin preparing a support bot for customers who write in English, German, Turkish and Japanese. The task stays the same: read a delivery complaint and draft a helpful reply. But when the developers compare API usage, the token totals differ, even for carefully translated versions of the same request.

That difference matters when you estimate costs or decide how much conversation history to keep. It starts with a simple distinction: models process tokens, and tokens do not line up neatly with words.

Tokens are pieces of text, not a word counter

Before a model processes your message, a tokenizer converts the text into a sequence of numbered pieces called tokens. Depending on the tokenizer and the text, a piece might represent a whole word, part of a word, punctuation, whitespace or part of a character.

A familiar word may fit into one token. An uncommon name or a long compound word may need several. Two sentences with the same number of words can therefore produce different token counts. Character counts are not a reliable substitute either.

The tokenizer belongs to the model's processing system. Your application usually sends ordinary text; the service handles the conversion.

Equivalent translations can take different amounts of space

A translation preserves meaning, but it changes the text. Languages differ in word order, writing systems, word formation and the amount of wording needed to express a request.

Tokenizers also differ in which text patterns they represent efficiently. Their vocabularies are built using particular data and design choices. A common sequence in one language may have a compact representation, while a sequence in another language gets split into more pieces.

This means there is no universal rule such as “Japanese always uses twice as many tokens as English.” The result depends on the actual wording and the tokenizer. A short translated instruction may show one pattern; a technical document full of product names may show another.

A delivery complaint makes a useful first measurement

Start with a small request such as “My package arrived damaged. Please help me request a replacement.” Have a fluent speaker prepare natural equivalents in the languages your customers use.

Keep the task and surrounding instructions consistent, then run each version through the tokenizer or token-counting endpoint documented for your chosen model, when available. A token counter for an unrelated model can give misleading estimates.

Record the language, exact text, model and input token count.
Send representative requests and record the input and output usage reported by the API.
Include short messages, long complaints, addresses, product codes and mixed-language conversations.
Check that each reply meets the same quality standard before comparing cost.

One sentence demonstrates the mechanism. A collection of real support cases gives you a useful budget.

Token differences affect both bills and conversation length

Where pricing is based on tokens, more input tokens generally mean a higher input charge at the same rate. Output tokens matter separately, often at a different price. A translated answer can also have a different token count, so measuring only the prompt leaves part of the bill out.

For a basic estimate, multiply input tokens by the input rate and output tokens by the output rate, using the provider's stated pricing unit. Account for caching or other applicable charges separately.

Tokens also consume the model's context allowance. Instructions, conversation history, retrieved documents and tool results can all use that space. If equivalent content needs more tokens in one language, fewer messages or documents may fit within the same allowance. Reserve room for the response according to the model's documented limits.

A multilingual budget needs measurements by language

For the Berlin team, the practical next step is to track tokens and cost per successfully resolved conversation, grouped by language. That connects spending to the job the bot performs. Cutting tokens is useful only if customers still receive clear, accurate help.

RelayVano is a practical option for developers who want pay-as-you-go access to multiple AI models through an OpenAI-compatible SDK, with https://api.relayvano.com as the API base. Keep usage measurements tied to the selected model when comparing results.