Swahili Speech Recognition: Choosing an ASR Model for Kenya

Most speech-to-text models are benchmarked on American and British English, and it shows the moment a Nairobi caller mixes Swahili, English, and Sheng in one sentence. The good news: the last two years produced the first credible wave of Swahili-first ASR models, from Google chirp models with a Swahili (Kenya) locale to open Kenyan fine-tunes of Whisper reporting word error rates near or below 14 percent. This guide compares the real options with sourced numbers, works out the cost at call-center volumes, and gives you a one-week procedure for choosing on your own audio instead of vendor benchmarks.

Why generic speech-to-text fails on Kenyan calls

Three properties of Kenyan phone audio break ASR models trained mostly on English.

First, code-switching. Callers move between Swahili and English mid-sentence, often with Sheng vocabulary layered on top. A model that must commit to one language per utterance will transcribe half the sentence as phonetic noise. Second, accent. Even purely English speech from a Kenyan caller sits far from the training distribution of most US-built models. Third, the channel. Telephony audio arrives at 8 kHz through compression codecs, which strips the acoustic detail models rely on.

This is not speculation. OpenAI's own model card for Whisper large-v3 warns that the models "perform unevenly across languages," with lower accuracy on low-resource languages and "disparate performance on different accents and dialects," and that hallucinated text is "likely worse on lower-resource and/or lower-discoverability languages." Swahili sits in exactly that category for most global models.

We covered the acoustic and linguistic root causes in why voice AI mishears Kenyan callers. This post is about the next question: given those constraints, which model do you actually pick?

One measurement note before the numbers. ASR quality is measured as word error rate (WER): the percentage of words the model gets wrong, so lower is better. WER is only comparable within the same test set. A model scoring 14 percent on clean read Swahili can easily score 30 percent on noisy phone calls. Every number below comes from a different evaluation, so treat them as ballparks, not rankings, and run your own benchmark before committing. The procedure at the end shows how.

The models that actually support Swahili today

Managed APIs

Google Cloud Speech-to-Text V2 is the most explicit option. Google's supported languages page lists Swahili (sw) and Swahili, Kenya (sw-KE) on its chirp, chirp_2, and chirp_3 models. The chirp_2 and chirp_3 rows for Swahili include model adaptation, word-level confidence, and profanity filtering. Model adaptation matters in practice: it lets you bias recognition toward your vocabulary, such as SACCO product names, Kenyan place names, and surnames, which is where generic models fail hardest. Luo (Kenya) also appears as luo-KE on chirp and chirp_2, and Kamba (Kenya) appears as kam-KE on the same two models. Kikuyu does not appear anywhere on the page at the time of writing.

Other major US speech APIs have uneven African language coverage. Deepgram's models and languages documentation notes that all its models default to English unless told otherwise, and African language support across its Nova lineup should be verified against its current language list before you commit. Vendor language support changes quarterly, so check the docs, not a blog post, including this one.

Open models you can self-host

This is where the interesting movement is. Four models worth knowing:

microsoft/paza-whisper-large-v3-turbo. Microsoft's Paza model is a fine-tune of OpenAI's whisper-large-v3-turbo for six Kenyan languages: Swahili, Kalenjin, Kikuyu, Luo, Maasai, and Somali. It is MIT-licensed and was trained on the Africa Next Voices Kenya dataset, a Kikuyu dataset from DigiGreen plus a proprietary one, and the Swahili split of Mozilla Common Voice. The card reports consistent WER improvements over the base model across the six languages, with gains tracking training data volume per language.

msingiai/sauti-asr. A Kenyan fine-tune of the Paza checkpoint focused on Swahili. It reports 13.72 percent WER on a 500-sample held-out Kenyan Swahili test set, the strongest published Swahili number we found. Two honest caveats from the card itself: performance is weaker on code-switched Swahili and English speech, which describes most real Nairobi calls, and the authors frame it as suitable for evaluation and prototyping. The license is listed as "other," so read it before commercial use.

mutaician/east-africa-omniasr-300m. A 325-million-parameter CTC model built on Meta's omniASR, Apache 2.0 licensed, with INT8 exports that run on CPU through sherpa-onnx. On its development benchmark it scores 16.00 percent WER on Swahili with greedy decoding, improving to 9.23 percent with a KenLM language model. A small CPU-friendly model with an Apache license is a serious option for high-volume batch transcription where GPU costs dominate.

