AI running costs are the line nobody budgets for. The build quote is a one-time number, but the assistant you launch in Kuwait or Dubai bills you every month it answers a customer — and the bill has five parts, not one.
What actually lands on the monthly bill
AI running costs are the five recurring lines a live assistant generates, and most proposals we review in Kuwait disclose two of them: model usage (tokens in and out), retrieval and storage (your knowledge base, re-indexed every time prices or policies move), the channel fee (WhatsApp, Instagram DM or a phone number), hosting and monitoring, and human review of what the assistant actually told customers. The build price and the run-rate are two different conversations, which is why we publish fixed terms with no retainers for the build rather than one monthly figure that quietly bundles both and lets neither be checked.
Ranked by how often they surprise an owner, that order is almost exactly reversed. Model usage is the line everyone asks about and the one least likely to hurt. Human review is the line nobody prices and the one that decides whether the assistant survives its first quarter. Why AI projects fail in the Gulf is rarely a model problem — it is an ownership problem, and ownership has a monthly cost whether or not anyone wrote it down.
Why Arabic costs more per conversation
Tokenisers split Arabic into more tokens per word than English — commonly close to twice as many for the same meaning, because Arabic morphology and script fragment under subword vocabularies built mostly on English text. The practical effect is direct: a bilingual assistant answering the same question in Arabic consumes materially more of your token budget than the English version, and a retrieval step that pulls Arabic policy text pays that multiplier on the way in as well.
That is not an argument for launching English-only. It is an argument for sizing the Arabic path deliberately — keep retrieved passages short and specific, cache answers to your twenty most repeated questions, and summarise long documents once at indexing time instead of re-reading them inside every conversation. Building DWA, a bilingual pharmacy delivery service in Kuwait, made the same point in a non-AI setting: the Arabic and English journeys are never mirror images, so they should not be forecast as one.
A worked example: one WhatsApp assistant, one month
Take a Kuwait services business handling roughly 3,000 inbound customer messages a month, about 1,200 distinct conversations, a little over half of them in Arabic. The lines look like this:
- Model usage — a retrieval-grounded answer is typically 2,000 to 4,000 input tokens and 150 to 400 output. At current list prices that is a fraction of a fils per answer, so a few thousand conversations land in the low tens of dinars, not the hundreds.
- Channel fees — Meta bills template messages per message by category, while replies inside the 24-hour customer-initiated service window are free. What moves this line is the volume of outbound templates you send, not the number of questions you answer. Check the current Kuwait rate card before modelling it.
- Retrieval and hosting — a vector index of a few thousand passages plus a small always-on service is a fixed, predictable line. It scales with how much content you index and how often you re-index, not with conversations.
- Human review — thirty to sixty minutes a week of someone reading transcripts and correcting the knowledge base. Costed at a real salary, this is frequently the largest single line on the list.
- Change — menus, prices, policies and opening hours move, and every move is a re-index plus a round of spot checks.
The shape matters more than our figures: at this volume the variable AI cost is the small part and the fixed operational cost is the big part. If a vendor quotes a monthly number that rises with conversations but never with content, ask what is actually being billed. Our published ranges for build and run sit in AI automation pricing in Kuwait, and the comparable numbers for a mobile product are in app development cost in the GCC.
How to keep the run-rate flat
Five habits keep month twelve looking like month two:
- Cap and alert on spend per day and per conversation, so a loop or a scraper is a notification rather than an invoice.
- Route by difficulty — a small, cheap model for classification and repeat FAQs, a frontier model only for the hard ten percent that genuinely needs it.
- Own the knowledge base in your own repository, in plain files. The moment your answers live only inside a vendor dashboard, switching costs become part of your run-rate.
- Measure deflection, not conversations. A rising message count is not progress; the number that matters is tickets a human never had to touch.
- Re-index on a schedule rather than on every edit, and keep one versioned source of truth so two teams cannot publish two prices.
The honest frame for all of this is total cost of ownership rather than a build quote, and the provider quota and limit documentation — Microsoft publishes theirs in detail — is where the ceilings that shape your bill are actually written down. If you want a run-rate forecast before you commit to a build, that is part of how we scope AI work: a monthly number you can defend to a finance director, produced before the first line of code, not discovered in month three.