Modèle
Le modèle ou la famille de modèles demandée.
Exemples du catalogue
RouterLab se place entre vos applications, agents et workflows et les routes de modèles. Il authentifie la requête, applique la route choisie, puis rattache la réponse à l’usage et aux crédits.
Schéma produit
Existant
Application
OpenAI SDK
Existant
Agent IA
Claude Messages API
Existant
Workflow
Job / automatisation
Changer la base URL
de
api.openai.com/v1
vers
api.routerlab.ch/v1
ROUTERLAB
Routes · crédits · statuts
OpenAI
Route vers un provider externe
Anthropic
Route vers un provider externe
Route vers un provider externe
RouterLab
Modèles open source hébergés par RouterLab · CH / DE
Tableau de bord d’usage
Exemple illustratif
Usage
1 248 req.
Crédits
42,80 USD
Réponse
vers le client
Après la requête
usage + crédits
Concepts
Ces trois niveaux répondent à trois questions différentes : quoi utiliser, comment l’appeler et qui exécute la requête.
Le modèle ou la famille de modèles demandée.
Exemples du catalogue
Le protocole utilisé par le client pour appeler RouterLab.
Exemples du catalogue
L’infrastructure qui exécute réellement la requête.
Exemples du catalogue
Avant / avec RouterLab
La homepage explique pourquoi RouterLab existe. Cette page montre ce qui change dans le flux technique.
Flux détaillé
La séquence reste courte : garder l’intégration simple, rendre le routage et l’usage observables.
Votre application, agent ou SDK compatible envoie la requête.
RouterLab authentifie la clé et reçoit la requête.
La route sélectionnée détermine le format et la destination.
La requête est traitée par le provider ou l’infrastructure indiquée par la route.
La réponse revient au client ; RouterLab rattache l’usage et les crédits.
Endpoint et compatibilité
RouterLab expose des formats compatibles. Le changement porte sur la base URL et la clé RouterLab ; le chemin exact dépend ensuite du SDK utilisé.
https://api.routerlab.ch/v1
Changez le point d’entrée, puis lisez les routes et l’usage au lieu de deviner ce qui se passe.
Les SDK peuvent utiliser une base URL légèrement différente, car chacun construit son propre chemin d’API. Ils accèdent néanmoins à la même couche RouterLab.
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-/v1/models",
messages: [{ role: "user", content: "Route this request" }],
});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: "model-id-with-claude-messages-route",
max_tokens: 1024,
messages: [{ role: "user", content: "Route this request" }],
});Contrôle
Les modules sont concrets : clés, crédits, usage et catalogue. Ils servent à piloter le trafic IA, pas à ajouter une promesse de routage automatique.
Les apps gardent un point d’entrée stable sans exposer chaque clé provider.
Le coût est rattaché aux requêtes et au ledger de crédits.
Le dashboard montre la route, le format et le coût associés à la requête.
Modèles, formats et statuts restent visibles pour choisir une route.
Gouvernance
Le catalogue sépare la famille de modèle, le format d’API et le chemin de traitement. RouterLab ne présente pas un provider comme s’il s’agissait d’un modèle.
La couche de contrôle, le routage publié et la visibilité.
Chaque provider opère son infrastructure et ses modèles.
Table des routes
| Modèle / famille | Format d’API | Traitement / hébergement | Ce que cela signifie |
|---|---|---|---|
| Claude | Claude Messages API | Provider externe | Claude est une famille de modèles appelée avec le format Messages ; l’infrastructure dépend de la route du catalogue. |
| GPT | OpenAI-compatible API | Provider externe | GPT est une famille de modèles ; OpenAI-compatible décrit le protocole, pas à lui seul l’infrastructure finale. |
| Gemini | OpenAI-compatible API | Provider externe | Gemini est une famille de modèles ; le format d’appel et le provider de traitement sont deux informations distinctes. |
| Familles open source | OpenAI-compatible API | RouterLab si la route est hébergée ; sinon provider externe | Open source décrit la famille ou le type de modèle ; l’hébergement doit être lu route par route. |
| Modèles d’embeddings | Embeddings API | Traitement selon la route du catalogue | Les modèles d’embeddings utilisent une route spécialisée et ne sont pas des modèles de chat. |
Une route peut viser un provider externe ou héberger un modèle open source chez RouterLab. L’hébergement et le traitement se lisent route par route ; consultez la page Trust pour les informations d’infrastructure.
Essai
Commencez par une clé d’essai, puis consultez le catalogue pour choisir les routes adaptées.