OpenRouter for Africa — Business Model & Pricing
Status: Draft for internal review Owner: Hassan Last updated: 2026-08-24
Companion document: see OpenRouter for Africa — Design Document for technical design, payments integration, and security.
Partly superseded (2026-09-19). The design doc is the source of truth for balance semantics, and
pricing-model.mdfor pricing mechanics. §4’s monthly repricing cadence is replaced by a daily published rate locked at hold time, and the §3 price table and margin figures are illustrative only. Provider strategy (§2) and the business rationale (§1) still stand.
1. Business model summary
Section titled “1. Business model summary”The wedge is payments, not routing. Model access via a routing layer is a commodity — LiteLLM/Bifrost plus a handful of provider relationships gets us there quickly, and any competitor (including OpenRouter itself) could technically serve this market. The differentiation is entirely in solving the payment friction African developers and businesses face today: international card declines, unpredictable FX costs, and USD-only billing. Niobi’s existing local-currency collection rails are the actual moat.
This means margin doesn’t need to come from being the cheapest router — OpenRouter itself reportedly runs on thin blended margins (~5%) at massive scale. We’re not trying to out-cheap a global aggregator; we’re charging a fair premium for solving a real access problem, which supports a meaningfully higher margin per transaction even at much lower volume.
2. Provider strategy & cost comparison
Section titled “2. Provider strategy & cost comparison”| Category | Providers | Relationship type |
|---|---|---|
| Closed frontier models | OpenAI, Anthropic, Google | Direct — required, no aggregator can resell |
| Open-weight models | Fireworks (primary candidate) | One aggregator account covering 200+ models |
Aggregator evaluation (Fireworks vs. Together AI vs. DeepInfra): compared on price for the highest-volume open-weight models (DeepSeek, Kimi, GLM, Qwen). Fireworks came out cheapest or tied on most of these, with two added benefits: cached-input discounts (up to 50% off repeated context, valuable for agent-style or repeated-system-prompt traffic) and a SOC 2/HIPAA compliance posture. DeepInfra undercuts on list price for some models but skews toward slightly older model versions and a less consistent catalog. Together sits in between on both price and consistency.
This is a reversible choice. Swapping or adding aggregators later is a config change at the gateway layer (OpenAI-compatible API format is the industry standard), not a product rewrite — unlike the gateway framework choice itself (LiteLLM vs. Bifrost), which is more deeply integrated into the billing bridge and harder to swap later.
Margin work still to do: model unit economics per model (not blended), decide markup structure, and determine minimum top-up size given provider cost variance across models.
3. Pricing model (local currency)
Section titled “3. Pricing model (local currency)”Approach: convert each model’s USD provider cost to local currency at the prevailing FX rate, then round up to a clean customer-facing price. Rounding naturally produces a margin band rather than a flat percentage — worked examples at today’s rate (~129.3 KES/USD) landed in the 14.5–23% margin range, comfortably above thin blended-aggregator margins (e.g. OpenRouter’s own ~5%), which fits a positioning built on solving payment friction rather than competing purely on being the cheapest router.
Example (illustrative, needs verification against live rates before launch):
| Model | Provider cost (KES/M, blended) | Customer price (KES/M) | Margin |
|---|---|---|---|
| DeepSeek V4 Flash | ~8–12 | 10–15 | ~17–19% |
| MiMo-V2.5 | ~19 | 25 | ~23% |
| Hy3 | ~28 | 35 | ~19% |
| GPT-5.6 Luna | ~58 | 70 | ~17% |
| GLM 5.2 | ~67 | 80 | ~17% |
| DeepSeek V4 Pro | ~64 | 75 | ~15% |
Free-tier provider models (e.g. stealth/promotional models with $0 provider cost) need a separate decision: pass through free as an acquisition hook, or charge a small flat access fee.
Split input/output pricing: the worked table above uses a blended per-million-token rate for simplicity. Actual customer-facing pricing (and billing ledger logic) should price input and output tokens separately, since usage mix varies a lot by workload and a blended assumption will misprice customers in either direction depending on their actual pattern.
4. Repricing policy
Section titled “4. Repricing policy”Superseded by the daily published rate in
pricing-model.md. Kept for history.
Periodic, not real-time. Recommended v1 approach: review and update prices monthly, with a manual override available for an off-cycle repricing if the local currency moves sharply against the dollar. This avoids building automated FX-threshold logic before it’s needed, while still protecting margin from a significant currency shock.
Since customer balances are pure currency, not model-credits (see architecture doc, Section 5), a repricing event applies immediately and uniformly to all customers — no need to reconcile old rates against existing balances, no grandfathering.
5. Open questions
Section titled “5. Open questions”- Live-rate verification: the pricing table above uses illustrative provider costs and today’s FX rate — needs to be re-verified against actual live provider pricing and FX before becoming the real price sheet.
- Input/output price split: finalize actual separate rates per model, rather than the blended approximation used for initial modeling.
- Minimum top-up size: given provider cost variance across models, what’s a sensible minimum top-up that avoids high-frequency low-value transactions eating into margin via payment processing costs.
- v1 model list scope: curated short list (easier margin management, simpler dashboard) vs. broad catalog from day one.
- Free-tier model treatment: pass through free-cost models at zero charge as an acquisition hook, or apply a flat access fee.