Kostenlose OpenRouter-Modelle: Limits, Datenschutz und Fallbacks

Kurzfassung: OpenRouter nennt für kostenlose Modelle 50 Anfragen pro Tag. Nach dem Kauf von Guthaben im Wert von 10 US-Dollar steigt das Limit auf 1.000; in beiden Fällen gelten 20 Anfragen pro Minute.^[1] Der Guthabenkauf macht weder jedes Modell kostenlos noch klärt er dessen Datenschutz: Trainingsfreigaben für kostenlose und kostenpflichtige Modelle sind getrennt, und bei einem kostenpflichtigen Fallback zählt der Preis des tatsächlich verwendeten Modells.^[5][8]

Union Alpha brachte Leser zu OpenRouter, um ein geheimnisvolles Modell auszuprobieren. Seine Identität ist inzwischen bekannt. Die nächste nützliche Frage betrifft den Betrieb: Was passiert mit Kontingent, Daten und Rechnung, wenn der bisher bevorzugte Endpunkt ausfällt?

Die eigentliche Geschichte ist nicht die Null auf der Preisliste. Entscheidend sind die Entscheidungen hinter jeder Anfrage. Ein Prototyp kann auf eine Antwort warten. Eine Anwendung für Kunden braucht berechenbares Verhalten, wenn ein Kontingent erschöpft ist, ein Anbieter Anfragen ablehnt oder ein Fallback das Modell wechselt.

Titelbild: generierte redaktionelle Illustration von Anfragekontrollen, kein Screenshot von OpenRouter und keine Darstellung vermessener Infrastruktur.

Kostenlose Kontingente: Anfragen zählen, nicht Gespräche

OpenRouter veröffentlicht für die gewöhnliche Nutzung kostenloser Modelle folgende Limits. Sie beschreiben ein Kontingent, keine garantierte Anzahl erfolgreicher Antworten.^[1]

Die Limits-Dokumentation bezieht sich auf insgesamt gekauftes Guthaben, nicht auf den aktuell verbleibenden Kontostand. Sie nennt außerdem einen kleinen Spielraum an der Kaufgrenze für Rundungen und Aufladegebühren. Maßgeblich sollte deshalb das vom Konto gemeldete Limit sein, nicht eine Rückrechnung aus dem Zahlungsbeleg.^[2]

Prüfen Sie GET /api/v1/key: free_model_daily_requests meldet Verbrauch, Limit und verbleibende Anfragen für den aktuellen UTC-Tag. usage_daily misst Guthabenverbrauch, keine kostenlosen Anfragen. Aus is_free_tier allein lässt sich das geltende Anfragekontingent nicht ableiten.^[2]

Ein beispielhafter Agent mit fünf Modellaufrufen pro Aufgabe hätte ein Kontingent von 50 Anfragen nach zehn Aufgaben verbraucht, sofern keine weiteren Anfragen oder Fehler anfallen. Laut OpenRouters Kostenleitfaden verbrauchen auch fehlgeschlagene kostenlose Anfragen Kontingent. Ständige Wiederholungen gegen einen defekten Endpunkt können den Tagesvorrat deshalb aufbrauchen, ohne die Aufgabe zu erledigen.^[1]

Kapazitätsplanung: Versuche vor Arbeitsbeginn reservieren

Betrachten wir einen hypothetischen Ablauf mit vier Modellanfragen pro abgeschlossener Aufgabe. Jede Aufgabe erhält eine zusätzliche Anfrage zur Fehlerbehebung; zehn der täglich verfügbaren 50 Anfragen bleiben für manuelle Diagnose reserviert. Die übrigen 40 reichen für acht Aufgabenbudgets mit je fünf Versuchen, nicht für eine Zusage von acht erfolgreichen Aufgaben. Benötigt eine Aufgabe eine zweite Wiederholung, stoppt oder wartet sie, statt das Budget einer anderen Aufgabe zu verbrauchen.

Bei einem Kontingent von 1.000 Anfragen bleiben nach einer Reserve von 200 noch 800 übrig, genug für 160 gleiche Aufgabenbudgets. Das sind Planungsszenarien, kein gemessener Durchsatz. Sie setzen voraus, dass sämtliche Anfragen demselben Kontingent unterliegen und kein weiterer Anwendungsverkehr anfällt.