openai/whisper-large-v3. The baseline everyone fine-tunes from. Trained on five million hours of labeled audio, it covers roughly 99 languages including Swahili, and it is MIT-licensed via the official repository. For Kenyan audio it is usually the floor, not the ceiling: the Kenyan fine-tunes above exist precisely because the base model underperforms on this distribution. It also runs as a batch model, not a real-time streaming one, out of the box.

Beyond Swahili: Kikuyu, Dholuo, and the long tail

Kenyan callers do not only speak Swahili and English. Here is the honest state of the other major languages, from the two sources publishing numbers.

The east-africa-omniasr-300m development benchmark, with the KenLM decoder, reports Kikuyu at 34.52 percent WER, Dholuo at 37.28 percent, Somali at 39.97 percent, Maasai at 56.11 percent, and Kalenjin at 61.43 percent. A recent arXiv engineering study adapting NVIDIA's Nemotron 3.5 streaming ASR model reports Kikuyu at 42.97 percent WER and Dholuo at 33.98 percent on internal evaluation sets, with Kalenjin still a work in progress at 68.74 percent. That second result matters for a different reason: it keeps the streaming decoder intact, which is what a live voice agent needs.

Interpretation, without spin. A WER in the mid-thirties means roughly one word in three is wrong. That is usable for transcription with human review, keyword spotting, or analytics over large call volumes where errors average out. It is not good enough for an autonomous voice agent that must act on what the caller said. For Dholuo and Kikuyu you are at the edge; for Kalenjin and Maasai, production ASR does not exist yet. If your customer base demands those languages today, design for human handoff rather than waiting for a model.

What it costs: a worked example at 100,000 minutes a month

Take a support line handling 100,000 minutes of calls a month, about 55 hours of audio per day. Using Google's published Speech-to-Text pricing:

• V2 standard recognition (chirp models): $0.016 per minute at this volume, so $1,600 per month.
• V2 dynamic batch: $0.003 per minute, so $300 per month, for workloads that can tolerate deferred processing, such as next-day call analytics.
• V1 API: also $0.016 per minute with data logging, $0.024 without, but the chirp models that carry Swahili support are V2-only, so V1 is not the budget path here.
• Self-hosted open models: zero license cost for the Apache 2.0 and MIT checkpoints above. Your costs are infrastructure and engineering time instead.

Two consequences follow. If you transcribe recordings after the fact, the cost question is nearly settled: dynamic batch pricing or a CPU-hosted open model makes transcription cheap enough that accuracy, not price, should drive the decision. If you need live streaming for a real-time voice agent, you are comparing $1,600 a month of API spend against the fixed cost of running and babysitting your own streaming stack, and the API usually wins until volumes climb into the hundreds of thousands of minutes. Above two million minutes a month, Google's per-minute price drops to $0.004, which resets the breakeven math again.

Data residency can override the arithmetic. If call audio cannot leave your infrastructure for policy or regulatory reasons, a self-hosted open model stops being a cost decision and becomes the only option. That is the same trade-off banks face with private LLM deployment, which we cover in our enterprise AI work.

A one-week benchmark you can run on your own calls

Vendor numbers tell you what a model does on someone else's audio. Here is how to get your own number in five working days.

1. Day 1: pull a real sample. Export 200 to 300 calls from your phone system, with the telephony codec and 8 kHz sampling intact. Do not re-record in a studio; the channel is part of the problem.
2. Day 1 to 2: stratify. Tag each call by language mix (English only, Swahili only, code-switched), noise level, and caller demographics where known. Your error budget lives in the code-switched, noisy bucket, so make sure it is well represented.
3. Day 2 to 3: build a gold set. Hand-transcribe 40 to 50 of the calls, weighted toward the hard buckets. This is tedious and non-negotiable; every WER you compute downstream is only as good as this reference.
4. Day 3 to 4: run the candidates. At minimum: Google chirp_2 with sw-KE, the sauti-asr checkpoint, and omniasr with its KenLM decoder. Add whisper-large-v3 as the baseline so you can see what fine-tuning buys.
5. Day 4: score properly. Compute WER with a normalization step (lowercase, strip punctuation, standardize number formatting) using a library like jiwer. Report one overall number and a separate number for code-switched calls. The gap between those two numbers is your real risk.
6. Day 5: measure in the loop. If the model will feed a live agent, wire the winner into your pipeline and measure end-to-end latency, because a more accurate model that adds 400 milliseconds can feel worse to callers. Our voice AI integration best practices guide covers how to budget latency across the telephony-to-LLM pipeline.
7. Day 5: decide against a task threshold. Define what the transcript is for. If an LLM must extract an account number and a request type, test that extraction directly on the transcripts; a 15 percent WER transcript often still yields perfect intent extraction, while the same WER destroys name spelling.

