TokenLab Fusion: Erkenntnisse aus dem DRACO Weighted-100 Research Dataset

Hinweis zum Forschungsstatus: TokenLab Fusion: Dies ist ein „Proof-of-Recipe“, ein historisches Forschungsergebnis mit starker Baseline, kein Anspruch auf Produktionsreife. Die Ergebnisse wurden unter Verwendung eines Premium-Gemini-Ankers erzielt; ein Canary-Run ohne Premium-Modell sowie ein abschließender, reiner Fusion-Rerun stehen noch aus, um die Reproduzierbarkeit ohne Premium-Abhängigkeiten zu bestätigen. DRACO weighted-100 ist eine proprietäre interne Evaluierung von TokenLab und kein externer oder standardisierter Benchmark. Bitte entsprechend interpretieren.

Abstract

Dieser Bericht dokumentiert den aktuellen Beweisstand von TokenLab Fusion, einem Multi-Modell-Orchestrierungssystem zur Laufzeit, das gegen eine feste, mit 100 gewichteten Aufgaben versehene, bereichsübergreifende Forschungssuite (das DRACO weighted-100 Forschungsmanifest, das Finanzen, Shopping/Produktvergleich, Akademisches, Technologie, Allgemeinwissen, UX-Design, Recht, Medizin, Needle-in-a-Haystack und personalisierte Assistenzaufgaben abdeckt) evaluiert wurde. Die zentrale Forschungsfrage ist nicht, ob ein Ensemble von Modellen einen höheren Gesamtwert als ein einzelnes Modell in einem Benchmark-Segment erzielen kann, sondern ob ein diszipliniertes Rezept (Panel-Zusammensetzung, Synthese, rubrikbasierte Validierung, Quellenbeschaffung und Kostenrechnung) in ein reproduzierbares, auditierbares und erweiterbares System organisiert werden kann, das starke Single-Model-Baselines über alle Bereiche hinweg schlägt, nicht nur in einer günstigen Teilmenge.

Die stärksten Belege stammen bisher aus dem weighted-100 Forschungslauf, einer gepaarten, Baseline-gestützten Evaluierung gegen gpt-5.5 und claude-opus-4-8 auf dem festen 100-Aufgaben-DRACO-Datensatz. TokenLab Fusion erzielte einen Mittelwert von 86.04, mit einem gepaarten Mittelwert-Delta von +32.60 gegenüber gpt-5.5 (Win/Loss/Tie 95/4/1, Kosten 0.71x, Score-pro-Dollar 2.26x) und +45.63 gegenüber claude-opus-4-8 (Win/Loss/Tie 97/2/1, Kosten 0.69x, Score-pro-Dollar 3.06x). Diese Zahlen sind stark, gepaart und gegenüber einem festen Manifest reproduzierbar, aber sie unterliegen zwei wichtigen Einschränkungen, die dieser Bericht als erstklassige Erkenntnisse und nicht als Fußnoten behandelt: Das erfolgreiche Rezept verwendete ein historisches Premium-Gemini-Pro-Modell (gemini-3.1-pro-preview) als Anker für Synthese/Urteil/Validierung, und der Release-Status des Systems erfordert noch einen abschließenden, reinen Fusion-Rerun, bevor das Ergebnis als vollständig bezeichnet werden kann. Der Rest dieses Berichts trennt das, was im Forschungsdurchlauf mit starker Baseline bewiesen wurde, von dem, was vor einem Produktionsanspruch noch aussteht, und legt die spezifischen Beweise dar, die noch benötigt werden – am dringendsten ein Canary-Run ohne Premium-Gemini –, um diese Lücke zu schließen.

1. Forschungsumfang und Zielsetzung

TokenLab Fusion wird hier als Orchestrierung zur Inferenzzeit über mehrere Upstream-Modelle definiert, nicht als trainiertes Modell mit zusammengeführten Gewichten. Eine einzelne Anfrage wird durch verschiedene Modellrollen geleitet (Panelist, Synthesizer, Validator, Richter, Reviewer, Tool-Owner), und das Rezept steuert, wie Ausgaben generiert, verglichen, umgeschrieben und zurückgegeben werden. Dies kommt einer verifizierbaren Multi-Modell-Produktionskonfiguration näher als einer zustandslosen Ensemble-Abstimmung; es teilt strukturelle Gemeinsamkeiten mit Mixture-of-Agents und LLM-Blender, obwohl der unten beschriebene Apparat für Rezeptauswahl und Kostenrechnung über beide hinausgeht.

Das Evaluierungsziel ist die weighted-100 Forschungssuite: ein fester Satz von bereichsübergreifenden, beweisdichten und streng nach Rubrik bewerteten Forschungsaufgaben. Das Forschungsprogramm lehnt Vergleiche mit schwachen Baselines explizit ab. Die einzigen akzeptierten Baselines sind gpt-5.5 und claude-opus-4-8, und beide werden strikt aus den Rollen Panel, Synthese, Richter, Validator und Tool-Owner herausgehalten; eine Kontamination des Panels mit dem Baseline-Modell würde jeden Anspruch, dass ein „günstigeres Multi-Modell-Rezept ein starkes Single-Model schlägt“, entwerten.

Die in diesem Papier referenzierten Modellkennungen – gpt-5.5, claude-opus-4-8, gemini-3.1-pro-preview, deepseek-v4-pro und glm-5.2 – sind logische Modell-IDs der TokenLab Fusion-Plattform und Forschungs-Baseline-IDs, die aus dem am 2026-07-07 beobachteten TokenLab Model Single-Source-of-Truth (SSOT)-Snapshot stammen. Diese Kennungen bezeichnen interne Routing- und Evaluierungslabels und keine unabhängige, öffentlich auditierte Bestenliste. Es wird nicht behauptet, dass diese Namen eins zu eins mit den öffentlichen Veröffentlichungsnamen eines externen Anbieters korrespondieren. Kennungen wie gpt-5.5 und claude-opus-4-8 sind interne Baseline- und Routing-Labels aus der TokenLab SSOT und sollten nicht als offizielle Modellbezeichnungen der Anbieter interpretiert werden. Folglich sollten die Vergleiche mit starken Baselines in diesem Papier nicht als vollständiger Anspruch auf Produktionsreife gelesen werden: Die Canary-Evaluierung ohne Premium-Gemini und der verbleibende reine Fusion-Rerun sind noch nicht abgeschlossen und unterliegen weiterer Validierung. Die hier präsentierten Ergebnisse stellen einen Forschungsvergleich zu einem bestimmten Zeitpunkt dar, kein finalisiertes oder vollständig validiertes Produktions-Benchmark-Ergebnis.

Zwei Produktlinien teilen sich diese Forschungsinfrastruktur, unterscheiden sich jedoch im Rezept: eine Deep-Research-Linie (evidenzbasiert, quellenvalidiert, validator-lastig) und eine Coding-Agent-Linie (tool-ausführungsintensiv, latenzsensibel, noch vor Phase-0). Dieser Bericht befasst sich primär mit der Deep-Research-Linie, da hier gepaarte Beweise gegen starke Baselines existieren.

2. Warum ein festes 100-Aufgaben-Manifest

