# Bunyan’s Saudi AI hub: check the API, pricing and data route

OmniOps has launched Bunyan Inference Hub, a Saudi-hosted service intended to give organisations access to AI models without building a separate serving stack for each one. For a Saudi product team, that could make a small inference project easier to start. The buying decision still needs more detail than the launch announcement supplies.

The most useful evidence is in the product’s own pages. They distinguish Riyadh from planned regional locations, advertise a trial beside a business plan that is not yet available, and show API examples that do not use the same hostname. An older residency page also qualifies claims made more confidently on the homepage. These are questions to resolve before sending customer records or committing a production workload.

*Cover: original SultanByte artwork showing a Saudi inference service with separate API, commercial and data-route checks.*

## What the launch actually offers

The [OmniOps press release published by Wamda on 11 November](https://www.wamda.com/en/2026/11/omniops-unveils-bunyan-inference-hub-simplify-ai-deployment-saudi-arabia) describes a shared model catalogue, customer-supplied models, token bundles and optional dedicated GPU infrastructure. It also describes an optimisation engine that adapts execution to available hardware and workload requirements.

Those are the supplier’s descriptions. The release does not provide a reproducible customer benchmark showing cost savings, Arabic task accuracy or performance under concurrent load. Its appearance on a news platform does not turn the optimisation claims into an independent test.

The practical proposition is nevertheless specific: buy managed inference rather than operate a serving environment yourself. A startup may value avoiding infrastructure work; an enterprise may care more about isolation and a negotiated service commitment. They should not assume that the same plan meets both needs.

## Riyadh is listed as live; other cities are planned

[Bunyan’s public catalogue](https://bunyan.ai/) labels Riyadh as live. Abu Dhabi, Dubai, Amman and Baghdad are marked as coming soon. That is the provider’s published availability map, not a verification that a particular customer account can access every listed model.

For a UAE team, a Saudi endpoint is not an in-country UAE deployment. Likewise, a planned Amman location does not establish a Jordanian service today. Keep the intended processing country in the order form, along with the actual model and service configuration. A regional sales conversation should not blur those distinctions.

The homepage also says model availability varies by country. Ask for the catalogue visible to the proposed project, rather than selecting a model from a general marketing list. Preserve its exact identifier and ask how retirement, replacement and temporary capacity shortages are handled.

## Resolve the endpoint before testing compatibility

The homepage’s integration example uses `https://api.bunyan.ai/v1`. The linked [API reference](https://wiki.bunyan.ai/reference/api/) identifies `https://inference-v2.bunyan.ai/v1/` as the production LLM base URL. These may represent different supported routes, but the public pages alone do not establish that they are interchangeable.

Get the intended endpoint from the supplier’s onboarding process and test it with the project’s available model configuration. Do not infer a migration policy from two snippets. Record the working hostname, model identifier and tested client version in the deployment configuration.

The reference also distinguishes the LLM API from Document Intelligence. LLM calls use bearer authentication and a key with the `llm` scope; Document Intelligence uses an `X-API-Key` header and operation-specific scopes. An integration that successfully sends a chat request has not thereby validated document parsing or asynchronous job retrieval.

Treat OpenAI compatibility as an interface claim to test, not a guarantee of identical behaviour. Exercise streaming termination, timeouts, error responses and any structured output or tool-calling features your application requires. Check usage accounting too. A response that renders correctly can still leave the application unable to reconcile its bill or recover an interrupted request.

## Price the workload, not the trial

The homepage advertises a 14-day trial with $30 credit for tokens and APIs, including OCR and Document Intelligence. Its Business card displays $90 per seat per month but marks that plan as coming soon. Enterprise pricing requires a sales conversation.

The launch release’s token-bundle description and the live site’s trial, model-rate cards and seat-plan presentation are not a complete commercial schedule. Before budgeting, obtain the purchased allowance, overage treatment, expiry rules and charges for each enabled API. Establish whether seats, token consumption and dedicated capacity are separate billable items.

For an Arabic document assistant, the useful unit is a successfully reviewed document or answer. Include extraction, retries, rejected outputs and human correction in the evaluation. A cheap generated answer that requires extensive checking is not necessarily a cheap completed task. This is a proposed costing method, not a measured Bunyan result.

![Bunyan buyer checks: Riyadh is listed live while Abu Dhabi, Dubai, Amman and Baghdad are planned; confirm the API route, purchased allowance and data handling before production.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/5a76e402-0e76-4432-a752-9d74397b054a.png align="center")

*Original infographic: SultanByte. Availability and commercial labels from Bunyan’s public pages, November 2026; the checks are an editorial decision framework, not a certification or performance benchmark.*

## Ask for a current data-handling statement

The homepage makes broad claims about local processing and alignment with Saudi requirements. Its linked [Data Flow & Residency page](https://bunyan.ai/data-residency), however, carries a September 3, 2026 review date and says physical-residency, encryption and strict prompt-retention claims are unverified. It separately describes configurable operational-event retention, with a default of 180 days.

That older page may not describe the newly announced commercial service. Nor does its wording prove that data travels overseas. It does mean the public documentation does not provide a single, consistent assurance statement that a buyer can safely substitute for current contractual terms.

Request a dated statement for the exact service being purchased. It should identify where prompts, completions, uploaded files, operational events and backups are processed or retained, who can access them, and whether any upstream provider receives content. Ask which event fields the stated retention period covers; do not assume it means raw prompts are stored for that duration.

This matters beyond geography. [OWASP’s guidance on sensitive-information disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) recommends least-privilege access, restricted data sources and clear retention, usage and deletion policies. A model running locally can still disclose information to an unauthorised user through a poorly scoped application. A local endpoint does not replace the application’s access checks or establish regulatory approval.

## Give the pilot an acceptance decision

Use a bounded Arabic-English task with synthetic or otherwise approved material. For example, extract specified fields from bilingual documents and require a reviewer to confirm them against the originals. Include scans with missing fields, mixed-language content and ambiguous values. Define when the system must decline rather than invent an answer.

[NIST’s AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a voluntary reference for incorporating trustworthiness into AI design, use and evaluation. Apply that principle to this pilot by assigning an owner to the task’s failure criteria and recording outcomes, rather than treating successful API access as acceptance. NIST guidance is not Saudi certification.

Run the same workload through the proposed commercial configuration. Measure completed-task quality and elapsed time under expected concurrency, and reconcile observed usage with the supplier’s billing explanation. Rehearse loss of service without silently routing the documents to an unapproved replacement.

Bunyan’s launch creates a Saudi managed-inference option worth evaluating. The next buying milestone should be a working, documented configuration with agreed charges and a current data-handling statement. Start with approved test material; expand only when those terms and the workload results support the additional exposure.