OpenRouter: ein API-Key für hunderte Modelle

OpenRouter bündelt Modelle von vielen Anbietern hinter einer OpenAI-kompatiblen Schnittstelle. Statt für jeden Anbieter ein eigenes Konto und SDK zu pflegen, hast du einen Key, eine Rechnung und einen Modellkatalog, in dem du frei mischen kannst.

Account und Key anlegen

1. Konto auf openrouter.ai erstellen.
2. Im Dashboard unter "Keys" einen Inference-Key anlegen. Das Format ist sk-or-v1-..., und der Key wird nur einmal angezeigt: sofort speichern.
3. Dem Key direkt ein Ausgabelimit mitgeben (Feld limit in USD, optional limit_reset auf daily, weekly oder monthly). Überschreitet der Verbrauch das Limit, antwortet die API mit HTTP 402 statt unkontrolliert weiterzuziehen. Für Automatisierungen ist das der wichtigste Schutzhebel.

Wer Keys programmatisch verwaltet (z. B. für ein Team), nutzt zusätzlich einen Management Key. Der darf keine Completion-Calls machen, kann aber Keys erstellen, Limits setzen und den Credit-Stand über GET /api/v1/credits abfragen.

Basis-URL und erste Anfrage

Die OpenAI-kompatible Basis ist https://openrouter.ai/api/v1, der Chat-Endpunkt liegt auf /chat/completions. Ein Minimalbeispiel:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "HTTP-Referer: https://example.com" \
  -H "X-Title: Meine App" \
  -d '{"model":"anthropic/claude-sonnet-4.5","messages":[{"role":"user","content":"Hi"}]}'

HTTP-Referer und X-Title sind optional und beeinflussen nur das App-Ranking auf OpenRouter. Jedes OpenAI-SDK funktioniert mit base_url="https://openrouter.ai/api/v1".

Modelle finden und Varianten verstehen

Der Katalog liegt auf openrouter.ai/models bzw. hinter GET /api/v1/models - mit Filtern nach Preis, Kontextlänge, Latenz und unterstützten Parametern (etwa tools oder reasoning). Preise stehen in USD pro Token; mit 1.000.000 multiplizieren ergibt die vertraute Dollar-pro-Million-Tokens-Sicht.

Bei den Modell-Slugs lohnt Blick auf die Suffixe:

• :free ist ein eigener Gratis-Eintrag im Katalog mit eigenen Rate-Limits (ohne gekaufte Credits grob 50 Anfragen pro Tag, ab 10 Credits Guthaben 1000 pro Tag).
• :nitro sortiert Provider nach Durchsatz, :floor nach Preis (Flex-Tarif), :exacto nach Zuverlässigkeit beim Tool-Calling. Das sind Routing-Hinweise, keine anderen Modelle.
• :thinking, :extended und :online sind veraltet bzw. zurückgezogen. Reasoning steuert heute über den reasoning-Parameter, Websuche über Server-Tools.

Fallback-Routing und Auto-Router

Zwei Mechanismen verhindern, dass ein Request an einem ausgefallenen oder überlasteten Provider stirbt:

• Modell-Fallbacks: "models": ["anthropic/claude-sonnet-4.5", "openai/gpt-5-mini"] probiert der Reihe nach durch.
• Provider-Steuerung: das provider-Objekt mit order, sort (Preis, Durchsatz, Latenz) und allow_fallbacks. Mit max_price setzt du ein hartes Preis-Limit; ohne Konfiguration balanciert OpenRouter selbst-lastabhängig und bevorzugt günstige Provider.

Der Auto-Router (model: "openrouter/auto") klassifiziert den Prompt in einen von rund 30 Task-Typen und wählt ein passendes Modell. Es fällt kein Zuschlag an, das gewählte Modell steht in der Antwort.

Kosten im Blick und Caching nutzen

Jede Antwort enthält usage.cost, also den echten Preis des Requests. Für Analyse gibt es GET /api/v1/generation?id=... und die Activity-Seite im Dashboard.

Prompt-Caching spart bei wiederholten Präfixen (System-Prompt, Tool-Definitionen) grob 75 bis 90 Prozent des Input-Preises. Bei OpenAI, DeepSeek oder Gemini passiert das automatisch; Anthropic verlangt einen cache_control-Marker. OpenRouter leitet Folgerequests bis 10 Minuten nach der letzten Nutzung an denselben Provider ("Sticky Routing"), damit der Cache auch trifft. Achte in der Antwort auf usage.prompt_tokens_details.cached_tokens und cache_discount: Bleibt der Wert 0, stimmt die Prompt-Struktur nicht.