Ein Benchmark-Durchlauf mit nur einem Segment kann keine Rezeptentscheidungen stützen. Das 100-Aufgaben-Manifest dient gleichzeitig sechs verschiedenen technischen Funktionen: bereichsübergreifende Rezeptauswahl (Vermeidung von Overfitting auf ein glückliches Segment), Trainingsdaten für Router-Richtlinien, Nachweise für die Zuweisung von Modellrollen, Erstellung von Kosten-/Qualitäts-/Latenzkurven, eine Fehlerbibliothek für Regressionstests und zukünftige Modell-Upgrade-Canaries sowie ein wiederverwendbares, geschichtetes Regressionsset, das nicht bei jeder Änderung eines Upstream-Modells einen vollständigen Rerun erfordert.

Das in den berichteten Experimenten verwendete Manifest ist weighted-100-v1, ein deterministisches gewichtetes Segment mit einem festen Aufgaben-Hash (b08a09aacbc76c5e5aafd5ca0a6fa614a5061bc478f905007ae5aee4a93fc43a). Die Gewichtung der Bereiche ist nicht gleichmäßig: Finanzen (20), Shopping/Produktvergleich (16), Akademisches (12), Technologie (10), Allgemeinwissen (9), UX-Design (9), Recht (6), Medizin (6), Needle-in-a-Haystack (6), Personalisierte Assistenz (6). Diese Verteilung ist wichtig, da die Gewinne von Fusion bereichsabhängig sind und insbesondere Finanzen das hartnäckigste offene Risiko birgt (Abschnitt 6).

DRACO weighted-100 ist ein interner Forschungsdatensatz von TokenLab, der ausschließlich innerhalb der TokenLab Fusion-Evaluierungspipeline dieses Papiers verwendet wird. Er ist kein externer, öffentlich gepflegter Benchmark und ist nicht mit einer Benchmark-Suite Dritter verbunden, von dieser unterstützt oder daraus abgeleitet. Das weighted-100-Manifest, einschließlich seiner Stichprobenziehung, des Kategorien-Gewichtungsschemas und der Herkunftsmetadaten, wird durch eine private TokenLab-Quellenkarte gesteuert, die nicht mit diesem Papier veröffentlicht wird. Die berichteten Scores sollten daher als interne Vergleichssignale interpretiert werden, die spezifisch für die Evaluierungsmethodik von TokenLab sind, und nicht als Scores, die mit öffentlichen Bestenlisten oder Community-Benchmarks vergleichbar sind. Leser sollten nicht davon ausgehen, dass sich die Ergebnisse von DRACO weighted-100 auf andere Datensätze mit ähnlichem Namen oder ähnlicher Struktur verallgemeinern oder mit diesen referenzieren lassen.

3. Methodik

Der Forschungszyklus ist evidenzbasiert: Jeder starke Anspruch muss auf ein festes Manifest, Aufgaben-IDs, Bereichsgewichtungen, Laufzeiteinstellungen, Rohergebnisdateien, Kostenzeilen und Baseline-Zeilen zurückführbar sein. Aggregierte Zusammenfassungen ohne diese Artefakte werden nicht als Beweis behandelt.

Vier methodische Verpflichtungen sind am wichtigsten.

Geteilte Evidenz statt opaker nativer Suche

Such-, Abruf- und Lesetools erzeugen ein Evidenzpaket außerhalb der zu testenden Modelle, und dasselbe Paket wird, wo immer möglich, sowohl dem Panel als auch den Baseline-Modellen zur Verfügung gestellt. Dies isoliert die Frage „Kann das Modell gut schlussfolgern und synthetisieren?“ von „Hat das Modell zufällig gut gesucht?“, und ist eine strikte Anforderung für Proof-Runs der weighted-100 Forschungssuite, Vergleiche mit starken Baselines, Modell-Upgrade-Canaries und abschließende Reruns.

Rollenspezifische Kostenrechnung

In einem Baseline-gestützten Lauf vermischt die aggregierte Kostenspalte Fusion-Aufrufe und Baseline-Aufrufe; eine direkte Verwendung würde den Anspruch auf die Kosten von Fusion allein über- oder unterbewerten. Die Analyse des weighted-100 Forschungslaufs schließt Baseline- und Baseline-Score-Zeilen explizit aus, um auf eine offizielle Summe für Fusion allein von $12.837461 über 799 Kostenzeilen zu kommen. Diese Unterscheidung – rollenspezifische Kostenzeilen statt vermischter Summen – ist die Grundlage für jeden kostenbereinigten Qualitätsanspruch in diesem Bericht.

Gepaarter Vergleich statt ungepaarter Mittelwerte

Die Ausgaben von Fusion und Baseline werden bei identischen Aufgaben-IDs verglichen, und die Ergebnisse werden als Mittelwert-Delta, Bootstrap-Konfidenzintervall, Sign-Test-p-Wert, Win/Loss/Tie-Anzahl, Kostenmultiplikator, Latenzmultiplikator und Fehlerquoten-Delta berichtet. Ungepaarte Mittelwerte mit unterschiedlicher Aufgabenabdeckung werden nicht als Beweis akzeptiert.

Resumierbare, geshardete Ausführung

Der weighted-100 Forschungslauf wurde in zehn Shards zu je zehn Aufgaben ausgeführt und dann zu einem einzigen Beweisartefakt aggregiert. Der abschließende reine Fusion-Rerun (Abschnitt 6) verwendet dasselbe gestufte, resumierbare Muster.

Methodendimension	Verwendeter Ansatz	Begründung
Aufgabenauswahl	Festes gewichtetes 100-Aufgaben-Manifest, gehasht	Verhindert Cherry-Picking, ermöglicht Reruns
Evidenzbeschaffung	Geteiltes, reproduzierbares Evidenzpaket	Isoliert Schlussfolgerungsqualität von Suchglück
Baseline-Isolation	gpt-5.5, claude-opus-4-8 aus Panel/Synth/Richter/Validator ausgeschlossen	Verhindert Baseline-Kontamination des Fusion-Anspruchs
Kostenrechnung	Rollenspezifische Zeilen; Fusion-only Summen schließen Baseline-Aufrufe aus	Vermeidet Verzerrung durch vermischte Kosten
Vergleichsdesign	Gepaart, gleiche Aufgaben-IDs, Bootstrap-KI, Sign-Test	Kontrolliert Bereichs- und Stichprobenvarianz
Ausführung	Geshardete, resumierbare Runner	Ermöglicht Fortschrittsverfolgung und gestufte Reruns
Bewertung	Rubrikbasierte Validator/Richter-Bewertung gegen Bereichsrubriken	Ermöglicht Validator-Ablation und Score-Dekomposition

TokenLab Fusion bewertet Modellausgaben durch eine automatisierte Bewertungspipeline, die mehrere Metriksignale zu einem Gesamtscore aggregiert. Bewertungsregeln werden in diesem Stadium programmatisch ohne manuelle Überprüfung angewendet. Öffentliche Daten zu menschlichen Audits oder Inter-Rater-Übereinstimmungen für diese Methode wurden noch nicht veröffentlicht; die berichteten Ergebnisse spiegeln nur die automatisierte Evaluierung wider, bis eine unabhängige Verifizierung vorliegt.

