OPENROUTER: WARUM DIE AUTOMATISCHE MODELL-ROUTE ZUR FALLE WIRD

Das Wichtigste

OpenRouters automatisches Routing zwischen verschiedenen Backend-Providern kann dazu führen, dass identische API-Aufrufe unterschiedliche Ergebnisse liefern. Simon Willison verweist auf eine Analyse von Mohamed Moustafa, die zeigt, wo genau das Problem liegt.

Was ist passiert?

OpenRouter wirbt damit, Anfragen automatisch an den güstigsten verfügbaren Provider weiterzuleiten und Fallbacks zu übernehmen, wenn ein Anbieter ausfällt. Ein einziger API-Endpunkt reicht, der Rest passiert im Hintergrund.

Genau das ist laut Moustafa das Problem. Verschiedene Provider setzen unterschiedliche Serving-Software mit unterschiedlichen Optimierungen ein. Der gleiche Modell-Endpunkt kann sich je nach Backend also unterschiedlich verhalten.

Besonders heikel: Manche Provider unterstützen bei vermeintlich vision-fähigen Modellen gar keine Bildverarbeitung. Auch die Verarbeitung von Reasoning-Effort-Parametern unterscheidet sich zwischen Anbietern, was bei komplexeren Prompts zu inkonsistenten Ergebnissen führt.

Warum ist das relevant?

Wer OpenRouter für produktive Anwendungen nutzt, testet sein Setup womöglich gegen einen Provider, bekommt im Live-Betrieb aber einen anderen zugewiesen. Das macht Ergebnisse schwer reproduzierbar, gerade bei Vision-Tasks oder Reasoning-intensiven Prompts kann das zu stillen Fehlern führen, die im Monitoring nicht sofort auffallen.

Für Teams, die auf konsistente Modell-Antworten angewiesen sind (etwa in regulierten Branchen oder bei Agenten-Workflows), ist das kein Detail, sondern ein Zuverlässigkeitsrisiko.

Die Lösung

OpenRouter bietet mit der provider.only-Option einen Hebel, um das Routing auf einen bestimmten Anbieter festzulegen. Wer wissen will, welche Provider für ein Modell überhaupt zur Auswahl stehen, findet das über die /endpoints-Methode der API.

Take-Away

Wer OpenRouter im Produktivbetrieb einsetzt, sollte das automatische Routing nicht blind vertrauen. Provider über /endpoints prüfen und bei kritischen Anwendungsfällen mit provider.only fixieren, das erspart böse Überraschungen bei Vision-Tasks oder Reasoning-Parametern.