Methodik

Prompt: Eine feste Anweisung, die auf ca. 500 Tokens Ausgabe ausgelegt ist. Derselbe Prompt wird für jedes Modell in jedem Laufzyklus verwendet.

Läufe: 3 sequenzielle Aufrufe pro Testzyklus. Wir messen die End-to-End-Latenz (erstes bis letztes Byte), nicht TTFT.

Metriken: P50 (Median) und P95 (Tail) über die 3 Läufe. P50 ist die Hauptkennzahl; P95 gibt Auskunft über die Konsistenz.

Messstandort: EU — Amsterdam (AMS). Alle Ergebnisse basieren auf EU-Latenz. US- oder Asien-Ergebnisse würden abweichen.

Geschwindigkeits-Tiers:

Status: Live seit Mai 2026. 13,593 bewertete Läufe in 6 Kategorien und bei 4 Anbietern. Neue Läufe alle 6 Stunden parallel zu Geschwindigkeits- und Verfügbarkeitsprüfungen.

Judge-Modell: Claude Sonnet 4.5 fungiert als unparteiischer Richter. Der Name des bewerteten Modells wird nie in den Judge-Prompt aufgenommen — nur der rohe Antworttext wird bewertet (Blind-Review).

Bewertung: Jeder Prompt erhält vom Judge einen einzigen Qualitätswert von 0–100 sowie eine Klassifikation (korrekt / teilweise / falsch). Der Judge bewertet sachliche Korrektheit, Vollständigkeit, Reasoning-Qualität und Format-Einhaltung als kombiniertes Rubric. Kategorie-Durchschnitte werden auf Modellseiten angezeigt.

Sechs Prompt-Kategorien:

Gesamt-Qualitätswert: Ungewichteter Durchschnitt aller bewerteten Läufe eines Modells über alle Kategorien.

Statische Benchmarks messen ein Modell an einer festen Messlatte. Die Arena misst Modelle gegeneinander — in realistischen Kundenservice-Szenarien, bewertet von einem Panel rivalisierender Modelle. Das Ergebnis ist etwas, das ein einzelner Score nicht liefern kann: ein relatives Ranking mit Unsicherheitsmarge.

Warum dies die statischen Benchmarks ergänzt (aber nicht ersetzt):

• Statische Tests liefern absolute Qualität pro Kategorie; die Arena liefert Stärke im Direktvergleich und einen Kosten-Qualitäts-Kompromiss bei realistischen Aufgaben.
• Die Arena erfasst, was ein 0–100-Score übersieht: Konsistenz über mehrere Züge, wie ein Modell Nachfragen behandelt und — bei councils — ob Zusammenarbeit tatsächlich einen Mehrwert bringt.
• Das Rennen auf dem Bildschirm ist eine Möglichkeit, den Wettkampf zu verfolgen. Das Ergebnis wird stets vom Panel festgelegt, niemals von den Lebensbalken.

Die Bewertung erfolgt in zwei Phasen. Während des Spiels führt ein einzelner schneller Schiedsrichter eine laufende Auswertung; am Ende stimmt ein unabhängiges Panel über den Sieger ab.

Phase 1 — live, pro Zug: Ein schneller, bewusst günstiger Judge (gpt-4o-mini) bewertet jede Antwort in einem einzigen Aufruf auf einer 0–10-Skala. Dies speist ausschließlich die Live-Rennspur — es ist indikativ, nicht entscheidend.

Phase 2 — Rundenende, das Panel: Ein Panel aus 3–5 Judges verschiedener Modellfamilien stimmt unabhängig voneinander auf einer 0–100-Skala über den Sieger ab. Die Mehrheit gewinnt; Gleichstände werden durch den höchsten Paneldurchschnitt aufgelöst, dann deterministisch über die niedrigste Modell-ID.

Blind nach Index: Modellnamen werden aus dem Panel-Prompt entfernt — Teilnehmer werden nur durch Nummern/Index bezeichnet, sodass das Panel keine vertraute Marke bevorzugen kann.

Feste Schwellenwerte: Ein Modell erhält einen Upvote (▲), wenn ein Judge es mit ≥60 bewertet. Ein Zug gilt als »entscheidend«, wenn der Vorsprung des Siegers ≥30% der Score-Skala erreicht. Diese festen Werte definieren die angezeigten Tallys.