Datenverfügbarkeit

Der Manifest-Hash, die Kostenzeilen, die Rohergebnisdateien, der Snapshot der Modell-Single-Source-of-Truth und die Quellenkarte, die dieser Studie zugrunde liegen, werden im internen Forschungsarchiv von TokenLab aufbewahrt. Diese Materialien sind zugangsbeschränkt und werden nicht mit diesem Papier veröffentlicht. Folglich ist die öffentliche Reproduzierbarkeit begrenzt, bis eine geschwärzte Stichprobe oder eine öffentliche Teilmenge der zugrunde liegenden Daten veröffentlicht wird.

4. Rezeptentwicklung: Mehr Modelle sind nicht der Hebel

Eine frühe und wichtige Erkenntnis ist negativ: Das Hinzufügen weiterer Modelle zum Panel verbessert die Qualität nicht zuverlässig und kann nicht als gegeben vorausgesetzt werden. Das Rezept entwickelte sich durch eine Sequenz kontrollierter Ablationen, anstatt die Panelgröße zu skalieren.

Schneller Kern als Kontrollgruppe

Ein kostengünstiges, diverses, stabiles Drei-Modell-Panel (gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning) dient als Kosten-/Latenz-Kontrollbedingung, gegen die jede Ergänzung und jede Validator-Variante gemessen wird.

Konkreter kostengünstiger Modell-Mix

TokenLab Fusion ist eine Orchestrierungsschicht zur Inferenzzeit und kein Modell mit zusammengeführten Gewichten: Es koordiniert Aufrufe an mehrere bestehende Modelle und kombiniert deren Ausgaben zur Laufzeit. Um dies zu konkretisieren: Die Basismodelle gpt-5.5 und claude-opus-4-8 sind von jeder Fusion-Rolle ausgeschlossen – Panel, Synthese, Beurteilung, Validierung, Überprüfung und Tool-Owner –, sodass die berichteten Leistungssteigerungen nicht auf eine versteckte Arbeit dieser Basismodelle innerhalb der Pipeline zurückgeführt werden können.

Die Standardkonfiguration ist ein schnelles, kostengünstiges Kontrollpanel aus drei parallel laufenden Modellen, ergänzt durch einen optionalen vierten Panelisten im Qualitätsmodus, einen historischen Anker zum Nachweis der Leistungsobergrenze sowie einen „No-Premium“-Canary-Kandidaten, für den noch gepaarte Nachweise ausstehen.

Rolle	Modell(e)	Status
Schnelles, kostengünstiges Kontrollpanel	gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning	Geprüftes Standard-Niedrigkostenpanel
Qualitäts-Add-back-Kandidat	kimi-k2.7-code	Als vierter Panelist evaluiert; nicht übernommen – erhöht Latenz, Regression in einigen Bereichen mit Validator
Historischer Leistungsanker	gemini-3.1-pro-preview	Verwendet für Synthese/Beurteilung/Validierung/Revision im Strong-Baseline-Rezept; belegt Obergrenze, nicht der angestrebte Produktkostenpfad
„No-Premium“-Canary-Kandidat	deepseek-v4-pro (Synthese/Validierung/Revision), glm-5.2 (unabhängiger Richter)	Angestrebter Kostenpfad; ausstehende gepaarte Canary-Nachweise

Die Orchestrierung erfolgt als feste Sequenz und nicht als ungeordneter Aufruf von Modellen:

1. Einmalige Erstellung eines gemeinsamen Beweispakets, sodass jeder Panelist auf Basis identischer Kontexte schlussfolgert.
2. Parallele Ausführung der kostengünstigen Panelisten gegen dieses Beweispaket.
3. Normalisierung der Panel-Ausgaben in ein gemeinsames Format zum Vergleich.
4. Durchführung einer Panel-Analyse, um Übereinstimmungen, Konflikte und fehlende Beweise aufzuzeigen.
5. Synthese einer einzigen Antwort, anschließende Ausführung eines rubrikbasierten Validators und einmalige Überarbeitung, falls der Validator Probleme meldet.
6. Bewertung/Beurteilung der finalen Antwort durch einen dedizierten Tool-Owner – Panelisten führen Tools niemals direkt aus.

Das Ergebnis von kimi-k2.7-code sowie der ausstehende Canary-Kandidat deepseek-v4-pro/glm-5.2 werden getrennt von den Standard-Panel-Zahlen berichtet, um eine Vermischung von evaluierten, aber evaluierten, aber nicht übernommenen Konfigurationen mit dem angestrebten Produktkostenrezept zu vermeiden.

Kimi-Ergänzung: ein reales, aber marginales Signal

Ein Pilotprojekt mit 20 Aufgaben, das ein Coding-/Diversitätsmodell zum schnellen Kern hinzufügte, ergab einen mittleren Score von 34.36 gegenüber 31.37 beim schnellen Kern (gepaartes Delta +2.99, 95% KI -0.04 bis 6.10, Win/Loss/Tie 11/6/3, Kosten ~1.01x, Latenz ~1.57x). Da das KI die Null umschließt und der Sign-Test-p-Wert bei 0.3323 liegt, ist dies nicht stark genug, um die Ergänzung zu einem latenzsensiblen Standard zu machen; es gab zudem Regressionen bei einigen Aufgaben in Akademischem, Medizin und Technologie. Die Schlussfolgerung ist rollenspezifisch: Diese Modellklasse wird besser als Spezialist für Coding/Front-End/langen Kontext behandelt denn als allgemeiner, ständig aktiver Panelist.

GLM- und DeepSeek-Pro-Ergänzungen benötigen Rollen, keine pauschale Aufnahme

Eine GLM-Ergänzung erbrachte nur etwa +1.22 bei 1.49x Kosten und 1.85x Latenz auf einem kleinen Segment – nützliche Evidenz für eine Richter-/Synth-/Coding-Reviewer-Rolle, aber keine ausreichende Evidenz für eine Standard-Panel-Promotion. Die Evaluierung von DeepSeek V4 Pro änderte sich materiell nach einer Preiskorrektur (Input $0.435, Output $0.87 pro 1M Token), was ein früheres „zu teuer“-Urteil entwertete und es zu einem führenden Kandidaten für eine Synth-/Validator-Rolle in einem kostengünstigeren Rezept erhob (Abschnitt 6). Die Preiskorrektur für DeepSeek V4 Pro leitet sich aus der internen Modell-SSOT vom 2026-07-07 ab und stellt eine Forschungskostenannahme dar, keine Zitierung eines externen, vom Anbieter veröffentlichten Preises.

Validator/Umschreiben ist der größte gefundene Einzelhebel