Das Minutenlimit bleibt eine eigene Grenze. Ein beispielhafter Scheduler könnte 16 geplante Aufrufe pro Minute zulassen und vier zur Fehlerbehebung reservieren, innerhalb der veröffentlichten Obergrenze von 20. Vier geplante Aufrufe je Aufgabe ergeben rechnerisch vier Aufgabenäquivalente pro Minute. Langsame Antworten, Anbieterkapazität und Abhängigkeiten können die Abschlüsse jedoch verringern. Die Warteschlangenlänge signalisiert Überlastung besser als eine grüne Guthabenanzeige.

Zählen Sie Versuche zentral über alle Worker hinweg. Wenn jeder Worker unabhängig freie Kapazität sieht und Arbeit startet, lässt sich ein gemeinsames Kontingent überbuchen. Reservieren Sie das Aufgabenbudget vor dem Start, geben Sie ungenutzte Reservierungen nach Abschluss frei und gleichen Sie Ihre Schätzung mit dem Kontozähler ab. Ein lokales Reservierungssystem ist Ihre Anwendungskontrolle, kein zusätzliches OpenRouter-Kontingent.

Guthaben: Eine Einzahlung kauft keine unbegrenzte Inferenz

Die Grenze von 10 US-Dollar ist eine Kaufbedingung für das höhere kostenlose Kontingent. Sie macht kostenpflichtige Modelle nicht kostenlos. OpenRouter zieht kostenpflichtige Nutzung von einem Guthaben in US-Dollar ab; beim Kauf fällt außerdem eine Plattformgebühr an. Prüfen Sie den tatsächlichen Gesamtbetrag im Bezahlvorgang.^[3]

Verwechseln Sie die Zugangsberechtigung nicht mit der Gültigkeit des Geldes. OpenRouters Kostenleitfaden behauptet, die Einzahlung verfalle nie. Die FAQ behalten dagegen das Recht vor, ungenutztes Guthaben nach einem Jahr verfallen zu lassen. Das widerspricht sich. Kaufen Sie kein Guthaben im Vertrauen auf eine unbegrenzt gültige Geldeinlage; prüfen Sie vorher die aktuellen Bedingungen.^[1][3]

Trennen Sie drei Budgets: kostenlose Anfragen, bezahlte Nutzung und Wiederholungsversuche der Anwendung. Ein Tokenpreis von 0 US-Dollar beschreibt nur einen Teil der Abrechnung. Kostenpflichtige Werkzeuge oder Ausweichmodelle brauchen eine eigene Prüfung. Unsere Empfehlung: Legen Sie die Ausgabenregeln ausdrücklich fest, bevor Sie den Durchsatz erhöhen.

Modellauswahl: Der kostenlose Router ist keine Qualitätsrangliste

openrouter/free wählt zufällig aus den verfügbaren kostenlosen Modellen, nachdem er nach benötigten Fähigkeiten wie Werkzeugaufrufen, Bildverständnis und strukturierten Ausgaben gefiltert hat. OpenRouter beschreibt ihn nicht als Auswahl des besten Modells für Ihre Aufgabe. Das Feld model in der Antwort nennt das tatsächlich verwendete Modell.^[4]

Das eignet sich für Erkundungen, bei denen Schwankungen akzeptabel sind. Ohne Protokollierung der zurückgegebenen Identität lässt sich daraus aber nicht ableiten, dass ein bestimmtes Modell einen Regressionstest bestanden hat. Wählen Sie für die Bewertung eines konkreten Modells gezielt dessen gelistete kostenlose Variante und prüfen Sie unterstützte Parameter sowie Kontextfenster.

Das Suffix :free bezeichnet eine Katalogvariante. Es ist kein Schalter, der jedes kostenpflichtige Modell kostenlos macht. Laut FAQ benötigen Katalogvarianten einen eigenen Eintrag. Auch die Verfügbarkeit kostenloser Modelle kann sich ändern.^[3][4] Ein gespeicherter Modellname ist keine langfristige Verfügbarkeitszusage.

Passende Fähigkeiten: Eine Antwort ist noch kein akzeptiertes Ergebnis

Definieren Sie vor der Freigabe eines Ausweichmodells den Mindestvertrag der Aufgabe: Eingabemodalität, erforderliche Werkzeugschnittstelle, Ausgabeschema, Kontextgröße, erlaubte Anbieter und Ausgabenobergrenze. Ein Modell für Textzusammenfassungen ersetzt nicht automatisch eines, das ein validiertes Objekt aus einem Bild extrahiert.

