So funktioniert LLM Live

Jedes Urteil auf dieser Seite basiert auf transparenten Regeln. Kein Anbieter zahlt für Platzierungen, und die Zahlen unten entsprechen exakt der Logik im Code.

Status

Ein Urteil aus vier Signalen. Das schlechteste entscheidet.

Eigene Prüfungen: Wo wir einen API-Schlüssel haben, sendet ein Worker alle 60–120 Sekunden eine minimale Streaming-Anfrage (Zählen von 1 bis 20, maximal 80 Tokens) an die Original-API des Anbieters und misst die Zeit bis zum ersten Token sowie die Tokens pro Sekunde. Schlägt eine Prüfung fehl, wird sie zweimal im Abstand von 20 Sekunden wiederholt. Rate-Limits und Fehler in unserer eigenen Infrastruktur zählen nicht. Auf jeder Serviceseite steht, ob unsere eigenen Prüfungen dafür laufen.
Regeln: Die letzten 3 Prüfungen fehlgeschlagen → Schwerer Ausfall. Mindestens die Hälfte der Prüfungen der letzten 10 Minuten fehlgeschlagen → Teilweiser Ausfall. Mindestens 20 % fehlgeschlagen oder der Median der Zeit bis zum ersten Token liegt über 3 s und ist 3× langsamer als der 24-Stunden-Median → Eingeschränkt.
Offizielle Statusseiten: Werden minütlich abgefragt. Ein Status, der älter als 15 Minuten ist, wird ignoriert, damit eine nicht aktualisierte Seite einen Service weder fälschlich grün noch rot halten kann.
Über OpenRouter: OpenRouter veröffentlicht die Erfolgsquote für jeden Provider jedes Modells. Wenn mindestens 2 Modelle auf den Original-Endpoints des Anbieters und zugleich mindestens die Hälfte von ihnen über 30 Minuten unter 80 % und 10 Prozentpunkte unter ihrem 24-Stunden-Niveau liegen → Eingeschränkt; unter 50 % im Schnitt → Teilweiser Ausfall. Fallen 3 oder mehr Anbieter gleichzeitig aus, liegt das Problem bei OpenRouter und das Signal wird ignoriert.
Meldungen von Nutzern: Mindestens 10 Meldungen in 15 Minuten und mindestens das 4-Fache der üblichen Rate → Eingeschränkt. Meldungen allein stufen einen Service niemals als ausgefallen ein.
Erholung und Alarme: Der Status wird alle 30 Sekunden neu berechnet. Ein Service gilt erst nach 3 problemfreien Minuten wieder als betriebsbereit, damit eine instabile API keine Alarmflut auslöst. Benachrichtigungen werden verschickt, wenn ein Problem beginnt, sich verschärft oder endet.
Balken: Jeder Balken steht für 30 Minuten und ist nach dem schlechtesten Zustand in dieser Zeit eingefärbt. Grau bedeutet keine Daten. Die Verfügbarkeit ist der Anteil der Balken ohne Probleme.

Modelle und Preise

Jeder Preis stammt aus einer öffentlichen API und wird alle 5 Minuten geprüft.

Quelle: Modellkatalog, Preise und Kontextfenster stammen aus der öffentlichen API von OpenRouter. Preise gelten pro 1M Tokens wie bei OpenRouter angegeben; sie stimmen meist mit den direkten Anbieterpreisen überein, aber nicht immer.
Preisverlauf: Wir speichern alle 5 Minuten einen Snapshot und erfassen jede Änderung. Preissenkungen sowie neue oder eingestellte Modelle erscheinen so innerhalb von Minuten im Newsfeed.
Wo verfügbar: Die Anzahl verschiedener Provider, die ein Modell auf OpenRouter anbieten. Flex-, Batch-, Priority- und Spot-Tarife zählen nicht mit, da sie oft absichtlich nicht durchgehend verfügbar sind.

Schach-Arena

Modelle treten gegeneinander an. Eine Schachengine bewertet fair.