Bei einer Erweiterung um 20 Aufgaben führte das Hinzufügen einer rubrikbasierten Validator-/Umschreibestufe zum schnellen Kern zu einem mittleren Score von 81.70 gegenüber 29.88 für den schnellen Kern allein, ein gepaartes Delta von +51.81 (95% KI 42.64 bis 61.23), Win/Loss/Tie 20/0/0, bei 2.14x Kosten und 1.89x Latenz. Dies ist keine inkrementelle Verbesserung; es ist eine strukturelle Verschiebung dessen, wozu das Rezept fähig ist. Es ist auch nicht kostenlos: Der Kostenmultiplikator überschritt in einem Analysedurchgang die automatische Beibehaltungsschwelle von 2.0x, was bedeutet, dass dasselbe Ergebnis, das für eine Deep-Research-Ebene eindeutig wertvoll ist, eine echte Einschränkung für eine schnelle/günstige Produktebene darstellt. Günstigere Alternativen wurden getestet und als Standards abgelehnt: Eine Lite-Review/Lite-Stack-Variante verlor etwa 28 Punkte gegenüber der vollständigen Validierung und verlor jeden gepaarten Vergleich; selektive Validierung basierend auf Heuristiken schwacher Bereiche sparte nur etwa 11% der Kosten bei einem Verlust von -8.53 im mittleren Score, und eine Variante nur für Hochrisikofälle verlor noch mehr. Selektive Validierung bleibt daher ein offenes Routing-Forschungsproblem, keine gelöste Technik zur Kostenreduktion.

5. Ergebnisse mit starker Baseline: Was bewiesen wurde

Der weighted-100 Forschungslauf mit starker Baseline ist das stärkste Evidenzartefakt im Programm. Er hält gpt-5.5 und claude-opus-4-8 als reine Baseline-Vergleicher, die aus jeder Fusion-Rolle ausgeschlossen sind.

Zusammenfassung für Fusion-only über die 100 Aufgaben:

Metrik	Wert
Mittlerer Score	86.04
Offizielle Gesamtkosten	$12.837461
Offizielle mittlere Kosten	$0.128375
Plattform-Gesamtkosten	$6.568959
Score pro offiziellem Dollar	670.21
Fehlgeschlagene Aufrufe	0
Fehlerrate	0.0%
Mittlere Aufruflatenz	216.4s
Kostenzeilen	799
Aggregierte Fallback-Aufgaben	0

Der berichtete Wert von 670.21 bezeichnet den rohen Mittelwert von Fusion-only geteilt durch die offiziellen mittleren Kosten von Fusion-only, während die 2.26x und 3.06x-Zahlen gepaarte, Baseline-relative Score-pro-Dollar-Multiplikatoren darstellen, die gegen abgestimmte Vergleichskonfigurationen berechnet wurden.

Gepaarter Vergleich gegen die zwei starken Baselines:

Baseline	Baseline mittlerer Score	Fusion Delta	95% KI	Win/Loss/Tie	Fusion Kosten-Multiple	Score/$ Verhältnis	Latenz-Multiple
gpt-5.5	53.43	+32.60	28.13 – 37.28	95/4/1	0.71x	2.26x	1.23x
claude-opus-4-8	40.41	+45.63	40.85 – 50.21	97/2/1	0.69x	3.06x	2.15x

Qualität und kostenbereinigte Qualität sind eindeutige Fusion-Siege auf diesem Manifest. Ein Fehlerquoten-Delta von 0.0 Prozentpunkten macht Stabilität zu einem Unentschieden statt zu einem Differenzierungsmerkmal. Latenz ist ein klarer Fusion-Verlust: 1.23x langsamer als gpt-5.5 und 2.15x langsamer als claude-opus-4-8. Das ehrliche Produkt-Framing aus diesen Daten ist qualitativ hochwertige, kosteneffiziente, verifizierbare Deep Research, kein interaktiver Chat mit niedriger Latenz.

Die Bereichsaufschlüsselung zeigt positive Deltas in jedem Bereich gegenüber beiden Baselines, was dagegen spricht, dass die Verbesserung ein Artefakt eines einzelnen Bereichs ist. Ausgewählte Werte: gegen gpt-5.5, Finanzen +37.13, Shopping +38.20, Needle-in-a-Haystack +62.56, Technologie +33.49; gegen claude-opus-4-8, Shopping +55.96, Needle-in-a-Haystack +69.38, Technologie +52.43, UX-Design +52.77. Finanzen ist auch der Bereich mit dem klarsten ungelösten Risiko: acht Warnungen vor unzureichender Evidenz mit hohem Schweregrad, alle im Bereich Finanzen, markiert als finance:needs_more_sources, unter Hinweis auf Lücken bei Metrikbegriffen, Periodenbegriffen und der Beschaffung für die aktuelle Primärperiode. Dies sind keine Aufruffehler; es sind Warnungen zur Quellenhinlänglichkeit, die darauf hindeuten, dass das finanzspezifische Evidenz-Routing noch nicht vollständig gelöst ist, selbst dort, wo das Score-Delta groß ist.

6. Bereitschaftsstatus: Bewiesen vs. noch blockiert

Es ist wichtig, zwei Statusebenen zu trennen. Dies ist ein „Proof-of-Recipe“-Ergebnis, kein Ergebnis eines ausgelieferten Systems, und die Bereitschaftsverfolgung, die im gesamten Programm verwendet wird, spiegelt diese Unterscheidung explizit wider.

Bestanden: festes gewichtetes 100-Aufgaben-Manifest, Panel-Richtlinie, Evidenz-Router-Shakedown, Panel-Ablationsbeweis, Validator/Synth-Ablationsbeweis, die Konfiguration mit starker Baseline selbst, der Beweis für schwache Quellen-Gates, Rezeptartefakte und der in Abschnitt 5 beschriebene gepaarte Beweis mit starker Baseline.

Noch nicht bestanden: der abschließende reine Fusion-Rerun.

Der abschließende Rerun ist kein zweiter Vergleich gegen die starken Baselines; sein Zweck ist anders und enger gefasst: Bestätigen, dass das eingefrorene erfolgreiche Rezept auf demselben 100-Aufgaben-Manifest ohne Baseline-Kosten im Lauf reproduziert wird, dass die Laufzeitkonfiguration mit der Rezeptdefinition übereinstimmt, dass die Kostenzeilen vollständig sind und dass es keine Baseline-Kontamination im reinen Fusion-Pfad gibt. Stand des letzten gestuften Laufs: Abdeckung bei 20 von 100 Aufgaben bewertet, 20 von 20 laufzeitkompatibel, offizielle Kosten für Fusion-only von $2.619654, Baseline-Kosten $0, wobei die verbleibenden 80 Aufgaben in weiteren versetzten Stufen ausgeführt werden.

Diese Unterscheidung ist wichtig dafür, wie die Zahlen des weighted-100 Forschungslaufs gelesen werden sollten: Das Delta der starken Baseline ist real und gepaart, aber es wurde mit einem Rezept gemessen, das noch nicht unabhängig von Ende zu Ende ohne Baseline-Kosten in der Schleife reproduziert wurde, und es verwendete einen Synthese-/Validator-/Richter-Anker, den der produktkostenorientierte Pfad bewusst auslaufen lassen will.

