ARC
Pricing
Discord
Talk to an engineerStart free
Start free
ARCby FenxLabsCollective Intelligence

Platform

  • How it works
  • Custom routing and governance
  • Use cases
  • Example architectures

Deployment

  • Hosted Platform
  • Managed Service
  • Self-hosted Licence
  • For ISVs
  • Open the portal

Services

  • Assessment and planning
  • Architecture and integration
  • Model Adaptation
  • EU AI Act readiness
  • Managed Service operations

Resources

  • Cost modeller
  • Compare approaches
  • Pricing
  • FAQ
  • Transparency
  • Get started
  • Discord community

Legal

  • Privacy notice
  • Terms and conditions
  • Sub-processors
  • Accessibility

For individuals

  • FenxChat

FenxLabs. KvK 91762782.

Herengracht 320, 1016 CE Amsterdam, Netherlands

+31 85 060 5273contact@fenxlabs.ai

© 2026 FenxLabs. All rights reserved.

Decide where model policy lives

Four things separate a control plane from a gateway, a cloud AI stack or an internal build: your network boundary, your existing models, your data, and where the fee is taken.

Talk to an engineerStart free

Four questions that separate the approaches

Where FenxARC™ runs, what it can reach and how FenxLabs is paid are decided differently by each approach. Check all four against your own shortlist.

Does the router run inside your network?

ARC request handling runs inside your VPC, on your own hardware, or fully air-gapped. Internal routes can remain inside your network; an approved external route still receives the context it needs.

Self-hosted Licence. The Hosted Platform runs on FenxLabs infrastructure.

Does it route to the models you already run?

Fraud scoring, demand forecasting, document classification. The machine learning and deep learning models you already run become routing destinations alongside your language models.

Self-hosted Licence.

Does your vector storage sit behind it?

Connect vector storage directly to the router. It sits between the models and the data, and a model reaches only what it has permission to see.

Self-hosted Licence.

Where does the vendor take its fee?

Inference stays a direct relationship between you and your providers, at their rates. We take no margin on it.

FenxLabs resells no inference and holds no commercial relationship with any model vendor. The router has no commercial reason to prefer one destination over another.

Three of these four belong to the Self-hosted Licence. Where ARC runs is one decision and what it enforces is another.

Choose where ARC runsExplore the Self-hosted LicenceSee where FenxLabs takes its fee

ARC governs the model layer, not your entire AI stack

ARC governs how users, applications and agents access models, tools and approved data sources. It does not govern an agent's reasoning, planning, application logic, runtime or business accountability.

Applications keep their workflows. Providers keep serving inference. ARC evaluates each governed request against the active list, applies your eligibility and privacy rules, then ranks whatever survives them.

A list groups the models, tools and rules approved for a team or use case.

See how a request is handled
Five approaches

Choose an operating approach

What separates them is where the governing rule lives, and who is on the hook for keeping it right.

Where each of five operating approaches puts the endpoint, the policy, per-team approval, privacy handling and the provider relationship, and who is on the hook for each.
What it takesDirect provider integrationsProvider SDKs, called from your own codeCloud AI platformFor example AWS Bedrock, Azure AIGateway or routerFor example LiteLLM, Portkey, HeliconeInternal buildARC
One endpoint in front of every model○You build itEvery provider is integrated separately, in the application.◐Varies by productWithin that cloud's own services and the endpoints connected to it.●Built inA common request path is what the category exists for.○You build itYou write the endpoint and you keep it working.●Built inOne OpenAI-compatible base URL for everything on the list.
Policy that lives outside application code○You build itThe rules sit in each workload that calls a provider.◐Varies by productUsually split between cloud services and application configuration.◐Varies by productHow much policy the gateway holds differs by product.○You build itWhatever your team builds, and keeps current as models change.●Built inLists, customer-defined tags and routing policy, at the model layer.
A different approved set per team○You build itEnforced by whoever writes each integration.◐Varies by productDepends on how that platform models tenancy and access.◐Varies by productDepends on the product and on how far its policy model goes.○You build itYours to design, and yours to keep aligned as teams change.●Built inA list carries the models, tools and policy approved for that team.
Privacy settled before a model is chosen○You build itWhatever each application checks before it calls out.◐Varies by productDepends on the services in front of the model call.◐Varies by productDepends on whether the product evaluates policy before routing.○You build itYours to define, and yours to prove to a reviewer.●Built inYour classes decide eligibility, and ranking only orders what is left.
Your own provider accounts and rates●Built inYou contract with each provider directly.◐Varies by productModel charges usually arrive on the cloud account.◐Varies by productWhether provider billing passes through differs by product.●Built inYou contract with each provider directly.●Built inInference stays between you and your providers, at their rates.
Read the detailSee how a request is handled
Approaches to compare