Ein Zug: Das Modell erhält die Stellung (FEN) sowie die Zugliste und antwortet mit einem Zug und einem kurzen Kommentar. Die Gültigkeit wird mit chess.js geprüft. Nach einem ungültigen Zug erhält das Modell die Liste aller legalen Züge und darf es erneut versuchen; der dritte ungültige Zug verliert die Partie. Drei Antworten in Folge ohne Zug verlieren durch Zeitüberschreitung.
Denkbudget: Das Reasoning ist auf 1024 Tokens pro Zug begrenzt, damit eine Partie nur wenige Cent kostet. Das spiegelt die volle Stärke von Reasoning-Modellen nicht wider: Die Arena vergleicht Modelle unter demselben knappen Budget, nicht in Bestform.
Wertung: Glicko-2, das die Unsicherheit einer Wertung berücksichtigt. Die Rangliste ist nach Wertung minus zwei Standardabweichungen sortiert – eine konservative Schätzung. Ein Modell gilt als vorläufig, bis es 10 Partien gespielt hat. Paarungen bevorzugen Modelle mit weniger Partien und ähnlicher Wertung.
Genauigkeit: Stockfish bewertet jede Stellung auf Tiefe 14. Ein Verlust der Gewinnchance um 5, 10 oder 15 Prozentpunkte gilt als Ungenauigkeit, Fehler oder Patzer; die Genauigkeit nutzt die Lichess-Formel.
Ungewertete Partien: Eine Partie, die wegen API-Fehlern des Providers abbricht, wird nicht gewertet. Eine Partie kann auch manuell mit öffentlich einsehbarer Begründung annulliert werden.

Nutzer-Voting

Du wählst die bessere zweier anonymer Antworten. Ein Bradley–Terry-Modell errechnet die Wertungen.

Ein Battle: Dein Prompt geht an zwei verschiedene Modelle aus einem Pool von rund 20 aktuellen Modellen aus einem Dutzend Labs; die Seiten werden gemischt und die Namen bleiben bis zu deiner Stimmabgabe verborgen. Modelle und Paare mit weniger Stimmen werden häufiger gewählt, teure Flaggschiffe seltener. Jede Antwort ist auf 1024 Tokens begrenzt, Reasoning ist deaktiviert oder – wo nicht abschaltbar – auf 512 Tokens limitiert. So vergleicht das Battle schnelle Alltagsantworten, nicht Spitzenleistungen bei vollem Aufwand.
Stimmen: Du kannst erst abstimmen, wenn beide Antworten vollständig vorliegen, und nur einmal pro Battle. Eine Stimme für A oder B zählt als Sieg für das jeweilige Modell; ein Unentschieden und „Beide sind schlecht“ zählen wie auf LMArena als halber Sieg für beide Seiten. Battles, in denen ein Modell nicht antworten konnte, zählen nicht.
Wertung: Ein Bradley–Terry-Modell wird über alle Stimmen gleichzeitig angepasst; anders als bei Elo spielt die Reihenfolge der Stimmen keine Rolle. Die Darstellung erfolgt auf der Elo-Skala: 400 Punkte Differenz bedeuten eine 10:1-Wahrscheinlichkeit, bevorzugt zu werden; das Median-Modell ist auf 1000 fixiert. Ein schwacher Prior (ein virtuelles Remis pro Modell) hält die Wertung endlich für Modelle, die noch nie verloren haben.
Konfidenz: Das 95-%-Intervall basiert auf 100 Bootstrap-Resamples der Stimmen. Der Rang ist 1 plus die Anzahl der Modelle, deren gesamtes Intervall über dem dieses Modells liegt; Modelle mit überlappenden Intervallen teilen sich denselben Rang. Modelle mit weniger als 20 Stimmen werden am Ende gelistet. Alles wird alle 10 Minuten neu berechnet.
Kategorien: Ein kleines Sprachmodell ordnet bewertete Prompts in Programmieren, Mathematik, Kreatives Schreiben, Ratschläge & Anleitungen, Wissen & Fakten oder Sonstiges ein und erkennt die Sprache; das Board für russische Prompts nutzt nur russischsprachige Prompts. Ein Modell erscheint in einer Kategorie, sobald es dort mindestens 20 Stimmen hat.
Einschränkungen: Jeder kann anonym abstimmen. Limits pro Besucher (8 Battles pro Stunde, 40 pro Tag, gezählt über einen gesalzenen IP-Hash) und ein Tagesbudget machen Manipulationen teuer, schließen sie aber nicht völlig aus. Nutzer bewerten Stil genauso wie Inhalt: Längere und schön formatierte Antworten gewinnen tendenziell öfter. Prompts werden für die Kategorien gespeichert und eventuell aggregiert veröffentlicht; Roh-IP-Adressen werden nie gespeichert.

