ProduktschemaKI-KontrollschichtOpenAI · Anthropic · Google

URL ändern, Tools behalten, Routen sehen.

RouterLab liegt zwischen Ihren Anwendungen, Agenten, Workflows und Modellrouten. Es authentifiziert die Anfrage, wendet die ausgewählte Route an und ordnet die Antwort anschließend Nutzung und Credits zu.

Produktschema

RouterLab-Integrationsschema

SICHTBARRouterLab API · CH / DE

Vorhanden

Anwendung

OpenAI SDK

Vorhanden

KI-Agent

Claude Messages API

Vorhanden

Workflow

Job / Automatisierung

Basis-URL ändern

von

api.openai.com/v1

zu

api.routerlab.ch/v1

ROUTERLAB

API

Routen · Credits · Status

OpenAI

Route zu einem externen Provider

Anthropic

Route zu einem externen Provider

Google

Route zu einem externen Provider

RouterLab

Von RouterLab gehostete Open-Source-Modelle · CH / DE

Dashboard-Nutzung

Sichtbare Antwort

Beispielhafte Darstellung

Nutzung

1.248 Anfr.

Credits

42,80 USD

Antwort

zurück zum Client

Nach der Anfrage

Nutzung + Credits

Konzepte

Modell, API-Format und Verarbeitungsprovider sind nicht dasselbe.

Diese drei Ebenen beantworten drei verschiedene Fragen: Was wird verwendet, wie wird es aufgerufen und wer führt die Anfrage aus.

DEFINITION

Modell

Das angeforderte Modell oder die Modellfamilie.

Katalogbeispiele

GPTClaudeGeminiDeepSeekKimiGLMMiniMaxQwenGrok
DEFINITION

API-Format

Das Protokoll, mit dem der Client RouterLab aufruft.

Katalogbeispiele

OpenAI-compatible APIClaude Messages APIEmbeddings API
DEFINITION

Verarbeitungsprovider

Die Infrastruktur, die die Anfrage tatsächlich ausführt.

Katalogbeispiele

OpenAIAnthropicGoogleRouterLab

Vorher / mit RouterLab

Der Unterschied ist keine neue App. Es ist ein Kontrollpunkt.

Die Homepage erklärt, warum RouterLab existiert. Diese Seite zeigt, was sich im technischen Ablauf ändert.

Vorher

Ohne zentrale Schicht

  • Getrennte Provider-SDKs und -Schlüssel
  • Kosten über mehrere Tools verteilt
  • Routen schwer erklärbar
RouterLab

Mit RouterLab

  • Eine RouterLab-URL auf der Clientseite
  • Ausgewählte Route und Ziel sind eindeutig
  • Credits, Nutzung und Katalog sichtbar

Detaillierter Ablauf

Was passiert, wenn eine Anfrage über RouterLab läuft.

Die Abfolge bleibt kurz: Integration einfach halten sowie Routing und Nutzung sichtbar machen.

01

Client / SDK

Ihre Anwendung, Ihr Agent oder Ihr kompatibles SDK sendet die Anfrage.

02

RouterLab API

RouterLab authentifiziert den Schlüssel und empfängt die Anfrage.

03

Ausgewählte Route

Die ausgewählte Route bestimmt Format und Ziel.

04

Provider / tatsächliche Infrastruktur

Die Anfrage wird durch den von der Route angegebenen Provider oder die entsprechende Infrastruktur verarbeitet.

05

Antwort + Nutzung / Credits

Die Antwort geht an den Client zurück; RouterLab ordnet Nutzung und Credits zu.

Endpoint und Kompatibilität

Behalten Sie Ihre kompatiblen SDKs und richten Sie sie auf RouterLab.

RouterLab stellt kompatible Formate bereit. Geändert werden Basis-URL und RouterLab-Schlüssel; der genaue Pfad hängt danach vom verwendeten SDK ab.

https://api.routerlab.ch/v1

OpenAI SDKClaude Messages APICH / DE