Speziell zum Gemini-Pro-Anker: Das eingefrorene Rezept, das diese Zahlen produzierte, verwendete gemini-3.1-pro-preview, ein historisches Premium-Gemini-Pro-Modell, als Anker für Synthese/Richter/Validator. Diese Konfiguration legt die Obergrenze dessen fest, was Rezeptstruktur und rubrikbasierte Validierung erreichen können, aber es ist nicht die Konfiguration, die der produktkostenorientierte Pfad ausliefern will. Da die Preisgestaltung für Premium-Gemini-Pro nicht in das Ziel-Kostenprofil passt, ist das nächste erforderliche Evidenzartefakt ein Canary-Run ohne Premium-Gemini: ein gepaarter Rerun in kleinerem Maßstab, bei dem deepseek-v4-pro für Synthese/Validierung und glm-5.2 für die Bewertung eingesetzt wird, ausgeführt gegen dieselben Aufgaben-IDs, bevor irgendein Anspruch erhoben wird, dass das kosteneffiziente Rezept die bewiesene Qualitätsobergrenze erreicht.

7. Protokoll und Kompatibilität: Warum ein Chat-Endpunkt nicht ausreicht

Ein Rezept, das nur gegen einen einzelnen OpenAI-kompatiblen Chat-Endpunkt funktioniert, wird den Kontakt mit echten Coding-Agent-Clients nicht überleben. Chat Completions ist ausreichend für einfache Konversationen, lässt aber Semantiken fallen, von denen Agent-Clients abhängen: typisierte Ausgabe-Items, Function-Call/Tool-Result-Paarung, gestreamte Item-Events, zustandsbehaftete versus zustandslose Historie und anbieterspezifische Reihenfolgegarantien.

Die Oberflächen, die wichtig sind, und die Semantiken, die jede trägt, unterscheiden sich so stark, dass sie nicht ohne Verlust in eine Form gebracht werden können:

Oberfläche	Wichtige Semantiken, die erhalten bleiben müssen
OpenAI Responses	typisierte Ausgabe-Items, Hierarchie der Entwickler/System-Anweisungen, Funktionsaufrufe und Ausgaben von Funktionsaufrufen, previous_response_id, store, gestreamte Item-Events, Nutzungsabrechnung
OpenAI Chat	Legacy-Nachrichten/Tools; als degradierte Fassade nutzbar, aber Kompatibilitätsverluste müssen protokolliert werden
Anthropic Messages	Top-Level-Systemfeld, Inhaltsblöcke, tool_use/tool_result, zustandslose Anfragen mit vollständiger Historie, stop_reason, Stream-Fehler nach 200
Codex-style Client-Profil	Responses-first, store, previous_response_id, gestreamte Tool-Argumente, Tool-Result-Replay, strikte Ereignisreihenfolge
Claude Code-style Client-Profil	Anthropic Messages, unmittelbare tool_result-Reihenfolge, parallele Tool-Batches, disable_parallel_tool_use, Allowlisten für Modell-Discovery

Die architektonische Antwort ist eine kanonische Zwischenrepräsentation (IR). Externe Protokolle werden auf eine interne Repräsentation von Anfrage/Antwort/Stream/Tool/Nutzung/Fehler/Trace abgebildet, und Rezeptausführung sowie Anbieteradapter operieren gegen diese IR statt gegen ein einzelnes Drahtprotokoll. Die IR muss mindestens tragen: Konversations- und Turn-Kennungen sowie Zeiger auf den Anbieterzustand (previous_response_id); Client-Protokoll und öffentliche Rezeptkennung; Herkunft und Vorrang von System-/Entwickler-/Gateway-/Rezeptanweisungen; Nachrichten, Inhaltsblöcke, Bilder und abgeleiteter Text; Tools, Tool-Ergebnisse, Tool-Wahl und Richtlinie für parallele Tools; Modalitäten und Generierungseinstellungen; eine Aufzeichnung von Kompatibilitätsverlusten; Nutzungszeilen und rollenspezifische Kostenzeilen; sowie einen Trace, der Evidenz-, Such-, Tool-, Kosten- und Modellrollenaktivität abdeckt.

Die praktische Rechtfertigung ist konkret: Anthropic's tool_result muss unmittelbar auf sein passendes tool_use folgen; Ausgaben von Funktionsaufrufen bei OpenAI Responses müssen per call_id wiederholt werden; eine Chat-Fassade kann die Priorität von Entwicklernachrichten nicht vollständig wahren; Claude Code sendet bei jedem Turn die zustandslose vollständige Historie, während Responses-basierte Clients auf einen anbieterseitigen Zustandszeiger angewiesen sind. Ohne eine IR und eine Kompatibilitätssuite, die diese Fälle direkt ausübt, kann ein System einen Benchmark bestehen und dennoch innerhalb eines echten Agent-Clients scheitern, weil die Tool-Schleife nie korrekt abgeschlossen wird.

Der aktuelle Implementierungsstatus sollte präzise statt optimistisch angegeben werden: Die Kompatibilitätsschicht existiert als Protokolldokumentation, Adapter-IR-Definitionen, Gateway-Vertrags-Fixtures, ein Turn-Planer, ein Stream-Writer, Tool-/Evidenz-Fixtures. Es ist ein Offline-Kompatibilitätsskelett, ausreichend, um Protokollformen einzuschränken, Lücken aufzudecken und frühe Design-Drifts zu verhindern, aber es ist noch kein Live-Produktions-Gateway. Es beinhaltet noch keine echte Anbieterausführung in großem Maßstab, eine Client-seitige Streaming-Produktoberfläche, Live-Tool-Ausführung, Produktionsauthentifizierung/-mandantenfähigkeit oder ein persistentes Trace-Backend. Die öffentliche Modell-Discovery ist so konzipiert, dass nur namensraumbezogene öffentliche Rezeptkennungen offengelegt werden; jede Anfrage für eine nicht-öffentliche oder nicht-namensraumbezogene Modell-ID sollte geschlossen fehlschlagen (z. B. model_not_public), anstatt einem Client zu erlauben, Rezept-, Kosten- oder Trace-Grenzen zu umgehen.

8. Kontrollmodell für Tool-Nutzung

Multi-Modell-Tool-Aufrufe sind der operationell gefährlichste Teil jeder Coding-Agent-Erweiterung dieses Systems. Wenn mehrere Modelle unabhängig voneinander Tool-Aufrufe im selben Turn ausgeben können, kann das Ergebnis doppelte Dateibearbeitungen, doppelte externe API-Aufrufe, doppelte Gebühren, gleichzeitige Schreibvorgänge, widersprüchliche Shell-Befehle oder die Offenlegung von Anmeldeinformationen sein. Das gewählte Kontrollmodell ist bewusst restriktiv:

• Ein Turn hat standardmäßig genau einen aktiven Tool-Owner.
• Andere Modelle können als Reviewer oder Kritiker agieren und Änderungen vorschlagen, dürfen aber keine Tools ausführen.
• Tool-förmiger Text in der Ausgabe eines Modells ist für sich genommen keine Ausführungsautorität.
• Jeder Tool-Aufruf wird in eine kanonische ToolCall-IR normalisiert, bevor eine Ausführungsentscheidung getroffen wird.
• Ein Scheduler klassifiziert jeden Aufruf als executable, advice_only, blocked oder requires_approval.
• Read-only-, Netzwerk-Lese- und reine Rechenaufrufe können unter sicheren Bedingungen in einer parallelen Gruppe gleichzeitig ausgeführt werden.
• Schreib-, Shell-Schreib-, Zahlungs-, Anmelde- und destruktive Aufrufe werden standardmäßig serialisiert und durch eine Genehmigung blockiert.
• Tool-Ergebnisse werden deterministisch in die erwartete Form des Zielprotokolls zurückgespielt.
• Partielles JSON wird niemals ausgeführt; selbst wohlgeformtes JSON muss noch Schema-, Nebenwirkungs-, Genehmigungs- und Owner-Prüfungen bestehen.

