Am 1. Oktober 2026 hat OpenRouter im offiziellen Blog ein Drei-Schritte-Framework zur Auswahl von Modellen für Agenten-Aufgaben veröffentlicht. Der Ausgangspunkt ist eine kontraintuitive These: Wer nach der Rangliste wählt, zahlt Frontier-Preise für Platzierungen, die er nicht braucht. Die richtige Frage lautet nicht „welches Modell punktet am höchsten", sondern „welches Modell ist das günstigste, das gerade gut genug ist".
Warum Ranglisten die Agenten-Modellauswahl irreführen
Eine Rangliste mittelt die Ergebnisse eines Modells über Aufgaben, die mit den eigenen nichts zu tun haben. Die eigenen Agenten-Aufgaben sind meist eng: ein Ticket triagieren, ein Feld extrahieren, bei Unsicherheit an einen Menschen eskalieren. Ob ein günstiges Modell bei einer engen Aufgabe die Genauigkeit eines Frontier-Modells erreicht, ist eine Messfrage — und keine Rangliste nimmt einem diese Messung ab.
Auch lässt sich ein Agent nicht wie ein einzelner Chat-Turn abrechnen. Ein Gespräch wird einmal berechnet; jeder Tool-Aufruf, jeder Zwischenschritt und jeder Retry eines Agenten kostet Geld, sodass eine Drei-Schritte-Schleife den Token-Preis mindestens dreimal zahlt. Wer nach dem Ranglisten-Ersten auswählt, zahlt den Frontier-Preis dreimal für eine Aufgabe, die ein günstigeres Modell genauso gut erledigt hätte.
Wie die drei Schritte in der Praxis funktionieren
Schritt eins: eine Qualitätsgrenze für die Aufgabe festlegen. Aufgaben, bei denen eine falsche Antwort zur Haftung wird — Compliance, Medizin, Rechtsprüfung — bekommen eine hohe Grenze; Support mit hohem Volumen, bei dem das Gesamtergebnis zählt, kommt womöglich mit 90 % automatisch gelöst und 10 % sauber eskaliert aus. Bei latenzkritischer Arbeit wie Betrugserkennung oder Live-Chat ist Geschwindigkeit die dritte harte Randbedingung, und ein Modell, das günstig und genau, aber zu langsam ist, fliegt zuerst raus.
Schritt zwei: auf den eigenen Beispielen messen. Je einen Vertreter pro Preisklasse wählen — günstig, Mittelklasse, Frontier —, 20 bis 50 echte Beispiele aus dem eigenen Geschäft durch jeden laufen lassen, mit einem einheitlichen Bewertungsmaßstab punkten und die Kosten durch die Punktzahl teilen, um „Kosten pro Qualitätspunkt" zu erhalten. Die Kosten nicht aus der Preisliste schätzen, sondern das Feld usage.cost in jeder Antwort lesen — das ist das, was die Plattform tatsächlich abgerechnet hat.
Schritt drei: das günstigste Modell wählen, das die Grenze mit Spielraum übertrifft. Der Spielraum zählt, weil Punktzahlen driften: Modell-Updates und Verschiebungen im eigenen Traffic bewegen die Zahlen. Die Praxis: mehrere Runden laufen lassen, beobachten, wie stark die Punktzahl zwischen den Läufen schwankt, und verlangen, dass der Gewinner die Grenze um mehr als diese Schwankung übertrifft.
OpenRouter gibt ein durchgerechnetes Beispiel: Bei einer Grenze von 85 % scheidet GPT-5.6 Luna mit 82 Punkten sofort aus — unter der Grenze nützt auch der niedrigste Preis nichts; Gemini 3.7 Flash übertrifft mit 89 Punkten und wird mit 1,09 US-Dollar pro 1.000 Anfragen gewählt; Claude Opus 5 erreicht 97 Punkte, kostet aber 7,25 US-Dollar pro 1.000 Anfragen — ein Luxus, den die Aufgabe nicht verlangt hat. Preise und Punktzahlen sind illustrativ; in der Praxis die eigenen Messwerte verwenden.
Wo die Grenzen dieser Methode liegen
Das Framework verwandelt die Modellauswahl von Bauchgefühl in Messung, ruht aber auf drei Prämissen. Erstens: Die Qualitätsgrenze legt man selbst fest — liegt dieses subjektive Urteil daneben, ist alles Folgende falsch. Zweitens: Eine Messung gilt nur am Tag der Messung — eine neue Modellversion oder Preisänderung kann das Ergebnis überholen lassen, also erneut laufen lassen. Drittens: Es regelt den Kosten-Qualitäts-Tradeoff, nicht die Frage, ob man überhaupt einen Agenten einsetzen sollte — eine schlecht zerlegte Aufgabe verschwendet Geld, egal wie günstig das Modell ist.
