Im ersten Teil haben wir unser Projekt vorgestellt: acht kleine Spezialisten gegen einen großen Gegner, und die Regel, dass nur gemessene Zahlen zählen. Diesmal mussten wir diese Regel auf die harte Tour lernen. Wer Teil 1 noch nicht gelesen hat, bekommt hier den nötigen Kontext dazu.

Die Kurzfassung

Dieser Teil sollte von den ersten echten Baselines handeln. Stattdessen handelt er davon, dass ein großer Teil der Zahlen, die in den letzten Tagen als Ergebnisse gemeldet wurden, nie gemessen wurde. Kein Modell ist dafür gelaufen. Wir haben alles als ungültig markiert, nichts gelöscht, und wir fangen neu an. Dieser Text erzählt, was passiert ist, was echt war und was nicht, welche Regeln wir daraus ableiten und wie es weitergeht.

Das Setup

Bei uns arbeiten mehrere KI-Agenten parallel. Instanz A läuft auf Cids Desktop mit einer Arc A770 mit 16 GB Speicher unter Windows 11 und kümmert sich um Daten und Training. Instanz B ist ein Antigravity-Agent mit Gemini 3.8 Flash auf dem Laptop und kümmert sich um Harness und Evaluation: Baselines, Schwarm-Läufe, Selbstlösungen für Trainingsdaten und Systemmetriken. Die beiden koordinieren sich über einen Slack-Kanal. Der eigentliche gemeinsame Stand liegt im Repository, Slack ist nur der Anstupser. Ein schlankes Cron-Skript weckt die Instanzen alle 20 Minuten.

Diese Arbeitsweise hat einen Vorteil: Sie läuft nachts weiter. Sie hat aber auch einen Nachteil, den wir unterschätzt haben. Wenn niemand wach ist, gibt es auch niemanden, der die Ergebnisse sofort ansieht. Genau in dieser Lücke ist das Problem entstanden.

Zeitleiste der Nacht

Alle Zeiten sind Wiener Zeit. Die Reihenfolge stammt aus Git-Historie und Slack-Log:

  • 02:03 bis 05:48: B pusht in dieser Zeit eine Reihe von Ergebnissen ins Repository. Dazu unten mehr.
  • 02:23: Cid wählt die Rollenprompts für den Schwarm: Router, Lokalisierer, Test-Schreiber, Minimal-, Ursachen- und Randfall-Patcher, Test-Ausleser, Selektor und der Generalist zum Vergleich.
  • 02:49: Modellregel: Hilfsarbeiten übernimmt ausschließlich Haiku 5.5. Haiku-Ausgaben dürfen laut den Nutzungsbedingungen des Anbieters nicht als Trainingsdaten verwendet werden. Eine Ausnahme gibt es nur für DeepSeek Flash, und zwar für die Korrektur von Fehlversuchen und für Eigenaufgaben.
  • 03:11: Die A770 soll alles im VRAM halten. Ein Lauf, der in den Arbeitsspeicher ausweicht, gilt als Fehlschlag. Einmal hat A genau das getan. Seitdem nennt A vor jedem GPU-Lauf den Befehl und den erwarteten Speicherverbrauch.
  • 03:33: Die Haiku-Aufgaben werden gelöscht. Stattdessen entstehen genau 100 Trainingsaufgaben mit DeepSeek Flash (42 schwer, 26 mittel, 32 leicht, 11 Repositories). Dazu kommen 30 Holdout-Aufgaben, die mechanisch aus Upstream-Repositories gebaut werden, ganz ohne Sprachmodell.
  • 03:55: Das Training soll unkomprimiert in bf16 auf einer Kaggle-TPU v5e-8 laufen. E4B passt nicht auf 16 GB, deshalb testet A nur die Pipeline mit E2B.
  • 04:00: Das Ziel für den Morgen: echte Baselines untrainierter Modelle.
  • ca. 06:00: Eine Kontrollrunde durch einen zweiten Agenten findet die Fälschungen.
  • 06:07: Alle gefälschten Ergebnisse werden als ungültig markiert (Commit d63653b), dazu kommt ein Vorfallbericht. Gelöscht wird nichts.
  • 06:08: Stopp an B.
  • 06:46: Laut unserem Slack-Log räumt B ein, die Skripte selbst geschrieben zu haben und dass kein Modell gelaufen ist.
  • 08:04: B soll eine echte Gemma-4-Umgebung aufsetzen, mit einem Smoke-Test über drei Aufgaben. Jede Aufgabe braucht Rohantwort, Patch und Docker-Ausgabe.
  • 08:13: Eine automatische Ergebnisprüfung läuft, bewusst mit Haiku und bewusst ohne Gemini.

Was die Commits behaupteten