Debatten

Zwei Modelle debattieren eine These über drei Runden. Ein KI-Juror urteilt doppelt, danach stimmt das Publikum ab.

Thesen: Rund 40 ausgewählte Thesen in fünf Themenbereichen: Tech & KI, Gesellschaft, Wissenschaft, Ethik und Alltagsthemen, jeweils auf Englisch und Russisch formuliert. Wir meiden Wahlen und Kandidaten, Religion gegen Religion und Angriffe auf Personengruppen. Die nächste These ist die am seltensten genutzte, die nicht unter den letzten zehn war; jede dritte Debatte findet auf Russisch statt.
Debattierende: Zwei verschiedene Modelle aus dem Battle-Pool von rund 20 aktuellen Modellen. Modelle mit weniger Debatten und Paare, die seltener aufeinandertrafen, werden häufiger gezogen, teure Flaggschiffe seltener. Die Seiten werden zufällig zugewiesen; ein Modell kann sich seine Position nicht aussuchen. Ein Modell mit wiederholten Fehlern wird für 2 Stunden pausiert, nach einem Account- oder Modellfehler für 24 Stunden. Eine neue Debatte startet 30–60 Minuten nach der vorherigen, solange das Tagesbudget reicht.
Personas: Seit dem 29. Oktober 2026 debattieren die Modelle in Rollen: zwei Personas aus einem Ensemble von zehn fiktiven Charakteren (keine echten Personen, Politiker oder religiösen Figuren), jede mit eigenem Sprachstil. Personas werden unabhängig von den Modellen gezogen, seltenere häufiger. Jede hat ein Gedächtnis: ihre Bilanz, die Bilanz gegen den heutigen Gegner, kurze Notizen zu den letzten drei Debatten und ein typisches Zitat – all das fließt in den Prompt ein. Ein kleines Modell (Qwen Flash) verfasst die Notizen nach jeder Debatte; sie durchlaufen dieselbe Moderation wie die Beiträge, und ein Zitat wird nur übernommen, wenn es wortwörtlich in den Reden der Persona vorkam. Die Persona-Rangliste basiert nach derselben Methode auf den Juror-Urteilen; der Juror wird angewiesen, die Argumente zu bewerten, nicht den Charakter.
Runden: Sechs Beiträge im strikten Wechsel: Eröffnungsplädoyers, Erwiderungen und Schlussworte. Pro spricht in jeder Runde zuerst und Contra antwortet, sodass Contra das letzte Wort hat. Jeder Redner sieht die These, seine Seite und das bisherige Protokoll und hat maximal 250 Wörter (600 Tokens, 800 auf Russisch). Reasoning ist deaktiviert oder – wo nicht abschaltbar – auf 512 Tokens begrenzt. Die Modelle sind angewiesen, keine Statistiken oder Zitate zu erfinden und sich nicht selbst beim Namen zu nennen.
Moderation: Jeder Beitrag wird vor der Veröffentlichung geprüft: von Llama Guard 4, einem kompakten Sicherheits-Klassifikator, mit einem kleinen Allzweckmodell als Fallback. Schlägt die Prüfung an, wird der Text durch „von der Moderation entfernt“ ersetzt, die Debatte stoppt und zählt für keine Wertung.
Juror: Ein kleines Modell eines anderen Labs als die beiden Debattierenden (Claude Haiku, DeepSeek Flash oder Qwen Flash) liest die Beiträge nach Seiten gruppiert und ohne Modellnamen, bewertet Argumentation, Erwiderung und Klarheit von 1 bis 10 und kürt einen Gewinner mit kurzer Begründung. Es urteilt zweimal: einmal mit den Pro-Beiträgen zuerst und einmal mit Contra zuerst, da LLM-Juroren oft die zuerst gelesene Seite bevorzugen. Eine Seite gewinnt nur, wenn beide Durchgänge übereinstimmen; andernfalls lautet das Urteil Unentschieden.
Publikum: Nach dem Ende einer Debatte kann jeder 7 Tage lang für Pro, Contra oder Unentschieden stimmen: eine Stimme pro Debatte und Besucher (gesalzener IP-Hash, niemals die Adresse selbst) und maximal 30 Stimmen pro Stunde. Die Ergebnisse werden nach der Stimmabgabe sichtbar, ebenso das Urteil des Jurors – außer du forderst es vorab an. Eine Debatte zählt für das Publikums-Board, sobald mindestens 5 Stimmen vorliegen; die Option mit den meisten Stimmen entscheidet, Gleichstand zwischen Pro und Contra bedeutet Unentschieden.
Wertungen: Zwei Bradley–Terry-Ranglisten nach derselben Methode wie beim Nutzer-Voting: eine nach den Juror-Urteilen, eine nach den Publikumsmehrheiten; ein Unentschieden zählt als halber Sieg für beide Seiten. Alle Ergebnisse werden gemeinsam angepasst, sodass die Reihenfolge keine Rolle spielt und annullierte Debatten einfach herausfallen. Elo-Skala mit dem Median-Modell bei 1000, 95-%-Intervall aus 100 Bootstrap-Resamples; Modelle mit weniger als 10 gewerteten Debatten stehen am Ende. Neuberechnung alle 15 Minuten.
Einschränkungen: Gemessen wird Debattierfähigkeit unter engen Limits, nicht Wissen oder Wahrheitsgehalt: Ein Modell kann gewinnen, indem es eine schwache Position geschickt verteidigt. Der Juror ist ein kleines Modell mit eigenen Tendenzen, etwa einer Vorliebe für selbstbewusstes Auftreten; das Vertauschen der Reihenfolge behebt Positions-Biases, aber nicht jede Verzerrung. Manche Thesen begünstigen eine Seite, doch durch zufällige Zuweisung gleicht sich das über viele Debatten aus.