OpenRouter dokumentiert provider.require_parameters: true, um nur Anbieter zu verwenden, die alle übergebenen Parameter unterstützen.^[10] Betrachten Sie das als Routingfilter, nicht als Beweis korrekter Aufgabenerfüllung. Validieren Sie Ausgabeschema und Werkzeugargumente in Ihrer Anwendung. Prüfen Sie fehlende Felder, übergroße Eingaben, Ablehnungen und unterbrochene Übertragungen, bevor Sie den Ersatz akzeptieren.

Halten Sie für eine deterministische Bewertung einen kleinen Eingabesatz mit bekannten Abnahmekriterien bereit. Erfassen Sie angefordertes und tatsächlich verwendetes Modell getrennt. Verletzt das Ersatzmodell eine Anforderung, liefern Sie ein klar eingeschränktes Ergebnis oder stoppen Sie. Machen Sie aus einer erforderlichen strukturierten Antwort nicht stillschweigend Fließtext, nur weil das Ausweichmodell überhaupt reagiert hat.

Datenschutz: Training und Speicherung getrennt entscheiden

OpenRouter dokumentiert getrennte Trainingsfreigaben für kostenlose und kostenpflichtige Modelle. Prüfen Sie beide. Der Ausschluss von Anbietertraining und die Freigabe von OpenRouters eigener Protokollierung sind unterschiedliche Einstellungen.^[5]

Bei OpenRouter selbst setzt das Speichern von Eingaben und Antworten eine ausdrückliche Zustimmung voraus. Private Fehleranalyseprotokolle und die Freigabe zur Produktverbesserung sind getrennte Einstellungen, beide standardmäßig deaktiviert. Anfragemetadaten werden weiterhin gespeichert; die Dokumentation beschreibt außerdem eine anonyme Kategorisierung von Eingaben.^[6] „Keine standardmäßige Prompt-Protokollierung“ bedeutet nicht, dass nirgendwo etwas verarbeitet oder aufgezeichnet wird.

Bei Inferenzanbietern bedeutet ein Trainingsverzicht nicht automatisch einen Speicherverzicht. Die spezielle ZDR-Dokumentation von OpenRouter beschreibt provider.zdr: true als Beschränkung auf Endpunkte mit einer Zero-Data-Retention-Richtlinie. Aktivierte Plugins und Werkzeuge sind von dieser Zusage ausgenommen.^[7]

Die Dokumentation ist hier widersprüchlich: Die Übersicht zur Anbieterprotokollierung behauptet, es gebe keine Routingregeln auf Grundlage der Datenspeicherung. Die spezielle ZDR-Seite dokumentiert genau solche Regeln. Für die beschriebene Einstellung stützen wir uns auf die spezifische ZDR-Referenz, haben ihre Durchsetzung aber nicht unabhängig getestet. Prüfen Sie geeignete Endpunkte, bevor Sie vertrauliche Inhalte senden.^[5][7]

Datenentscheidungen: Die Grenze vor der Wiederholung festlegen

Die folgende Matrix ist unser Vorschlag für eine Prüfung, keine rechtliche Beurteilung oder Anbieterzertifizierung. Wenden Sie die tatsächlichen Datenregeln Ihrer Organisation auf jedes zulässige Ziel an.

Prüfen Sie Werkzeuge gesondert: Die Freigabe eines Inferenzendpunkts genehmigt nicht jeden Suchdienst oder jedes Werkzeug des Ablaufs. Prüfen Sie auch, was Ihre eigene Fehlerverfolgung speichert. Ein sorgfältig konfigurierter Anbieter kann einen Prompt in unbeschränkten Anwendungsprotokollen nicht zurückholen.

Halten Sie neben der Ausweichkonfiguration eine datierte Richtlinienentscheidung fest, einschließlich der Begründung für jedes erlaubte Ziel. Prüfen Sie sie erneut, wenn Route, Modell oder Dienstbedingungen wechseln. „Beim Ausprobieren war es kostenlos“ ist weder eine Datenklassifizierung noch eine Freigabe für die nächste Anfrage.

Fallbacks: Festlegen, was ein Ausfall kosten darf

Ein Anbieter-Failover versucht einen anderen Anbieter für dasselbe Modell. Ein Modell-Fallback kann dagegen das Modell wechseln. OpenRouters Array models legt Alternativen in einer Prioritätsreihenfolge fest. Unter anderem Ratenlimits, Ausfälle, Kontextfehler und Moderationsmeldungen können den Wechsel auslösen. Abgerechnet wird nach dem Modell, das die Anfrage letztlich beantwortet hat.^[8]

