Building an Arabic AI assistant: what changes, what it costs, and what still breaks

Most guides to Arabic chatbot development are written by vendors. They say Arabic has "30+ dialects", that it's "hard", and that their platform solves it, usually with an accuracy figure nobody can trace.

We built and run ConGreeto, a website assistant that answers visitors in their own language, Arabic included, for businesses across the Gulf and beyond. This post covers what actually changes in the engineering when Arabic is a first-class language: cost, language handling, rendering, lead capture, retrieval and compliance. Where we measured something, we say how, so you can check it.

1. What Arabic costs in tokens: it depends on the tokenizer

The common claim is that Arabic costs several times more than English to run through an LLM. That was true for older tokenizers. It's much less true now, and the difference matters when you budget.

We took six sentences that a Gulf business website actually receives (a property search, opening hours, a dental booking, a PPF quote, a delivery question, and a closing reply) and counted tokens for the English and Arabic versions using OpenAI's open-source tokenizer library, tiktoken:

Tokenizer

Used by

English tokens

Arabic tokens

Arabic ÷ English

cl100k_base

GPT-4, GPT-3.5, text-embedding-3

87

237

2.72×

o200k_base

gpt-4o, gpt-4o-mini, GPT-4.1, GPT-5 family

88

101

1.15×

Measured 14 October 2026 with tiktoken 0.14.0. Model-to-tokenizer mapping from tiktoken's own model table.

Per sentence on o200k_base, Arabic ranged from 0.79× to 1.6× the English count. The worst case was a sentence full of brand and model names ("Toyota Land Cruiser"), which get transliterated into Arabic script and split into more pieces.

Six sentences is a small sample, and translation choices move the numbers. Treat it as a direction, not a constant. The point holds: on current OpenAI chat models, Arabic costs roughly the same as English per message, not three times as much. Older articles quoting a large multiple are usually describing the older tokenizer.

There's one catch. OpenAI's text-embedding-3 models still use cl100k_base. If you embed Arabic content, budget for around 2.7× the tokens of the English equivalent. At embedding prices that's still small money (we covered the numbers in what a RAG chatbot actually costs), but it shows up when you re-embed large sites often.

Reproduce it yourself:

import tiktoken

pairs = [
("What are your opening hours on Friday?", "ما هي ساعات العمل يوم الجمعة؟"),
("Is delivery free to Riyadh, and how long does it take?", "هل التوصيل مجاني إلى الرياض، وكم يستغرق؟"),
# add your own: real questions from your own site beat ours
]

for name in ("cl100k_base", "o200k_base"):
enc = tiktoken.get_encoding(name)
en = sum(len(enc.encode(e)) for e, _ in pairs)
ar = sum(len(enc.encode(a)) for _, a in pairs)
print(f"{name}: English {en}, Arabic {ar}, ratio {ar / en:.2f}")

2. Language detection: Arabic script is easy, Arabizi is not

To reply in the visitor's language, you first need to know what it is. For Arabic that splits into two very different problems.

Arabic script is the easy case. Arabic characters sit in fixed Unicode blocks (U+0600–U+06FF, plus the supplement and extended blocks). Counting characters by range tells you the script with complete reliability, at zero cost, with no model call. It also can't be talked out of its answer by a clever prompt.

Statistical detectors are unreliable on short text. Libraries that guess the language of Latin-script text work well on paragraphs and poorly on chat messages. In our own testing, one widely used library read "Hello how are you today" as Somali. If you use one, require both a minimum length and a high confidence score, and when it isn't confident, don't force a language at all.

Arabizi is invisible to both. Many Arabic speakers type Arabic in Latin letters, with numbers standing in for sounds Latin lacks: "3" for ع, "7" for ح, "2" for ء. "kifak", "3ndi so2al", "kam el se3r?" are Arabic, written in the same script as English. Script detection sees Latin. Statistical detectors see noise.

You have to choose what to do with it, and both options have a cost:

• Reply in Arabic script. Many Arabizi writers read Arabic script fine, but some use Arabizi precisely because they're more comfortable reading Latin, and a wrong guess on an ambiguous message produces an Arabic reply to a visitor who wrote in another language.
• Reply in English. Safe and readable for most Gulf visitors, but it can feel like the assistant didn't understand.