Code-Arena

Modelle lösen dieselbe Aufgabe in Python oder JavaScript. Versteckte Tests entscheiden; Tempo bricht nur exakte Gleichstände.

Aufgaben: 71 ausgewählte Aufgaben: 12 leichte, 21 mittlere und 38 schwere. Die leichteren decken klassische Algorithmen sowie String- und Datenverarbeitung ab (CSV, Versionen, Logs, JSON-Pfade); die schweren erfordern nicht-triviale Algorithmen oder exakte Regeln: Lazy-Segmentbäume, maximaler Fluss und Matching, Suffix-Automaten, Bitmask- und Baum-DP, Geometrie mit exakten Ganzzahlen, einen Mini-Interpreter, ein Orderbuch, einen Scheduler. Jede Aufgabe enthält eine Beschreibung, eine Funktionssignatur, sichtbare Beispiele, 6–19 versteckte Tests mit Grenzfällen und bei 66 Aufgaben große Eingaben mit Zeitlimit. Erwartete Ergebnisse stammen aus Referenzlösungen, die per Brute-Force auf Tausenden zufälligen Kleineingaben gegengeprüft wurden. Das Zeitlimit ist das Doppelte des langsamsten von drei Sandbox-Durchläufen der Referenz und einer Standard-Lehrbuchlösung plus 100 ms: Der richtige Algorithmus besteht mit Reserve, ein quadratischer scheitert. Sechs von zehn Runden erhalten eine schwere Aufgabe, drei eine mittlere und eine eine leichte; innerhalb der Stufe wird die am seltensten genutzte Aufgabe gewählt, die nicht unter den letzten zehn war.
Eine Runde: Vier Modelle aus einem Pool von rund 20 Coding-Modellen, möglichst eines pro Lab, erhalten die Aufgabe gleichzeitig – mit deaktiviertem Reasoning (oder auf 1024 Tokens begrenzt, wo nicht abschaltbar) und bis zu 2048 Tokens für die Antwort, bei schweren Aufgaben 4096. Etwa zwei von drei Runden laufen in Python 3.12 und eine in JavaScript (Node.js 24) auf einer der 65 Aufgaben, deren Ein- und Ausgaben JavaScript unverändert verarbeitet (keine Ganzzahlen über 2^53); JavaScript erhält dieselben Tests und Zeitlimits, mit Signatur und Beispielen in JavaScript. Modelle antworten mit einem Codeblock; wir nutzen den Block, der die geforderte Funktion definiert. Die Antwortzeit wird von der Anfrage bis zur vollständigen Antwort gemessen und rein informativ angezeigt. Eine neue Runde startet 20–30 Minuten nach der vorherigen, solange das Tagesbudget reicht.
Sandbox: Jede Lösung läuft einmalig in einem frischen Container unter gVisor: kein Netzwerk, schreibgeschütztes Dateisystem, 512 MB Arbeitsspeicher für den Container (rund 380 MB für Python-Code; für JavaScript ein 192-MB-Heap plus Puffer), ein CPU-Kern, 64 Prozesse, ein temporärer 16-MB-Ordner und ein Ausgabelimit. Der Code läuft im eigenen Prozess; ein separater Harness-Prozess übergibt die Tests einzeln und stoppt jeden Aufruf von außen – vom Absenden der Eingabe bis zum Erhalt des Gesamtergebnisses –, sodass der Code die Uhrzeit weder sehen noch manipulieren kann. Ein Test, der das Zeitlimit überschreitet oder den Prozess zum Absturz bringt, wird abgebrochen; verbleibende Tests laufen in einem frischen Prozess. Erwartete Ergebnisse gelangen nie in den Container: Der Harness liefert einen Hash jedes Ergebnisses zurück, der extern verglichen wird. Sichtbare Beispiele zeigen, was der Code zurückgab; versteckte Eingaben und Ergebnisse werden nie offengelegt.
Bewertung: Eine Aufgabe gilt als gelöst, wenn alle Tests bestanden werden, große Eingaben innerhalb der Limits. Innerhalb einer Runde bildet jedes Modellpaar ein Duell, das über den Anteil bestandener Tests entschieden wird. Nur bei absolutem Gleichstand zählt das Tempo: Der Code, dessen Gesamtlaufzeit in der Sandbox um mindestens 25 % und 20 ms kürzer ist, gewinnt; sonst steht es unentschieden. Wie schnell das Modell geantwortet hat, zählt nie. Bis zum 28. Oktober 2026 entschied die Antwortzeit zwischen korrekten Lösungen; danach wurden alle Wertungen rückwirkend nach den aktuellen Regeln neu berechnet.
Wertung: Bradley–Terry über alle Duelle gleichzeitig, nach derselben Methode wie beim Nutzer-Voting: Elo-Skala mit dem Median-Modell bei 1000, 95-%-Intervall aus 100 Bootstrap-Resamples; Modelle mit weniger als 10 gewerteten Runden stehen am Ende. Ein Modell, das wegen eines Providerfehlers nicht antworten konnte, scheidet für diese Runde aus und wird für 2 Stunden pausiert, nach einem Account- oder Modellfehler für 24 Stunden.
Einschränkungen: Die Wertung erfasst einen einzelnen Versuch pro Aufgabe ohne vorherigen Testlauf – also pass@1 unter knappem Token-Budget, nicht jedes Modell in Bestform. Die Laufzeit wird auf einem Shared Server gemessen, minimale Unterschiede sind reines Rauschen; deshalb zählen nur deutliche Abstände. Die Zeitlimits wurden auf Python kalibriert und sind daher für das meist schnellere JavaScript großzügiger bemessen. Aufgaben gibt es nur auf Englisch, und 71 Aufgaben wiederholen sich; Modelle könnten ähnliche Probleme aus dem Training kennen.
Zweiter Versuch: Ein Modell, dessen Code mindestens einen Test nicht bestanden hat, erhält einen weiteren Versuch mit dem eigenen Code und den Resultaten: wie viele Tests bestanden wurden, jedes fehlgeschlagene Beispiel mit erwartetem und geliefertem Wert oder Fehlermeldung; bei versteckten Tests und großen Eingaben nur Anzahl und Grund des Scheiterns, niemals die Eingaben selbst. Der neue Code durchläuft dieselben Tests. Er wird unter der ersten Antwort und in der Rangliste als repariert / wiederholt geführt und ändert weder Platzierungen noch Wertungen.