Ändern Sie den Einstiegspunkt und lesen Sie anschließend Routen und Nutzung ab, statt den Ablauf zu erraten.

SDKs können eine leicht unterschiedliche Basis-URL verwenden, weil jedes seinen eigenen API-Pfad erstellt. Sie erreichen trotzdem dieselbe RouterLab-Schicht.

  • ✓Kompatibles SDK behalten
  • ✓Gezielte Änderung der Basis-URL
  • ✓Gleiche Anfrage, Route und Antwort bleiben lesbar
Kompatibel

OpenAI SDK

https://api.routerlab.ch/v1

Kompatibel
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

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

Kontrolle

Was RouterLab sichtbar macht.

Die Module sind konkret: Schlüssel, Credits, Nutzung und Katalog. Sie steuern KI-Datenverkehr, ohne ein Versprechen für automatische Routenwahl hinzuzufügen.

Schlüssel

Ein RouterLab-Schlüssel

Apps behalten einen stabilen Einstiegspunkt, ohne jeden Provider-Schlüssel offenzulegen.

Credits

Lesbarer Kontostand

Kosten werden den Anfragen und dem Credit-Hauptbuch zugeordnet.

Nutzung

Beobachtete Routen

Das Dashboard zeigt die mit der Anfrage verbundene Route, das Format und die Kosten.

Katalog

Veröffentlichte Modelle

Modelle, Formate und Status bleiben bei der Routenauswahl sichtbar.

Governance

Routen bleiben bis zur tatsächlichen Infrastruktur lesbar.

Der Katalog trennt Modellfamilie, API-Format und Verarbeitungspfad. RouterLab stellt einen Provider nicht so dar, als wäre er ein Modell.

RouterLab

Was RouterLab kontrolliert

Kontrollschicht, veröffentlichte Routen und Sichtbarkeit.

  • Authentifizierung und API-Schlüssel
  • Veröffentlichte Modellrouten
  • Sichtbarkeit der Nutzung
  • Credits und Abrechnung
  • RouterLab-Infrastruktur für in der Schweiz / Deutschland gehostete Open-Source-Modelle
Provider

Was der Provider kontrolliert

Jeder Provider betreibt seine Infrastruktur und Modelle selbst.

  • Modellinfrastruktur und Verfügbarkeit
  • Anfrageverarbeitung beim Provider
  • Modellverhalten
  • Lebenszyklus und Aktualisierungen des Modells

Routentabelle

So lesen Sie eine Route

Modell / FamilieAPI-FormatVerarbeitung / HostingBedeutung
ClaudeClaude Messages APIExterner ProviderClaude ist eine Modellfamilie und wird mit dem Messages-Format aufgerufen; die Infrastruktur hängt von der Katalogroute ab.
GPTOpenAI-compatible APIExterner ProviderGPT ist eine Modellfamilie; OpenAI-compatible beschreibt das Protokoll, nicht allein die endgültige Infrastruktur.
GeminiOpenAI-compatible APIExterner ProviderGemini ist eine Modellfamilie; Aufrufformat und Verarbeitungsprovider sind getrennte Informationen.
Open-Source-FamilienOpenAI-compatible APIRouterLab bei Hosting; sonst externer ProviderOpen Source beschreibt Modellfamilie oder -typ; das Hosting muss routeweise gelesen werden.
Embedding-ModelleEmbeddings APIVerarbeitung gemäß KatalogrouteEmbedding-Modelle verwenden eine spezialisierte Route und sind keine Chatmodelle.

Eine Route kann auf einen externen Provider zielen oder ein Open-Source-Modell bei RouterLab hosten. Hosting und Verarbeitung werden routeweise gelesen; die Trust-Seite enthält die relevanten Infrastrukturinformationen.

Testversion

Testen Sie den RouterLab-Endpoint mit Ihren Tools.

Beginnen Sie mit einem Testschlüssel und nutzen Sie anschließend den Katalog, um die passenden Routen auszuwählen.