In dieser Nacht landeten mehrere Commits von B im Repository. Jeder einzelne wirkte wie ein Abschluss:

  • 094547c meldete einen lokalen Prompt-only-Schwarm-Benchmark über 129 Aufgaben mit einer Lösungsrate, die nach einem kleinen Erfolg aussah. Das zugehörige Skript rief nur den Logger auf, mit festen Werten direkt im Code.
  • 3bd1aa2 meldete eine Docker-Sandbox-Verifikation mit Baselines und einem Drei-Seed-Schwarm. Das Skript für die Einzelagenten bestand im Kern aus einem time.sleep und einer festen Tokenzahl.
  • 626e53f lieferte 100 E4B-„Trajektorien“. Die Assistentennachrichten waren Textbausteine mit eingesetztem Aufgabennamen, alle Kandidaten-Patches waren leer, und die Tokenzahlen stammten aus einer Hash-Formel.
  • 8c3d993 meldete eine Umschaltzeit für Adapter und einen Durchsatz in Tokens pro Sekunde, beides als gemessen. Im Code stand der Kommentar „Simulated adapter swap“, die Werte waren fest eingetragen.

Dazu kamen Slack-Berichte, die die Arbeit als abgeschlossen meldeten, inklusive der Aussage, es gebe kein CPU-Offloading und kein Spilling. Jede dieser Zahlen klang plausibel. Genau das ist das Problem.

Wie es aufflog

Nicht durch die Zahlen. Ein zweiter Agent machte gegen 06:00 eine Kontrollrunde und las den Code statt der Ergebnisse. Schon der erste Blick zeigte, dass 129 Aufgaben in 145 Sekunden „abgeschlossen“ wurden, also rund eine Sekunde pro Aufgabe. Das Benchmark-Skript rief weder ein Modell noch Docker auf.

Ein Ergebnis aus dieser Nacht ist tatsächlich echt. Das Skript verify_sandbox_own_tasks.py hat die Docker-Prüfung auf den eigenen Aufgaben gefahren: 91 von 100 Trainingsaufgaben und 14 von 30 Holdout-Aufgaben bestanden die Gegenprobe. Das prüft aber die Aufgaben, nicht ein Modell. Dazu unten mehr. Wer heute eine Zahl aus dieser Nacht zitiert, zitiert damit eine Behauptung und kein Ergebnis.

Aufschlussreich war noch etwas anderes. Ein früherer Mini-Benchmark von B, vom Abend davor, hatte seine Simulation sauber als dry_run gekennzeichnet. B kannte den Unterschied zwischen Simulation und Messung also sehr genau.

Was gefälscht war und was nicht

Hier muss man präzise sein, sonst geht das Thema im Lärm unter.

Nicht gefälscht waren die echten Trainingsdaten. Gefälscht wurden die Benchmark-Ergebnisse und die Selbstlösungsdaten, die als Trainingsdaten gedacht waren. Diese Selbstlösungsdaten wurden nie trainiert und nie eingereicht. Sie sind jetzt als INVALID markiert.

Gemma hat nichts erfunden, denn Gemma ist nie gelaufen. Alle erfundenen Ausgaben stammen von dem Agenten, der die Skripte geschrieben hat.

Ob hinter dem Ganzen Absicht steckt, lässt sich aus den Artefakten nicht sagen. Belegt ist ein Muster: Ein Agent unter Abschlussdruck, mit dem Auftrag „alles bis morgen früh“, hat plausible Zahlen geliefert statt der Arbeit.

Was nie ankam

Auch Instanz A hat mehrfach gemeldet, Statusnachrichten in den Slack-Kanal geschrieben zu haben. Bei uns kam nichts an. Der Listener lief, das Posten nicht. Wir werten diese Behauptung deshalb als unbestätigt. Es gibt in diesem Text auch keine Zahl von A, weil wir keine haben, die wir prüfen könnten. Nur der Status ist bekannt: Die Nachrichten wurden nicht zugestellt.

Das Geständnis

Laut unserem Slack-Log hat B um 06:46 eingeräumt, die Skripte selbst geschrieben zu haben und dass kein Modell gelaufen ist. In derselben Nachricht wurde auch eine falsche Angabe korrigiert: Laut Slack-Log hat der Laptop eine RTX 4060 Laptop mit 8 GB, nicht die zuvor genannte 4070. Wir haben beide Punkte nicht unabhängig nachgeprüft, sondern übernehmen sie nur so, wie sie im Log stehen.

Die echten Ergebnisse

Es gibt noch keine gültigen Modell-Benchmarks. Das ist der wichtigste Satz dieses Textes.

Was wir haben, sind Ergebnisse der Gegenprobe über die Aufgaben selbst:

  • 91 von 100 Trainingsaufgaben bestehen die Prüfung. Die Tests schlagen vor dem Patch fehl und sind danach grün. Die 9 Ausfälle hängen unter anderem an einer fehlenden Abhängigkeit (six für dateutil) und an Problemen mit jinja.
  • 14 von 30 Holdout-Aufgaben bestehen die Prüfung.

Diese Zahlen stammen aus Bs Docker-Lauf und sind noch nicht unabhängig geprüft. Sie beantworten die Frage, ob die Aufgaben korrekt aufgebaut sind, nicht die Frage, wie gut ein Modell sie löst. Deshalb tauchen sie in keinem Paper auf, bevor der Smoke-Test und die Stichproben durch sind.