Select one or two. Answers appear below, one criterion at a time.

One endpoint in front of every model

Direct provider integrations · Provider SDKs, called from your own code
○You build itEvery provider is integrated separately, in the application.
Cloud AI platform · For example AWS Bedrock, Azure AI
◐Varies by productWithin that cloud's own services and the endpoints connected to it.
Gateway or router · For example LiteLLM, Portkey, Helicone
●Built inA common request path is what the category exists for.
Internal build
○You build itYou write the endpoint and you keep it working.
ARC
●Built inOne OpenAI-compatible base URL for everything on the list.

Policy that lives outside application code

Direct provider integrations · Provider SDKs, called from your own code
○You build itThe rules sit in each workload that calls a provider.
Cloud AI platform · For example AWS Bedrock, Azure AI
◐Varies by productUsually split between cloud services and application configuration.
Gateway or router · For example LiteLLM, Portkey, Helicone
◐Varies by productHow much policy the gateway holds differs by product.
Internal build
○You build itWhatever your team builds, and keeps current as models change.
ARC
●Built inLists, customer-defined tags and routing policy, at the model layer.

A different approved set per team

Direct provider integrations · Provider SDKs, called from your own code
○You build itEnforced by whoever writes each integration.
Cloud AI platform · For example AWS Bedrock, Azure AI
◐Varies by productDepends on how that platform models tenancy and access.
Gateway or router · For example LiteLLM, Portkey, Helicone
◐Varies by productDepends on the product and on how far its policy model goes.
Internal build
○You build itYours to design, and yours to keep aligned as teams change.
ARC
●Built inA list carries the models, tools and policy approved for that team.

Privacy settled before a model is chosen

Direct provider integrations · Provider SDKs, called from your own code
○You build itWhatever each application checks before it calls out.
Cloud AI platform · For example AWS Bedrock, Azure AI
◐Varies by productDepends on the services in front of the model call.
Gateway or router · For example LiteLLM, Portkey, Helicone
◐Varies by productDepends on whether the product evaluates policy before routing.
Internal build
○You build itYours to define, and yours to prove to a reviewer.
ARC
●Built inYour classes decide eligibility, and ranking only orders what is left.

Your own provider accounts and rates

Direct provider integrations · Provider SDKs, called from your own code
●Built inYou contract with each provider directly.
Cloud AI platform · For example AWS Bedrock, Azure AI
◐Varies by productModel charges usually arrive on the cloud account.
Gateway or router · For example LiteLLM, Portkey, Helicone
◐Varies by productWhether provider billing passes through differs by product.
Internal build
●Built inYou contract with each provider directly.
ARC
●Built inInference stays between you and your providers, at their rates.
Read the detail
See how a request is handled
Built in means the approach provides it. You build it means the approach leaves it to your team. Varies by product means it genuinely differs inside that category, which is the question to take to a shortlist rather than one this page can answer for you.

The same five, in full

Best fit, policy location, model choice, team burden and the main trade-off, for each of the five operating approaches.
QuestionDirect provider integrationsProvider SDKs, called from your own codeCloud AI platformFor example AWS Bedrock, Azure AIGateway or routerFor example LiteLLM, Portkey, HeliconeInternal buildARC
Best fitA small number of stable workloads tied to one provider.Organisations standardising hard on one cloud operating model.Teams that mainly need a common endpoint, provider abstraction and traffic controls.Teams with unusual requirements and the capacity to own a control-plane product.Organisations that want governed choice across models, tools, providers and environments.
Policy locationEach application, or each provider configuration.Cloud services plus application configuration.Gateway configuration and application logic.Your code and your operating environment.Lists, customer-defined tags and routing policy at the model layer.
Model choiceConstrained to the connected provider and the application's own logic.Depends on the platform and the endpoints connected to it.Depends on the gateway's routing and provider support.Whatever your team integrates and keeps working.The models and tools approved on the active list.
Team burdenIntegrations and policy maintained inside every workload.Governance aligned to that cloud's services and boundaries.Routing policy defined, tested and maintained by your team.Design, security, evaluation, operations and change, all of it yours.You own policy and provider relationships. ARC applies that policy on each governed request.
Main trade-offSimple at first. Changes multiply as providers and teams grow.Broad platform integration, with the decisions shaped by that platform.Useful connectivity. Governance depth and deployment options vary by product.Maximum customisation, against continuing product and operational ownership.One more layer to integrate and govern.
Read the detailSee how a request is handled
Approaches to compare, in detail