Dies ist eine bedeutende Abkehr von typischen Multi-Agenten-Demonstrationen, bei denen mehrere Agenten alle versuchen könnten, ein Problem gleichzeitig zu „lösen“. Ein produktionsorientiertes Coding-Rezept erfordert Rollendisziplin über Ausführungssicherheit: Ein Reviewer kann markieren, dass ein vorgeschlagener Patch eine Testsuite beschädigt, kann aber selbst keinen destruktiven Shell-Befehl ausführen. Ein Tool-Owner kann eine Dateibearbeitung oder einen Shell-Befehl initiieren, aber seine Ausgabe wird vor der Ausführung noch vom Gateway verifiziert.

Dies schränkt auch ein, wie die Tool-Fähigkeits-Tags der Modellbibliothek gelesen werden sollten: Ein „tool-use“-Tag bedeutet, dass ein Modell plausibel einen Tool-Aufruf ausdrücken kann, nicht, dass es als Produktions-Tool-Owner freigegeben ist. Die Beförderung zum Owner-Status erfordert das Bestehen einer Kompatibilitätssuite, die gestreamte Tool-Argumente, Tool-ID-Stabilität, Reparatur von fehlerhaftem JSON, Tool-Result-Replay, Richtlinien für parallele Tools, Nutzungsabrechnung und Fehlerformen abdeckt. Ein verwandter Grenzfall ist die Inline-Tool-„Rettung“: Einige Anbieter geben Tool-Aufrufe als Assistant-Text aus (XML/JSON-Blöcke, private Funktions-Tags, Objekt- oder doppelt kodierte Argumente). Die Adapterschicht kann diese Dialekte erkennen und reparieren, aber die Reparatur erzeugt nur eine Kandidaten-ToolCall-IR; sie gewährt keine Ausführungsautorität, sie ist nur auf den Antworttext des aktuellen Owners begrenzt (niemals auf Benutzertext, Tool-Ergebnisse, Reviewer-Notizen oder die endgültige fusionierte Antwort), und ein reparierter Aufruf muss immer noch Owner-, Schema-, Nebenwirkungs-, Genehmigungs-, Parallelitäts- und Idempotenz-Gates passieren. Wiederholtes fehlerhaftes JSON sollte die Kompatibilitätsprüfung dieses Owners für den Turn fehlschlagen lassen, anstatt stillschweigend ausgeführt zu werden.

9. Vision und Websuche: Fairness vs. Produkterfahrung

Die Evaluierungs- und Produktpfade gehen hier absichtlich auseinander. Der Benchmark-Beweis verwendet geteilte, reproduzierbare Evidenz; Produktanfragen können native Suche oder Vision verwenden, aber nur, wenn sie nachvollziehbar sind.

Die Suche wird über drei verschiedene Pfade gehandhabt: shared_evidence (ein von Fusion besessenes, reproduzierbares externes Such-/Abruf-/Lese-Paket, obligatorisch für Proof-Runs der weighted-100 Forschungssuite, Vergleiche mit starken Baselines, Modell-Upgrade-Canaries und abschließende Reruns), native_search (die eigene Web-/Browse-/Grounding-Fähigkeit eines Modells oder Anbieters) und external_search (nachvollziehbare externe Tools wie Fetch, Browser-Read oder Dokumentenextraktion). Native Suche ist nicht untersagt; sie kann die Produkterfahrung verbessern, aber sie kann keinen fairen Benchmark-Anspruch stützen, denn wenn das eigene Suchverhalten eines Modells, die abgerufenen Quellen und der Zitatpfad opak sind, hört der Vergleich auf, ein Vergleich derselben Aufgabe zu sein.

Vision folgt derselben Logik. Native Vision und abgeleiteter OCR-/Caption-Text sind keine äquivalenten Eingaben, und ein Vergleich über Modelle mit unterschiedlicher Sichtbarkeit in ein Bild ist kein fairer Vision-Vergleich. Der Trace zeichnet die Sichtbarkeit jedes Modells explizit als native_image, derived_text oder none auf. Das empfohlene Produktionsmuster ist ein Hybrid: Primärmodelle können native Vision verwenden, während kostengünstigere Reviewer mit abgeleitetem Text arbeiten; Aufgaben zu aktuellen Fakten verwenden standardmäßig externe Suche/Fetch, und native Suche ist nur zulässig, sobald eine Route eine Fähigkeitsprüfung bestanden hat und einen vollständigen Trace erzeugt. Die Evaluierung hingegen verwendet immer standardmäßig geteilte Evidenz und ein gehashtes Evidenz-Bündel.

10. Modellbibliothek als rollenbewusstes Auswahl-Schema

Der Modellkatalog, der TokenLab Fusion zugrunde liegt, hat sich von einer flachen Fähigkeitstabelle zu einem geschichteten Auswahl-Schema mit Feldern für Kostenebene, Fusion-Rollen, Fähigkeits-Tags, Auswahlmetriken, Routing-Profil und empfohlener Evaluierungsspur entwickelt. Dies spiegelt eine Produktrealität wider, die ein einzelnes Ranking „wie stark ist dieses Modell“ nicht erfasst: Ein Modell kann ein exzellenter Coding-Reviewer und ein schlechter Panelist für Forschung mit niedriger Latenz sein; ein Modell kann kostengünstig sein, aber instabile Tool-Call-IDs haben; ein Modell kann ein natives Vision-Fähigkeits-Tag tragen, ohne bisher über Trace-Evidenz zu verfügen, die für eine Fairness-gegate Evaluierung ausreicht.

Schicht	Repräsentative Rolle	Produktbedeutung
Günstig, ständig aktiv	kostengünstige Panel-/Reviewer-/Richter-Kandidaten	Standard-Panel-Zusammensetzung, nur durch gepaarte Canary-Evidenz befördert
Starkes Reasoning-Upgrade	Eskalation bei schwierigen Aufgaben	Synth-/Validator-/Richter-Rolle für schwierige Aufgaben
Coding-/Agent-Spezialist	Tool-Schleife, Repo-Skala, Front-End-Review	Kandidaten für Coding-Agent-Tool-Owner und Reviewer
Vision-/Such-Spezialist	bild-/suchlastige Produkt-Workflows	Erfordert Trace-Probe vor Fairness-gegateter Nutzung
Ultra-langer Kontext	Diagnostik für riesige Repos/Evidenz-Bündel	Kein Standard-Panel-Mitglied
Black-Box-Vergleicher	anbieterseitige Multi-Agenten-Systeme	Nur Referenzpunkt; interne Fusion-Attribution kann nicht daraus abgeleitet werden

