Wie gemessen wurde — und was die Messung nicht kann
Das RUNBOOK stand vor dem ersten Lauf fest. Alles, was danach geändert wurde, steht mit Datum und Begründung im Entscheidungs-Log — 15 der 32 Einträge ergänzen oder ändern die pre-registrierte Methodik. Jede Aussage auf dieser Seite nennt ihre Belegstelle im Harness.
Die Ergebnisse selbst stehen auf Leaderboard.
RUNBOOK
Das RUNBOOK wurde VOR dem ersten Run festgeschrieben. Metriken, Schwellen und Entscheidungsregeln standen fest, bevor Ergebnisse existierten — das ist der Schutz gegen ergebnisgetriebenes Nachjustieren. Jede Änderung danach steht mit Begründung und Zeitstempel im Entscheidungs-Log darunter, nie still.
§0 Leitprinzipien
Objektiv gegradet zuerst: wo ein deterministisches Orakel existiert (AST-Match, Execution-Pass, DB-State), wird KEIN LLM-Judge benutzt. Kein globaler Score — das Ergebnis ist ein Leaderboard pro Use-Case, und Capability wird strikt von Latenz und Kosten getrennt. Billigste ausreichende Lane zuerst. Ehrlichkeit über das Tier: n < ~30 Cases heißt „Viability", 200–400 reale, private, rotierte Cases heißen „Gate"; jedes Ergebnis trägt sein Tier sichtbar. Harness konstant über alle Modelle je Task. Alles dokumentiert, append-only.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §0
§2 Metriken und Reliabilität
temperature=0, fester Seed wo unterstützt, k = 3 Wiederholungen pro (Case × Target). Berichtet wird valid-pass mit Wilson-95%-CI als primärem Intervall, n = Anzahl valider Cases pro Target (nicht Versuche, nicht Rows), z = 1,959963984540054. Zusätzlich pass^k als Konsistenzmaß. temp=0 ist unter MoE- und Batch-Serving NICHT voll deterministisch — genau deshalb k > 1.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §2 · §11.1 (nach D7/D30)
§3 Entscheidungsregeln
Pro Use-Case gewinnt das Modell mit dem höchsten objektiven Score; bei überlappenden 95%-CIs ist es ein Tie, und der Tie-Break läuft in genau dieser Reihenfolge: (1) EU-Souveränitäts-Klasse, (2) Self-host-Machbarkeit und -Kosten, (3) Latenz. Gold-Trust: failen zwei Modelle am selben Case identisch stark, wird der Case als gold-verdächtig geflaggt und bis zur Prüfung aus dem Ranking genommen.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §3
§4 Lanes und Kosten-Leiter
Die Lane-Reihenfolge folgt den MARGINALEN Kosten: lokal und NVIDIA-Free (gratis) vor Subscription-CLIs (Claude Code, Codex) vor Cursor (Firmen-Guthaben) vor OpenRouter (privates Budget, letzter Ausweg). Hartes Budget-Gate: vor jedem OpenRouter-Call wird `limit_remaining` geprüft; unter 3,00 EUR wird der Call blockiert. Keine Secrets im RUNBOOK oder in targets.json — nur Env-Var-Namen.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §4
§5 Roster und Souveränitäts-Klasse
Vier Klassen: EU-origin, EU-hostable-open-weight, Chinese-open-weight, US-closed. Jede Leaderboard-Zeile trägt ihre Klasse. Modell-IDs werden LIVE gegen den Modell-Katalog der jeweiligen Lane gepinnt (NVIDIA, OpenRouter, Cursor) — nie gegen SEO-Quellen, wegen Namensdrift („Opus 5" etwa existierte nicht).
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §5
§6 Reproduktion durch Dritte
Der Ablauf ist als 1:1 nachstellbare Kette festgeschrieben: `build_cases.mjs` erzeugt die Case-Kataloge mit gepinnter Provenienz, `run_bakeoff.mjs` schreibt einen exklusiven `results-<token>.jsonl`-Shard pro Runner (jede Zeile mit Modell-Revision, Lane, Provenance, Timestamp, Latenz), `summarize.mjs` erzeugt den Report deterministisch daraus. Jeder Schritt landet im append-only Run-Log, jede Abweichung im Entscheidungs-Log.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §6
§7 Bekannte Confounder und ihre Controls
Contamination → Execution-/State-Grading plus privates Held-out, Benchmark-Version und -Datum gepinnt. Prompt-Format-Sensitivität → EIN fixes Template pro Task über alle Modelle, nie per Modell getunt. Reasoning-Budget-Falle → `json_schema` statt `json_object`, `tool_choice="required"`, max_tokens 4096–8192. Judge-Bias → objektive Grader zuerst. Latenz-Confound der gedrosselten Free-Lane → Latenz zählt nur auf dem Self-host-Stack als Verdikt. Endpoint-apples-to-oranges → Precision, Quant, Kontext und Revision pro Endpoint pinnen.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §7
§11 Statistik-Kontrakt (Zweit-CI und Paarvergleiche)
Wilson bleibt primär. Daneben steht ein Cluster-Bootstrap-95%-CI (10 000 Iterationen, Ziehen von CASES mit Zurücklegen, jeder gezogene Case bringt alle seine k validen Versuche mit, seeded mulberry32 — nie Math.random). Die ehrliche Lesart steht im Vertrag selbst: weil unser Wilson-n schon Cases zählt, ist das Cluster-Intervall meist gleich breit oder SCHMALER und bei homogenen Cases degeneriert (Breite 0). Es ist eine Sensitivitätsangabe, kein Rang-Kriterium — Tie-Cluster werden ausschließlich über überlappende Wilson-Intervalle gebildet.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §11 (per D30 ergänzt)
Lane-Äquivalenz
Eine Lane-Zeile misst nie ein Modell allein, sondern Modell PLUS Harness. Das ist bei den CLI-Lanes strukturell so und war bisher nirgends offengelegt. Konkret: der CLI-Treiber reicht die Konfigurations-Verzeichnisse des Hosts an den Kindprozess weiter (`XDG_CONFIG_HOME`, `CLAUDE_CONFIG_DIR`, `CODEX_HOME`, `CURSOR_CONFIG_DIR` stehen in seiner Env-Allowlist) — und nur `codex` bekommt `--ignore-user-config`. Für claude-code und cursor bedeutet das: was in der lokalen Nutzer-Konfiguration steht (Skills, MCP-Server, Modell-Defaults), läuft potenziell mit. Deshalb ist „ohne Lane-Angabe ist ein Modell-Verdikt unvollständig" ein Kernbefund und keine Floskel.
| Lane | Transport | Tool-Kanal | Nicht kontrollierte Fläche | Misst deshalb |
|---|---|---|---|---|
| nvidia | HTTP | nativer `tool_calls`-Kanal (OpenAI-kompatibel) | Serving-Backend fremd: Precision, Quantisierung und Gewichts-Revision clientseitig nicht verifizierbar. Free-Tier mit ~40 RPM Drossel, RPM-Floor im Treiber. | Capability. Ausdrücklich NICHT Latenz (D4: GLM-5.2 lief hier 6× ins 60-s-Timeout, während Mistral Small 4 in 0,5–1,2 s antwortete). |
| openrouter | HTTP | nativer `tool_calls`-Kanal (OpenAI-kompatibel) | Router vor fremdem Serving: der tatsächliche Provider kann pro Request wechseln. Hartes Budget-Gate ≥ 3,00 EUR vor jedem Call. | Capability auf reduzierter Fallzahl (Budget-Subsets, D9/D15). |
| huggingface | HTTP | nativer `tool_calls`-Kanal (OpenAI-kompatibel) | `modelRevision` ist ein verifizierter Hub-Katalog-Commit — er behauptet NICHT, dass das Serving-Backend denselben Commit pinnt (W4 §8). | In dieser Kampagne nichts Rankbares: beide HF-Targets blieben nach HTTP-402-Ketten lane-limitiert (D18, D28.4). |
| aiat | HTTP | nativer `tool_calls`-Kanal (OpenAI-kompatibel) | Eigene Infrastruktur — die einzige Lane, auf der Precision/Quant/Kontext wirklich kontrolliert sind. Die Runs treffen den Serving-Origin direkt statt über den LiteLLM-Gateway-Hop; dieser Hop wird im Report als +Δ benannt, nicht gemessen. | Capability UND Latenz — die einzige Lane, auf der ein Latenz-Verdikt laut §2 überhaupt zulässig ist (D31). |
| ollama | HTTP | nativer `tool_calls`-Kanal (`auto` und `required` verifiziert) | Lokale Hardware. Erstmals ist die Quantisierung wirklich gepinnt UND clientseitig verifiziert (`ollama show` liefert Quant, Kontextlänge, Parameterzahl) — auf allen fremden HTTP-Lanes war das prinzipiell unverifizierbar. | Capability auf kontrolliertem Deployment (D32). |
| claude-code | CLI | KEIN nativer Tool-Kanal — die JSON-Schemas werden in den Prompt inliniert, die Antwort muss ein `{"tool_calls":[…]}`-Envelope sein, der zurückgeparst wird. | Kein `--ignore-user-config`. Der Kindprozess erbt `HOME`, `XDG_CONFIG_HOME` und `CLAUDE_CONFIG_DIR` — die lokale Nutzer-Konfiguration ist damit Teil des Messaufbaus. Zusätzlich trägt die Lane laut D8.2 rund 50 000 gecachte Kontext-Tokens pro Call. | Modell PLUS Harness. `tok/s` ist auf dieser Lane gar nicht messbar (kein Token-Stream) und steht deshalb als „nicht gemessen". |
| cursor | CLI | KEIN nativer Tool-Kanal — Schemas prompt-inliniert, wie claude-code. | Kein `--ignore-user-config`; erbt `HOME`, `XDG_CONFIG_HOME` und `CURSOR_CONFIG_DIR`. Zusätzlich ist die gehostete Variante nicht zwingend das Serving des Modell-Anbieters („Cursor Grok 4.5" ≠ zwingend x.ai-API, D15.2), und der Modell-Katalog driftete innerhalb von 24 Stunden. | Modell PLUS Harness PLUS Cursor-Serving. `tok/s` nicht messbar. |
| codex | CLI | KEIN nativer Tool-Kanal — Schemas prompt-inliniert, wie claude-code. | Die EINZIGE CLI-Lane mit `--ignore-user-config`: `~/.codex/config.toml` wird übersprungen, damit Plugin-Skills und MCP-Server nicht mitlaufen (einer blockierte auf OAuth und hing 180 s). Dazu `--ephemeral`, `--skip-git-repo-check` und Sandbox `read-only`. Die Auth löst weiterhin über `CODEX_HOME` auf. | Modell PLUS Harness — aber mit deutlich kleinerer unkontrollierter Fläche als die beiden anderen CLI-Lanes. `tok/s` nicht messbar. |
Belegstellen: eval/agentic-bakeoff/lanes/cli.mjs (OPERATIONAL_ENV_KEYS, buildArgs) · lanes/http.mjs · decisions.md D8.2 · D31 · D32
Der gemessene Beleg
Auf der ordering-v1-Metrik lagen die HTTP-Lanes bei rund 56% und die CLI-Lanes bei rund 8% Pass — ein Doppel-Confound aus dem geteilten „Call exactly one tool"-System-Prompt und der zusätzlichen CLI-Instruktion „emit exactly one entry". Das ist keine Fähigkeits-Differenz zwischen den Modellen, sondern eine Harness-Differenz zwischen den Lanes. Sie wurde zum Anlass für den korrigierten v2-Arm.
Belegstelle: eval/agentic-bakeoff/decisions.md D10.1 · report-317-wilcoxon-20260724.md
Fehlertaxonomie
Die pauschale Gruppe „Model failure" der ersten Report-Fassung war zu rund 77% ein Ordering-Artefakt (D10.2). Seither wird jeder Fehlschlag nach Kategorie aufgeschlüsselt. Diese vier Zahlen erklären in einer Zeile, warum die Headline-Rangfolge nichts trennt: der weitaus größte Block ist Lane-Infrastruktur, der zweitgrößte ein Prompt-Confounder — und nur 45 Fehlschläge sind genuine, nicht-ordering-bedingte Modellfehler.
- 523Infra (Lane-Confounder)
- Versuche, die an Timeout, HTTP 402/429/503/5xx, Netzwerk oder einem deaktivierten bzw. nicht provisionierten Endpoint scheiterten. Kein Modellversagen — aus valid-pass, Latenz und Format-Rate ausgeklammert (RUNBOOK §7, D7.2).
- 321ordering-Fails
- Multi-Call-Ordering. Der v1-Anteil ist prompt-confoundet: alle 40 Cases teilten den System-Prompt „Call exactly one tool", die CLI-Lanes zusätzlich „emit exactly one entry" — die Metrik maß, ob ein Modell den Prompt MISSACHTET. Ein gehorchendes Modell failt per Konstruktion. Nur der v2-Arm ist als Multi-Call-Fähigkeit lesbar (D10.1).
- 45genuine non-ordering Modellfehler
- Die Kategorien hard-args, tool-selection und simple-call. Das ist der Rest, nachdem Infrastruktur und Prompt-Confounder abgezogen sind — und er ist klein.
- 37abstain-Fails
- Abstentions-Disziplin: ein Pflicht-Argument erfunden oder ein Tool aufgerufen, obwohl keines passte. Das ist das genuine Capability-Signal der Kampagne und die einzige Achse mit echter Trennkraft.
Die vier Zahlen stammen aus EINEM Report, nicht aus einer Mischung mehrerer. Andere Reports derselben Kampagne zeigen andere Werte, weil sie einen anderen Shard-Korpus selektieren — sie zu addieren wäre Doppelzählung.
Belegstelle: eval/agentic-bakeoff/report-317-wilcoxon-20260724.md
Grader-Semantik
Gegradet wird deterministisch per AST-Match auf Funktionsname, Argument-Schema und Argument-Werten. Kein LLM-Judge, kein Fuzzy-Matching, keine Edit-Distanz. Der vollständige Verhaltensvertrag steht im Kopf des Graders und ist damit selbst pre-registriert; eine Änderung nach einem Run muss im Entscheidungs-Log stehen.
Orakel-Formen
Ein Case trägt entweder einen erwarteten Einzel-Call (`expected_call`), ein explizites Abstain (`expected_call: null` — das Modell DARF nicht aufrufen) oder eine geordnete Call-Folge (`expected_calls`). Dazu optional eine Case-eigene Grading-Policy.
Belegstelle: eval/agentic-bakeoff/graders/index.mjs
Per-Case-Policy
`allowExtraArgs` (Default an; aus ⇒ ein halluziniertes Zusatz-Argument lässt den Case failen), `exactlyOne` (Default aus; an ⇒ ein Einzel-Call muss genau EIN Tool feuern), `strictArgs` (an ⇒ jedes String-Argument muss exakt normalisiert übereinstimmen statt per Substring), `arrayOrder` (`strict` oder `set`). Die Defaults sind so gewählt, dass das Verhalten der ursprünglichen n=6-Suite exakt erhalten bleibt — Run-1-Vergleichbarkeit ist Teil des Vertrags.
Belegstelle: eval/agentic-bakeoff/graders/index.mjs
Werte-Grammatik je Argument
Ein Skalar-String matcht LOOSE (bidirektionale normalisierte Substring-Enthaltung, Rückwärtskompatibilität). Eine Zahl matcht über normalisierte numerische Gleichheit (verarbeitet „1.000.000", „1,000", „1_000", „ 250 "). `{ eq: v }` erzwingt strikte normalisierte Gleichheit (exakte Enums, exakte Datumsformate). `{ anyOf: [...] }` erlaubt ausdrücklich benannte Alternativen und wird sparsam eingesetzt. Arrays und Objekte matchen rekursiv strukturell.
Belegstelle: eval/agentic-bakeoff/graders/index.mjs
Was von BFCL übernommen wurde
AST-artiger Match auf Funktionsname plus Argument-Keys/Werten statt String-Gleichheit auf einem serialisierten Call (robust gegen Key-Reihenfolge und Whitespace). Eine eigene Relevanz-/Irrelevanz-Achse: ein Case, dessen richtige Antwort „kein Tool aufrufen" ist — unsere Kategorie `abstain`; ein falscher Call ist ein harter Fail. Ausdrücklich erlaubte Antwort-Alternativen pro Argument.
Belegstelle: eval/agentic-bakeoff/graders/index.mjs
Wo bewusst von BFCL abgewichen wird
Geordnete Multi-Calls sind eine erstklassige Kategorie mit POSITIONS-basiertem Matching — falsche Reihenfolge failt. BFCLs parallel-multiple ist reihenfolgenunabhängig; echte Agent-Workflows sind es nicht (suchen→buchen, umrechnen→überweisen). Dazu: eine explizite Zusatz-Argument-Policy statt BFCLs Silent-Ignore-Default, eine `exactlyOne`-Policy für Tool-Selection-Cases, bewusst NARROW gehaltene Wert-Normalisierung (keine locale-mehrdeutige Dezimal-Raterei, keine Fuzzy-Distanz) und kein weltwissen-abhängiges Gold: jeder geprüfte Wert ist durch den Prompt fixiert, nie durch einen zeitvarianten Fakt.
Belegstelle: eval/agentic-bakeoff/graders/index.mjs
Abstain-Semantik (der Ehrlichkeits-Caveat)
Eine klärende Rückfrage ohne Call ist ein Pass, ein plausibler Guess ist ein Fail. Gemessen wird damit Abstentions-DISZIPLIN, nicht Hilfsbereitschaft — das ist eine bewusste Wertung und steht als solche im Entscheidungs-Log (D7.6b).
Belegstelle: eval/agentic-bakeoff/decisions.md D7.6
Power und minimal erkennbarer Effekt
Die wichtigste Zahl dieser Seite ist keine Passrate, sondern die Fallzahl. Sie erklärt, warum die Rangfolge nichts trennt.
Das pre-registrierte Tier-Kriterium
Das RUNBOOK legt vor dem ersten Run fest: n < ~30 Cases ist „Viability", 200–400 reale, private, rotierte Cases sind „Gate". Die S1-Suite steht bei 35 Root-Cases (plus 10 Chinook-Cases) — also am unteren Rand von „Viability+", nicht bei „Gate". Das Tier steht deshalb sichtbar in jeder Zeile.
Belegstelle: eval/agentic-bakeoff/RUNBOOK.md §0.4 · cases.json (35 Cases)
Die Referenz-Rechnung aus der Literatur
Miller 2024, „Adding Error Bars to Evals" (arXiv 2411.00640), rechnet für binäre Pass/Fail-Metriken vor: rund 969 Fragen sind nötig, um eine Differenz von 3 Prozentpunkten bei 80% Power und α = 0,05 zu erkennen; die Empfehlung für neue Evals lautet ≥ 1 000 Fragen. Diese Quelle ist im Research-Memo der Kampagne festgehalten und hat auch die Umstellung auf Wilson als Primär-Intervall ausgelöst (D7.1).
Belegstelle: eval/agentic-bakeoff/research/best-practices-s1.md §1/§3
Die Konsequenz für dieses Leaderboard
Bei n = 35 ist das Wilson-95%-Intervall um eine Rate von ~91% rund 20 Prozentpunkte breit ([78–97] in der ersten Zeile). Die Suite liegt damit etwa eine Größenordnung unter der Fallzahl, die für ein 3-Prozentpunkte-MDE nötig wäre. Genau deshalb überlappen die Intervalle ALLER 21 Targets zu einem einzigen Tie-Cluster, und genau deshalb ist die Rangfolge Tie-Break-Präsentation und kein Capability-Verdikt. Das ist kein Zufallsbefund, sondern eine vorhersagbare Eigenschaft der Fallzahl.
Belegstelle: src/lib/benchmarks/bakeoff-s1.ts (leaderboard[0].headlineCi) · RUNBOOK.md §3
Was daraus NICHT folgt
Dass die Messung wertlos wäre. Sie trennt dort, wo die Effekte groß genug sind: die Abstain-Achse spreizt zwischen 20% und 100% Missing-arg-Rate, und der Ordering-v1→v2-Sprung erreicht bis zu +100 Prozentpunkte. Was sie nicht kann, ist zwei Modelle mit 91% und 94% Headline auseinanderhalten — und das behauptet sie an keiner Stelle.
Belegstelle: src/lib/benchmarks/bakeoff-s1.ts (abstain, s1b.orderingV2)
Subset-Zusammensetzung
Nicht jedes Target lief die volle Suite. Wo Budget knapp war, lief ein VOR dem Lauf festgeschriebenes, balanciertes Subset — das ist der Unterschied zwischen einer reduzierten Messung und einer nachträglich zurechtgeschnittenen. Die Leaderboard-Spalte `n` markiert solche Zeilen mit „Subset"; eine Zeile mit kleinerem n OHNE diese Markierung hat die volle Suite gefahren und Cases an die Lane verloren.
Volle T1-Suite
RUNBOOK §6 · D7.535 Root-Cases + 10 Chinook-Cases, k = 3 — 45 Cases je Target.
Fünf pre-registrierte Kategorien (simple-call, tool-selection, multi-call-ordering, abstain, hard-args), DE/EN 15/15, die Original-6 in allen model-facing und grading-relevanten Feldern byte-identisch zu Run 1. Die Chinook-Cases sind live gegen Chinook_Sqlite v1.4.5 verifiziert, SHA256 dokumentiert.
Cursor-Subset-20
D920 Cases, k = 2: 3 simple · 4 selection · 3 ordering · 4 abstain · 4 hard-args · 2 Chinook.
Balanciert über alle fünf Kategorien statt zufällig gekürzt. Der Report weist Subset-Läufe mit reduzierter n-Basis und eigenem Wilson-CI aus; ein Vergleich „Subset-Target vs. Voll-n-Target" ohne Caveat ist ausdrücklich untersagt.
Grok-Subset-12
D912 Cases, k = 1, mit aktivem 3-EUR-Budget-Guard.
Weitgehend eine Teilmenge des Cursor-Subsets — genau damit die beiden Budget-Lanes untereinander vergleichbar bleiben.
Abstain-Additions v2
D12.5 · D1414 Trap-Cases: 10 missing-required-arg und 4 no-suitable-tool, DE/EN 7/7. Separater Analysearm.
Die Abstain-Headline stand vorher auf 2 diskriminierenden Cases. Die Additions wurden VOR Sichtung neuer Ergebnisse verfasst, mit byte-identischen Tool-Schemas aus der Hauptsuite. Sie werden NIE in die Suite-Headline gepoolt. Von den 10 missing-arg-Cases sind 6 gold-trust-geflaggt; deshalb steht die Spalte „⌀ Flags" daneben, statt dass etwas still entfernt würde.
W4-v2-Protokoll
RUNBOOK §8 · D27.220 primäre Cases + 5 ordering-v2-Cases + 14 Additions, k = 2 = 78 erwartete Rows je Target.
Eine ausdrückliche Erweiterung von D9/D15, kein historisches Budget-Subset — der Report darf es auch nicht so benennen. Die Additions bleiben ein separater Arm.
aiat-Parity-Lauf
D31.4Suite-Arm: volle 45-Case-Suite × k = 3 (exakt das S1-Protokoll). Additions-Arm: 14 Cases × k = 2, eigener Shard.
Bewusst matched gegen `deepseek-v4-flash-nvidia`, damit der Lane-Vergleich ein Lane-Effekt ist und keine Protokoll-Differenz. Der Ehrlichkeits-Caveat steht in der Entscheidung selbst: die NVIDIA-Seite war bereits publiziert, der Test ist damit einseitig pre-registriert.
Entscheidungs-Log D1–D32
Append-only, mit Datum und Begründung. Die Nummerierung ist die Reihenfolge der Vergabe, nicht immer die des Eintrags — D6 wurde nach D11 protokolliert, und das steht so im Log, statt geglättet zu werden. Als „ergänzt/ändert das RUNBOOK" markiert sind die Einträge, die nach dem ersten Run an der pre-registrierten Methodik etwas verändert haben: genau dafür existiert dieses Log.
- D1
Objektiv-first Grading, kein Judge in Stage 1
AST-Grader auf Funktionsname und Argument-Keys/Werten statt LLM-Judge. Begründung: eliminiert Judge-Bias (Position, Länge, Self-Preference) und ist contamination-resistenter.
- D2
Marginal-Cost-Lane-Reihenfolge und OpenRouter-Guard
Lanes nach marginalen Kosten geordnet; harter Guard: kein OpenRouter-Call unter 3,00 EUR Restguthaben. Versunkenes Firmen-Guthaben wird vor privatem Budget verbraucht.
- D3
Deployment-Precision als eigene Achse
Quantisierung und KV-Cache-Precision werden eigene Messachsen; benchmarkt wird auf Deployment-Precision, nicht auf Headline-Precision. Ausdrücklich als Ehrlichkeits-Flag festgehalten: der EU-Winkel ist unsere eigene Ableitung, nicht die der Quelle.
- D4
Capability ≠ Latenz
Auf derselben Free-Lane lief ein Modell in 0,5–1,2 s durch, ein anderes 6× ins 60-s-Timeout. Konsequenz: die NVIDIA-Lane misst Capability, NIE Latenz. Ein Latenz-Verdikt gibt es nur auf dem Self-host-Stack. Langsam ≠ schlecht.
- D5
Stage 1 ist Viability-Tier, ehrlich gelabelt
Die erste Suite hatte n = 6 Cases und ist damit „Viability", kein Gate. Zweck war, den Harness zu de-risken, nicht ein Verdikt zu erzeugen.
- D7ergänzt / ändert das RUNBOOK
W1-Härtungs-Checkpoint
Wilson-95%-CI wird PRIMÄRES Intervall für die binäre valid-pass-Rate (ändert RUNBOOK §2; Bootstrap bleibt Sensitivität) — begründet mit Miller 2024. Dazu: Infra-Fehler als eigene Klasse aus der Capability ausgeklammert, Targets über 50% Infra werden lane-limitiert statt gerankt; Retry-Policy; Per-Target-Timeouts; Suite auf n = 40 erweitert; Abstain-Semantik-Caveat.
- D8ergänzt / ändert das RUNBOOK
Run-Guards vor den Gate-Runs
Circuit-Breaker: ab 8 konsekutiven Infra-Fehlern wird ein Target abgebrochen und als lane-limited protokolliert. Reiner Effizienz-Guard, Grading unberührt. Dazu die CLI-Lane-Findings, u. a. dass die claude-code-Lane rund 50 000 gecachte Kontext-Tokens pro Call trägt.
- D9ergänzt / ändert das RUNBOOK
Pre-registrierte Case-Subsets für Budget-Lanes
Cursor-Subset-20 (k = 2) und Grok-Subset-12 (k = 1), beide vor den Läufen festgeschrieben und über alle Kategorien balanciert. Der Report weist sie mit eigener n-Basis und eigenem CI aus.
- D10ergänzt / ändert das RUNBOOK
Konsequenzen des adversarialen Audits
ordering-v1 ist prompt-confoundet und wird NICHT als Capability gerankt; ein v2-Arm mit korrigiertem Template kommt dazu, die v1-Records bleiben append-only erhalten. Die pauschale „Model failure"-Gruppe war zu 77% Ordering-Artefakt. Ein durch parallelen Datei-Append verlorener Record bleibt fehlend und dokumentiert, statt rekonstruiert zu werden. Und: alle rankbaren Targets bilden EINEN Wilson-Tie-Cluster.
- D11ergänzt / ändert das RUNBOOK
Endpoint-Fehlerklassen der NVIDIA-Lane
„DEGRADED function cannot be invoked" wird `endpoint_degraded`, „404 Not found for account" wird `endpoint_unavailable` — beides Infrastruktur, nicht Capability. Beide Marker sind snippet-genau gescoped; generische 4xx bleiben Modell-/Request-Fehler.
- D6
Publish-Gate und eigener Standard statt Nachbau
Capability-Zahlen dürfen öffentlich werden — immer mit Lane-Angabe und Caveat-Label; Latenz und Kosten nur aus dem Self-host-Stack. Dazu die Kern-Direktive, BFCL/τ²-bench/SWE-bench kritisch zu prüfen und einen eigenen Standard zu etablieren, statt nachzubauen. (Nach D11 protokolliert.)
- D12ergänzt / ändert das RUNBOOK
Nachfahr-Welle: Grid-Lücken und Abstain-Additions
Nur FEHLENDE target×case-Paare werden nachgefahren, nicht ganze Targets neu gemessen — Letzteres wäre ergebnisgetriebenes Re-Rolling. Dazu die 14 Abstain-Trap-Cases (10 missing-arg, 4 no-tool), verfasst VOR Sichtung neuer Ergebnisse.
- D13ergänzt / ändert das RUNBOOK
Roster-Erweiterung mistral-medium-3.5
Ein EU-Origin-Mid-Tier-Peer kommt dazu, weil die EU-Headline auf der Free-Lane nicht zuverlässig messbar war. Ausdrücklich als Post-hoc-Roster-Änderung dokumentiert; Suite und Grader bleiben unverändert.
- D14ergänzt / ändert das RUNBOOK
Gold-Trust-Review und Doppel-Ausweisung
Drei geflaggte Abstain-Cases wurden einzeln adjudiziert: einer borderline-ambig, zwei legitim. Entscheid: Doppel-Ausweisung statt Entfernen — die Spalte „⌀ Flags" rechnet die geflaggten Cases heraus und steht neben der vollen Rate. Nichts wird still entfernt.
- D15ergänzt / ändert das RUNBOOK
Roster-Erweiterung und eigene Durchsatz-Messung
Kimi K3 und drei Cursor-Neuzugänge kommen dazu; die OpenRouter-Beschränkung „nur Grok" weicht auf, Budget-Gate und Subset-Protokoll bleiben. Weil die öffentliche Provider-API tok/s und Latenz als null liefert, wird die EIGENE Messung zur primären KPI — mit Pflicht-Fußnote: lane-inklusiv, cross-lane nicht vergleichbar.
- D16
Lane-, Provenance- und Redaction-Contract
Jede neue Zeile trägt vollständige Provenance-Keys und eine Harness-Version. Credentials werden nur aus einer expliziten Allowlist gelesen, bleiben in einer In-Memory-Map und landen nie in `process.env` oder im Log.
- D17
Review-Härtung (offline)
CLI-Kindprozesse erben ausschließlich eine benannte Allowlist operativer und Locale-Variablen — kein Wildcard. Ein vorhandener, aber kaputter Case-Katalog failt laut statt still. Shard-Namen sind auf das Bakeoff-Verzeichnis und ein festes Namensmuster beschränkt.
- D18ergänzt / ändert das RUNBOOK
HTTP 402 ist Infrastruktur, nicht Modellversagen
Ein Lauf lieferte 9 Passes gefolgt von 69× HTTP 402 (Funding/Provider erschöpft), abgelegt als generisches `http_4xx` — der Circuit-Breaker griff nicht, und das Target wäre als Modellversagen berichtet worden. 402 ist jetzt kanonisch Provider-Infrastruktur, auch rückwirkend in der Auswertung. Die Shards selbst bleiben unverändert.
- D19ergänzt / ändert das RUNBOOK
Coverage-Contract über erwartete Records
Ein Lauf mit 17 von 78 erwarteten Rows wurde fälschlich mit 100% gerankt, weil die Infra-Quote unter der alten 50%-Schwelle lag. Jede Zeile trägt jetzt die erwartete Record-Zahl; unvollständige Targets werden lane-limitiert, unabhängig von der Infra-Quote.
- D20
Härtung des Final-Review-Contracts
Der OpenRouter-Bearer kann nicht mehr über eine Env-Variable umgeleitet werden. Coverage ist eine Envelope-Invariante pro (run_id, target): sowohl zu wenige als auch zu viele Rows sind lane-limitiert. Fail-closed beim Start: unbekannte Targets und fehlende Credentials brechen den Lauf ab, statt als erfolgreiche Skips zu gelten.
- D21
Exakte Run-Identitäts-Matrix
Jede Zeile führt die exakte Liste der (case_id, k_idx)-Identitäten ihres Laufs mit. Damit failen auch Läufe mit korrekter Anzahl, aber falschen Cases oder falschen Wiederholungs-Indizes die Coverage-Prüfung.
- D22
Explizite Shard-Selektion für Final-Reports
Der Summarizer behält den historischen All-Shard-Default, akzeptiert aber eine explizite, basename-only Shard- und Report-Auswahl. Ungültige, fehlende, doppelte oder pfadtragende Werte failen fail-closed. So kann vollständige v2-Evidenz nicht von historischen Rows kontaminiert werden.
- D23
Redigiertes Runner-Logging
Der Runner loggt Grader-Details erst NACH der Credential-Redaction. Ein Regressionstest schmuggelt ein Credential-Sentinel in ein grader-kontrolliertes Feld und prüft, dass weder Log noch persistierte Zeile es im Klartext enthalten.
- D24
Provenance-Gate fürs Ranking
Gerankt wird nur, was vollständige oder wenigstens teilweise Provenance trägt; unbekannte und gemischte Provenance bleibt lesbar, aber lane-limitiert. Ein Caller darf den Budget-Guard verschärfen, nie aufweichen.
- D25
CLI-Hard-Timeout-Settlement
Der Timeout-Pfad signalisiert nur die eigene, abgekoppelte Prozessgruppe und beendet sofort — nie eine fremde PID. Importierte Rows, deren Timeout-Latenz über der gesetzten Deadline liegt, bekommen einen generierten Caveat und bleiben Infrastruktur.
- D26
Physische Rows vs. Capability-Universum
Coverage, Provenance und Transport werden über ALLE selektierten Rows gerechnet; Headline und Kategorien nur über den Suite-Arm. Der Additions-Arm bleibt getrennt und wird nie in die Headline gepoolt.
- D27
Selektions-bewusster Report-Kontext
Report-Header trennen sichtbar das vollständige physische Row-Universum, den Capability-Arm und den Additions-Arm — damit ein 25-Case-Capability-Universum nicht als vollständige Row-Zahl missverstanden wird. Die Fußnote zum historisch verlorenen Record ist selektions-bewusst und wird nicht auf eine Auswahl übertragen, in der er gar nicht liegt.
- D28
Kein ergebnisgetriebenes Neu-Würfeln
Die sechs verzögerten Timeout-Rows aus dem Live-Lauf bleiben Infrastruktur-Evidenz mit Caveat; der Lifecycle-Fix gilt für künftige Rows. Der Lauf wird NICHT wiederholt, nachdem die Ergebnisse bekannt sind — das wäre Selektionsbias. Und: alle drei rankbaren Targets haben überlappende Wilson-Intervalle, die Report-Reihenfolge ist reine Tie-Break-Präsentation.
- D29ergänzt / ändert das RUNBOOK
Dedupe-Regel für wiederaufgenommene Läufe
Ein nach Circuit-Breaker-Stopp fortgesetzter Lauf erzeugt eine neue Lauf-Identität und damit zwei physische Rows für denselben Case — kein Werkzeug-Fehler, aber eine irreführende Summe. Report-Regel: bei einem lauf-übergreifenden Duplikat ist die ÄLTESTE Instanz maßgeblich für „unique usable". Reine Interpretations-Ebene, kein Shard und kein Code wurde geändert.
- D30ergänzt / ändert das RUNBOOK
Cluster-Bootstrap-CI und pre-registrierte Paarvergleiche
Ein Zweit-CI auf Case-Ebene kommt dazu, Wilson bleibt primär und Tie-Cluster bleiben Wilson-Cluster. Die ehrliche Einschränkung steht in der Entscheidung selbst und widerspricht der ursprünglichen Annahme: weil unser Wilson-n schon Cases zählt, ist das Cluster-Intervall meist gleich breit oder schmaler. Dazu drei pre-registrierte gepaarte Wilcoxon-Vergleiche ohne Multiplizitätskorrektur — einer davon degeneriert (alle Differenzen exakt 0), was so ausgewiesen wird, statt einen p-Wert zu erfinden.
- D31ergänzt / ändert das RUNBOOK
Eigene Infrastruktur-Lane und Endpoint-Parity-Lauf
Eine `aiat`-Lane auf eigener Infrastruktur kommt dazu — die erste, auf der ein Latenz-Verdikt laut §2 überhaupt zulässig ist. Das Protokoll ist bewusst matched gegen den NVIDIA-Lauf desselben Modells. Ehrlichkeits-Caveat in der Entscheidung: die Vergleichsseite war bereits publiziert, der Test ist damit einseitig pre-registriert.
- D32ergänzt / ändert das RUNBOOK
Lokale Lane und Matched-Pair auf eigener Hardware
Eine `ollama`-Lane kommt NEBEN die bestehende lokale Lane, nicht an ihre Stelle. Erstmals ist die Quantisierung wirklich gepinnt und clientseitig verifizierbar. Nebenbefund, der eine bestehende Roster-Notiz korrigiert: `tool_choice` funktioniert auf dieser Lane entgegen der alten Notiz — die Notiz wird mit Datum und Version korrigiert, nicht gelöscht.
Belegstelle: eval/agentic-bakeoff/decisions.md
Kern-Befunde
Open-weight spielt auf Augenhöhe mit Closed-Frontier.
Das gesamte Ranking ist ein Wilson-CI-Tie; die Spitzengruppe der Abstain-Disziplin (>= 70%) ist durchgehend open-weight (MiniMax, Nemotron, GLM, gpt-oss, DeepSeek Flash, Mistral Large), alle US-Closed liegen bei <= 65%. Aber: open garantiert nichts (Mistral Small 4 nur 19%).
Der Serving-Kanal ändert das Verdikt radikal (wichtigster Einzelbefund).
Grok 4.5 via OpenRouter: 0/20 auf den missing-arg-Traps, schlechtester Wert des Felds. Dieselbe Modellfamilie als Cursor-gehostete Variante: 45%, und zugleich der sauberste Suite-Lauf des gesamten Felds (100% all-cat). Konsequenz für alle unsere Modell-Empfehlungen: ohne Lane-/Harness-Angabe ist ein Modell-Verdikt unvollständig. (Gleiches Muster kleiner: GLM 5.2 via Cursor 75% vs. via NVIDIA-HTTP 90% auf den Traps.)
EU-Angebot ist real konkurrenzfähig.
Mistral Large 3 95%, Medium 3.5 94%, Small 4 91% Headline; das EU-Trio führt die Tabelle über den Souveränitäts-Tie-Break an. Die Abstain-Staffel (Small 19 / Medium 70 / Large 81) ist ein Generations-, kein Größeneffekt.
Kimi K3 (Release 2026-07-16, am Release-Tag gemessen).
Platz 7, 97% [77 bis 100], aber Abstain-Traps exakt auf dem Niveau des Geschwisters K2.7 Code (60%) und Multi-Call-Ordering nur 60%. Kein Ausreißer nach oben.
GPT-5.6-Varianten sind konsistent.
Sol, Terra und Luna liefern nahezu identische Profile (Headline 85 bis 96%, Traps je 65%), die Varianten-Wahl ist für Tool-Calling zweitrangig.
Cursors Hausmodell Composer 2.5.
Solide Suite (94%), aber schwache Abstain-Disziplin (40%).
Langfrist-KPIs laufen jetzt mit.
Zu jedem Run-Block wird ein Markt-Snapshot (Provider-Pricing, Uptime, tps sobald verfügbar) append-only archiviert, plus eigene tok/s-Messung je Target (Beispiel Kimi K3: 27.1 gemessen vs. 28 laut Anbieter-Seite). Damit sind Capability und Serving-Ökonomie zum Testzeitpunkt langfristig gegenüberstellbar.
Einschränkungen
Nicht weglassbar, auch bei Weiterverwendung.
- Viability-Tier, kein Gate-Verdikt: n pro Target meist unter 30 Cases; belastbare Gate-Aussagen brauchen 200 bis 400 Cases (geplant).
- Budget-Lanes (Cursor, OpenRouter) liefen auf pre-registrierten Subsets (n=20 bzw. 25) mit eigenem CI; kein 1:1-Vergleich mit Voll-n-Targets.
- CLI-Lanes können temperature/seed nicht pinnen (beobachtete Flake-Rate bis 11%).
- 6 der 14 Trap-Cases sind Gold-Trust-geflaggt (viele Modelle failen identisch, Formulierungs-Review läuft); deshalb die Doppel-Ausweisung mit/ohne Flags.
- Latenz- und tok/s-Werte sind lane-inklusive Beobachtungen, keine Serving-Verdikte (die kommen aus Stage 4).
Methodik
Pre-registriert
Metriken, Schwellen und Entscheidungsregeln wurden VOR dem ersten Run festgeschrieben (RUNBOOK-Muster); jede Abweichung ist mit Begründung und Timestamp protokolliert (Decisions D1 bis D15), Ergebnisse append-only.
Objektiv gegradet, kein LLM-Judge
AST-Match auf Funktionsname, Argument-Schema und Werte, korrektes Abstinieren, plus DB-geerdete Chinook-Cases. 45 Cases (DE/EN gemischt), Kategorien: simple, selection, abstain, hard-args, multi-call-ordering, plus 14 separate Abstain-Trap-Cases (missing-required-arg / no-suitable-tool).
Statistik
k=2 bis 3 Repeats, valid-pass mit Wilson-95%-CI (primär), pass^k, Infra-Fehler (timeout/429/503/Congestion) werden aus der Capability-Wertung ausgeklammert und separat ausgewiesen.
Lanes (Kostenklassen)
Lokale Inferenz (gratis), NVIDIA-Free-API (gratis, gedrosselt), Claude-Code- und Codex-CLI (Subscription), Cursor-CLI (Firmen-Guthaben), OpenRouter (metered, nur für Modelle ohne andere Lane). Wichtig: Latenzwerte der Free-Lanes sind KEIN Verdikt, Latenz-/Kosten-Verdikte entstehen erst in Stage 4 auf eigenem Serving.
Ehrlichkeits-Layer
Eine erste Ordering-Metrik (v1) war prompt-confoundet ("call exactly one tool" galt auch für Multi-Call-Cases); ein adversarialer Verify fand das, v2-Arm korrigierte es. v1 bleibt sichtbar, wird aber nicht gerankt. Genau diese Methodik-Story ist der Differenzierungs-Ansatz gegenüber fertigen Benchmarks.
Kosten und Reproduzierbarkeit
Fast alles lief auf marginal kostenfreien Lanes (lokal, NVIDIA-Free, Subscriptions, Firmen-Guthaben); der einzige metered Lauf (Kimi K3 via OpenRouter, 78 Records) kostete rund 0,42 EUR. Harness: pre-registriertes RUNBOOK, append-only JSONL-Shards, deterministische Report-Generierung; ein Dritter kann den Aufbau 1:1 nachstellen (Cases, Grader-Tests, Provenienz-Pins dokumentiert). Quell-Harness liegt derzeit in einem privaten Repo; bei Publikation können Cases + Grader + RUNBOOK als sanitized Fork veröffentlicht werden.
Rohdaten
5.215 gegradete Attempt-Zeilen aus 51 append-only Shards, auf zehn Spalten projiziert. Ein Export, keine Neuberechnung: abgeleitet sind nur category (aus dem Case-Katalog, exakt wie der Summarizer kanonisiert) und infra_class (aus der Harness-Funktion, RUNBOOK §7). Wichtig beim Lesen: (target, case_id, k_idx) ist KEIN Primärschlüssel — Gap-Fill-, Resume- und Recheck-Läufe haben weitere Attempts für denselben Slot angehängt, und der Summarizer zählt sie alle (D29 regelt, wie sie zu lesen sind). Dedupliziert wird hier nicht, das wäre eine Neuberechnung.