Select one or two. Answers appear below, one criterion at a time.

Best fit

Direct provider integrations · Provider SDKs, called from your own code
A small number of stable workloads tied to one provider.
Cloud AI platform · For example AWS Bedrock, Azure AI
Organisations standardising hard on one cloud operating model.
Gateway or router · For example LiteLLM, Portkey, Helicone
Teams that mainly need a common endpoint, provider abstraction and traffic controls.
Internal build
Teams with unusual requirements and the capacity to own a control-plane product.
ARC
Organisations that want governed choice across models, tools, providers and environments.

Policy location

Direct provider integrations · Provider SDKs, called from your own code
Each application, or each provider configuration.
Cloud AI platform · For example AWS Bedrock, Azure AI
Cloud services plus application configuration.
Gateway or router · For example LiteLLM, Portkey, Helicone
Gateway configuration and application logic.
Internal build
Your code and your operating environment.
ARC
Lists, customer-defined tags and routing policy at the model layer.

Model choice

Direct provider integrations · Provider SDKs, called from your own code
Constrained to the connected provider and the application's own logic.
Cloud AI platform · For example AWS Bedrock, Azure AI
Depends on the platform and the endpoints connected to it.
Gateway or router · For example LiteLLM, Portkey, Helicone
Depends on the gateway's routing and provider support.
Internal build
Whatever your team integrates and keeps working.
ARC
The models and tools approved on the active list.

Team burden

Direct provider integrations · Provider SDKs, called from your own code
Integrations and policy maintained inside every workload.
Cloud AI platform · For example AWS Bedrock, Azure AI
Governance aligned to that cloud's services and boundaries.
Gateway or router · For example LiteLLM, Portkey, Helicone
Routing policy defined, tested and maintained by your team.
Internal build
Design, security, evaluation, operations and change, all of it yours.
ARC
You own policy and provider relationships. ARC applies that policy on each governed request.

Main trade-off

Direct provider integrations · Provider SDKs, called from your own code
Simple at first. Changes multiply as providers and teams grow.
Cloud AI platform · For example AWS Bedrock, Azure AI
Broad platform integration, with the decisions shaped by that platform.
Gateway or router · For example LiteLLM, Portkey, Helicone
Useful connectivity. Governance depth and deployment options vary by product.
Internal build
Maximum customisation, against continuing product and operational ownership.
ARC
One more layer to integrate and govern.
Read the detail
See how a request is handled
Capabilities vary by product and change over time. Use this to choose an operating approach, then verify the specific requirements during evaluation.

Eligibility runs before ranking, so nothing in the ordering step can reach a destination the policy excluded.

See how a request is handled

Ask before you commit

These separate an operating approach from a feature list. Put them to every option on the shortlist, ARC included.

  • Can we govern models and tools through the same request policy?
  • Can each team have an approved set without hard-coding it in every application?
  • Can we keep our direct provider relationships and rates?
  • Can the same policy model run hosted, managed or self-hosted?
  • What must our team build, test and operate after the first integration?

ARC is not necessary for every workload

One provider, one model and application-level controls may cover everything you can foresee. A second control layer would then be cost without a return.

  • One workload and one provider. Nothing to route between yet.
  • Tracing, evaluation and prompt versioning. Buy a tool built for that.
  • A route changes which approved destinations run. It does not make any model better.

ARC is built for the case where workload categories, model choice, privacy handling, access policy and deployment boundaries have to change across teams without rewriting each workload.

See where ARC sits in real environmentsChoose where ARC runsWhat it costsEmbed ARC in your software

Compare ARC against today's approach

Bring a workload and a constraint. We will tell you whether routing changes anything for you.

Talk to an engineerStart free