Das aktuelle Urteil über den ausgemusterten Premium-Anker verdient eine explizite Aussage: Das historische Premium-Gemini-Pro-Modell, das den weighted-100-Beweis verankerte, wurde aus der aktiven produktkostenorientierten Rezeptplanung entfernt, und ein günstigeres Gemini-Flash-Modell wurde ebenfalls aus dem Standardplan entfernt, aufgrund einer Output-Preisgestaltung, die nicht in das Kostenprofil des Zielrezepts passt. Dies revidiert nicht das Ergebnis des weighted-100 Forschungslaufs – dieser Beweis steht wie aufgezeichnet –, aber es bedeutet, dass der Beweis und das beabsichtigte Auslieferungsrezept derzeit nicht dasselbe System sind, was genau der Grund ist, warum der Canary-Run ohne Premium-Gemini der nächste erforderliche Evidenzschritt ist, kein optionaler.

11. Upgrade-Gates für die Modellbibliothek

Ein wiederkehrendes operationelles Anliegen ist, ob jede Modelländerung einen vollständigen 100-Aufgaben-Rerun erfordert. Die vom Programm gewählte Antwort ist eine geschichtete, risikoproportionale Gating-Strategie statt eines der Extreme (blinde vollständige Reruns bei jeder Änderung oder blinde Substitution innerhalb derselben Familie ohne Evidenz):

1. Vertrags-Smoke-Test: Bestätigung von Route, Preisgestaltung, Streaming, Kontextfenster, Ausgabelimits, Modalität sowie Tool-/Such-/Vision-Flags.
2. Kompatibilitätssuite: Ausübung von OpenAI Chat, OpenAI Responses, Anthropic Messages, Tool-Aufruf, Tool-Ergebnis, parallelem Tool-Einsatz, Nutzung, Fehler- und Stream-Handhabung.
3. Sentinel-Evaluierung: Ausführung eines kleinen bereichsspezifischen Sets, das auf die beanspruchte Rolle des Modells abgestimmt ist (z. B. Finanzquellen-Hinlänglichkeit, Coding-Tool-Schleife, visuelle Front-End-Überprüfung).
4. Gepaarter Canary: Vergleich gegen das aktuelle Rezept bei identischen Aufgaben-IDs hinsichtlich Qualität, Kosten, Latenz und Fehlerrate.
5. Vollständiger 100-Aufgaben-Lauf: Reserviert für Kandidaten, die das Standardrezept oder einen Anspruch auf eine starke Baseline ändern könnten.

Selbst ein scheinbar geringfügiges Upgrade innerhalb derselben Familie erfordert das Durchlaufen dieses Trichters: Preisgestaltung, Tool-Call-Verhalten, Streaming und gepaarte Qualität müssen unabhängig bestätigt werden, anstatt sie von einem geteilten Modellfamiliennamen abzuleiten. Dies ist auch der Grund, warum das 100-Aufgaben-Manifest nicht kontinuierlich ausgeführt wird; es ist für die endgültige Bestätigung reserviert, während tägliche Modelländerungen durch die günstigeren, schnelleren Gates oben gesteuert werden.

12. Verwandte Arbeiten und was (nicht) wiederverwendet wird

Das Programm stützt sich auf mehrere öffentliche Forschungs- und Tooling-Richtungen, ohne deren Ziele vollständig zu übernehmen. Mixture-of-Agents motiviert die Idee, dass schwächere Modellausgaben einen stärkeren Synthesizer nützlich konditionieren können, aber die Erkenntnisse zur Panel-Aufblähung in Abschnitt 4 mahnen zur Vorsicht vor Schichtung ohne Ablation. LLM-Blender trägt zur Kandidatengenerierung, zum paarweisen Ranking und zur generativen Fusionsstruktur bei, die den Panel-/Richter-/Synthesestufen ähnelt, obwohl derzeit kein dedizierter trainierter Ranker den rubrikbasierten Richter ersetzt. FrugalGPT und RouteLLM motivieren kostenbewusstes Kaskadieren und Routing, aber das Routing-Problem hier ist mehrrollig (Panel, Synthese, Richter, Validator, Suchstrategie, Tool-Owner können jeweils unabhängig routen), nicht eine einzelne binäre Modellwahl. Evaluierungs-Harness-Tools wie Inspect AI, OpenAI Evals, Promptfoo und Ragas informieren über das technische Muster einer systematischen, CI-freundlichen Evaluierungsschleife, aber keines davon ersetzt das feste gewichtete Manifest, die Quellen-Hinlänglichkeitsprüfungen, die rollenspezifischen Kostenzeilen oder die bereichsgewichtete gepaarte Beweisstruktur, die hier verwendet wird.

13. Einschränkungen

Einschränkung	Aktueller Status	Warum es wichtig ist
Abhängigkeit vom Premium-Anker	Der weighted-100-Beweis verwendete ein historisches Premium-Gemini-Pro-Modell als Synth/Richter/Validator	Beweist Rezept-Obergrenze, nicht das beabsichtigte Produktkosten-Rezept
Abschließender Rerun unvollständig	Reiner Fusion-Rerun bei 20/100 Aufgaben, 20/20 laufzeitkompatibel	Reproduzierbarkeit ohne Baseline-Kosten ist noch nicht vollständig bestätigt
Keine öffentlichen Daten zu menschlichem Audit/Inter-Rater-Übereinstimmung	Ergebnisse zu menschlichem Audit und Inter-Rater-Übereinstimmung wurden noch nicht veröffentlicht	Zuverlässigkeit und Konsistenz automatisierter Scores gegenüber menschlichem Urteil bleiben ungeprüft
Latenznachteil	1.23x vs. gpt-5.5, 2.15x vs. claude-opus-4-8	Akzeptabel für Deep Research, wahrscheinlich inakzeptabel für interaktive Coding-Agenten
Rubrikbasierter Validator	Validator sieht die Bewertungsrubrik/Checkliste	Vergleiche müssen dies offenlegen; nicht direkt vergleichbar mit rubrikblinden Systemen
Warnungen vor Finanzquellen	8 Warnungen mit hohem Schweregrad finance:needs_more_sources	Quellen-Hinlänglichkeit in Finanzen ist trotz großer Score-Deltas ungelöst
Inferenz nativer Fähigkeiten	Such-/Vision-Fähigkeits-Tags sind kein Beweis für Trace-Unterstützung in Produktionsqualität	Erfordert Probing pro Route vor jeder Fairness-gegateten Evaluierung
Reife der Kompatibilitätsschicht	Offline-Skelett (IR, Fixtures, Router-Vertrag, Planer, Stream-Writer)	Noch kein Live-Gateway mit echter Anbieterausführung, Auth/Mandantenfähigkeit oder persistentem Trace
Preis-/Routen-Volatilität	Preiskorrektur für DeepSeek V4 Pro änderte bereits eine strategische Entscheidung	Modell-Bibliotheks-Tiering muss bei Preis- und Routenänderungen neu verifiziert werden

14. FAQ

Bedeutet das 100-Aufgaben-Ergebnis, dass TokenLab Fusion GPT-5.5 und Claude Opus 4.8 generell schlägt?