We chose English for transliterated text in ConGreeto, because a predictable answer in a language most visitors read beats a guess. It's a product decision, not a solved problem, and we'd revisit it with real conversation data.

3. The language allow-list should be enforced in code, not just the prompt

Your client chooses which languages the assistant may reply in, usually the languages their team can follow up in. "Arabic and English only" is a common Gulf configuration. A visitor writing in another language should get a reply in a fallback language (English, in our case), not silence and not a language the business can't handle.

Writing that rule into the system prompt works most of the time. "Most of the time" isn't good enough when a visitor writes in Russian or Urdu and keeps insisting. So we also enforce it in code: detect the visitor's script deterministically and, if it's off the client's list, tell the model which language to use for that turn. The prompt describes the policy; code backs it up for the cases the prompt can lose.

Keep the language rule out of the cached part of the prompt, too. If changing a client's languages forces a rebuild of the whole static prompt, you lose your cache for nothing. We inject it at request time, which makes a language change instant and free.

4. Dialects: models understand them better than they write them

Gulf visitors often write in their spoken dialect. The honest state of current models comes from a 2024 benchmark by researchers at QCRI, AraDiCE, covering Gulf, Egyptian and Levantine Arabic. The authors found that Arabic-focused models such as Jais and AceGPT do better on dialect than general multilingual models, but that dialect identification, generation and translation remain hard.

In practice that suggests a sensible default for business assistants: understand the dialect, reply in clear Modern Standard Arabic with a natural, not overly formal, register. MSA is understood across the region, and a business reply in a slightly wrong dialect reads worse than one in plain standard Arabic. If your client needs a specific dialect (some consumer brands do), budget for a native-speaker review loop and an evaluation set in that dialect. Don't trust a demo.

5. Right-to-left rendering: let the browser do the bidi work

Chat UIs break on Arabic in predictable ways: a full stop at the wrong end of the line, a phone number with its groups reversed, "AED 150,000" mangled inside an Arabic sentence.

The fixes are mostly HTML, not code:

• Set direction per message with dir="auto", not on the whole chat window. A conversation can mix English and Arabic turns, and each bubble should take its direction from its own content. The W3C's guidance recommends dir="auto" for content whose direction isn't known in advance, and warns that it's not foolproof: it uses the first strong character, so an Arabic message that starts with an English brand name can be laid out left to right.
• Use logical CSS properties (margin-inline-start, padding-inline-end, text-align: start) so bubbles, avatars and timestamps mirror correctly without a separate RTL stylesheet.
• Don't set direction in CSS alone. The W3C advice is to keep it in the markup so it survives when styles don't load.
• Test on a phone, with real messages that mix Arabic, digits, English names and emoji.

6. Lead capture: Arabic numerals and Arabic context words

If your assistant captures phone numbers, Arabic changes two things.

Arabic-Indic digits. Visitors may type ٠٥٠١٢٣٤٥٦٧ (Arabic-Indic) or ۰۵۰۱۲۳۴۵۶۷ (the Persian/Urdu variant) instead of 0501234567. In Python, \d matches all of these by default, so a phone regex will happily capture them. But what it stores is the original characters, which a CRM's click-to-dial or a tel: link may not handle. When we tested our own extractor while writing this post, it caught the number and stored it in Arabic-Indic digits. Normalise to ASCII digits before storage:

import unicodedata

def ascii_digits(s: str) -> str:
return "".join(str(unicodedata.digit(c)) if c.isdigit() else c for c in s)

Context words. Short digit runs are ambiguous (an order number? a price? a phone?), so extractors often look for words like "call", "phone" or "WhatsApp" nearby. If that list is English-only, "رقمي" ("my number") or "واتساب" doesn't count, and shorter numbers given in Arabic get dropped. Gulf mobile numbers are usually long enough to pass on length alone, but landlines and short local formats may not be.

7. Retrieval: an Arabic question against English content

The most common Gulf case is an English website and an Arabic question. RAG systems usually combine vector search with keyword search, and the two legs behave differently here.

