Change the URL, keep your tools, see the routes.
RouterLab sits between your SDKs, agents, workflows, and providers like OpenAI, Claude, Google, and open-source models to make routes, credits, usage, and costs visible.
IntegrationSchematic
RouterLab integration schematic
Existing
App
OpenAI SDK
Existing
Agent
Claude Messages API
Existing
Workflow
Job / automation
Replace baseURL
from
api.openai.com/v1
to
api.routerlab.ch/v1
ROUTERLAB
API
Routes · credits · statuses
OpenAI
OpenAI SDK
Claude
Claude Messages API
OpenAI-compatible
Open source
OpenAI-compatible
Dashboard usage
Visible return
Usage
1,248 req
Credits
CHF 42.80
Before / with RouterLab
The difference is not a new app. It is a control point.
The homepage explains why RouterLab exists. This page shows what changes in the technical flow.
Without a central layer
- OpenAI, Claude, and Google SDKs and keys are split
- Costs scattered across tools
- Routes are hard to explain
With RouterLab
- One RouterLab URL on the client side
- Named provider routes
- Credits, usage, and catalog visible
Detailed flow
What happens when a request goes through RouterLab.
The sequence is deliberately short: keep integration simple, make routing observable.
The app keeps its SDK
OpenAI SDK, Claude Messages API, agent, or workflow keep their current logic.
The baseURL points to RouterLab
The main change is the endpoint, not a full rewrite.
RouterLab publishes the route
Provider, format, status, and route type stay explicit.
The dashboard attaches usage
Credits, costs, usage, and catalog return to one place.
Universal endpoint
One endpoint for your AI clients.
https://api.routerlab.ch/v1
The goal is to change the entry point, then read routes and usage instead of guessing what happened.
OpenAI SDK
https://api.routerlab.ch/v1
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.routerlab.ch/v1",
apiKey: process.env.ROUTERLAB_API_KEY,
});
await client.chat.completions.create({
model: "model-id-from-catalog",
messages: [{ role: "user", content: "Route this request" }],
});Claude Messages API
https://api.routerlab.ch
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic({
baseURL: "https://api.routerlab.ch",
apiKey: process.env.ROUTERLAB_API_KEY,
});
await client.messages.create({
model: "claude-model-id-from-catalog",
max_tokens: 1024,
messages: [{ role: "user", content: "Route this request" }],
});Control
What RouterLab makes visible.
The modules are concrete: keys, credits, usage, and catalog. They exist to operate AI traffic, not decorate the page.
One RouterLab key
Apps keep one stable entry point without exposing every provider key.
Readable balance
Cost is tied to requests and the credit ledger.
Observed routes
The dashboard shows which provider answers, using which format, and at what cost.
Published models
Providers, formats, and statuses stay visible when choosing a route.
Governance
Third-party routes stay readable.
RouterLab shows the role of the CH / DE layer, external providers, formats, and statuses without adding unverified legal promises.
Hosted in Switzerland & Germany
The RouterLab layer is positioned in CH / DE.
Explicit providers
Third-party providers remain named in routes.
RouteTable
Provider routes
| Provider | Format | Status | Route type |
|---|---|---|---|
| OpenAI | OpenAI SDK | Active | Third-party route |
| Claude | Claude Messages API | Active | Messages route |
| Google | OpenAI-compatible | Available | Provider route |
| Open source | OpenAI-compatible | Active | RouterLab catalog |
Trial
Try the RouterLab endpoint with your tools.
Start with a trial key, then use the catalog to choose the right routes.