Das gepaarte Ergebnis gilt spezifisch für das feste gewichtete 100-Aufgaben-Forschungsmanifest, unter Verwendung geteilter Evidenz und rollenspezifischer Kostenrechnung, wobei gpt-5.5 und claude-opus-4-8 aus dem Fusion-Panel herausgehalten wurden. Es ist ein starker, bereichsbreiter Beweis innerhalb dieses Umfangs, kein allgemeiner Anspruch unabhängig von Aufgabentyp, Evidenzbedingungen oder Manifestzusammensetzung.

Warum ist der Gemini-Pro-Anker wichtig, wenn das Score-Delta bereits groß ist?

Das Delta wurde durch ein Rezept erzeugt, das ein historisches Premium-Gemini-Pro-Modell für Synthese, Bewertung und Validierung verwendete. Diese Konfiguration legt fest, was die Rezeptstruktur erreichen kann, aber es ist nicht das Kostenprofil, das der Produktpfad ausliefern will. Bis eine Konfiguration ohne Premium-Gemini als gepaarter Canary gegen dieselben Aufgaben-IDs ausgeführt wird, werden die erzielte Qualität und die beabsichtigten Auslieferungskosten separat bewiesen, nicht zusammen.

Sind niedrigere Kosten pro Aufruf dasselbe wie niedrigere Kosten pro Qualitätseinheit?

Nein, und aus diesem Grund werden beide für diesen Zweck separat berichtet. Die 0.71x und 0.69x Kostenmultiplikatoren beschreiben die rohen Kosten gegenüber den beiden Baselines; die 2.26x und 3.06x Score-pro-Dollar-Verhältnisse beschreiben die kostenbereinigte Qualität. Beide werden benötigt, da ein System pro Aufruf günstiger sein und dennoch schlechter abschneiden kann, oder pro Aufruf teurer und dennoch pro Qualitätseinheit kosteneffizienter sein kann; diese Evaluierung berichtet beide explizit, anstatt sie zusammenzufassen.

Warum ist die Validator-Ablation für dieses Ergebnis wichtig?

Die rubrikbasierte Validator-/Umschreibestufe erzeugte die größte in diesem Programm gemessene Qualitätsänderung (gepaartes Delta +51.81 bei einer 20-Aufgaben-Erweiterung), bei etwa 2.14x Kosten und 1.89x Latenz gegenüber der Fast-Core-Kontrolle. Jeder Vergleich zwischen Rezepten oder zwischen Fusion und einer Baseline muss offenlegen, ob die Validator-Stufe aktiv ist, da sie sowohl das Kostenprofil als auch das Fairness-Framing ändert (der Validator hat Einblick in die Bewertungsrubriken).

Ist TokenLab Fusion heute bereit, in einem echten Coding-Agent-Client zu laufen?

Nein. Die Protokoll- und Tool-Nutzungs-Kontrollarchitektur (kanonische IR, Kompatibilitätssuite, Tool-Owner-Modell) existiert als Offline-Kompatibilitätsskelett mit dokumentierten Protokollzuordnungen und Fixtures, beinhaltet aber noch kein Live-Produktions-Gateway, keine echte Anbieterausführung in großem Maßstab, keine Authentifizierung/Mandantenfähigkeit oder persistente Trace-Speicherung. Der Deep-Research-Beweis und die Coding-Agent-Linie werden nach unterschiedlichen Zeitplänen evaluiert, und die Coding-Linie hat ihre erste Validierungsphase mit kleiner Stichprobe noch nicht abgeschlossen.

15. Forschungsabschluss

Was bewiesen ist

Auf einem festen, gehashten, gewichteten 100-Aufgaben-Multi-Domain-Manifest, unter Verwendung geteilter Evidenz und rollenspezifischer Kostenrechnung, erzielte ein mit Validatoren ausgestattetes Multi-Modell-Rezept ein gepaartes Mittelwert-Delta von +32.60 gegenüber gpt-5.5 und +45.63 gegenüber claude-opus-4-8, bei 0.71x bzw. 0.69x Kosten, mit null Aufruffehlern über 799 Kostenzeilen. Die rubrikbasierte Validierung ist als der größte getestete Qualitätshebel bestätigt, mit einem gepaarten Delta von +51.81 gegenüber einer Fast-Core-Kontrolle. Positive Deltas halten sich in jedem Bereich des Manifests gegenüber beiden Baselines, was darauf hindeutet, dass der Gewinn nicht auf einen Aufgabentyp konzentriert ist.

Was noch blockiert ist

Der abschließende reine Fusion-Rerun des eingefrorenen erfolgreichen Rezepts ist unvollständig (20 von 100 Aufgaben beim letzten Check) und muss eine vollständige Abdeckung mit einem sauberen Bereitschaftsaudit erreichen, bevor der Beweis als von Ende zu Ende reproduzierbar bezeichnet werden kann. Das Rezept, das den Beweis erbrachte, hängt von einem historischen Premium-Gemini-Pro-Anker ab, den der produktkostenorientierte Pfad auslaufen lassen will; es gibt noch keine gepaarte Evidenz für die beabsichtigte Substitution ohne Premium-Gemini. Die Latenz bleibt ein ungelöster Produkt-Tradeoff, insbesondere für jede Coding-Agent-Anwendung. Die Quellen-Hinlänglichkeit bei Finanzen trägt acht ungelöste Warnungen mit hohem Schweregrad trotz eines großen Score-Vorteils in diesem Bereich. Die Protokoll-Kompatibilitätsschicht ist architektonisch definiert, aber noch kein laufendes Produktions-Gateway.

Welche Evidenz als nächstes gesammelt werden sollte

Vervollständigung des abschließenden reinen Fusion-Reruns für die verbleibenden 80 Aufgaben und erneutes Bereitschaftsaudit zur Bestätigung der Reproduzierbarkeit ohne Baseline-Kosten in der Schleife. Ausführung eines gepaarten Canary-Runs mit denselben Aufgaben-IDs, bei dem deepseek-v4-pro für Synthese/Validierung und glm-5.2 für die Bewertung anstelle des Premium-Gemini-Pro-Ankers eingesetzt wird, beginnend im kleinen Maßstab vor jedem Anspruch auf das vollständige Manifest. Schließung der acht ausstehenden Warnungen zur Finanz-Evidenz-Hinlänglichkeit durch bereichsspezifische Quellen-Gate-Arbeit, bevor das Ergebnis im Bereich Finanzen als vollständig gelöst behandelt wird. Erweiterung der Kompatibilitätssuite von einem Offline-Skelett hin zur Live-Anbieterausführung und Ausführung einer Validierungsphase für Coding-Agenten mit kleiner Stichprobe (in der Größenordnung von fünf Aufgaben), um zu testen, ob die Tool-Owner/Reviewer-Architektur einen messbaren Vorteil gegenüber einem einzelnen Modell bietet, bevor weiter in die Coding-Agent-Infrastruktur investiert wird. Jedes dieser Punkte ist ein spezifisches, falsifizierbares nächstes Experiment, kein allgemeiner Roadmap-Punkt.