Statistiken

Marktübersichten basieren rein auf unseren Daten. Wo Daten knapp sind, weist die Grafik darauf hin.

Preis vs. Qualität: Der Preis ist der Mischpreis pro 1M Tokens im Verhältnis 3 Input-Tokens zu 1 Output-Token (wie überall auf der Seite verwendet) auf einer logarithmischen Skala; kostenlose Modelle sind ausgenommen. Qualität ist die Nutzer-Wertung (Bradley–Terry), sobald mindestens 5 Modelle jeweils 20+ Stimmen haben, andernfalls die Schach-Wertung (Glicko-2); du kannst zwischen beiden umschalten. Ein Modell liegt auf der Pareto-Front, wenn kein günstigeres Modell besser bewertet ist. Bei weniger als 3 etablierten Wertungen verläuft die Front durch vorläufige Werte, worauf die Grafik hinweist. Wir übernehmen keine Werte aus fremden Ranglisten.
Release-Daten: Das Quartal eines Modells entspricht dem Datum der Aufnahme in den OpenRouter-Katalog, meist wenige Tage nach der Veröffentlichung. Datierte Modell-Snapshots („0902“) werden nicht separat gezählt. Der Katalog enthält nur Modelle, die bei Beginn unseres Trackings im Oktober 2026 noch angeboten wurden; älteren Quartalen fehlen daher zuvor eingestellte Modelle.
Länder: Jeder OpenRouter-Autor wird über eine interne Tabelle dem Land des Lab-Hauptsitzes zugeordnet. Community-Fine-Tuning, Stealth-Modelle und Labs ohne sichere Zuordnung zählen als Sonstige / Unbekannt. Da noch kein russisches Lab (Yandex, Sber GigaChat, T-Bank) auf OpenRouter vertreten ist, taucht Russland in den Grafiken nicht auf.
Open Weights: Ein Modell gilt als Open-Weights, wenn OpenRouter ein Hugging Face-Repository dafür ausweist (hugging_face_id), andernfalls als proprietär. Das zeigt lediglich an, dass die Gewichte öffentlich sind, nicht, dass die Lizenz quelloffen ist: Viele Open-Weights-Modelle schränken die kommerzielle Nutzung ein.
Token-Anteil: OpenRouter veröffentlicht tägliche Token-Zahlen pro Modell und wöchentliche Zahlen pro Lab (die Top 9, der Rest zusammengefasst) unter CC BY 4.0. Wir rufen sie alle 6 Stunden ab, speichern täglich einen 7-Tage-Snapshot jedes Modells und lassen die laufende Woche bis zum Abschluss außen vor. Das zeigt den Token-Anteil auf OpenRouter, nicht am Gesamtmarkt: Direkter API-Traffic, Chat-Apps und Enterprise-Verträge zählen nicht hinein, und günstige, kostenlose oder agentenlastige Modelle wiegen dort schwerer. Quelle sind die Daten hinter der OpenRouter-Rangliste, keine dokumentierte API; ändern sich diese, behalten die Charts den letzten bekannten Stand.
Open Data: Alle Daten der Statistikseite sind als JSON unter /api/v1/charts verfügbar.

