OpenRouter ist Entwicklerinfrastruktur, die über 500 Modelle von mehr als 80 Anbietern hinter einer einzigen OpenAI-kompatiblen API bündelt. Sie klassifiziert jede Anfrage zur Modellwahl, verteilt die Last über Anbieter, wechselt bei Ausfällen automatisch und reicht Anbieterpreise ohne Aufschlag durch.
Hast du dieses Tool genutzt? Bewerte es
Hast du dieses Tool genutzt? Bewerte es
OpenRouter ist Infrastruktur, die zwischen Ihrer Anwendung und den KI-Modellanbietern sitzt, die Sie nutzen möchten. Die eigene Positionierung ist knapp: eine einheitliche Schnittstelle für jedes Modell, verbunden mit dem Versprechen besserer Preise, besserer Verfügbarkeit und keiner Abonnements. In der Praxis heißt das: Sie integrieren einmal gegen einen einzigen Endpunkt und erhalten Zugang zu einem Katalog, für den sonst Dutzende separate Anbieterkonten, Entwicklungskits, Abrechnungsbeziehungen und Fehlerbehandlungspfade nötig wären.
Die Dokumentation formuliert den Nutzen ohne Schmuck: Zugriff auf hunderte KI-Modelle über einen einzigen API-Endpunkt, automatische Behandlung von Ausweichpfaden und die Wahl einer kosteneffizienten Option je Anfrage. Diese zwei Sätze enthalten das ganze Produkt: Bündelung, dazu die Intelligenz darüber, welches Modell und welcher Anbieter einen bestimmten Aufruf bedienen sollte.
Es lohnt sich, die Zielgruppe klar zu benennen, denn OpenRouter wird häufig falsch einsortiert. Die Website beherbergt tatsächlich eine Chat-Oberfläche im Browser, weshalb manche Verzeichnisse das Produkt neben Chat-Anwendungen für Endverbraucher einordnen. Das ist ein Missverständnis. Diese Seite existiert, damit Entwicklerinnen und Entwickler Modelle ausprobieren und Prompts debuggen können; das Produkt selbst ist eine API-Schicht mit Abrechnung, Routing und Beobachtbarkeit. Wer keinen Code schreibt und keine Anwendung so konfiguriert, dass sie eine API aufruft, würde dieses Werkzeug nicht direkt nutzen. Wer es tut, findet hier die Antwort auf ein Problem, das rasch schmerzhaft wird: Jeder Modellanbieter hat eigenes Entwicklungskit, eigene Authentifizierung, eigene Ratenbegrenzungen und eigene Ausfälle.
Betrieben wird der Dienst von OpenRouter, Inc., eingetragen in der Madison Avenue 169 in New York, wobei die Bedingungen dem Recht des Staates New York unterliegen. Gegründet wurde das Unternehmen von Alex Atallah, zuvor Mitgründer von OpenSea, und ein Investorenkommentar fasst das Angebot als eine API, eine zentrale Abrechnung zusammen. Diese Formel erfasst die zweite Hälfte des Werts: Ausgaben über viele Anbieter hinweg auf einem Konto zu bündeln, statt ein Dutzend Rechnungen abzugleichen.
Überlegen Sie, was die direkte Anbindung von fünf Modellanbietern bedeutet: fünf API-Schlüssel im Wechsel, fünf Entwicklungskits auf Stand zu halten, fünf Preisseiten zu beobachten, fünf Statusseiten zu prüfen und eigene Ausweichlogik, wenn einer schwächelt. Multipliziert mit dem Tempo, in dem neue Modelle erscheinen, wird Integrationspflege zu dauerhaften Entwicklungskosten. OpenRouter verwandelt diese wiederkehrenden Kosten in eine einzige Abhängigkeit. Ob sich dieser Tausch lohnt, ist die eigentliche Bewertungsfrage und wird im Abschnitt zu den Einschränkungen direkt behandelt.
Das markanteste Merkmal ist die automatische Modellauswahl, und ihr Mechanismus ist ungewöhnlich genug, um ihn genau zu beschreiben. Der Router ordnet jeden Prompt zunächst einem von rund dreißig fein unterteilten Aufgabentypen zu — Kategorien wie Code-Fehlersuche, mehrstufige Agentenplanung, Wissensfragen, Mathematik oder Kundenbetreuung. Die Einordnung geschieht im Durchlauf und laut Dokumentation ohne dass Prompts aufbewahrt werden müssen.
Im zweiten Schritt weicht das Verfahren vom üblichen Routing ab. Statt auf eine feste Qualitätsrangliste zu setzen, betrachtet der Router, wofür die Gemeinschaft bei diesem Aufgabentyp tatsächlich Geld ausgibt, gemessen über ein rollierendes Fenster von sieben Tagen. Das Unternehmen vergleicht dies mit einem Marktindex: Verschiebt sich die Nutzung zu einem neu erschienenen Modell, das etwa beim Debuggen besser abschneidet, folgt das Routing der Ausgabe automatisch. Zwei Kennungen betreiben dieses System, der stabile Pfad openrouter/auto und der Vorabpfad openrouter/auto-beta.
Die Modellwahl löst nur die halbe Aufgabe, denn ein einzelnes Modell wird oft von mehreren Anbietern mit unterschiedlichen Preisen, Geschwindigkeiten und Zuverlässigkeiten bereitgestellt. Standardmäßig werden Anfragen über die besten Anbieter verteilt, um die Verfügbarkeit zu maximieren. Über diesen Standard hinaus lässt sich das Routing umfangreich über ein provider-Objekt im Anfragekörper konfigurieren, mit Feldern für Anbieterreihenfolge, Erlaubnis von Ausweichpfaden, Anforderung vollständiger Parameterunterstützung, Datenerhebungsrichtlinie, Beschränkung auf Nichtspeicherung, Zulassungs- und Ausschlusslisten, Filter nach Quantisierungsstufe und Preisobergrenzen.
Für Entwicklungsteams zählen Sortierung und Schwellenwerte am meisten. Sie können Anbieter nach Preis, Durchsatz oder Latenz sortieren, einen gewünschten Mindestdurchsatz oder eine Höchstlatenz mit Perzentilgrenzen festlegen und einen Höchstpreis für die Anfrage setzen. Aus einer vagen Präferenz wie „günstig, aber nicht langsam" wird so ein ausdrücklicher und durchsetzbarer Anfrageparameter.
Zuverlässigkeit ist häufig das Argument, das über die Einführung entscheidet. Das dokumentierte Verhalten ist eindeutig: Gibt ein Anbieter einen Fehler zurück, wechselt die Plattform automatisch zum nächsten. Das geschieht transparent, Ihre Anwendung braucht also keine eigene Wiederhol- und Umleitungslogik. Für Produktivsysteme, in denen der Ausfall eines einzelnen Anbieters sonst zu einem für Nutzende sichtbaren Fehler führen würde, rechtfertigt genau dieses Merkmal die Abhängigkeit.
Die Plattform bietet die rohe API für volle Kontrolle in jeder Sprache, typsichere Client-Kits und ein Agentenkit für Systeme mit Werkzeugaufrufen, Schleifen und Zustandsverwaltung. Die Abstufung ist sinnvoll: Ein Skript, das den Endpunkt mit curl anspricht, muss nichts installieren; eine typisierte Anwendung profitiert vom Kit; und ein agentisches System mit Werkzeugaufrufen und Zustandsverwaltung erhält eine eigens gebaute Schicht statt selbstgestrickter Orchestrierung.
Der Funktionsumfang reicht weit über die Modellwahl hinaus. Die Dokumentation behandelt Antwort-Caching, Prompt-Caching, Werkzeugaufrufe, strukturierte Ausgaben, Nachrichtentransformationen, Streaming, Stapelverarbeitung, eigene Klassifikatoren, Leitplanken, Servicestufen, Voreinstellungen und eine Absicherung gegen leere Vervollständigungen. Auf Teamseite gibt es Arbeitsbereiche mit Budgets, einmalige Anmeldung, SCIM-Gruppenzuordnung und Auswertungen. Das ist der Unterschied zwischen einem Hobby-Proxy und etwas, worauf eine Organisation standardisieren kann.
Der Hauptfall ist schlicht: Sie bauen ein Produkt, das ein Sprachmodell aufruft, und wollen sich nicht unumkehrbar an einen Anbieter binden. Die Integration über OpenRouter macht einen Modellwechsel zu einer Änderung einer Zeichenkette statt zu einem Umbau. Erscheint ein besseres oder günstigeres Modell, bewerten Sie es, ohne zuvor ein Integrationsprojekt aufzusetzen.
Verschiedene Aufgaben verdienen verschiedene Modelle, und Spitzenpreise für einfache Klassifikation zu zahlen ist Verschwendung. Da Preise durchgereicht werden, Anbieter nach Preis sortierbar sind und pro Anfrage eine Obergrenze gilt, können Teams günstige Aufgaben zu günstigen Modellen leiten und teure Modelle für Arbeit reservieren, die sie braucht — alles innerhalb einer Abrechnungsbeziehung.
Wo Modellaufrufe auf einem für Nutzende kritischen Pfad liegen, verwandelt automatisches Ausweichen zwischen Anbietern eine harte Abhängigkeit in eine weiche. Zusammen mit Durchsatz- und Latenzpräferenzen lassen sich damit belastbare Serviceziele stützen, ohne eine eigene Routing-Schicht zu bauen.
Teams, die Modelle für eine bestimmte Aufgabe vergleichen, können dieselben Prompts über eine Schnittstelle auf viele Modelle anwenden. Öffentliche Ranglisten und Anwendungs-Bestenlisten liefern ein zweites Signal: was andere Entwickelnde bei vergleichbarer Arbeit tatsächlich produktiv einsetzen.
Agentische Lasten verstärken jede Schwäche einer Ein-Anbieter-Konfiguration: Sie erzeugen viele Aufrufe, brauchen Werkzeugaufrufe, und ein Fehler mitten im Lauf verwirft die gesamte Ablaufkette. Das Agentenkit samt automatischem Ausweichen zielt genau auf diese Arbeitsform.
Für regulierte Organisationen unterstützt die Plattform ein Routing innerhalb der Region für die Europäische Union und die Vereinigten Staaten für Unternehmenskunden, ergänzt um die Beschränkung auf Endpunkte ohne Datenspeicherung und um Datenrichtlinien auf Anbieterebene. Diese Kombination erlaubt es, Compliance-Anforderungen als Anfragekonfiguration auszudrücken statt als Verhandlung mit einem Anbieter.
Die Nutzung läuft über vorausbezahltes Guthaben. Neue Konten erhalten ein kleines kostenloses Kontingent zum Testen, und Guthaben wird vor dem Produktiveinsatz über die Plattform gekauft.
Erstellen Sie einen Schlüssel im Dashboard. Da ein einzelner Schlüssel jedes Modell des Katalogs erreicht, verdient die Schlüsselverwaltung dieselbe Sorgfalt wie jede hochprivilegierte Zugangsberechtigung — die Bedingungen machen Sie allein für die Vertraulichkeit Ihrer Kontodaten verantwortlich.
Das ist meist der kürzeste Schritt. Die API setzt die OpenAI-Spezifikation um, Sie senden also gewöhnliche HTTP-Anfragen an den Endpunkt für Chat-Vervollständigungen; in den meisten Fällen genügt es, in einer bestehenden Integration Basis-URL und Schlüssel zu ändern.
Entscheiden Sie, ob Sie ein bestimmtes Modell benennen oder an den automatischen Router abgeben. Ein benanntes Modell bringt Bestimmtheit; der automatische Router bringt Anpassung an eine sich wandelnde Modelllandschaft. Viele Teams tun beides — feste Modelle auf ausgabesensiblen Pfaden, automatisches Routing für allgemeine Arbeit.
Wenn Sie Vorgaben haben, drücken Sie sie ausdrücklich aus, statt Standardwerte zu übernehmen. Setzen Sie Preisobergrenzen zur Kostensteuerung, Latenz- oder Durchsatzschwellen für nutzerseitige Pfade und Beschränkungen zur Datenerhebung oder Nichtspeicherung, wo Compliance es verlangt. Das sind Parameter je Anfrage, verschiedene Codepfade können also verschiedene Regeln tragen.
Prüfen Sie, ob das Ausweichen bei Ihrer Konfiguration wie erwartet greift, insbesondere wenn Sie die Anbieterliste eingeengt haben. Zu starke Einschränkung verkleinert den Pool, auf den ausgewichen werden kann, und schwächt still den Zuverlässigkeitsgewinn, dessentwegen Sie die Plattform eingeführt haben.
Verfolgen Sie mit den Auswertungen im Dashboard den Verbrauch nach Modell und Anwendung. Da die Kosten je Token im Katalog um Größenordnungen schwanken, kann eine Routing-Änderung die Ausgaben deutlich verschieben. Behandeln Sie Überwachung daher als Teil der Integration, nicht als Nachgedanken.
Setzen Sie einen Höchstpreis je Anfrage. Der Parameter max_price ist die einfachste Sicherung gegen die unerwartete Auswahl eines teuren Modells. Gerade auf automatisch gerouteten Pfaden verwandelt er offene Kosten in begrenzte.
Passen Sie die Routing-Strategie dem Codepfad an. Fixieren Sie Modelle dort, wo gleichbleibende Ausgaben zählen — ein auf ein Modell abgestimmter Prompt kann sich auf einem anderen anders verhalten. Nutzen Sie automatisches Routing, wo die Aufgabe allgemein ist und Anpassung an einen bewegten Markt mehr wert ist als Bestimmtheit.
Engen Sie die Anbieterliste nicht zu stark ein. Die Verengung auf einen bevorzugten Anbieter stellt genau den Einzelfehlerpunkt wieder her, dem Sie entkommen wollten. Erlauben Sie Ausweichpfade, sofern keine konkrete Compliance-Regel dagegen steht.
Drücken Sie Datenrichtlinien im Code aus, nicht in einem Dokument. Muss Ihre Last Speicherung vermeiden, setzen Sie die Nichtspeicherungsbeschränkung und die Erhebungsrichtlinie in der Anfrage. Eine konfigurierte Vorgabe ist durchsetzbar, eine niedergeschriebene Absicht nicht.
Nutzen Sie kostenlose Modelle zur Bewertung, nicht produktiv. Die Dokumentation ist deutlich: Kostenlose Modelle haben niedrige Ratenbegrenzungen und eignen sich in der Regel nicht für den Produktivbetrieb. Sie sind eine Testerleichterung.
Prüfen Sie die Plugin-Kennung beim Konfigurieren des automatischen Routings. Einstellungen unter der Kennung des jeweils anderen Pfades werden angenommen, aber stillschweigend ignoriert — ein Fehlermodus ohne Fehlermeldung, während Modellbeschränkungen und Kostenstufen leise wirkungslos bleiben.
Kennzeichnen Sie Ihre Anwendung, wenn Sie Sichtbarkeit wollen. Die optionalen Zuordnungs-Header platzieren Ihre Anwendung auf den öffentlichen Ranglisten, was der Auffindbarkeit hilft, wenn Sie etwas für die Öffentlichkeit bauen.
Budgetieren Sie vor dem Hochskalieren. Arbeitsbereichsbudgets und Auswertungen existieren, weil Tokenausgaben nicht linear mit der Nutzung wachsen. Konfigurieren Sie Grenzen vor einer Lastspitze und nicht nach einer Rechnung.
Anwendungsentwickelnde, die Sprachmodelle einbinden, sind das Kernpublikum — alle, die sonst Integrationen gegen mehrere Modell-APIs schreiben und pflegen müssten.
Teams, die Inferenzkosten optimieren, profitieren von durchgereichten Preisen samt Routing-Steuerung, die Abwägungen zwischen Kosten und Qualität je Anfrage statt als globalen Kompromiss erlauben.
Ingenieurinnen und Ingenieure für Produktivzuverlässigkeit erhalten automatisches Ausweichen über Anbieter hinweg, das intern schwer und mühsam gut zu bauen ist.
Wer Agenten baut, wird vom Agentenkit und von der Robustheit bedient, die mehrstufige Lasten verlangen.
Unternehmen mit Governance-Anforderungen werden über Arbeitsbereiche, einmalige Anmeldung, SCIM, regionales Routing und Datenrichtliniensteuerung adressiert.
Forschende und Bewertende im KI-Bereich können viele Modelle über eine Schnittstelle vergleichen, ohne bei jedem Anbieter ein Konto anzulegen.
Für wen es nichts ist: für Endnutzende, die einen Chat-Assistenten suchen. Zwar gibt es eine Chat-Oberfläche auf der Website, doch dies ist Entwicklerinfrastruktur, und ihre Nutzung setzt Code oder eine konfigurierte Anwendung voraus. Wer ein fertiges Verbraucherprodukt will, sollte ein Verbraucherprodukt nutzen. Teams, die sich per Unternehmensvertrag auf einen Anbieter festgelegt haben, dürften den Zusatznutzen dieser Schicht ebenfalls gering finden.
OpenRouter wird als Web-API bereitgestellt, die eigentliche Plattformfrage betrifft daher nicht das Betriebssystem, sondern die Integrationsfläche. Die API setzt die OpenAI-Spezifikation am Endpunkt für Chat-Vervollständigungen um, sodass jede Sprache mit HTTP-Client sie nutzen kann und bestehender Code in der Regel mit geänderter Basis-URL funktioniert.
Offiziell gepflegte Integrationswege umfassen die rohe API, typisierte Client-Kits und ein Agentenkit. Darüber hinaus bietet die Dokumentation eigene Anleitungen für gängige Entwicklungsrahmen: auf der Orchestrierungsseite LangChain und Mastra, auf der Frontend- und Anwendungsseite Vercel AI SDK sowie TanStack AI, für typisierte Backends PydanticAI, für Beobachtbarkeit Langfuse, für Echtzeitsprache LiveKit, dazu Migrationshinweise von den Kits von OpenAI und Anthropic sowie Anbindungswege für Entwicklungs- und Automatisierungsumgebungen wie Replit, Xcode und Zapier. Das ist ein nützliches Signal: Es handelt sich um erstseitig dokumentierte Integrationen, nicht um Behauptungen aus der Gemeinschaft.
Die auf der Startseite veröffentlichten Größenangaben nennen mehr als zweihundert Billionen Token monatlich, über zehn Millionen Nutzende weltweit, mehr als achtzig Anbieter und über fünfhundert Modelle. Behandeln Sie diese als Angaben des Anbieters und als Momentaufnahme: Ein Investorenkommentar aus einer anderen Periode nennt deutlich abweichende Zahlen, was zeigt, dass sich diese Werte schnell bewegen und live geprüft statt aus einem Artikel zitiert werden sollten, auch aus diesem.
Zu den Funktionen für Teams und Unternehmen zählen Arbeitsbereiche mit Budgets, einmalige Anmeldung, SCIM-Gruppenzuordnung und für Unternehmenskunden Routing innerhalb der Europäischen Union und der Vereinigten Staaten.
Das Preismodell ist der am häufigsten missverstandene Aspekt von OpenRouter und ungewöhnlich genug, um es genau zu benennen.
Auf Inferenz wird kein Aufschlag erhoben. Die Dokumentation ist ausdrücklich: Die Preise der zugrunde liegenden Modellanbieter werden ohne jeden Aufschlag durchgereicht, Sie zahlen also denselben Satz wie im direkten Geschäft mit dem Anbieter. Die Kosten je Token entsprechen damit dem, was der Anbieter verlangt. Da diese Sätze über einen Katalog von hunderten Modellen stark schwanken und sich mit den Preisanpassungen der Anbieter ändern, wird hier keine konkrete Zahl je Token genannt — prüfen Sie die aktuellen Sätze auf der Modellseite.
Der Umsatz stammt aus dem Guthabenkauf. Eine Gebühr fällt beim Kauf von Guthaben an, nicht bei Inferenzaufrufen. Das Unternehmen beschreibt sie als geringe Gebühr und betont erneut, dass Anbieterpreise nie erhöht werden. Der genaue Prozentsatz wird auf der Website dynamisch dargestellt und nicht als abrufbarer Seitentext, prüfen Sie den aktuellen Wert daher beim Kauf.
Guthaben ist vorausbezahlt, mit festgelegten Grenzen. Käufe reichen von mindestens fünf bis höchstens fünfundzwanzigtausend Dollar je Transaktion. Zahlungen über Stripe werden in US-Dollar abgerechnet, Zahlungen über Coinbase laufen über eine Krypto-Wallet, und eine automatische Aufladung kann das Guthaben auffüllen, sobald es eine von Ihnen gesetzte Schwelle unterschreitet.
Eigene Anbieterschlüssel folgen einer eigenen Rechnung. Wenn Sie direkte Anbieterverträge halten, können Sie sie über die Plattform nutzen. Dazu gehört ein vom Tarif abhängiges kostenloses Kontingent, gemessen an den Inferenzkosten zum Listenpreis und nicht an der Zahl der Anfragen — ein wichtiger Unterschied, denn teure Aufrufe verbrauchen das Kontingent schneller als viele günstige. Nutzung darüber hinaus zieht eine anteilige Gebühr nach sich, die vom Guthaben abgezogen wird.
Kostenlosen Zugang gibt es, aber bewusst begrenzt. Neue Konten erhalten ein kleines kostenloses Kontingent, und der Katalog enthält kostenlose Modelle. Diese haben niedrige tägliche Anfragegrenzen, und die Dokumentation nennt sie in der Regel ungeeignet für den Produktivbetrieb. Bemerkenswert ist, dass die Ratengrenze kostenloser Modelle mit gekauftem Guthaben steigt, zahlende Konten also höhere kostenlose Obergrenzen erhalten.
Erstattungen sind eng gefasst. Ungenutztes Guthaben kann innerhalb von vierundzwanzig Stunden nach der Transaktion erstattet werden; danach wird ungenutztes Guthaben nicht mehr erstattet. Zahlungen in Kryptowährung sind überhaupt nicht erstattungsfähig. Kaufen Sie in Schritten, die Sie voraussichtlich verbrauchen.
Kein Abonnement. Das Versprechen der Startseite, ohne Abonnement auszukommen, trifft für das Standardprodukt zu: Sie zahlen für die Nutzung statt einer wiederkehrenden Plattformgebühr, Unternehmensvereinbarungen werden gesondert behandelt.
Der Vergleichskreis hängt davon ab, welchen Teil des Nutzens Sie ersetzen.
Ehrliches Fazit: OpenRouter konkurriert über Katalogbreite, Routing-Tiefe und eine Preisstruktur ohne Aufschlag. Wer dauerhaft ein Modell eines Anbieters nutzt, fährt direkt einfacher. Wo die Modellwahl eine fortlaufende Entscheidung ist, verdient diese Schicht ihren Platz.
Sie fügen Ihrem kritischen Pfad eine Abhängigkeit hinzu. Jeder Inferenzaufruf läuft über einen Dritten. Das erkauft Widerstandsfähigkeit gegen Ausfälle einzelner Anbieter, führt aber die Plattform selbst als möglichen Fehlerpunkt ein. Wo Modellaufrufe tragend sind, sollte dieser Tausch eine bewusste Architekturentscheidung sein.
Ein zusätzlicher Latenzsprung ist unvermeidbar. Der Weg über eine Zwischenschicht erzeugt gegenüber dem Direktaufruf zusätzlichen Netzaufwand. Das Unternehmen arbeitet daran, ihn klein zu halten, und Präferenzsteuerungen existieren, doch der Sprung ist real und wirkt sich bei engen interaktiven Schleifen aus.
Guthaben ist vorausbezahlt und das Erstattungsfenster kurz. Ungenutztes Guthaben ist nach vierundzwanzig Stunden nicht mehr erstattungsfähig, Kryptozahlungen nie, und die Bedingungen halten fest, dass Guthaben kein gesetzliches Zahlungsmittel ist. Beim Löschen des Kontos verfällt verbleibendes Guthaben.
Stille Konfigurationsfehler sind möglich. Die falsche Plugin-Kennung beim automatischen Routing ist das deutlichste Beispiel: Falsche Einstellungen werden angenommen, aber stillschweigend ignoriert, sodass Modellbeschränkungen und Kostenstufen ohne Fehlermeldung wirkungslos bleiben können. Prüfen Sie die Wirkung, statt sie vorauszusetzen.
Kostenlose Modelle sind keine Produktivstufe. Niedrige Ratengrenzen und der ausdrückliche Hinweis auf mangelnde Eignung für den Produktivbetrieb bedeuten, dass der kostenlose Katalog allein der Bewertung dient.
Der Umgang mit Daten ist konfigurierbar, also Ihre Verantwortung. Der Standardwert der Erhebungsrichtlinie erlaubt Anbieter, die Daten speichern könnten. Routing ohne Speicherung und Richtlinienbeschränkungen sind verfügbar, müssen aber gesetzt werden. Ein Team, das strengen Umgang als Standard annimmt, könnte sich über die eigene Lage irren.
Nutzungsregeln sind durchsetzbare Vertragsklauseln. Die Bedingungen untersagen illegale Nutzung, falsche Identitätsangaben, das Auslesen von Inhalten, das Umgehen von Sicherheitsfunktionen und nicht genehmigte gegnerische Tests an Modellen. Forschungsteams, die solche Tests planen, sollten diese Klausel vorab lesen.
Vom Anbieter berichtete Kennzahlen unterscheiden sich je Quelle. Modell- und Anbieterzahlen sowie Tokenvolumen weichen zwischen Startseite und Drittartikeln verschiedener Zeiträume voneinander ab. Behandeln Sie jede konkrete Zahl als zeitabhängig.
Modellverhalten ist nicht einheitlich. Ein auf ein Modell abgestimmter Prompt kann sich auf einem anderen anders verhalten, automatisches Routing kann die Ausgabemerkmale also verändern. Wo Konstanz zählt, fixieren Sie das Modell.
Es ist Entwicklerinfrastruktur. Das Produkt ist eine API, die Ihre Anwendung aufruft, samt Routing, Abrechnung und Beobachtbarkeit darum herum. Eine Chat-Oberfläche existiert auf der Website zum Ausprobieren von Modellen und Debuggen von Prompts, weshalb manche Verzeichnisse falsch einordnen, doch sinnvoll nutzen lässt sich OpenRouter nur mit Code oder einer konfigurierten Anwendung.
Nein. Die Dokumentation hält fest, dass Anbieterpreise ohne Aufschlag durchgereicht werden und Sie denselben Satz zahlen wie im Direktgeschäft. Der Umsatz stammt aus einer Gebühr beim Guthabenkauf, nicht aus der Inferenz.
Ein leichter Klassifikator ordnet Ihren Prompt einem von rund dreißig fein unterteilten Aufgabentypen zu, danach reiht der Router Modelle danach, wie viel die Gemeinschaft für diesen Aufgabentyp in einem rollierenden Sieben-Tage-Fenster tatsächlich ausgegeben hat. Es verhält sich wie ein Marktindex und verschiebt sich zu Modellen, die für diese Art Arbeit reale Verbreitung gewinnen.
Meist nicht. Die API setzt die OpenAI-Spezifikation am Endpunkt für Chat-Vervollständigungen um, eine bestehende Integration läuft daher üblicherweise nach Änderung von Basis-URL und Schlüssel. Typisierte Client-Kits und ein Agentenkit stehen bereit, wenn Sie mehr als rohes HTTP möchten.
Die Plattform weicht automatisch auf den nächsten Anbieter aus, transparent für Ihre Anwendung. Das ist das Kernargument für Zuverlässigkeit: Ihr Code braucht keine eigene Wiederhol- und Umleitungslogik, um den Ausfall eines Anbieters zu überstehen.
Neue Konten erhalten ein kleines kostenloses Kontingent, und der Katalog enthält kostenlose Modelle. Diese haben niedrige tägliche Anfragegrenzen, und die Dokumentation nennt sie in der Regel ungeeignet für den Produktivbetrieb. Nach dem Kauf von Guthaben steigt die Grenze für kostenlose Modelle, die kostenlose Stufe ist daher als Bewertungsweg zu verstehen.
Ja, und zwar je Anfrage statt als kontoweite Einstellung. Sie können Anbieter ablehnen, die Daten speichern könnten, das Routing auf Endpunkte ohne Speicherung beschränken und Zulassungs- oder Ausschlusslisten für bestimmte Anbieter nutzen. Unternehmenskunden können zusätzlich Routing innerhalb der Europäischen Union oder der Vereinigten Staaten verlangen.
Ja. Dazu gehört ein vom Tarif abhängiges kostenloses Kontingent, gemessen an den Inferenzkosten zum Listenpreis statt an der Zahl der Anfragen, wobei Nutzung darüber hinaus eine anteilige Gebühr auslöst, die vom Guthaben abgeht. Das passt zu Teams, die bereits verhandelte Anbieterverträge halten und dennoch einheitliches Routing wollen.
Nur innerhalb von vierundzwanzig Stunden nach der Transaktion, über die Erstattungsschaltfläche auf der Guthabenseite. Danach ist ungenutztes Guthaben nicht mehr erstattungsfähig, Kryptozahlungen überhaupt nicht. Beim Löschen des Kontos geht verbleibendes Guthaben ebenfalls verloren.
Drei Überlegungen überwiegen. Sie fügen Ihrem Inferenzpfad einen Dritten hinzu. Sie nehmen einen zusätzlichen Netzsprung und dessen Latenzkosten in Kauf. Und Sie binden sich an ein vorausbezahltes Guthabenmodell mit engem Erstattungsfenster. Wer per Unternehmensvertrag auf einen Anbieter standardisiert ist oder absolute Mindestlatenz braucht, fährt mit dem Direktaufruf womöglich besser.