Jedes Modell hat ein geschätztes Kompetenzniveau μ (mu) und eine Unsicherheit σ (sigma). Ein neues Modell startet bei μ=25, σ=8.333 — hohe Unsicherheit. Jedes Spiel bewegt μ in Richtung der wahren Stärke des Modells und verringert σ. Zwei Modelle mit gleichem μ aber unterschiedlichem σ sind nicht gleichwertig: das mit niedrigem σ ist bewiesen, das andere ist noch eine Schätzung.

Die tatsächlich verwendeten Konstanten: Startbewertung μ=25, σ=8.333; Kompetenzvarianz BETA=4.167; Drift pro Spiel TAU=0.0833. Diese sind im Code fest verankert und für jedes Modell identisch.

Wie wir aktuell sortieren — offen kommuniziert: Das Leaderboard sortiert nach rohem μ (geschätzte Stärke). Ein strengeres »bewiesenes« Ranking würde nach dem konservativen μ−3σ sortieren. Da es sich um frühe Daten handelt — die meisten Modelle haben nur wenige Spiele — ist σ noch groß, sodass sich die Tabellenspitze noch verschieben kann. Wir zeigen die Schätzung und teilen mit, dass es eine Schätzung ist, statt uns hinter einer einzigen Zahl zu verstecken.

Eine Runde kann einen günstigen council kleinerer Modelle gegen ein einzelnes teures frontier-Modell antreten lassen. In einem council ist die Antwort jedes Zuges die Konsens-Synthese seiner Mitglieder. So kann die Arena eine Frage beantworten, die ein einzelner Score nicht kann: Kann ein günstiger council ein teures frontier-Modell schlagen — und wenn ja, um wie viel?

Wie Einsparungen berechnet werden: Wenn ein council eine Runde gewinnt und dabei weniger kostet als das besiegte frontier-Modell, zeigen wir die Differenz als Einsparung. Ein council-Sieg wird der Gruppe zugeschrieben, nie dem Leaderboard eines einzelnen Mitglieds, sodass ein Gruppenergebnis das Ranking keines einzelnen Modells aufbläht.

Best-Case-Vorbehalt: Einsparungen kumulieren nur aus Runden, die der council gewonnen hat. Councils, die verloren haben (und damit Geld für nichts ausgegeben haben), werden nicht abgezogen. Der Wert ist daher eine Best-Case-Einsparung in den gewonnenen Runden — kein Netto-Ergebnis.

Ein Modell wird auf zwei verschiedene Weisen gemessen, und die beiden können sich widersprechen, ohne dass eine davon falsch ist — sie messen unterschiedliche Dinge.

Arena-Reputation (relativ): TrueSkill aus Direktvergleichs-Siegen. Bewertet ein Modell im Verhältnis zu seinen Konkurrenten in realistischen Szenarien.

Neutral-Judge-Reputation (absolut): Wie oft ein Modell im wiederkehrenden Intelligenztest als korrekt / teilweise / falsch bewertet wird — an einem festen Rubric statt gegen einen Gegner.

Ein Modell kann Spiele verlieren und trotzdem eine hohe Korrektheitsbewertung haben, oder Spiele gewinnen, während es im absoluten Korrektheitsmass nur teilweise abschneidet. Wir halten diese beiden Reputationen bewusst getrennt.

Ein blind spot ist ein wichtiger Punkt, den ein Teilnehmer übersieht, während ≥2 andere ihn abdecken — er ist also nachweislich wichtig, kein Randdetail.

Vom Panel bestätigt: Ein blind spot wird nur gezählt, wenn ≥2 Panel-Judges unabhängig voneinander dieselbe Auslassung bestätigen. Ein Judge schlägt die Aspektliste und eine Fehler-Matrix vor; die anderen Judges füllen dieselben festgelegten Aspekte aus, und eine Auslassung wird nur bestätigt, wenn mindestens zwei Matrizen in dieser Zelle übereinstimmen.

Status: Diese Erkennung ist live und wird schrittweise ausgerollt. Wir veröffentlichen noch keine Zahl — wir zeigen lieber keine Zahl als eine, die noch nicht durch ausreichend Daten gestützt ist.

Jede Auswertung auf den Arena-Seiten ergibt sich aus einer kleinen Menge fester Entscheidungen. Wir listen sie hier auf, damit die Zahlen nachprüfbar sind.

