Orq.ai governs model traffic through an AI gateway

Orq.ai places a shared gateway between applications and the model providers they use. It combines routing, credentials, usage visibility and policy controls so that each application does not need to recreate those functions. The important decision is where that shared layer helps the organisation and where it creates a new dependency. A gateway can standardise access, but it cannot make different models behave identically or remove the need to validate the application itself.

01 / ProductA common control point for model requests

The gateway introduction describes an OpenAI-compatible endpoint with routing, retries, fallbacks, load balancing and usage tracking. The documented setup connects a provider, enables a model and makes a request through the gateway. This lets an application use a common access surface while the organisation manages provider selection in one place.

Orq.ai’s company page identifies its Dutch origins and the evolution from AI experimentation into enterprise operation. Its current website also presents managed agents and a Software Factory. The latter is advertised with an early-access route. This blueprint centres on the documented gateway workflow; a new software-delivery product should be evaluated separately for its actual availability and scope.

The BYOK guide explains how organisations connect their own provider credentials. Alternatively, the platform offers access using Orq.ai credits. Those routes change who bills the inference and where provider limits apply. The application-facing gateway key and the upstream provider credential serve different purposes, so access to one should not be treated as permission to manage the other.

02 / AudienceMost relevant when model use is becoming an organisational concern

A team with several products, internal agents or experiments may need a common view of which models are being used and what they cost. Orq.ai is worth examining when individual application keys and ad hoc billing reports are becoming difficult to govern. A single small script may not need the same layer; additional infrastructure should solve an observed coordination or operational problem.

OpenRouter is a useful comparison for access to multiple models through a common interface. LiteLLM provides another gateway-oriented approach to investigate. Compare credential ownership, deployment options, policy controls and operational responsibility. The relevant distinction is how the gateway fits your organisation’s architecture, rather than which catalogue advertises the largest number of models.

Platform teams should also involve the people who own the applications. Routing changes can alter response format, tool behaviour, latency or cost. A central administrator may prefer a cheaper model while an application depends on a specific capability. A useful gateway operating model gives those owners a way to approve changes and see the evidence, rather than treating model selection as an invisible infrastructure detail.

03 / WorkflowProposed workflow: route one internal assistant through the gateway

This is a proposed rollout, not a measured deployment. Select a low-risk internal assistant with a clear task and an existing evaluation set. Record its current model, typical request size and failure behaviour. Create a separate project and key for the pilot, then connect the chosen provider through BYOK. Keep the original application configuration available so the team can reverse the routing change if required.

Follow the documented gateway setup and send a small representative set of requests. Check the response content, structured output, tool calls and streaming behaviour that the application actually uses. An endpoint being described as compatible does not prove that every provider-specific feature is interchangeable. Record which features the application relies on before enabling a second model.

Configure a deliberately limited fallback and retry policy. Retries address transient failures; fallback sends the request to another model. They solve different problems. Test a controlled failure and verify which route was used. A fallback model should meet the application’s requirements for output shape, data handling and task performance, rather than merely returning a successful HTTP response.

Apply a budget to the pilot’s key or project and give the application a clear response when the limit is reached. The documentation supports controls at several scopes, including workspace, project, identity, provider and model. Separate an experiment’s allowance from production so a repeated test cannot consume the budget intended for customer traffic.

Review the observed calls with the application owner. Compare task success and latency with the previous route, and inspect any request that changed model. Reconcile provider and gateway usage to understand the full cost. Only after the pilot is understood should the team widen the shared policy. A gradual rollout helps distinguish a gateway configuration issue from a pre-existing problem in the assistant.

04 / PricingBYOK and platform-billed inference have different cost paths

The pricing page offers one million free BYOK gateway requests per month, followed by a 4% fee. Its FAQ specifies a 4.5% platform fee on credit top-ups when using Orq.ai keys. Enterprise is custom priced. BYOK model-provider charges remain separate; the public 4% line does not fully explain the calculation base, which buyers should confirm before modelling a larger deployment.

A request allowance and a token bill describe different things. One request can contain a short question or a large document and can produce very different amounts of output. When estimating cost, preserve both dimensions. A shared gateway can make request volume visible, while the application’s prompt size, chosen model and number of retries still influence inference spend.

The same page lists AI Studio at €35 per seat per month, while gateway seats are unlimited. An API-only team and a team using the visual workspace therefore have different cost profiles. Check the additional meters for agent runs, knowledge features and team controls if the scope expands. Start with the functions in the proposed deployment and reconcile each charge, rather than treating a gateway allowance as an all-inclusive platform budget.

05 / DistinctionsControls can follow the organisational boundary

Scoped budgets are a practical distinction because an organisation rarely has only one useful spending boundary. A customer-facing service, a staging environment and an experimental model evaluation may share a provider while needing separate limits. Orq.ai documents independent enforcement when several budgets apply to the same request. That lets a team express both a local allowance and a broader organisational ceiling.

The budget guide also explains an important limitation: usage settles after requests complete, so requests already in flight can finish after a threshold is reached. A budget is therefore not a mathematical guarantee that the final bill can never exceed its nominal ceiling. Choose an operational margin and inspect concurrency when setting limits for expensive models or high-volume jobs.

Retries and fallbacks centralise a function that otherwise tends to be implemented repeatedly. The value is consistency and visibility. It can also increase the impact of a mistaken shared policy. Keep routing changes reviewable, monitor which fallback actually ran and ensure that the application can distinguish a recovered transport failure from a lower-quality answer that merely completed.

06 / QuestionsEU platform hosting does not determine every inference destination

The EU residency documentation says hosted platform data such as traces, prompts and evaluations stays in the EU by default. It separately states that model calls go to the provider chosen by the customer. This is a crucial distinction: selecting a European gateway does not automatically establish EU-only inference for every model behind it.

If the application requires a particular region or retention commitment, apply that requirement to every provider in the fallback chain as well as the primary route. Confirm where traces are stored and what masking means for data sent upstream. A field omitted from stored logs may still be sent to a model to answer the request. The right check follows the data through the whole path.

The public documentation describes VPC and on-premises deployment routes and security controls, but this research did not inspect a private installation, audit report or signed agreement. We also did not test model compatibility, routing latency or budget enforcement. Claims about sovereignty and compliance should be assessed against the selected provider configuration and contract, rather than treated as automatic properties of the completed application.

07 / DecisionAdopt the gateway around a measurable operating problem

Orq.ai is a useful candidate when model usage needs a consistent point of control across teams or applications. Start with one service, a known evaluation set and a clear spending boundary. The pilot should show where the gateway improves visibility and reliability while making its own dependencies and limits understandable to the people operating the application.