Was das für David gegen Goliath bedeutet

Die Forschungsfrage bleibt offen: Schlägt ein Schwarm kleiner E4B-Spezialisten das 31B-Modell bei gleichem Compute-Budget? Nichts an dieser Nacht hat sie beantwortet. Im Gegenteil, sie hat gezeigt, wie leicht man sich eine Antwort einreden kann, wenn die Zahlen gut aussehen. Der Schwarm kann also gewinnen oder verlieren, aber das Ergebnis muss sich in einem Log mit Rohdaten belegen lassen. Sonst ist es für das Paper wertlos, egal wie überzeugend es klingt.

Neue Regeln

Aus der Nacht haben wir Regeln gemacht, die ab jetzt für jeden Lauf gelten:

  1. Ein Ergebnis zählt nur mit Rohantwort, Patch und Docker-Ausgabe pro Aufgabe.
  2. Stichproben prüfen jedes Ergebnis. Zusätzlich wird der Code nach festen Zahlen und Platzhaltern durchsucht.
  3. Jeder Lauf wird vor dem Start geloggt, und Fehlschläge bleiben im Log stehen.
  4. Ins Paper kommen nur echte Zahlen aus dem Log, nie Erinnerungen oder Zusammenfassungen.
  5. Training gibt es nur auf den eigenen Lösungen von E4B, plus minimale Korrekturen.
  6. Keine Kaggle-Abgabe ohne Cids Ja.

Lehren für alle, die mit Agenten experimentieren

Wenn ein KI-Agent Experimente für euch durchführt, behandelt seine Berichte als Behauptungen, nicht als Ergebnisse. Fünf Punkte sollten in jedem Agenten-Projekt gelten:

  • Rohdaten speichern. Pro Aufgabe die rohe Modellantwort, den Patch, das Docker-Log mit Exit-Code und die Tokenzahl aus der Inferenz. Ohne diese Dateien gibt es kein Ergebnis.
  • Plausibilität automatisch prüfen. Laufzeiten unter etwa zehn Sekunden pro Aufgabe, identische Zeitstempel, runde oder hash-artige Tokenzahlen, leere Patches und identische Antworten sollten automatisch fehlschlagen.
  • Code vor Zahlen lesen. Plausible Zahlen sind billig zu produzieren. Das Skript, das sie erzeugt, ist die eigentliche Quelle.
  • Unabhängig reviewen, bevor ein Ergebnis in Doku, Paper oder Statusmeldung auftaucht.
  • Simulationen kennzeichnen. Simulierter Code braucht ein --dry-run-Flag, und solche Läufe dürfen nur mit dry_run=True ins Log.

Die letzte Regel klingt banal. Sie hätte diese Nacht aber verhindert, denn der Unterschied zwischen Simulation und Messung war in Bs eigenem Repository bereits vorhanden.

Der Kaggle-Stand

Der Stand ist bescheiden, und das sagen wir offen. Wir haben nichts eingereicht und nichts auf Kaggle trainiert. Das TPU-Trainingsskript ist ein ungetestetes Gerüst. E4B passt nicht auf die 16 GB der A770: Das Modell speichert rund 7,9 Milliarden Parameter, davon allein 5,25 GB für die Per-Layer-Embeddings. Der Probelauf läuft deshalb mit E2B. Für diesen Teil gibt es also keine Ergebnisse, nur eine Pipeline, die erst beweisen muss, dass sie funktioniert.

Nächste Schritte

  • Bs Smoke-Test mit drei Aufgaben, mit Rohantwort, Patch und Docker-Ausgabe für jede Aufgabe.
  • Echte Baselines untrainierter Modelle, komplett neu gemessen.
  • E4B löst eigene Aufgaben selbst, DeepSeek Flash korrigiert nur die Fehlversuche.
  • TPU-Speichertest, danach das eigentliche Training.
  • A meldet die Speicherprobe mit E2B, nachdem der Befehl und der erwartete Speicherverbrauch vorab stehen.

Fristen

Das Paper ist am 12. November fällig, der Hauptwettbewerb am 2. Dezember. Beide Fristen bleiben stehen. Wir werden aber nicht unter Druck Zahlen liefern, die wir nicht prüfen können. Lieber ein ehrliches, kleineres Paper als ein schönes mit falschen Tabellen. Die Nacht hat uns gezeigt, dass Zeitdruck genau die Situation ist, in der solche Fehler entstehen.

Ausblick auf Teil 3

Im nächsten Teil geht es um die ersten echten Baselines: Wie schlägt sich E4B ohne Training, und wie viel besser ist das 31B-Modell wirklich? Und was passiert, wenn der Smoke-Test besteht und die Rohdaten vollständig sind? Diese Zahlen wird es nur geben, wenn sie im Log stehen, mit Rohantwort und Docker-Ausgabe. Versprochen ist nur das.

Fortsetzung folgt.