Arabic AI that actually answers in Arabic
Bolting Arabic onto an English-first AI product breaks in predictable places — dialect, layout, scanned documents and the token bill. What to look for instead.
Every AI product now claims to support Arabic. Most of them mean the model will reply in Arabic if you write to it in Arabic — which is table stakes, and is not the same as a product an Arabic-speaking team can actually work in all day.
The gap between those two things is where the frustration lives, and it shows up in the same places every time.
Replying in Arabic is the easy 20%
Ask an English-first assistant a question in Arabic and you will usually get a competent Arabic answer. Then you try to use the product around that answer:
- The interface is still left-to-right, so your Arabic paragraph is pinned to the wrong edge of the screen and punctuation lands on the wrong side of the sentence.
- The Arabic text renders in whatever fallback font the browser found, which is why it looks thin and slightly broken next to the English.
- Mixed content — an Arabic sentence containing an English product name and a number — reorders itself in ways that change the meaning of what you wrote.
- The settings, the billing screens, the emails and the documentation are all English, so anything beyond the chat box drops the user back into another language.
This is the same lesson as any bilingual interface, and we have written the long version: true RTL is not a checkbox. An assistant that answers beautifully inside a product that does not is still a product your team will resent using.
Dialect is a real requirement, not a nice-to-have
People do not write to an assistant in formal Modern Standard Arabic. They write the way they speak — Iraqi, Gulf, Levantine, Egyptian — often mixed with English technical words, sometimes typed in Latin characters.
A useful assistant has to understand input in dialect and know when to answer in dialect versus when to produce formal MSA. That distinction matters commercially: a WhatsApp reply to a customer and a letter to a ministry are not written in the same register, and a tool that only produces one of them is only half a tool. When you evaluate any assistant, test it with a real message from a real customer, not with a clean sentence you composed for the demo.
The document problem is the Arabic problem
The most valuable business use of AI here is not writing marketing copy. It is reading the pile of documents a company already has — and in this market a large share of them are Arabic, and many are scans rather than text.
That means the practical questions are: can it read an Arabic PDF that is really a photograph of a page? Can it pull line items out of a scanned invoice with Arabic headers and Latin numerals? Can it summarise a twelve-page Arabic contract without inventing a clause? Vision handling of Arabic script is meaningfully harder than Latin, and this is precisely where products that "support Arabic" quietly stop supporting it.
Arabic costs more per token — so billing design matters
Here is a detail that surprises people: the same sentence in Arabic usually consumes noticeably more tokens than its English equivalent, because tokenizers were built with English text in mind. Arabic script fragments into more pieces.
The practical consequence is that Arabic workloads cost more to run than an English cost estimate suggests. That makes the billing model more important than the headline rate:
- Per-token billing in small increments, so you are not buying a subscription tier sized for someone else's usage.
- Rates frozen at the moment of the request, so a future price change never rewrites a historical invoice.
- Per-key rate limits and monthly caps, so one runaway script cannot produce a surprise.
- A usage view you can actually reconcile against what your team did.
These are unglamorous properties. They are also the difference between an AI line item you can defend in a budget meeting and one you cannot.
What we built, and why
Peak AI exists because we needed a bilingual assistant for our own team before we needed a product: streaming chat with history that persists across sessions, documents and screenshots you can ask about, web search with cited sources, and three models to pick from depending on whether you want depth, speed or vision.
The parts we care most about are the ones that make it usable in Arabic beyond the reply: the entire product — chat, settings, documentation, emails — ships fully bilingual with real right-to-left layout, and the assistant answers in Arabic as naturally as in English. Chat is free with a PearlFibers account, which means testing the claims in this article costs you nothing but the ten minutes.
For builders, the API is deliberately boring: point any OpenAI-compatible SDK at the endpoint, swap the key, and your existing retries, streaming and telemetry keep working unchanged. Migration should not be a project.
How to evaluate any AI tool for an Arabic-speaking team
- Write to it in the dialect your customers use, not in textbook Arabic.
- Ask for output in both registers — a WhatsApp reply and a formal letter — and see if it knows the difference.
- Upload a scanned Arabic document and ask a specific question about a number inside it.
- Switch the whole interface to Arabic and try to reach the billing page.
- Paste a sentence mixing Arabic, an English brand name and a price, and check what comes back.
- Read the pricing model, not just the price.
And a word on judgement
An assistant is a drafting and reading tool, not a source of truth. It will produce a confident Arabic paragraph containing a wrong number as readily as a correct one. Keep a person between the model and anything with legal, financial or medical consequences, do not paste credentials or client data you are not permitted to share, and check figures against the system of record.
Used that way, the value is real and immediate: correspondence drafted in two languages, long Arabic documents summarised in seconds, and a team that stops switching languages to use its own tools.