Orq.ai Router Managed gateway
Orq.ai Router is a managed LLM gateway: an OpenAI-compatible API in front of ~500 models. There is no token markup; the paid surface is a 4.5% credit-purchase fee. It can be self-hosted or used as a managed service. Zero data retention, a HIPAA BAA and SOC 2 are published. You can point it at your own provider accounts. Beyond chat it also serves embeddings, image generation and audio.
· 45 of 113 fields dated · 58 sources
Access at a glance
Whether this product can work for you at all, before features matter: who pays the model bill, where it can run, and which of your existing API calls keep working. Every value is the vendor’s own claim, linked to the page it came from.
Vendor calls it the "AI Gateway" / Router inside a broader generative-AI collaboration platform, positioned as a "Sovereign AI Gateway and Platform"; requests go to a router endpoint such as POST https://my.orq.ai/v3/router/responses (Orq AI Gateway intro, page dated 2026-08-19).
Who pays the model bill
Your keys onlyYou contract with each model provider directly and hold those accounts. The gateway never resells inference.
On the evidence fetched: the quickstart requires "Open BYOK, choose OpenAI, select Connect, and add your provider API key" (AI Gateway intro); no Orq-sold inference credits appear on the pages fetched.
Merchant of record: Not stated on pages fetched; because provider keys are the customer's own (BYOK), the upstream provider bills for tokens, while Orq shows "latency, token usage, and cost" in Traces (AI Gateway intro). Formal invoicing language: n.a.
Key handling: Provider keys are connected per provider in the BYOK section of the workspace (AI Gateway intro); private-model credentials are entered with the endpoint at import time (Bring Your Own Model). Encryption/KMS details and vendor visibility of request content: n.a. on pages fetched; VPC and on-premise deployments keep the router in the customer's environment (Deployment options).
Where it can run
4 of 5 shapes documented- Vendor-hosted
- Self-host
- Your VPC
- On-premise
- Air-gapped
Dimmed shapes are not documented by the vendor, which is not the same as unsupported.
Hosted SaaS ("managed cloud"), VPC, and on-premise; self-hosted and on-premise deployments "serve /v3/router under their own hostname" (Deployment options, Base URLs, AI Gateway intro). Air-gapped: not documented.
Three documented options — Cloud, VPC, On-Premise — all with "sovereign AI controls"; on-premise supports model endpoints reachable from inside the environment (Deployment options). Clients point at a custom host via server_url / base_url / ORQ_BASE_URL (Base URLs). Tier gating: not stated (deployment options live under "enterprise" docs) (Deployment options).
API surfaces your code can keep using
5 of 7 documented- OpenAI chat
POST /v1/chat/completionsYes/v3/router/chat/completions(Supported models, Base URLs). Path prefix is/v3/router, not/v1. - Anthropic messages
POST /v1/messagesNot documentedn.a. (not documented on the router pages fetched: Supported models, Base URLs).
- OpenAI Responses
POST /v1/responsesYes/v3/router/responses, the endpoint used in the quickstart (AI Gateway intro, Supported models). - Embeddings
POST /v1/embeddingsYes/v3/router/embeddings(Supported models). - Images
POST /v1/images/generationsYes/v3/router/images/generations,/images/edits,/images/variations(Supported models). - Audio
POST /v1/audio/*Yes *yes, both:
/v3/router/audio/transcriptions(STT) and/v3/router/audio/speech(TTS) (Supported models). - Batch jobs
POST /v1/batchesNot documentedn.a. (not documented on pages fetched: Supported models).
An asterisk marks a qualified verdict: support that is indirect (SDK compatibility or provider passthrough rather than a native endpoint), or a gap that is narrower or wider than the label suggests. Read the note before porting.
OpenAI-shaped paths but under an Orq prefix (/v3/router/...), so it is a base-URL swap plus path-prefix change; SDKs allow overriding the base URL (Base URLs). Models are addressed provider-qualified, e.g. "model": "openai/gpt-5.4" (AI Gateway intro). Streaming caveats: n.a.
How much it reaches
"500+ models" (Supported models), page undated.
n.a. as a number on pages fetched; private-model sources number 3 (Azure AI Foundry, Google Vertex AI, LiteLLM) (Bring Your Own Model). Pages undated.
Whose models: Third-party routing: the customer connects providers such as OpenAI via BYOK and Orq routes to them (AI Gateway intro); private/fine-tuned/self-hosted models are imported from Azure AI Foundry, Vertex AI or LiteLLM (Bring Your Own Model). No Orq-owned inference hardware claimed.
Your own endpoints: yes: "Bring Your Own Model" supports fine-tuned, self-hosted and privately deployed models — choose Azure AI Foundry, Vertex AI or LiteLLM, enter the endpoint and credentials, then import and enable the deployment (Bring Your Own Model).
How it behaves in production
What happens when an upstream model is slow, wrong, or down — and what you can see and stop while it happens. Reliability features are recorded as where you configure them, not whether the vendor lists them, because almost every product here lists all of them.
4 of 6 reachable from code4 of 4 can block1 documented destination
When something goes wrong
Each row says where the knob is, not whether the feature is on the marketing page. A control you can only reach by hand in someone else’s dashboard cannot be reviewed or version-controlled.
- Request timeoutPer request
Your application decides per call, so one noisy endpoint can have its own timeout without a redeploy.
Request-body key
timeout.call_timeoutin milliseconds (documented examples10000and15000) (Orq.ai retries). - RetriesPer request
retry.countaccepts 1–5 withretry.on_codesdefaulting to[429]. Backoff is exponential with jitter: 1s / 2s / 4s / 8s / 16s ±25%, for a documented maximum of roughly 31s of retry delay (Orq.ai retries). - Fallback to another modelPer request
ORDERED:
fallbacks[].model, tried in order, with a documented recommendation of at most 3 entries (Orq.ai fallbacks). - Load balancingPer request
Weights supported:
load_balancer.typeofweight_based,round_robinorlatency_based, withmodels[].weightin the range 0.001–1.0, normalized (Orq.ai load balancing). - Upstream health trackingNot documented
The vendor does not document this, so any behaviour you observe today is unversioned and may change.
not_documentedas an explicit health check or circuit breaker. What exists is latency-history-driven selection: an in-memory latency store with 5-minute freshness, 10% exploration traffic and a 0.5 ms near-tie threshold (Orq.ai load balancing). - Cross-region failoverNot documented
Self-hosted/on-prem deployments serve
/v3/router, but no cross-region failover config is documented (Orq.ai introduction).
Fallback chain: Ordered list — Try A, then B, then C. Simple and predictable, but every failover is all-or-nothing.
Defaults: retry.count accepts 1–5 with retry.on_codes defaulting to [429].
Orq publishes unusually specific retry math (jitter percentage and cumulative worst-case delay), which matters because a 31s retry envelope plus a 15s call_timeout can exceed most client-side timeouts (Orq.ai retries).
How fast the hop is
Undisclosed vendor serviceThe vendor does not disclose what the request path runs on, so no overhead floor can be inferred at all.
Runtime is never disclosed on the fetched pages; only the hosted/self-hosted /v3/router endpoint is documented (Orq.ai introduction).
yes, per the docs' statement that self-hosted and on-prem deployments serve /v3/router; no specific artifact (image, chart, binary) is named on the fetched pages (Orq.ai introduction).
Streaming caveats: Supported; no streaming-specific caveat is stated on the fetched pages (Orq.ai introduction).
This vendor publishes no latency or throughput figure for the routing layer. That is the most common case here, and it is why the architecture class above carries the comparison instead of a number.
No figures published (Orq.ai load balancing).
What it will stop
4 of 4 can blockTwo separate questions per control: can it stop a request at all, and what does it do before you change any settings? A control that inspects and forwards is a logging feature, however it is named.
- Personal data in promptsCan block the request
Out of the box: Blocks out of the box
Guardrail rules include PII detection, and non-compliant generations are blocked; however "If the timeout is reached, the guardrail is skipped" (Guardrail rules, Guardrails). Separately, input variables flagged as PII are sent to the model but never stored or shown in logs (Data compliance)
- Prompt injection and jailbreaksCan block the request
Out of the box: Blocks out of the box
A jailbreak evaluator is available as a guardrail rule; detection is evaluator/model-based (Guardrail rules)
- Harmful contentCan block the request
Out of the box: Blocks out of the box
Guardrails are built on evaluators including LLM-as-judge, which can block non-compliant generations (Guardrails)
- Your own policiesCan block the request
Out of the box: You pick the action when configuring
Custom policies take the form of Python code guardrails, regex, JSON-schema validation, and HTTP calls, all able to block (Guardrails)
Fail open, documented: "If the timeout is reached, the guardrail is skipped" (Guardrail rules)
Sample rates mean a guardrail can be configured to evaluate only a fraction of traffic, which converts an apparent blocking control into a partial one; combined with skip-on-timeout, Orq's guardrails are best treated as best-effort enforcement (Guardrail rules).
What you can see
Export is limitedYou decide whether bodies are captured, by setting or by header.
PII flags on input variables and full output masking prevent storage while requests still run; a global body-logging switch is not documented (Data compliance)
OpenTelemetry natively: OTLP endpoint https://api.orq.ai/v2/otel, with agent traces and conversation threads represented (Observability overview)
Logs and traces retain input/output for observability, but PII-flagged variables and masked outputs are excluded from storage (Data compliance, Observability overview)
Where telemetry can go
- Webhook
n.a. — Orq documents OTel ingest into Orq, not outbound shipping (Observability overview)
Yes — orq.feedback.create(field=..., value=..., trace_id=...) submits feedback for an LLM transaction via the API, keyed on the trace ID returned by invoke/get_config (Feedback SDK reference)
Yes, on Orq's SaaS — the same evaluator library (LLM-as-judge, Python, HTTP) that powers guardrails is used for scoring, and guardrail rules carry sample rates for partial online evaluation (Guardrail rules, Guardrails)
Retention: Configurable retention period, after which data is automatically deleted; the default duration is not stated (Data compliance)
Whether it fits how you work
How much work stands between you and a first call, how different that is from running it in production, and whether it slots into the stack you already have. Recorded as the shape of the work rather than a number of minutes — how long it takes you depends on which accounts and quota you already hold, which no comparison can know.
to try: cloud console setupto run: cloud console setupfits 4 of 10 common stacks
Getting to a first call
7 numbered stepsYou cannot start from an empty editor. An account, a project or a deployed resource has to exist first, and that step is done by hand.
Read off: the vendor’s own quickstart — 7 numbered steps.
Before step one
- Your own provider keyRequired
You need an upstream provider account and key before anything works. That is a prerequisite, not a step.
In this quickstart: it instructs adding an OpenAI API key through AI Gateway > BYOK before enabling
gpt-4o, creating the agent, and calling it (Quick Start | Build - Orq.ai) - Payment methodNo card needed to start
Not stated; the account is described as free (Quick Start | Build - Orq.ai). No credit-card or credits wording on the deployment page (Deployment Options - Orq.ai)
- Gate before models answerYou enable it first
One extra click or API enable per model or project before a call succeeds.
No approval gate, but a per-model enablement action inside the product: the quickstart requires enabling
gpt-4oafter adding a BYOK key (Quick Start | Build - Orq.ai)
Everything you need first: None stated before step 1; step 1 itself is signing up for a free orq.ai account and creating a workspace. However the flow requires adding an OpenAI API key under AI Gateway > BYOK. No credit card, cloud account, or cluster mentioned (Quick Start | Build - Orq.ai)
Running it in production
The same scale applied to the path the vendor recommends for production traffic. Kept separate from the quickstart because for several products here the two are barely related pieces of work.
You cannot start from an empty editor. An account, a project or a deployed resource has to exist first, and that step is done by hand.
This is an infrastructure project, not an integration. Expect charts or Terraform, networking, secrets and someone who owns the deployment.
Getting to production is a step up in kind from the quickstart, not just more of the same.
What production needs: VPC: the customer's own AWS or Azure account, deployed through the AWS or Azure marketplaces. On-premise: Kubernetes 1.28+, at least 3 worker nodes with 4 vCPU and 16 GB RAM each, PostgreSQL 14–18, a MongoDB-compatible database, and S3-protocol object storage; "All components run inside the customer environment." (Deployment Options - Orq.ai)
Can you run it yourself
Self-hosting is advertised and the requirements are described, but no page publishes a command to start from. Expect to talk to the vendor before you can run it.
No literal install command is published; the deployment-options page states the requirements and that "container images must be downloaded or cached in a local registry" but gives no docker/helm command (Deployment Options - Orq.ai)
How it fits your stack
4 of 10Each row is a thing you might already run. “With a caveat” means it works but not the way the vendor’s marketing implies — read the reason, because that is usually where the surprise lives.
- FitsThe OpenAI SDKDrop-in once set up — but first-call work is cloud console setup.
- FitsThe Vercel AI SDK@orq-ai/vercel-provider
- NoCloudflare WorkersNo Workers guidance published.
- FitsKubernetessingle Orq chart, Kubernetes 1.28+
- FitsTerraform or OpenTofuorq-ai/orq 0.1.0
- NoAn existing API gatewayNothing published about running behind your gateway.
- NoCloud IAM I already runStatic upstream credentials only. Your calls to it still use its own key.
- With a caveatLangChain or LlamaIndexLlamaIndex only.
- With a caveatMCP servers to governHosted MCP server — governs nothing on your side.
- NoNothing — plain Node or PythonA cloud console or resource has to exist before your first call.
Reading this the other way round — pick what you already run and see every product scored against it.
The integration surfaces behind those answers
- Vercel AI SDKOfficial provider package
Install the package, swap the model factory, done. Maintained by a party with a stake in it.
Named:
@orq-ai/vercel-providerYes. Orq.ai documents the official TypeScript package
@orq-ai/vercel-provider, installed withnpm install @orq-ai/vercel-provider ai, and configured withcreateOrqAiProvider({ apiKey: process.env.ORQ_API_KEY }). (Orq.ai Vercel AI SDK integration) - Cloudflare WorkersNot documented
No Workers guidance either way. If you are edge-first, verify fetch-only compatibility yourself.
n.a. (not documented)
- KubernetesOfficial Helm chart
A named, published chart. You can read its values file before committing to anything.
Named:
single Orq chart, Kubernetes 1.28+Enterprise on-premise deployment is supported as a single Helm chart in a Kubernetes cluster; Kubernetes 1.28 or later is required, and the chart uses Helm hooks for database and data migrations. The optional agent sandbox uses the upstream
kubernetes-sigs/agent-sandboxcontroller versionv0.4.6with its own Helm chart. (Orq.ai deployment options) - TerraformOfficial Terraform provider
You can manage this product as first-class Terraform resources, versioned on the Registry.
Named:
orq-ai/orq 0.1.0An official Terraform provider is documented as
orq-ai/orq, version0.1.0. (Orq.ai Terraform provider guardrail rule) - Existing API gatewayNot documented
Nothing published about sitting behind an existing gateway. Treat it as a separate hop you route to yourself.
n.a. (not documented)
- Cloud identityStatic provider credentials only
You paste static provider credentials into this product so it can reach upstream models. Your own calls to it still use its own API key, and those pasted secrets are yours to rotate.
Partially: for Google Vertex AI, Orq.ai documents pasting a GCP service-account key JSON and granting the Service Account Token Creator and Vertex AI User roles; AWS SigV4/IAM roles and Azure Entra/managed identity are not documented. (Orq.ai Vertex AI provider integration docs)
- MCPHosted MCP server
The vendor runs an MCP server you connect a client to. Useful for reaching this product from an agent, but it does not govern your other MCP servers.
Yes. Orq.ai documents hosted MCP servers at
https://my.orq.ai/v2/mcpfor workspace access with 38 specialized tools, and supports MCP-compatible servers in agents through inlineserver_urlor saved tools, with Streamable HTTP and SSE. A separate documentation MCP server is hosted athttps://docs.orq.ai/mcp. (Orq.ai MCP server integration)
LlamaIndex integration is documented through the packages llama-index and llama-index-llms-openai-like, using the OpenAILike class. LlamaIndex Agents examples use ReActAgent and FunctionTool; LangChain is not documented. (Orq.ai LlamaIndex Agents integration)
Official SDKs are documented for Python and Node.js: Python package orq-ai-sdk with class Orq, and Node.js package @orq-ai/node with class Orq. The orq CLI command is also documented. (Orq.ai client libraries reference)
Agent features: Orq.ai supports function, HTTP, MCP, and built-in tools, tool-choice modes, conversation continuation with previous_response_id, and multi-agent orchestration using sub-agents and team_of_agents. Its MCP integration also supports tool filtering with allowed_tools; A2A is not documented. (Orq.ai run agents)
The path is agent-centric rather than a raw model call: create an agent, enable gpt-4o, configure Web Search and Web Scraper tools, publish, call, then view traces; the guide is billed as "Beginner-friendly, no AI experience needed." Optional SDKs: pip install orq-ai-sdk, npm install @orq-ai/node. Every agent call is automatically traced (Quick Start | Build - Orq.ai)
Orq.ai documents managed cloud, self-hosted, VPC, and on-premise deployment options. Managed Cloud is hosted in EU data centers on Google Cloud Platform; VPC runs in a customer AWS or Azure account and is available through those marketplaces; Enterprise on-premise runs in Kubernetes on customer or self-managed infrastructure and can operate air-gapped after images are cached locally, provided configured model endpoints are reachable. (Orq.ai deployment options)
Silence in the docs: 2 of the integration questions on this card have no published answer either way. That is recorded as undocumented, not as a no — but it does mean you would be verifying it yourself.
What it does well
- Strongest EU/sovereignty story here: EU data centers, sovereign VPC, on-prem and air-gapped Helm deployment
- Zero markup on model traffic, with free BYOK up to 1M requests/month
- Zero-data-retention routing filter and PII redaction built into the gateway
- SOC 2 Type II, GDPR, HIPAA BAA availability and detailed audit logs with SIEM export
- Broad multimodal reach (image, video, audio, embeddings, rerank) plus 40+ evaluators and prompt versioning
Where it falls short
- Closed source with no free self-host path; sovereign deployment is enterprise-only at unpublished prices
- Line-item pricing in euros across spans, processed data, agent runs, seats, teams and knowledge bases is hard to forecast
- Free tier is rate-limited to 100 requests/minute with only 30-day retention
- An independent European-gateway review disputes how EU-only the default data storage really is, and notes ISO 27001 is still in progress
Choose it when
European teams that want an EU-resident managed gateway with governance, evaluations and observability in one platform rather than a bare proxy.
Look elsewhere when
You just need a thin high-throughput proxy, or you want a self-hostable open-source gateway without an enterprise contract.
Managed gateway: A hosted control plane in front of the models: routing, caching, guardrails, spend limits, and logs. You trade a little simplicity for governance.
How hard is it to leave?
Derived from six published facts, not from an opinion. The weights are fixed and the same for every product — see the arithmetic.
| What helps you leave | Points | Source |
|---|---|---|
| Works with standard OpenAI codeSwitching away is a base-URL change rather than a rewrite of every call site. | 22/22 | vendor page |
| No vendor-specific SDK requiredA proprietary client library spreads through your codebase and has to be torn out again. | 10/10 | vendor page |
| Can use your own provider accountsYour keys and billing relationship stay yours, so removing the gateway does not cut off model access. | 20/20 | vendor page |
| Can be self-hostedYou can run it yourself instead of accepting a pricing or policy change. | 20/20 | — |
| Configuration lives in version controlRouting and budget rules are a file you keep, not dashboard state you would have to rebuild. | 0/16 | vendor page |
| Your request history can be exportedYou leave with your own logs instead of abandoning them. | 12/12 | vendor page |
Read the fine print: Telemetry query API is in private preview.
All six inputs are published, so this is scored against the full 100. This measures technical switching cost only. It does not price the engineering time to re-test prompts against a different routing stack.
Full specification
Every field we track. Blank fields say "Not published" rather than "No" — we do not infer an absence from silence. Switch to Technical in the header for the precise field names and the low-level details.
Overview
- What kind of product Category
- Managed gateway Not verified
- Marketplaces resell many providers behind one key. Gateways add governance on top. Open-source projects you run yourself. Cloud platforms are hyperscaler surfaces. Inference providers host models on their own hardware.
- Who runs it Deployment model
- Managed or self-host Not verified
- Managed means the vendor operates it. Self-host means you run it on your own infrastructure. Both means you can choose.
- Licence Licence
- Proprietary Not verified
- Proprietary products cannot be inspected or forked. Open licences such as MIT and Apache-2.0 let you audit, modify, and run the code without permission.
- Company Company
- Orq.ai Not verified
- The organisation that maintains the product.
- Who you would be signing with Vendor status
- Independent company Not verified
- Whether the product is still an independent company, has been acquired, is a large cloud vendor’s product line, is run by a software foundation, or has been put into maintenance mode. Maintenance mode means bug fixes and security patches only — no new features.
- Last shipped an update Latest release
- 2026-08-26 Not verified
Orq.ai prints no dates on its changelog, so this is the last-modified timestamp of the Release 4.14 page rather than a published release date.
- The date of the most recent release or version tag. A product that has not shipped in a year is a different risk from one that shipped last week, regardless of what its marketing site says.
- GitHub stars GitHub stars
- Not published Not verified
- A rough proxy for community size on open-source projects. Not a quality measure.
Cost
- Markup on model prices Token markup
- None Verified 3 days ago
- How much the product adds on top of what the underlying model provider charges. Zero means you pay the same per-token price you would pay the model provider directly.
- Fee to add funds Credit purchase fee
- 4.5% Verified 3 days ago
- A percentage charged when you top up your balance, separate from token prices. It is easy to miss because it does not appear on the per-token price list.
- Monthly cost per person Seat fee
- Not published Not verified
- A recurring per-user platform charge that applies regardless of how much you use the models.
- Can use your own provider accounts BYOK supported
- Yes Verified 3 days ago
- Bring Your Own Key: you keep direct contracts with OpenAI, Anthropic and others, and the gateway only routes traffic. This preserves negotiated rates and committed-spend discounts.
- Cost of using your own accounts BYOK terms
- BYOK free for the first 1M requests/month, then 4%; no markup on model traffic itself. Verified 3 days ago
- What the product charges to route traffic through your own provider keys.
- Free tier Free tier
- Pay-as-you-go starts free: 100k spans, 1 GB processed data, 500 agent runs, unlimited AI Gateway seats, 100 req/min limit, 30-day retention. Verified 3 days ago
- What you can do without paying, useful for evaluation.
- Enterprise plan from Enterprise plan from
- Not published Not verified
- Annual entry price for the enterprise tier, where one is published or credibly reported.
- Cost to run it yourself Self-host cost
- No open-source or free self-host option. Enterprise-only sovereign deployments: customer-owned VPC on AWS or Azure via marketplace, or fully on-prem/air-gapped via a single Helm chart, priced custom and billed annually. Verified 3 days ago
- What self-hosting actually costs once you account for infrastructure and any paid tier.
- How the vendor makes money Pricing model
- Platform fee plus usage meters Not verified
- The shape of the vendor’s bill: does the routing layer charge a percentage on top of tokens, a flat monthly fee, both, neither (because inference is the product), or nothing at all (open source with no paid tier).
- How pricing works, briefly Pricing model detail
- Models billed at provider list prices with 0% Orq markup. Routing on Orq credits adds a 4.5% top-up fee; BYOK is free up to 1M req/mo then 4%. Seat, module and data overages layer on top. Enterprise annual. Not verified
- A one-paragraph description that covers the caveats a pricing category cannot: introductory rates, per-feature meters, tier gating, and pricing that resets on a specific date.
- Minimum commitment Minimum commitment
- None stated for Pay-as-you-go. Enterprise agreements run on annual terms. Not verified
- Whether the vendor requires a minimum contract term, a minimum spend, or a provisioned-capacity purchase to get its published rate.
- Charges that fire after you go over an allowance Overage terms
- Spans 100k/mo included then €7 per 100k. Processed data 1 GB/mo then €3/GB. Agent runs 500/mo then €0.01/run. Knowledge Bases include 2.5 GB document processing then €0.10/MB. Retention 30 days, no published price for extending. Usage beyond allowance bills as separate line items — nothing blocks. Not verified
- The line items that scale with usage after an included allowance is exhausted — log storage, extra requests, per-feature meters, data export — which is where cost estimates usually go wrong.
- Prompt cache offered Cache mechanism
- No gateway-owned cache Not verified
- Whether the gateway offers its own response cache, what kind of match it does (exact request, prefix, semantic), or simply passes provider caching through unchanged.
- Discount on cached input Cache-read discount
- Not published Not verified
- How much cheaper cached tokens are than fresh input, when the vendor publishes a single figure. Bundled-inference clouds usually price this per model instead of as one number.
- Premium on cache writes Cache-write premium
- Not published Not verified
- How much more the first write of a cached prefix costs versus a plain input token. A high write premium and a low hit rate can leave you paying more than you save, so this matters as much as the read discount.
- Who captures the cache saving Cache economics
- Pricing page lists caching in the platform comparison but does not name a mechanism; AI Gateway docs page timed out on fetch. Because model traffic is billed at provider rates with no Orq markup, any provider-side cache discount flows to the customer, but Orq publishes no cached-token pricing of its own. Not verified
- Whether the customer keeps the full saving from caching or the vendor captures part of it — and any conditions attached (write premium, storage fees, best-effort hits).
- What you can split spend by Cost attribution
- Attribution by workspace, project, identity, API key, provider and model. Tag/customer splits not stated. Not verified
- The dimensions the vendor documents for splitting spend — per key, per user, per team, per tag, per customer. Matters if you need to chargeback internally or bill an end customer.
- How you get cost data out Cost export
- CSV/JSON of traces, experiments and datasets; Dashboards & Reporting API; SIEM export to Splunk/Datadog — all with no stated additional cost. S3/warehouse export not stated. Not verified
- The mechanisms the vendor publishes for exporting cost and usage data: CSV, an API, webhooks, S3, a data warehouse, or nothing at all. Any per-unit price is included.
- Who pays the model bill BYOK mode
- Your keys only Not verified
- Whether you bring your own provider accounts (BYOK), buy inference from this vendor, or can do either. This is the single biggest commercial difference between these products: it decides who holds the contract with the model provider and who carries the spend.
Spend governance in detail
Seven signals matter when a bill starts to hurt: who can spend, how much, on what, and who gets paged when it goes wrong. Everything below is drawn from the vendor’s own pricing and docs pages — how we read these.
- Virtual or scoped keysNot published
Keys that carry their own budget and rate-limit policy, so an intern experiment cannot spend against a production budget.
Not stated as virtual keys, but budgets attach to API keys.
- Budget caps per keyYes
A dollar or token ceiling attached to an individual key. Where enforcement is soft, one over-limit request still completes before the block kicks in.
Budgets scoped to workspace, project, identity, API key, provider or model. Pre-request hard cap — requests are blocked with HTTP 429 until the period resets.
- Budget caps per team or workspaceYes
A ceiling applied at a higher scope than one key — a team, a workspace, a customer, or an entire environment.
Workspace / project / identity budgets supported; a 'team' scope not stated but workspace covers most team use.
- Rate limiting as a cost controlYes
Configurable request-per-time-window caps. Platform-set rate limits do not count as spend controls; user-configurable ones do.
Budgets include a per-minute rate cap; plan-level 100 req/min.
- Model allowlistsYes
A policy that constrains which models a key or team can call, keeping expensive frontier models out of the wrong hands.
Budgets can be scoped per model; a policy-style allowlist is not stated separately.
- Spend alertsYes
Alerts fired as spend approaches a threshold. Alerts that only fire after the meter has rolled over are marked as such.
Documented example of a $100 budget with an alert configured at 90% ($90).
- Webhook notificationsNot published
Programmatic notifications on spend events, so budget breaches can page an on-call or open a ticket.
Not stated as webhooks.
Enforcement:Enforced before each request
Catalog
- Models available Models available
- ~500 Verified 3 days ago
- How many models you can call, shown as a range because several vendors publish different totals on different pages. Vendor-reported either way, so counts are not directly comparable — some count every provider variant of the same model separately.
- Model providers reachable Upstream providers
- Not published Verified 3 days ago
- How many distinct model providers or labs you can reach, shown as a range where the vendor’s own pages disagree. More providers usually means better redundancy when one has an outage.
- Works with standard OpenAI code OpenAI-compatible API
- Yes Verified 3 days ago
- If yes, you can usually switch to it by changing one base URL, and switch away just as easily. This is the main defence against lock-in.
- OpenAI chat endpoint POST /v1/chat/completions
- Yes Not verified
- The endpoint almost every application ports first. "Not documented" means the vendor never states it, which is different from a documented no.
- Anthropic messages endpoint POST /v1/messages
- Not documented Not verified
- Whether Anthropic-shaped calls work without rewriting them. Several products support this only as SDK compatibility or provider passthrough rather than a native endpoint — the detail page says which.
- OpenAI Responses endpoint POST /v1/responses
- Yes Not verified
- The newer stateful OpenAI surface. Support is much thinner across this market than chat completions.
- Embeddings endpoint POST /v1/embeddings
- Yes Not verified
- Whether you can generate vectors through the same gateway, or need a second integration for retrieval workloads.
- Image generation endpoint POST /v1/images/generations
- Yes Not verified
- Whether image models are reachable through the same surface as text.
- Audio endpoints POST /v1/audio/*
- Yes Not verified
- Speech-to-text and text-to-speech. Frequently the first gap in an otherwise complete gateway.
- Batch jobs endpoint POST /v1/batches
- Not documented Not verified
- Asynchronous bulk processing, usually at a discount. Commonly undocumented, and commonly the reason a migration stalls late.
- Needs the vendor’s own code library Requires a vendor-specific SDK
- No Verified 3 days ago
- A proprietary client library spreads through your codebase and has to be torn out again if you leave. “No” is the better answer here, and it means the standard OpenAI client works.
- You can export your request history Logs / usage data export
- Yes Verified 3 days ago
- Whether you can get your own request logs, traces, or usage records back out — through an API, a bulk export, or a download. Decides whether you leave with your history or abandon it.
- Settings can live in version control Declarative config-as-code
- No Verified 3 days ago
- Whether routing, fallback, and budget rules can be declared in a file you keep in Git, rather than existing only as settings clicked into a hosted dashboard.
- Embeddings Embeddings
- Yes Verified 3 days ago
- Text-to-vector models, needed for search and retrieval features.
- Image generation Image generation
- Yes Verified 3 days ago
- Whether image models are reachable through the same interface.
- Speech and audio Speech and audio
- Yes Verified 3 days ago
- Text-to-speech or transcription models through the same interface.
- Video generation Video generation
- Yes Verified 3 days ago
- Whether video models are reachable through the same interface.
- Batch processing Batch processing
- Not published Not verified
- Submitting large jobs for cheaper, slower processing. Often 50% off for work that is not time-sensitive.
Routing & reliability
- Uptime it promises in writing Contractual SLA uptime
- Not published Not verified
- The uptime percentage in a published, contractual service level agreement. A public status page is not an SLA — it reports what happened, it does not promise anything or pay you back when it breaks.
- Automatic failover Automatic failover
- Yes Verified 3 days ago
- When a model provider goes down or rate-limits you, traffic moves to a backup automatically instead of returning errors to your users.
- Load balancing Load balancing
- Yes Verified 3 days ago
- Spreads requests across several providers or keys to raise your effective rate limit.
- Rule-based routing Conditional routing
- Yes Verified 3 days ago
- Send different requests to different models based on rules — for example a cheap model for free users and a strong model for paying ones.
- Response caching Response caching
- Yes Verified 3 days ago
- Reuses the answer when the exact same request comes in again, which cuts both cost and latency.
- Similar-question caching Semantic cache
- Not published Not verified
- Reuses an answer when a new question means roughly the same thing as an earlier one. Saves far more than exact-match caching but can return subtly wrong answers if tuned loosely.
- Where you set the timeout Request timeout surface
- Per request Not verified
Request-body key `timeout.call_timeout` in milliseconds (documented examples `10000` and `15000`) ([Orq.ai retries](https://docs.orq.ai/docs/ai-gateway/features/retries)).
- Where a request timeout can be set: per request, in a config file, in the vendor dashboard, or nowhere. Nine of the twenty products documented here do not describe a request timeout at all, so the worst case of a hung upstream call is unknowable from the docs.
- Where you set retries Retry policy surface
- Per request Not verified
`retry.count` accepts 1–5 with `retry.on_codes` defaulting to `[429]`. Backoff is exponential with jitter: 1s / 2s / 4s / 8s / 16s ±25%, for a documented maximum of roughly 31s of retry delay ([Orq.ai retries](https://docs.orq.ai/docs/ai-gateway/features/retries)).
- Where retry count and backoff are configured. Worth knowing alongside billing: a retried streaming call can be charged more than once.
- Where you set fallbacks Fallback surface
- Per request Not verified
ORDERED: `fallbacks[].model`, tried in order, with a documented recommendation of at most 3 entries ([Orq.ai fallbacks](https://docs.orq.ai/docs/ai-gateway/features/fallbacks)).
- Where the fallback chain is defined. Almost every product claims fallback; the useful question is whether you can change it from code or only by hand in a dashboard.
- Shape of the fallback chain Fallback shape
- Ordered list Not verified
- An ordered list tries targets in sequence; a weighted split sends a percentage of traffic to each, which is what you need to trial a new model on 5% of requests. Weighted splits are much rarer than the marketing implies.
- Upstream health tracking Health checks / circuit breaking
- Not documented Not verified
`not_documented` as an explicit health check or circuit breaker. What exists is latency-history-driven selection: an in-memory latency store with 5-minute freshness, 10% exploration traffic and a 0.5 ms near-tie threshold ([Orq.ai load balancing](https://docs.orq.ai/docs/ai-gateway/features/load-balancing)).
- Whether the product notices a failing upstream and stops sending traffic to it, and whether you can tune the thresholds. This is what turns a provider outage into a blip rather than a sustained error rate, and only four of the twenty expose it.
- Cross-region failover you control Multi-region failover surface
- Not documented Not verified
Self-hosted/on-prem deployments serve `/v3/router`, but no cross-region failover config is documented ([Orq.ai introduction](https://docs.orq.ai/docs/ai-gateway/get-started/introduction)).
- Whether you can define what happens when a region degrades. A vendor running many regions is not the same as a vendor letting you configure failover between them; only three document a user-controlled mechanism.
- Where you set load balancing Load balancing surface
- Per request Not verified
Weights supported: `load_balancer.type` of `weight_based`, `round_robin` or `latency_based`, with `models[].weight` in the range 0.001–1.0, normalized ([Orq.ai load balancing](https://docs.orq.ai/docs/ai-gateway/features/load-balancing)).
- Where traffic distribution across upstreams or keys is configured.
Operations
- Usage dashboards and logs Observability
- Yes Verified 3 days ago
- Built-in visibility into what was sent, what came back, what it cost, and how long it took.
- Spending limits Budget controls
- Yes Verified 3 days ago
- Hard caps that stop spend before it becomes a surprise invoice. The single most valuable control for a small team.
- Rate limits Rate limits
- Yes Verified 3 days ago
- Caps on request volume per key or per user, useful for protecting against abuse and runaway loops.
- Separate keys per team or app Virtual keys
- Not published Not verified
- Issue scoped keys with their own budgets and permissions so you can attribute cost and revoke access without rotating everything.
- Prompt versioning Prompt management
- Yes Verified 3 days ago
- Store and version prompts outside your code so they can be changed without a deploy.
- Quality testing Evals
- Yes Verified 3 days ago
- Built-in tooling to score model output against test cases, so you can tell whether a model swap made things better or worse.
- MCP support MCP support
- Yes Verified 3 days ago
- Native support for the Model Context Protocol, the emerging standard for connecting models to external tools.
- What gets logged Logged content
- Your choice Not verified
Logs and traces retain input/output for observability, but PII-flagged variables and masked outputs are excluded from storage ([Data compliance](https://docs.orq.ai/docs/administer/data-compliance), [Observability overview](https://docs.orq.ai/docs/observability/overview))
- Whether full prompts and responses are stored, only metadata, or nothing. Full-body logging is the most useful debugging feature here and the one most likely to need a conversation with your compliance team.
- You can turn logging off Body-logging opt-out
- Yes Not verified
PII flags on input variables and full output masking prevent storage while requests still run; a global body-logging switch is not documented ([Data compliance](https://docs.orq.ai/docs/administer/data-compliance))
- Whether prompt and response bodies can be suppressed while still keeping usage metrics. Nineteen of the twenty document a way to do this; the mechanisms range from a per-request header to an organisation-wide setting.
- Traces you can take elsewhere Distributed tracing
- OpenTelemetry Not verified
OpenTelemetry natively: OTLP endpoint `https://api.orq.ai/v2/otel`, with agent traces and conversation threads represented ([Observability overview](https://docs.orq.ai/docs/observability/overview))
- Whether the product emits OpenTelemetry, a proprietary format, or nothing. OpenTelemetry means the traces land in the tooling you already run instead of only in the vendor’s dashboard.
- Where telemetry can go Export destinations
- Webhook Not verified
`n.a.` — Orq documents OTel ingest into Orq, not outbound shipping ([Observability overview](https://docs.orq.ai/docs/observability/overview))
- Documented sinks for logs and metrics. This is a good proxy for how replaceable the vendor’s own dashboard is: around twenty destinations means you never have to depend on it, while a CSV download means you do.
- Can record user feedback Feedback capture API
- Yes Not verified
Yes — `orq.feedback.create(field=..., value=..., trace_id=...)` submits feedback for an LLM transaction via the API, keyed on the trace ID returned by invoke/get_config ([Feedback SDK reference](https://github.com/orq-ai/orq-python/blob/main/docs/sdks/feedback/README.md))
- Whether there is an API to attach a rating or score to a logged request, which is what lets production traffic feed quality work later.
- Scores live traffic Online eval hooks
- Yes Not verified
Yes, on Orq's SaaS — the same evaluator library (LLM-as-judge, Python, HTTP) that powers guardrails is used for scoring, and guardrail rules carry sample rates for partial online evaluation ([Guardrail rules](https://docs.orq.ai/docs/router/guardrail-rules), [Guardrails](https://docs.orq.ai/docs/ai-gateway/configuration/guardrails))
- Whether automated scorers can run against real production requests, rather than only against a test set you assemble yourself.
Performance
- Delay it adds Proxy overhead
- Not published Not verified
- Extra time the product itself adds to each request, on top of however long the model takes. Usually irrelevant next to multi-second model latency, but it matters for high-volume or streaming-sensitive workloads.
- Requests per second ceiling Throughput
- Not published Not verified
- Published sustained request rate before the product becomes the bottleneck. Only relevant at genuinely high volume.
- What the request path runs on Architecture class
- Undisclosed vendor service Not verified
Runtime is never disclosed on the fetched pages; only the hosted/self-hosted `/v3/router` endpoint is documented ([Orq.ai introduction](https://docs.orq.ai/docs/ai-gateway/get-started/introduction)).
- The comparable way to talk about latency here. An edge worker, a compiled Go or Rust binary, and a Python proxy have different overhead floors no matter which figures each vendor publishes. Products that never disclose their runtime are recorded as undisclosed rather than assumed.
- You can run the request path yourself Self-hostable data plane
- Yes Not verified
`yes`, per the docs' statement that self-hosted and on-prem deployments serve `/v3/router`; no specific artifact (image, chart, binary) is named on the fetched pages ([Orq.ai introduction](https://docs.orq.ai/docs/ai-gateway/get-started/introduction)).
- Whether the component that actually carries your prompts can run on your own infrastructure. Distinct from a vendor offering a self-hosted control plane while still proxying traffic through their network.
- Streaming responses Streaming support
- Yes Not verified
Supported; no streaming-specific caveat is stated on the fetched pages ([Orq.ai introduction](https://docs.orq.ai/docs/ai-gateway/get-started/introduction)).
- Whether token-by-token streaming is documented. The caveats matter more than the yes: some products cannot cancel a stream without still being billed, and several timeout and fallback mechanisms stop applying once the first token has been sent.
Security & compliance
- Does your prompt reach their servers Prompt transits vendor
- Depends how you deploy it Not verified
EU multi-tenant cloud on GCP, your own AWS or Azure VPC where platform data never leaves it, or an on-premises Helm install with every component inside your environment.
- Whether the text you send passes through this company’s own infrastructure. If it does, every other promise on this page is a policy commitment rather than a physical impossibility. Self-hosted products can answer no outright.
- What they keep if you change nothing Logging default
- Yes — prompts and replies Not verified
Hosted deployments log by default for the plan's retention period. Variables flagged as PII and masked responses are the exception: they reach the model but are not stored or shown in logs.
- Defaults matter more than options. A product that stores full prompts and replies unless you find the right header will have stored them by the time you read the docs.
- How long they keep it Default content retention (days)
- Not published Not verified
No number is published. Versions, evaluation logs and audit logs are deleted according to your plan's retention policy, which is not stated publicly.
- Default retention for request content, in days. Zero means nothing is kept. Read the note: several products keep nothing as a rule but make timed exceptions for abuse review or specific models.
- Could they train on your prompts Training on customer data
- No Not verified
No data flowing through Orq.ai is ever used to train or fine-tune any model by Orq.ai.
- Whether the vendor may use your prompts and outputs to train models. “Not published” means we could not find any position, which is not the same as a no — ask for it in writing.
- Where it runs, and what you can pin Region and residency control
- EU only for the hosted platform — there is no US region, and EU residency is included on every plan. Customer AWS or Azure VPC and on-premises or air-gapped installs are offered. Not verified
- Which regions are offered and whether you can force processing to stay in one. A global endpoint that silently picks a region is a different compliance story from an endpoint you pin yourself.
- Where safety filters run Guardrail execution location
- Either, depending on deployment Not verified
PII masking is available at platform level on all tiers, and VPC or on-premises deployment puts the whole platform — masking included — in your environment.
- A filter that strips personal data only helps if it runs before the data leaves your boundary. If guardrails execute in the vendor’s cloud, the vendor has already received whatever you wanted redacted.
- Who else touches the data Subprocessor list
- Not published Not verified
- The published list of third parties the vendor passes your data to. No list means you cannot know the full chain, which most data-protection agreements require you to.
- SOC 2 audited SOC 2 audited
- Yes Verified 3 days ago
- An independent audit of security controls. Enterprise buyers and their procurement teams routinely require it.
- Will sign a HIPAA agreement HIPAA BAA
- Yes Verified 3 days ago
- Required before you may send protected health information through the service. Without a signed BAA, healthcare data is off limits.
- GDPR commitments GDPR commitments
- Yes Verified 3 days ago
- Published data processing terms for handling personal data of people in the EU and UK.
- Can keep data in the EU EU data residency
- Yes Verified 3 days ago
- Requests can be processed inside the EU rather than routed to US infrastructure. Often the deciding constraint for European customers.
- Does not retain your data Zero data retention
- Yes Verified 3 days ago
- Prompts and responses are not stored after the request completes. Sometimes a paid add-on rather than the default.
- Strips personal data PII redaction
- Yes Verified 3 days ago
- Detects and removes identifiers such as names, emails, and card numbers before the request reaches the model provider.
- Content guardrails Content guardrails
- Yes Verified 3 days ago
- Policy checks on inputs and outputs — blocking unsafe content, enforcing formats, or catching prompt-injection attempts.
- Runs fully disconnected Air-gapped deployment
- Yes Verified 3 days ago
- Can be deployed in a network with no internet access, which some regulated and defence environments require.
- Blocks personal data in prompts PII / DLP enforcement
- Can block the request Not verified
Guardrail rules include PII detection, and non-compliant generations are blocked; however "If the timeout is reached, the guardrail is skipped" ([Guardrail rules](https://docs.orq.ai/docs/router/guardrail-rules), [Guardrails](https://docs.orq.ai/docs/ai-gateway/configuration/guardrails)). Separately, input variables flagged as PII are sent to the model but never stored or shown in logs ([Data compliance](https://docs.orq.ai/docs/administer/data-compliance))
- Whether personal data detection sits on the request path and can stop the call, merely inspects and forwards it, or is not documented. A control that only reports is a logging feature, not a policy control.
- Blocks prompt injection Injection / jailbreak enforcement
- Can block the request Not verified
A jailbreak evaluator is available as a guardrail rule; detection is evaluator/model-based ([Guardrail rules](https://docs.orq.ai/docs/router/guardrail-rules))
- Whether injection and jailbreak detection can stop a request. Most products offering this call a partner classifier rather than shipping their own.
- Blocks harmful content Toxicity / moderation enforcement
- Can block the request Not verified
Guardrails are built on evaluators including LLM-as-judge, which can block non-compliant generations ([Guardrails](https://docs.orq.ai/docs/ai-gateway/configuration/guardrails))
- Whether hate, violence, sexual and self-harm categories are checked inline and can stop a request, in either direction.
- Your own policy rules Custom policy hooks
- Can block the request Not verified
Custom policies take the form of Python code guardrails, regex, JSON-schema validation, and HTTP calls, all able to block ([Guardrails](https://docs.orq.ai/docs/ai-gateway/configuration/guardrails))
- Whether you can add your own rule — a regex, a webhook, or your own classifier — rather than choosing from the vendor library.
- Where guardrails run Guardrail execution location
- On the vendor's servers Not verified
- Whether guardrail evaluation happens inside your infrastructure or on the vendor’s servers. This decides whether the prompt you are trying to protect leaves your network in order to be checked.
- If the guardrail itself fails Guardrail failure mode
- Request proceeds Not verified
**Fail open, documented**: "If the timeout is reached, the guardrail is skipped" ([Guardrail rules](https://docs.orq.ai/docs/router/guardrail-rules))
- What happens when the guardrail service times out or errors: does the request proceed unchecked, or is it blocked? This is the worst-documented field in the entire catalogue — only two vendors state it plainly, which means most teams are running a control whose failure behaviour they cannot know.
- Third-party guardrail vendors Guardrail integrations
- Not published Not verified
- Named external guardrail services the product can call. A long list means the product is a router for policy engines rather than a policy engine itself — which also means another vendor bill and another hop.
Compliance evidence
Graded by how strong the evidence is, not whether the word appears on the vendor’s website. An audited report and a marketing claim are different things, and only one of them will satisfy your own auditor.
- SOC 2 Certified Type 2, monitored via Vanta
- ISO 27001 In progress proceeding towards formal certification
- GDPR DPA Available on request DPA on request
- HIPAA BAA Not published
- FedRAMP Not published
- ITAR Not published
Fit & integration
- Work to try it Evaluation work shape
- Set it up in a cloud console Not verified
- The shape of the work on the vendor’s own quickstart, from swapping one base URL through to deploying infrastructure. An ordinal class rather than a duration, because elapsed time depends on accounts and quota we cannot see.
- Work to run it Production work shape
- Set it up in a cloud console Not verified
- The same scale applied to the vendor’s recommended production path. For several products this is much heavier than the quickstart, which is exactly why both are recorded.
- Steps on the quickstart Numbered quickstart steps
- 7 Not verified
- A literal count of numbered steps on the vendor’s quickstart, recorded as evidence beside the work shape. Zero means the page publishes no numbered procedure at all. Large counts usually mean interleaved language tracks rather than more work.
- Can you self-host it today Self-host install documentation
- Offered, but no command published Not verified
No literal install command is published; the deployment-options page states the requirements and that "container images must be downloaded or cached in a local registry" but gives no docker/helm command ([Deployment Options - Orq.ai](https://docs.orq.ai/docs/enterprise/deployment-options))
- Whether an install command is actually published. Several products advertise self-hosting while publishing no command to start from, which a plain yes/no would hide.
- Works with the OpenAI SDK OpenAI SDK drop-in
- Yes Not verified
Yes. OpenAI-compatible clients can use the exact base URL `https://my.orq.ai/v3/router` with an Orq.ai API key in `Authorization: Bearer $ORQ_API_KEY`; another proxy page documents `https://api.orq.ai/v2/router`. ([Orq.ai base URLs reference](https://docs.orq.ai/reference/base-urls))
- Whether an existing OpenAI-compatible client can be pointed at it by changing the base URL and key.
- Vercel AI SDK support AI SDK provider package
- Official provider package Not verified
Yes. Orq.ai documents the official TypeScript package `@orq-ai/vercel-provider`, installed with `npm install @orq-ai/vercel-provider ai`, and configured with `createOrqAiProvider({ apiKey: process.env.ORQ_API_KEY })`. ([Orq.ai Vercel AI SDK integration](https://docs.orq.ai/docs/ai-studio/integrations/frameworks/vercel-ai))
- Whether a first-party AI SDK provider package exists, or only a community package, a documented workaround, or the generic OpenAI provider pointed at a custom base URL.
- Python framework integrations Documented Python frameworks
- LlamaIndex Not verified
LlamaIndex integration is documented through the packages `llama-index` and `llama-index-llms-openai-like`, using the `OpenAILike` class. LlamaIndex Agents examples use `ReActAgent` and `FunctionTool`; LangChain is not documented. ([Orq.ai LlamaIndex Agents integration](https://docs.orq.ai/docs/ai-studio/integrations/frameworks/llamaindex-agents))
- LangChain, LangGraph, LlamaIndex and similar orchestration frameworks with a documented integration.
- Callable from Cloudflare Workers Cloudflare Workers support
- Not documented Not verified
n.a. (not documented)
- Whether the docs show calling this product from your own Worker. Deliberately separated from the several products whose own gateway runs on Workers, which is a fact about their infrastructure and not about your edge compatibility.
- Kubernetes install Helm chart availability
- Official Helm chart Not verified
Enterprise on-premise deployment is supported as a single Helm chart in a Kubernetes cluster; Kubernetes 1.28 or later is required, and the chart uses Helm hooks for database and data migrations. The optional agent sandbox uses the upstream `kubernetes-sigs/agent-sandbox` controller version `v0.4.6` with its own Helm chart. ([Orq.ai deployment options](https://docs.orq.ai/docs/enterprise/deployment-options))
- Whether a named, published Helm chart exists, versus Helm being referenced with no chart named, versus generic cluster documentation that has nothing to do with this product.
- Terraform support Terraform provider or modules
- Official Terraform provider Not verified
An official Terraform provider is documented as `orq-ai/orq`, version `0.1.0`. ([Orq.ai Terraform provider guardrail rule](https://registry.terraform.io/providers/orq-ai/orq/latest/docs/resources/guardrail_rule))
- Whether you can declare this in code: an official provider, official modules, resources inside a hyperscaler’s provider, a community provider, or only Terraform code shipped in a repo.
- Reuses your cloud identity Cloud IAM reuse
- Static provider credentials only Not verified
Partially: for Google Vertex AI, Orq.ai documents pasting a GCP service-account key JSON and granting the Service Account Token Creator and Vertex AI User roles; AWS SigV4/IAM roles and Azure Entra/managed identity are not documented. ([Orq.ai Vertex AI provider integration docs](https://docs.orq.ai/docs/ai-studio/integrations/providers/vertex-ai))
- Whether you can authenticate with IAM roles, workload identity or managed identities instead of another long-lived API key. Distinguished from products that only accept static upstream provider credentials.
- Fits behind your API gateway API gateway integration
- Not documented Not verified
n.a. (not documented)
- Whether AI traffic can go through a gateway you already run, and who documented that — the product’s vendor or the gateway’s.
- MCP support MCP surface shape
- Hosted MCP server Not verified
Yes. Orq.ai documents hosted MCP servers at `https://my.orq.ai/v2/mcp` for workspace access with 38 specialized tools, and supports MCP-compatible servers in agents through inline `server_url` or saved tools, with Streamable HTTP and SSE. A separate documentation MCP server is hosted at `https://docs.orq.ai/mcp`. ([Orq.ai MCP server integration](https://docs.orq.ai/docs/ai-studio/code-assistants/orq-mcp))
- Which kind of MCP support this is: a gateway that governs many MCP servers, a hosted MCP server you connect to, MCP tools accepted inside the completion API, or client tooling. These are different products behind one acronym.
- Needs your own provider key Upstream provider key required
- Required Not verified
Yes in this quickstart: it instructs adding an OpenAI API key through AI Gateway > BYOK before enabling `gpt-4o`, creating the agent, and calling it ([Quick Start | Build - Orq.ai](https://docs.orq.ai/docs/quickstarts/build-your-first-agent))
- Whether an upstream provider account and key must exist before your first call works. A prerequisite rather than a step, and it can differ between the hosted and self-hosted forms of the same product.
- Gate before models work Model access gate
- You enable it first Not verified
No approval gate, but a per-model enablement action inside the product: the quickstart requires enabling `gpt-4o` after adding a BYOK key ([Quick Start | Build - Orq.ai](https://docs.orq.ai/docs/quickstarts/build-your-first-agent))
- Whether an enablement click, a quota grant, a paid tier or an approval form stands between a valid key and a working model call.
- Official client languages First-party client SDK languages
- Python, Node.js Not verified
Official SDKs are documented for Python and Node.js: Python package `orq-ai-sdk` with class `Orq`, and Node.js package `@orq-ai/node` with class `Orq`. The `orq` CLI command is also documented. ([Orq.ai client libraries reference](https://docs.orq.ai/reference/client-libraries))
- Languages with a first-party client library. An empty list can still mean the product is usable from any language via an OpenAI-compatible SDK.
Additional charges
These are the fees that do not appear on a per-token price list, and they are where estimates usually go wrong.
- Orq-managed model credits 4.5% fee on credits
- BYOK above 1M requests/month 4%
- AI Studio seats EUR 35 per seat per month
- Knowledge Bases and Agent Memory EUR 500 per month
- Teams EUR 300 per month
- Spans beyond 100k EUR 7 per 100k
- Processed data beyond 1 GB EUR 3 per GB
- Agent runs beyond 500 EUR 0.01 per run
How pricing actually works
No open-source or free self-host option. Enterprise-only sovereign deployments: customer-owned VPC on AWS or Azure via marketplace, or fully on-prem/air-gapped via a single Helm chart, priced custom and billed annually.
Common questions
Answered from the fields above, so these move when the catalog moves. Every figure quoted here appears in the specification with its source.
Does Orq.ai Router charge a markup on model prices?
Orq.ai Router adds no percentage markup to model prices. Buying credit costs 4.5%. Other charges on the page: orq-managed model credits (4.5% fee on credits), byok above 1m requests/month (4%), ai studio seats (EUR 35 per seat per month), knowledge bases and agent memory (EUR 500 per month), teams (EUR 300 per month), spans beyond 100k (EUR 7 per 100k), processed data beyond 1 gb (EUR 3 per GB) and agent runs beyond 500 (EUR 0.01 per run).
Can Orq.ai Router be self-hosted?
Yes. Orq.ai Router can be run on your own infrastructure or used as a managed service. The licence is Proprietary. Air-gapped installation is supported.
Is Orq.ai Router SOC 2 audited, and will it sign a HIPAA BAA?
A SOC 2 report is available for Orq.ai Router and it will sign a HIPAA business associate agreement. It offers a GDPR data processing agreement and EU data residency. Each of these is linked to the vendor's own page in the compliance section below.
Does Orq.ai Router retain your prompts?
Orq.ai Router publishes a zero-data-retention position. Whether prompt and response bodies are logged is configurable. Logging can be turned off. It states that it does not train on customer data.
Can you use your own provider keys with Orq.ai Router?
Yes. Orq.ai Router can route through your own accounts with the underlying model providers, so inference is billed to you directly. BYOK free for the first 1M requests/month, then 4%; no markup on model traffic itself.
How many models does Orq.ai Router support?
Orq.ai Router states ~500 models. Vendor-stated 500+ models from 30+ providers on the pricing page; the docs cite 300+ models and a competitor comparison cites 400+ from 28+ providers, so the number moves by page. The figure on this page is dated and carries its source.
Official links
Independent coverage
Third-party analysis, walkthroughs and operator threads. We link criticism as readily as praise. Nothing here is written or published by the vendor, by a competitor listed on this site, or by an SEO content farm — how we vet these.
Written reviews and analysis 1
- Scaling AI with Confidence: Our Real-World Experience with Orq.ai Consultant's hands-on account of running Orq.ai's model garden, routing, deployments, RAG and evaluators on client projects, with specific module-level criticism.
Practitioner discussion 1
- Compared OpenRouter, Portkey, and Orq's gateway for routing across providers Operator who ran all three gateways in production reports where Orq's routing and per-team cost breakdowns fall short (tier-gated), with commenters adding dashboard critiques.
What has changed here
- catalog entry catalog entry Not published Added to the catalog source ↗