Why Your AI Agent Fails in Gulf Arabic: The Tokenization Tax, Dialect Gap, and How to Architect a Bilingual Agent for Dubai

Why does Arabic cost more than English in an LLM API?

Because LLM APIs bill per token, and English-centric tokenizers split Arabic into more tokens per word. A tokenizer learns its vocabulary by merging the most frequent character sequences in its training corpus, so text in a language that was under-represented gets broken into smaller fragments. Researchers at NeurIPS 2023 showed that the same text translated into different languages can differ in tokenized length by up to 15 times, which translates directly into API cost, latency and how much of the context window the text consumes.

The metric to know is fertility: the average number of tokens per word. Bayanat Labs' analysis of the Arabic tokenization tax gives illustrative ranges rather than measurements of named models, but they show the shape of the problem:

Why does Arabic morphology break subword tokenizers?

Arabic attaches prefixes and suffixes directly onto words, so one written token can hold what English spreads across four. A single string can carry a conjunction, a definite article, the stem and a possessive pronoun, which means the number of distinct surface forms is enormous and each is individually rare. A byte-pair vocabulary trained mostly on English cannot afford dedicated entries for all of them, so it falls back to short fragments and, in the worst cases, single bytes.

Dialect makes this worse. Colloquial Gulf spelling isn't standardised, so the same word appears in several written forms, and every variant fragments differently. Add the habit of writing Arabic in Latin letters (often called Arabizi) and mixing in English terms mid-sentence, and the tokenizer sees three scripts' worth of noise in one message. The practical consequence is the same one we covered for Hinglish voice agents in India: the language your users actually type is not the language your model was benchmarked on.

Do LLMs really perform worse on Gulf and other Arabic dialects?

Yes, consistently. A 2026 study, Cultural Benchmarking of LLMs in Standard and Dialectal Arabic Dialogues, evaluated models across cultural reasoning, MSA-to-dialect translation and dialect-steering generation on a dataset spanning 13 Arabic-speaking countries, and reports that models perform worse on all three tasks in the dialectal setup than in the MSA one. On the speech side, the Arab Voices benchmark framework unifies 31 datasets across 14 dialects and reports substantial heterogeneity in acoustic conditions and in how strong and consistent the dialectal signal is, which is why a single word error rate quoted in a vendor deck says little about your callers.

Arabic-centric models exist to narrow the gap. The authors of Jais, a 13-billion-parameter Arabic-English model family, claim better Arabic knowledge and reasoning than existing open Arabic and multilingual models by a sizable margin. That is the authors' own evaluation, and a benchmark score is not a guarantee on your dialect, your domain or your tone, so any model shortlist needs testing on a sample of real messages from your customers before you commit.

What does a production architecture for a bilingual Arabic-English agent look like?

Treat language as a routed property of each message rather than a global setting. The pipeline below is our working design for Gulf deployments, offered as practice rather than a standard:

• **Language and register detection first.** Classify each incoming message as English, MSA, Gulf dialect, Arabizi or mixed. This decides the model route, the prompt template and the reply register.
• **Normalise before you embed or match.** Arabic text needs consistent handling of letter variants, optional diacritics and elongation characters, plus a decision on Arabic-Indic versus Western digits, or retrieval and exact-match tools silently miss.
• **Index knowledge in both languages.** For retrieval, use a multilingual embedding model and store the source document with an Arabic and an English rendering where possible, so a dialect query can land on either. Then test retrieval separately from generation, because cross-lingual recall drops are invisible in an end-to-end demo.
• **Route by cost and fluency.** Send routine intent classification to a cheaper or Arabic-optimised model and reserve the stronger model for hard turns, using the same principles as LLM model routing.
• **Reply in the user's register.** A customer writing in colloquial Arabic should not receive a legalistic MSA answer. Put register instructions in the system prompt and include dialect-appropriate examples.
• **Keep safety rules language-independent.** Guardrails and escalation triggers must fire on Arabic and mixed-script input as reliably as on English, and be tested in both.
• **Handle right-to-left in the interface and templates.** Bidirectional text in emails, PDFs and chat widgets breaks in subtle ways when numbers, English brand names or punctuation sit inside Arabic sentences.

How do you budget the token cost before launch?

Measure fertility on a sample of your own Arabic traffic and multiply it through your forecast, instead of reusing an English estimate. Bayanat Labs' own recommendation is the same: tokenize a representative sample of your Arabic traffic, divide tokens by words, and compare models by cost per word rather than price per million tokens, since that comparison can reorder a vendor shortlist.

Then feed the result into your inference budget forecast: higher fertility also means longer prompts, slower time to first token and a smaller effective context window for retrieved passages, so the cost shows up in latency and answer quality as well as the invoice. For enterprise buyers in the Gulf, this belongs in the business case alongside the typical AI consultancy cost in Dubai.

What about data residency and UAE regulation?

Language choice and data location interact. A regulated buyer may require that prompts containing personal data stay in-country or in a controlled region, which can push you toward a regionally hosted Arabic-centric model for sensitive turns and a global model for the rest. The legal side is covered in our UAE PDPL guide for AI agents, and the technical pattern of reducing what leaves your boundary is the one in our PII redaction architecture. Decide the routing rules with your DPO before you pick a model, not after.

How AIBOOTSTRAPPER solved this for a client

This is the problem we hit building VitalPulse, a remote patient monitoring platform and AI consultation assistant for a Dubai clinic. The challenge was that the clinic couldn't scale doctor availability, had no way to monitor patients between visits, and patients waited hours for basic triage. We engineered a wearable connected to a real-time dashboard, paired with a clinically guarded AI assistant that triages symptoms, has safety guardrails and bilingual support, and hands off to human doctors with a complete pre-filled summary.

The published results were 24/7 remote vitals monitoring and triage, 68% faster consultation prep and support in two languages, Arabic and English. If you are planning an AI agent for customers in the UAE or wider Gulf, we can help you measure the tokenization cost on your own traffic, choose and test models on your dialect mix, and design the routing and guardrails. See our AI product development services or get in touch.

Sources and further reading

1. 1.Petrov et al. — Language Model Tokenizers Introduce Unfairness Between Languages (NeurIPS 2023, arXiv 2305.15425)
2. 2.Bayanat Labs — The tokenization tax: the hidden cost of Arabic in English-first LLMs
3. 3.Al Kautsar et al. — Cultural Benchmarking of LLMs in Standard and Dialectal Arabic Dialogues (arXiv 2605.00119)
4. 4.Sullivan et al. — Arab Voices: Mapping Standard and Dialectal Arabic Speech Technology (arXiv 2601.13319)
5. 5.Sengupta et al. — Jais and Jais-chat: Arabic-Centric Foundation and Instruction-Tuned Open Generative LLMs (arXiv 2308.16149)