Punkte, die ein aufmerksamer Leser explizit wissen möchte — Grenzen, bekannte Verzerrungen und Entscheidungen, die die Zahlen beeinflussen.

Frühe Daten, volatile Rankings: Die Arena ist jung. Die meisten Modelle haben nur wenige Spiele, sodass ein einzelner Sieg oder eine Niederlage μ stark bewegen kann und die Rankings noch volatil sind. Wir zeigen Spielzahlen und Unsicherheit, statt zu suggerieren, die Reihenfolge sei bereits gesetzt.

Sortierung nach rohem μ: Das Leaderboard sortiert nach rohem μ, nicht nach dem konservativen μ−3σ. Bei hoher Unsicherheit kann ein Modell mit einem einzigen Glückssieg über einem besser bewiesenen stehen. Wir behandeln die aktuelle Reihenfolge als »geschätzt, noch nicht bewiesen«.

Jury-Übereinstimmung ist keine Korrektheit: Der Judge-Übereinstimmungswert misst, wie oft die Wahl eines Judges mit dem Panel-Sieger übereinstimmte — aber der Sieger ist die Mehrheit derselben Judges. Er misst Konformität zum Panel, nicht ob das Panel richtig lag. Ein korrekter, aber abweichender Judge erzielt hier einen niedrigen Wert.

Einsparungen sind Best-Case: Einsparungen zählen nur Runden, die der council gewann und günstiger war; verlorene councils werden nicht abgezogen. Lesen Sie es als Best-Case-Wert in den Gewinnerrunden, nicht als Nettoeinsparung.

Selbstpräferenz eines einzelnen Judges im Intelligenztest: Der wiederkehrende Intelligenztest läuft mit einem primären Judge (Claude Sonnet 4.5), der auch Claude-Familienmodelle bewerten kann — Selbstpräferenz ist ein bekanntes LLM-Bias. Ein sekundärer Cross-Check-Judge existiert zur Kalibrierung, und die Arena dämpft dies durch ein familienübergreifendes Panel; der einzelne Intelligenztest hat dieses Panel nicht.

Teilnehmer ↔ Judge-Familienüberlappung: Eine Modellfamilie kann in derselben Runde sowohl als Teilnehmer als auch im Judge-Panel auftreten. Blind-nach-Index-Verfahren und das familienübergreifende Panel reduzieren den Effekt, aber Überlappungen können vorkommen — wir legen dies offen, statt strikte Familientrennung zu behaupten.

Zwei Skalen, ein Leaderboard: Der Live-Judge pro Zug verwendet 0–10, das Rundenend-Panel 0–100. Wir normalisieren alles auf dieselbe Skala, bevor es das Leaderboard erreicht, sodass die beiden Zahlen, die während einer Runde sichtbar sind, im Ranking nicht vermischt werden.

Umgang mit Gleichständen: Eine Runde ohne klaren Sieger zählt als Unentschieden — kein Verlust für alle, was die Gewinnquoten verzerren würde — und bringt keine Einsparungen.

Versionierte, deterministische Ableitung: Die visuelle Ableitung auf dem Bildschirm ist rein, deterministisch und trägt einen Versions-Tag (v8.1-tokonomix), damit eine spätere Logikänderung vergangene Runden nie stillschweigend umschreibt. Wesentliche Methodikänderungen werden im Änderungsprotokoll vermerkt.

Im Juni 2026 führten wir die erste Basismessung der KI-Bildqualitätskontrolle durch. Sechs Einzelmodelle und zwei Rat-Konfigurationen wurden auf 300 Bildern getestet. Der Rat erreichte 87,5% Recall gegenüber 66,9% für das beste Einzelmodell — eine Lücke von 20,6 Prozentpunkten. Vollständige Ergebnisse unter /benchmarks/vision-qc.

Vollständige Ergebnisse →

Häufigkeit: Alle 6 Stunden (06:00, 12:00, 18:00, 00:00 UTC).

Methode: Ein minimaler Echo-Prompt wird gesendet. Wir erfassen HTTP-Status, Fehlermeldung (falls vorhanden) und Antwortzeit.

Fehlerverfolgung: error_count je Lauf wird aufgezeichnet. Dauerhaft hohe Fehlerquoten werden im Leaderboard angezeigt.

Alle Benchmark-Daten sind kostenlos verfügbar. Kein API-Schlüssel für Lesezugriff erforderlich.