Common mistakes when choosing ASR for Kenya

• Benchmarking on clean read speech. Mozilla Common Voice samples are recorded in quiet rooms on decent microphones. Your calls are not. Models that look equal on Common Voice separate fast on phone audio.
• Comparing WER across papers. Every number in this post comes from a different test set. The only valid comparison is the one you run on your own gold set.
• Ignoring code-switching. The strongest published Swahili checkpoint explicitly underperforms on mixed speech. If your callers code-switch, and Nairobi callers do, test that bucket separately.
• Forcing one language per call. Prefer configurations that auto-detect or tolerate mixed input over making the caller pick a language in the IVR.
• Skipping vocabulary adaptation. Google's model adaptation and similar biasing features exist for exactly the failure mode that hurts most: names, places, and product terms. Use them before you blame the model.
• Assuming Kikuyu is solved. It is not. Plan routing and handoff accordingly.

When a Swahili-first model is the wrong choice

If your IVR is English-only and your call volume is a few thousand minutes a month, a mainstream English ASR model will serve you fine, and the effort of running a Kenyan benchmark is better spent elsewhere. If you need production-grade Kikuyu or Kalenjin today, no model gets you there; design a human-answered line for those callers instead of shipping an agent that misunderstands one word in three. If your requirement is spotting a handful of spoken menu choices rather than full transcription, a small command-and-search model beats any large ASR system on cost and latency. And if your transcripts only feed after-the-fact analytics, batch pricing makes the managed API so cheap that self-hosting is an engineering vanity project.

Frequently asked questions

Does OpenAI Whisper support Swahili? Yes, Swahili is among the roughly 99 languages Whisper covers, and large-v3 is a usable baseline. But OpenAI's own documentation warns about uneven accuracy on low-resource languages, and Kenyan fine-tunes like Paza and sauti-asr exist because the base model leaves significant error on the table for this market.

What word error rate is good enough for a voice agent? There is no universal threshold, because what matters is whether the downstream system can act on the transcript. As a rough guide, WER under about 15 percent on your real call audio usually lets an LLM extract intent and entities reliably; above 30 percent you should expect visible failures and route to humans. Always test the end task, not just the transcript.

Can Google Speech-to-Text transcribe Sheng? There is no Sheng locale. The closest option is the sw-KE chirp model with model adaptation biased toward Sheng vocabulary, and even that will struggle because Sheng mixes grammar as well as words. Benchmark it on your calls before promising anything.

Is there a Kikuyu speech recognition model? Open research checkpoints exist: the omniasr East Africa model reports about 34.5 percent WER on Kikuyu with its language model decoder, and a 2026 arXiv study reports 42.97 percent with a streaming model. Neither is production-grade for autonomous agents today. Google's API does not list Kikuyu at all.

How much does Swahili speech-to-text cost per minute? On Google Cloud V2, $0.016 per minute at standard rates, falling to $0.003 per minute for dynamic batch and to $0.004 per minute above two million minutes a month. The open models are free to license under Apache 2.0 or MIT terms; you pay for servers and engineering instead.

Can we fine-tune a model on our own call recordings? Yes, and it is the reliable path when off-the-shelf models miss your domain vocabulary. Whisper and the Kenyan checkpoints are open-weight, so they can be fine-tuned on consented call recordings with a few thousand labeled examples. That is a standard part of our enterprise fine-tuning and private deployment work.

Where to go from here

Pick your candidate shortlist from the models above, then run the one-week benchmark on your own call audio before you sign anything; the right answer depends on your callers' language mix, and it is measurable. If you want a voice-capable AI employee that already handles this stack, or help fine-tuning open-weight models on your own recordings within your infrastructure, that is the work we do. Our voice AI implementation guide covers the rest of the production path from telephony integration to the LLM layer.