Eine praktikable Regel: Geben Sie die gesamte Ausweichliste frei, bevor Sie sie aktivieren. Ein rein kostenloses Experiment sollte ausschließlich überprüfte kostenlose Ziele enthalten. Eine Anwendung mit Ausgabenerlaubnis braucht ein ausdrückliches Budget und eine Bewertung des Ersatzmodells. Ein erfolgreicher Fallback beweist weder identische Antwortqualität noch gleiches Werkzeugverhalten oder gleiche Datenverarbeitung.

Diese Prüfungen folgen OpenRouters Referenzen zu Limits, Fehlern und Fallbacks. Ein negativer Kontostand kann selbst kostenlose Anfragen beeinträchtigen. Ein positiver Kontostand schließt eine Ablehnung wegen eines Ausgabenlimits nicht aus.^[2][8][9]

Begrenzte Wiederherstellung: Ein Ablauf für Störungen

Formulieren Sie die Fallback-Regeln zunächst auf Anwendungsebene. Zum Beispiel: zuerst das freigegebene kostenlose Hauptmodell versuchen; bei vorübergehendem Fehler eine genehmigte Alternative erlauben; keine kostenpflichtigen Ziele nutzen; Datenschutz- und Schemaanforderungen beibehalten; nach Ausschöpfen des Aufgabenbudgets stoppen. Das ist ein Regelvorschlag, nicht das Standardverhalten der Plattform.

Für eine Anwendung mit Ausgabenerlaubnis ergänzen Sie einen ausdrücklichen Zweig mit Aufgabenbudget und geprüfter Modellliste. Schätzen Sie die verbleibende Arbeit vor diesem Wechsel und gleichen Sie danach den tatsächlichen Verbrauch ab. Eine Tokenpreisgrenze allein deckelt keine Rechnung, wenn die Anwendung ständig weitere Anfragen sendet.

1. Bei steigenden Fehlerzahlen neue Aufträge pausieren. Bewahren Sie den ersten aussagekräftigen Fehler und die letzte erfolgreiche Route auf. Vermeiden Sie Hunderte Wiederholungen desselben gescheiterten Versuchs.
2. Den Fehler einordnen. Unterscheiden Sie erschöpfte Kontingente, Anbieterüberlastung, fehlendes Ausgabenbudget, ungültige Eingaben und unvollständige Datenströme. Ein Modellwechsel repariert nicht jede Kategorie.
3. Eine erlaubte Wiederherstellung wählen. Einen Wartehinweis beachten, eine unnötig große Anfrage verkleinern oder die freigegebene Alternative nutzen. Ursprüngliche Aufgaben-ID beibehalten und Zusatzversuch erfassen.
4. Validieren und abgleichen. Ersatzantwort prüfen, Modell und Kosten festhalten und anschließend die Aufgabenreservierung freigeben oder schließen. Eine Teilantwort wird nicht vollständig, nur weil die HTTP-Verbindung erfolgreich war.

Hat eine Werkzeugaktion möglicherweise bereits einen externen Zustand verändert, prüfen Sie diese Aktion vor der Wiederholung der gesamten Agentenschleife. Eine Modellantwort erneut anzufordern ist etwas anderes, als einen Kauf, eine E-Mail oder einen Datenbank-Schreibvorgang zu wiederholen. Eine Vorgangskennung auf Anwendungsebene kann Wiederherstellung von doppelter Arbeit unterscheiden.

Die unbequeme Wahrheit: Auch kostenlose Inferenz braucht einen disziplinierten Betrieb. Nutzen Sie sie, um herauszufinden, für welche Aufgaben sich eine Zahlung lohnt. Halten Sie fest, welches Modell geantwortet hat, stoppen Sie nutzlose Wiederholungen und behandeln Sie Datenschutz als Teil des Routings. Der stärkste Prototyp ist der, dessen Fehlerverhalten Sie bereits verstehen.

Quellen: Dokumentation und Anbieterangaben

Die mit Schlüsselquelle markierten Einträge tragen die zentralen Aussagen. Alle undatierten Dokumentationsseiten wurden am 20. September 2026 geprüft.

Zuletzt aktualisiert: 20. September 2026