• The vector leg can bridge the languages. Multilingual embedding models place an Arabic question and the English passage that answers it close together. That's what lets an assistant answer in Arabic from English content without translating the site.
• The keyword leg goes blind. An Arabic query shares no words with English text, so full-text search returns nothing. That's fine as long as your ranking doesn't punish results that only one leg found.
• Arabic content needs an Arabic text-search setup. If the site itself is in Arabic, a keyword index configured for English only matches exact word forms. Arabic attaches prefixes such as ال ("the") and و ("and") to words, so "الشقة" and "شقة" won't match. Recent PostgreSQL versions ship an arabic text search configuration (check with SELECT cfgname FROM pg_ts_config;). Ours is English-configured today, which is fine for English sites answered in Arabic and weaker for Arabic-language sites. It's on our list.

Whatever you build, evaluate retrieval with real Arabic questions against your client's real content. Don't assume a model that answers English questions well will retrieve as well for Arabic ones.

8. Data protection questions to settle early

Gulf clients will ask where conversation data lives, and they should. Two laws come up most often:

• Saudi Arabia: the Personal Data Protection Law (PDPL). In force since 14 September 2023 and fully enforceable from 14 September 2024, enforced by SDAIA. Transfers to countries without an adequacy decision need safeguards such as SDAIA's standard contractual clauses.
• UAE: Federal Decree-Law No. 45 of 2021 on personal data protection, listed on the UAE government portal. Free zones such as the DIFC have their own data protection laws.

For an AI assistant, that means mapping every place personal data goes: your database, your model provider, your email provider, your error tracking. Each one is a transfer to account for. We aren't lawyers and this isn't legal advice. Settle it with the client's counsel before the build, not after launch.

A build checklist

Area

Decision to make before writing code

Model

Which tokenizer? Budget Arabic at ~1× English on o200k_base models, ~2.7× on cl100k_base

Languages

Which reply languages, and what's the fallback?

Enforcement

Prompt plus a code-level check for off-list languages

Arabizi

Reply in English or Arabic script? Decide and document

Dialect

Understand dialect, reply in MSA, unless the brand needs more

Rendering

dir="auto" per message, logical CSS, real-device tests

Lead capture

Normalise Arabic-Indic digits; Arabic context words

Retrieval

Multilingual embeddings; Arabic text search for Arabic content; Arabic eval set

Data

Data map per provider; PDPL / UAE PDPL review with counsel

Frequently asked questions

Is Arabic more expensive to run through an LLM than English?

On current OpenAI chat models (the o200k_base tokenizer), only slightly. Our sample came out at 1.15× English. On older models and on OpenAI's text-embedding-3 models (cl100k_base), Arabic took 2.72× the tokens in the same test.

Should an Arabic chatbot reply in dialect or Modern Standard Arabic?

For most business use, understand the dialect and reply in clear MSA. Current models write dialect less reliably than they read it, according to the AraDiCE benchmark, and MSA is understood across the region.

Do I need an Arabic-specific model?

Not for most business assistants. Large multilingual models handle MSA well. Arabic-focused models such as Jais and AceGPT did better on dialect in the AraDiCE benchmark, so consider them if dialect output really matters to the product.

Can an assistant answer in Arabic from an English-only website?

Yes. Multilingual embeddings let Arabic questions retrieve English content, and the model answers in Arabic. Test retrieval quality with real Arabic questions, because the keyword half of hybrid search won't help across languages.

Sources

• Token counts: Brillnex Systems measurement, 14 October 2026, tiktoken 0.14.0, six parallel English/Arabic sentences. Script above.
• AraDiCE: Benchmarks for Dialectal and Cultural Capabilities in LLMs: Mousi et al., QCRI, arXiv, September 2024 (revised December 2024).
• Structural markup and right-to-left text in HTML: W3C Internationalization.
• Saudi Arabia's Personal Data Protection Law becomes enforceable: Clyde & Co, 10 September 2024.
• Data protection laws: UAE Government portal.

From us

• What a RAG Chatbot Actually Costs: Build It, Buy It, or Have It Built
• Building a Chatbot Knowledge Base From a Website: What the Crawl Gets Wrong
• For the business owner's view, ConGreeto's guide to website chat in Arabic for UAE and Saudi visitors has a ten-minute test you can run on any tool.
• Building for the Gulf? We work with businesses in the UAE and Saudi Arabia. Tell us about your content and languages and we'll scope it honestly, including when an off-the-shelf product would serve you better.