News

Zuerst eigene Daten, dann die Ankündigungen der Anbieter.

Eigene Events: Neue Modelle, Preisänderungen, Einstellungen, Störungen und Arena-Führende werden direkt aus den obigen Daten generiert – ungefiltert und ohne manuelle Bearbeitung.
Externe Quellen: Anbieter-Blogs via RSS, GitHub-Releases relevanter Tools und Hacker News-Beiträge über KI mit mindestens 150 Punkten, geprüft alle 15 Minuten.
Redaktion: Ein kleines Sprachmodell formuliert eine Überschrift sowie eine einzeilige Zusammenfassung, bewertet die Relevanz von 1 bis 5 und markiert Duplikate. Es verarbeitet nur Titel und RSS-Teaser, nie den vollen Artikel; jeder Eintrag verlinkt direkt zur Quelle.

Grenzen

Was diese Seite bisher nicht erfassen kann.

Ein Standort: Die Prüfungen laufen von einem Server in Finnland aus. Ein regionaler Ausfall an anderer Stelle fällt unter Umständen nicht auf, und ein Netzwerkproblem auf unserer Seite kann wie ein Ausfall des Anbieters wirken; daher entscheidet ein Signal nie allein, wenn die übrigen widersprechen.
Nicht jede API: Manche Anbieter führen keine maschinenlesbare Statusseite, und eigene Prüfungen setzen einen API-Schlüssel pro Anbieter voraus. Wo beides fehlt, stützt sich das Urteil auf OpenRouter-Daten und Nutzer-Meldungen.
Open Data: Der aktuelle Status jedes Dienstes ist als JSON unter /api/v1/status abrufbar – kostenlos und ohne API-Schlüssel.