Schéma produitCouche de contrôle IAOpenAI · Anthropic · Google

Changez l’URL, gardez vos outils, voyez les routes.

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

Schéma d’intégration RouterLab

VISIBLERouterLab API · CH / DE

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

API

Routes · crédits · statuts

OpenAI

Route vers un provider externe

Anthropic

Route vers un provider externe

Google

Route vers un provider externe

RouterLab

Modèles open source hébergés par RouterLab · CH / DE

Tableau de bord d’usage

Retour visible

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

Modèle, format d’API et fournisseur de traitement ne sont pas la même chose.

Ces trois niveaux répondent à trois questions différentes : quoi utiliser, comment l’appeler et qui exécute la requête.

DÉFINITION

Modèle

Le modèle ou la famille de modèles demandée.

Exemples du catalogue

GPTClaudeGeminiDeepSeekKimiGLMMiniMaxQwenGrok
DÉFINITION

Format d’API

Le protocole utilisé par le client pour appeler RouterLab.

Exemples du catalogue

OpenAI-compatible APIClaude Messages APIEmbeddings API
DÉFINITION

Fournisseur de traitement

L’infrastructure qui exécute réellement la requête.

Exemples du catalogue

OpenAIAnthropicGoogleRouterLab

Avant / avec RouterLab

La différence n’est pas une nouvelle app. C’est un point de contrôle.

La homepage explique pourquoi RouterLab existe. Cette page montre ce qui change dans le flux technique.

Avant

Sans couche centrale

  • SDK et clés de providers séparés
  • Coûts dispersés entre les outils
  • Routes difficiles à expliquer
RouterLab

Avec RouterLab

  • Une URL RouterLab côté client
  • Route sélectionnée et destination explicites
  • Crédits, usage et catalogue visibles

Flux détaillé

Ce qui se passe quand une requête passe par RouterLab.

La séquence reste courte : garder l’intégration simple, rendre le routage et l’usage observables.

01

Client / SDK

Votre application, agent ou SDK compatible envoie la requête.

02

RouterLab API

RouterLab authentifie la clé et reçoit la requête.

03

Route sélectionnée

La route sélectionnée détermine le format et la destination.

04

Provider / infrastructure réelle

La requête est traitée par le provider ou l’infrastructure indiquée par la route.

05

Réponse + usage / crédits

La réponse revient au client ; RouterLab rattache l’usage et les crédits.

Endpoint et compatibilité

Conservez vos SDK compatibles et pointez-les vers RouterLab.

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

OpenAI SDKClaude Messages APICH / DE

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.

  • ✓SDK compatible conservé
  • ✓Changement ciblé de base URL
  • ✓Même requête, route et réponse lisibles
Compatible

OpenAI SDK

https://api.routerlab.ch/v1

Compatible
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" }],
});

Claude Messages API

https://api.routerlab.ch

Compatible
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

Ce que RouterLab rend visible.

Les modules sont concrets : clés, crédits, usage et catalogue. Ils servent à piloter le trafic IA, pas à ajouter une promesse de routage automatique.

Clés

Une clé RouterLab

Les apps gardent un point d’entrée stable sans exposer chaque clé provider.

Crédits

Solde lisible

Le coût est rattaché aux requêtes et au ledger de crédits.

Usage

Routes observées

Le dashboard montre la route, le format et le coût associés à la requête.

Catalogue

Modèles publiés

Modèles, formats et statuts restent visibles pour choisir une route.

Gouvernance

Les routes restent lisibles jusqu’à l’infrastructure réelle.

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.

RouterLab

Ce que RouterLab contrôle

La couche de contrôle, le routage publié et la visibilité.

  • Authentification et clés API
  • Routes de modèles publiées
  • Visibilité de l’usage
  • Crédits et facturation
  • Infrastructure RouterLab pour les modèles open source hébergés en Suisse / Allemagne
Provider

Ce que le provider contrôle

Chaque provider opère son infrastructure et ses modèles.

  • Infrastructure et disponibilité du modèle
  • Traitement de la requête côté provider
  • Comportement du modèle
  • Cycle de vie et mises à jour du modèle

Table des routes

Comment lire une route

Modèle / familleFormat d’APITraitement / hébergementCe que cela signifie
ClaudeClaude Messages APIProvider externeClaude est une famille de modèles appelée avec le format Messages ; l’infrastructure dépend de la route du catalogue.
GPTOpenAI-compatible APIProvider externeGPT est une famille de modèles ; OpenAI-compatible décrit le protocole, pas à lui seul l’infrastructure finale.
GeminiOpenAI-compatible APIProvider externeGemini est une famille de modèles ; le format d’appel et le provider de traitement sont deux informations distinctes.
Familles open sourceOpenAI-compatible APIRouterLab si la route est hébergée ; sinon provider externeOpen source décrit la famille ou le type de modèle ; l’hébergement doit être lu route par route.
Modèles d’embeddingsEmbeddings APITraitement selon la route du catalogueLes 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

Essayez l’endpoint RouterLab avec vos outils.

Commencez par une clé d’essai, puis consultez le catalogue pour choisir les routes adaptées.