What language should your system instruction be in? Measuring three approaches when most prompts arrive in the user's language

Input tokens spread by more than 2x across languages

I started with the cost side. Here is the same twelve-sentence system instruction, translated into five languages and run through countTokens.

# measure_instruction_tokens.py
# Measure the same instruction across languages and report inflation vs. English
from google import genai
 
client = genai.Client()  # reads GEMINI_API_KEY from the environment
MODEL = "gemini-flash-latest"
 
INSTRUCTIONS = {
    "en": open("instructions/en.txt", encoding="utf-8").read(),
    "ja": open("instructions/ja.txt", encoding="utf-8").read(),
    "id": open("instructions/id.txt", encoding="utf-8").read(),
    "vi": open("instructions/vi.txt", encoding="utf-8").read(),
    "th": open("instructions/th.txt", encoding="utf-8").read(),
}
 
def count(text: str) -> int:
    # Measured as contents, not as system_instruction — see the note below
    return client.models.count_tokens(model=MODEL, contents=text).total_tokens
 
base = count(INSTRUCTIONS["en"])
for lang, text in INSTRUCTIONS.items():
    n = count(text)
    print(f"{lang}\t{n:>4} tokens\t{n / base:.2f}x\t{len(text):>4} chars")

Results for my instruction:

Mirroring into Thai spends about 2.9x the tokens of English to say the same thing — 398 extra tokens per request. My description pipeline runs up to about 1,200 requests a day. Even assuming Thai users are only 20% of the mix, that is over 90,000 tokens a day attributable purely to translating the instruction.

The spread mattered more than any single number. Indonesian at 1.25x is not worth thinking about. Thai at 2.86x is. What I had been treating as one thing — "multilingual support" — turned out to be several different things once cost entered the picture.

One snag worth flagging: passing an instruction through GenerateContentConfig means it will not show up in a plain contents token count. When you want a figure close to actual billing, reconcile against response.usage_metadata.prompt_token_count after generation. The gap between estimates and billing is the same one I worked through in building a budget gate on countTokens.

Output-language match — where nine tokens got me

Now the benefit side. I ran 4 languages x 3 approaches x 500 requests on gemini-flash-latest and classified the language of each response body. Classification uses Unicode script composition rather than asking a model, because otherwise the instrument and the subject share the same failure mode.

Approach B adds exactly one line to the end of the English instruction:

Respond only in the language identified by this BCP-47 tag: th-TH

countTokens puts that at 9 tokens.

Thai went from 91.2% to 99.1%. For nine tokens.

Mirroring reached 99.4% — 0.3 points ahead of the pin. That is one or two responses out of 500. For those one or two, Thai requests were paying 398 extra tokens each.

My prediction was wrong. What helped was not aligning the instruction's language with the input, but naming the output language explicitly as a single constraint. In hindsight it reads as obvious. The model could read the English instruction perfectly well; it simply had never been told which language to answer in.

That remaining 0.9% does not disappear here, of course. Driving match rate toward 100% is separate work, and I kept the design for measuring drift as a continuous quantity in measuring contamination rate and tightening it in stages. The question here stops at which approach to build on.

What mirroring quietly cost me

This is the part that made the measurement worth doing.

On the second metric — schema compliance — only C dropped.

Lining up the failures made the cause obvious. When the instruction was translated, the translation had also translated the field names and enum values.

The English instruction said:

Set "mood" to one of: calm, vivid, minimal.

In the Thai version, calm, vivid, and minimal had each become a Thai adjective. As prose for a human reader, that is a correct translation. But the response_schema enum is still in English, so the model follows the translated wording and returns values the enum does not contain. The better the translation, the more reliably this breaks.

So C's 96.8% was not a limit of mirroring. It was a hole in my translation step. Carving out what must never be translated closes it.

# Separate what may be translated from what must survive verbatim
PROTECTED = ("mood", "calm", "vivid", "minimal", "aspect_ratio", "safe_zone")
 
def assert_identifiers_intact(translated: str) -> None:
    """Fail the translation step if any protected identifier was lost."""
    missing = [w for w in PROTECTED if w not in translated]
    if missing:
        raise ValueError(f"Translation dropped identifiers: {missing}")

With that check in place, Thai mirroring came back to 99.0% schema compliance — essentially level with B.

