Visible provider
Routing
Destination and format visible
Each published route shows the call format and whether the model is hosted by RouterLab or processed by a third-party provider, without exposing internal routing logic.
Swiss AI Control LayerTrustRouteCredits tracked
Trust & infrastructure
See what RouterLab hosts, and what proprietary providers process.
This page separates roles: RouterLab controls access, credits, and usage, and hosts open-source models in Switzerland and Germany. Proprietary providers process requests sent to them.
TrustBoundaryMap
Responsibility map
A request crosses several zones. RouterLab makes those zones readable.
Client source
App / agent / workflow
OpenAI SDK
Claude Messages API
Product automation
ROUTERLAB CONTROL
RouterLab API
Authenticates API key
Applies permissions and access
Attaches usage and credits
Model processing
According to model type
Open source: RouterLab CH / DE
Proprietary: external provider
OpenAI / Anthropic / Google
Visible
Published route + hosting
Measure
Usage + credits
Metadata
No prompt content
What RouterLab controls
Access, routes, credits, and usage are grouped in one place.
RouterLab centralizes API access, applies account permissions, shows the published logical route, and ties each request to credits. Internal routing logic remains confidential.
Credits tracked
Credits
Consumption tied to balance
Each request feeds usage and the credit ledger so real cost can be tracked.
RouterLab key
API keys
One key in the application
Your apps call RouterLab with a RouterLab key instead of storing provider keys everywhere.
Dashboard
Tracking
Readable usage after the call
The dashboard shows the published logical route, consumption, and remaining credits, without displaying prompt and response content or internal routing logic.
Infrastructure and regions
The CH / DE signal is visible, and third-party providers are too.
RouterLab infrastructure and open-source models are hosted in Switzerland and Germany. Proprietary models are processed by their respective providers.
CH / DE infrastructure
RouterLab and open source in CH / DE
RouterLab infrastructure and open-source models run on our servers in Switzerland and Germany.
External processing
Named proprietary providers
OpenAI, Anthropic (Claude), and Google (Gemini) process requests that use their models under their own infrastructure and policies.
Visible routes
Readable provider statuses
Published routes expose format, status, and hosting category. They do not describe internal routing logic.
TrustRoute
Explicit hosting and providers
| Provider | Format | Role | What it means | Signal |
|---|---|---|---|---|
 | OpenAI SDK | Third-party provider | Processes the request on OpenAI infrastructure under its own policies | Third-party provider |
 | Claude Messages API | Third-party provider | Processes Claude requests on infrastructure external to RouterLab | Third-party provider |
 | OpenAI-compatible | Third-party provider | Processes Gemini requests on Google infrastructure | Third-party provider |
 | OpenAI-compatible | Hosted by RouterLab | Models run on RouterLab infrastructure in Switzerland and Germany | Hosted by RouterLab |
Data, keys, and limits
Trust also comes from what is limited.
The right trust level is precise: state what is controlled, and do not promise what depends on a provider.
Centralized access
API keys
Your integrations call RouterLab with a RouterLab key. Provider keys are not distributed into your client apps.
Credit ledger
Usage and credits
RouterLab keeps only the events and metadata needed to track credits, costs, usage, and support.
No durable archive
Prompts and responses
RouterLab does not log or durably archive their content. A very short-lived technical cache may be used when strictly necessary to operate the service.
Roles
Account access
Customer and admin areas remain separated by authentication and application roles.
TransparencyBoundary
Explicit limits
This page avoids unverified legal promises. It describes RouterLab's operational role.
Not a provider retention promise
OpenAI, Anthropic, and Google processing and retention policies depend on the provider and selected proprietary route.
Not a legal certificate
This page explains operational behavior. Legal commitments must remain in legal documents or contracts.
No provider hiding
When a route goes to a third-party provider, RouterLab should make it explicit instead of burying it.
Legal pages remain the source for terms, privacy, and data protection.
DataFlowDiagram
Trust follows the same path as the request.
Tracking covers the operational metadata needed for permissions, the published destination, usage, and credits. It includes neither prompt and response content nor internal routing logic.
01
Request
POST /v1/chat/completions
02
Control
Key + permissions + plan
03
Destination
Hosting / provider
04
Credits
Ledger + usage
Verification
Verify the flow with a trial key.
Test the endpoint, choose a model, and watch credits and usage return in the dashboard.