Which, good as that is, leaves C in an awkward position. You maintain a translation step and a protected-token check, retranslate five languages every time the instruction changes, and pay up to 398 extra tokens per request — to gain 0.3 points of output-language match. For my workload, that did not balance.

Before / After — collapsing it to one call site

With the answer in hand, I moved the implementation. Before, the per-language branch lived at the call site.

# Before — the caller has to know about languages
def generate_description(text: str, lang: str) -> str:
    if lang == "ja":
        si = JA_INSTRUCTION      # translated instruction
    elif lang == "th":
        si = TH_INSTRUCTION      # translated instruction
    else:
        si = EN_INSTRUCTION
    resp = client.models.generate_content(
        model=MODEL,
        contents=text,
        config=genai.types.GenerateContentConfig(
            system_instruction=si,
            response_mime_type="application/json",
            response_schema=DESCRIPTION_SCHEMA,
        ),
    )
    return resp.text

Every new language grows the elif chain, and every instruction edit means touching every translation. I once ran a stale Japanese instruction for two weeks without noticing, precisely because of this shape.

After, the instruction is one English text and the only thing that varies is a BCP-47 tag.

# After — one English instruction; only the final line changes
from google import genai
from google.genai import types
 
BASE_INSTRUCTION = open("instructions/en.txt", encoding="utf-8").read()
 
# UI language to BCP-47. Unknown languages fall back to English rather than guessing.
LOCALE_TAGS = {
    "ja": "ja-JP", "th": "th-TH", "vi": "vi-VN",
    "id": "id-ID", "en": "en-US",
}
 
def build_system_instruction(lang: str) -> str:
    tag = LOCALE_TAGS.get(lang, "en-US")
    return (
        f"{BASE_INSTRUCTION}\n"
        f"Respond only in the language identified by this BCP-47 tag: {tag}"
    )
 
def generate_description(text: str, lang: str) -> str:
    resp = client.models.generate_content(
        model=MODEL,
        contents=text,
        config=types.GenerateContentConfig(
            system_instruction=build_system_instruction(lang),
            response_mime_type="application/json",
            response_schema=DESCRIPTION_SCHEMA,
        ),
    )
    # Confirm real cost from usage_metadata rather than estimating
    log_usage(lang, resp.usage_metadata.prompt_token_count,
              resp.usage_metadata.candidates_token_count)
    return resp.text

Five instruction files became one, and the per-language maintenance cost went away. A side effect: the system instruction is now byte-identical across every language, which is exactly the shape context caching wants.

Falling back to English for anything outside LOCALE_TAGS is deliberate. Assembling an arbitrary tag from the device locale and passing it straight through led the model to attempt generation in low-resource languages, with a visible quality drop. Holding only the languages you have decided to support feels safer to me.

How I would choose

Rearranged into the order I would actually decide in:

Four of those five rows point to B for me. That is a statement about my workload, which is mostly structured output. For an app where conversational warmth is the product, 398 tokens is a bargain.

What decided it was not which approach is better in the abstract, but which failure hurts. When an enum breaks, my wallpaper metadata corrupts and the downstream batch stops. A slightly stiff tone costs me far less than that.

Three things I checked before shipping

1. Measure match rate per language. Averaged across all languages, strong English and Indonesian numbers mask a weak Thai one. I missed this for about three weeks. Grouping by language surfaces it the same day.

2. Don't classify with a model. Ask Gemini to identify the output language and your detector inherits the same wobble you are trying to measure. Unicode script composition is deterministic and ran in under 0.1 ms per item.

3. Re-measure when the model behind the alias changes. gemini-flash-latest switched to Gemini 3.5 Flash on July 15 when it reached general availability, so the alias now points somewhere new. Every number here was taken after that switch, but the same thing can happen again. Sampling 100 requests per language weekly is enough to notice. For the budget side of that watch, I wrote up setting a per-user token budget.

Where to start

If you are running a multilingual app on a single English instruction right now, measure that instruction with countTokens across your target languages. It takes ten minutes. At 1.2x there is nothing to think about. At 2.8x there is.

Then add the BCP-47 line, send 100 requests, and put the match rates next to each other. If that is enough, you never have to build the translation step at all.

The whole exercise cost me half a day. In exchange, an entire translation pipeline I had been about to build turned out to be unnecessary. Days when the thing you didn't have to build goes up by one are quietly good days.