Die Methodik von Argusic

Wie Argusic prüft, ob echte Software läuft, und wie es AI coding agents bewertet. Jede Regel hier ist absichtlich öffentlich: Der ganze Sinn besteht darin, dass jeder unsere Arbeit überprüfen kann. Jede Änderung dieser Regeln wird im Änderungsprotokoll am Ende festgehalten, gilt ab dem nächsten Testzyklus und wird nie rückwirkend angewendet.

1. Kurz gesagt

• Wir nehmen echte Open-Source-Projekte und lassen AI agents versuchen, sie

ohne menschliche Hilfe zu installieren, zu starten und zu debuggen, genau so, wie es ein neuer Engineer an seinem ersten Tag tun würde.

• Jeder Test wird von Anfang bis Ende aufgezeichnet. Jede veröffentlichte Zahl

verlinkt auf ihr Log und ihre Terminalaufzeichnung.

• Jedes Projekt erhält einen klaren Befund: Läuft es, läuft es mit Mock-Diensten,

oder konnten wir es nicht verifizieren.

• Agents werden unter identischen Bedingungen verglichen; jeweils drei Läufe, das

mittlere Ergebnis zählt, stark widersprüchliche Ergebnisse werden markiert und beiseitegelegt.

• Wir verkaufen keinen Agent und nehmen kein Geld, um ein Ergebnis zu ändern.

Argusic ist der Schiedsrichter.

• Das Messen ist automatisiert. Das Schreiben nicht: Kein Modell schreibt einen

Satz auf dieser Website, jede Zahl auf einer Seite ist eine Vorlage, die aus einem aufgezeichneten Lauf befüllt wird, und eine Person gibt alles frei, bevor es veröffentlicht wird. Siehe wie diese Inhalte entstehen.

2. Die Frage, die hier beantwortet wird

Kann ein AI coding agent ein echtes Open-Source-Projekt ganz allein installieren, starten, die Fehler abarbeiten und verifizieren, dass die Software läuft, wie ein Engineer an seinem ersten Tag, ohne menschliche Hilfe?

3. Warum neue Projekte

Statische Benchmarks verlieren an Wert, sobald ihre Antworten in Trainingsdaten gelangen. SWE-rebench (Badertdinov et al., 2025) ließ dieselben Agents gegen SWE-bench Verified und gegen Aufgaben laufen, die gesammelt wurden, nachdem dieser Benchmark öffentlich war, und die Scores verschoben sich deutlich: Tabelle 2 der Arbeit nennt für DeepSeek-V3-0324 39.7% gelöste Aufgaben in SWE-bench Verified und 21.3% im zeitlich gefilterten Satz, eine Lücke von 18 Prozentpunkten bei einem einzigen Modell. Argusic testet Projekte, die in den letzten Wochen im Trend liegen, mit einem geheimen Pool, der monatlich wechselt, sodass es nichts auswendig zu lernen gibt.

4. Was gemessen wird

Wir messen genau eine Sache: die autonome Fähigkeit, echte Software zum Laufen zu bringen. Jeder getestete Agent ist eine feste Kombination aus einem Modell in einer fixierten Version, einem Harness in einer fixierten Version, den veröffentlichten Standardanweisungen von Argusic sowie identischen Zeit- und Ressourcenlimits. Jeder Agent erhält exakt dieselben Bedingungen.

5. Getestete Agents

Der erste Zyklus läuft. Die Liste der Agents wird mit dem ersten Leaderboard veröffentlicht. Jeder Agent ist eine feste, fixierte Konfiguration, die unter einer neutralen Argusic-Identität auftritt; seine genauen Versionen werden erfasst und aufbewahrt, sodass sich jede Zahl auf dem Board auf die genaue Konfiguration zurückführen lässt, die sie erzeugt hat, und ein Ergebnis auf Anfrage über Argusic reproduziert werden kann (siehe "Ein Ergebnis reproduzieren").

6. Der Projektpool

• 80% öffentlicher Pool: Die Liste und die genauen Versionen (Commit-Hashes)

werden vor jedem Zyklus veröffentlicht.

• 20% geheimer Pool: ausgewählt aus Projekten, die in den letzten 30 Tagen im

Trend lagen, erst nach Ende des Zyklus veröffentlicht und monatlich gewechselt. Das verhindert, dass Agents auf den Test hin optimiert werden.

• Auswahlkriterien: eine permissive Lizenz, eine README, eine Streuung über

Sprachen und Schwierigkeitsgrade und die Möglichkeit, auf grundlegender Ebene ohne kostenpflichtige Konten zu laufen.

6a. Was ein getestetes Projekt sein kann

Ein getestetes Projekt ist etwas, das ein Agent einrichten und ausführen soll. Argusic testet heute eine Art davon und ist so gebaut, dass weitere hinzukommen können, ohne etwas daran zu ändern, wie ein Ergebnis zustande kommt: Das Bewertungsschema, die Regeln für Nachweise und das Vokabular der Befunde sind über alle Quellen hinweg identisch, sodass eine Zahl aus einer Quelle dasselbe bedeutet wie eine Zahl aus einer anderen.

Quelle	Was "läuft es" hier bedeutet	Status
Open-Source-Repository	Den fixierten Commit klonen, installieren, starten und verifizieren, dass es die Aufgabe erfüllt, die seine eigene README beschreibt	In Gebrauch. 3669 Projekte getestet
Hugging-Face-Modell	Das Modell in einer fixierten Revision herunterladen und die Inferenz genau so ausführen, wie seine Model Card es dokumentiert, auf einem GPU-Worker. Es läuft, wenn das dokumentierte Snippet auf einer sauberen Maschine eine Ausgabe erzeugt, ohne dass der Tester es umschreibt	In Gebrauch. 1 Projekt getestet
Hugging Face Space	Den Space aus seiner eigenen Definition bauen und starten, dann seine Oberfläche erreichen und die Interaktion abschließen, die er verspricht	Deklariert, nicht begonnen
Veröffentlichtes Paket (npm, PyPI)	Die fixierte Version in ein leeres Projekt installieren und den Quickstart aus seiner eigenen README ausführen	Deklariert, nicht begonnen
Hersteller-Tool	Den vom Hersteller selbst veröffentlichten Build installieren und starten, ausschließlich nach den eigenen Anweisungen des Herstellers	Deklariert, nicht begonnen
Vorgefertigtes Cloud-Template	Das Template so bereitstellen, wie sein eigenes Angebot es dokumentiert, und prüfen, dass es startet und das liefert, was es verspricht, ohne dass der Tester es vorher patcht	Deklariert, nicht begonnen
Container-Image	Das Image mit einem fixierten Digest pullen und den Befehl ausführen, den seine eigene Beschreibung angibt, dann prüfen, dass es tut, was diese Beschreibung behauptet	Deklariert, nicht begonnen
MCP-Server	Den Server wie dokumentiert installieren und starten, einen Client verbinden und bestätigen, dass er die Tools auflistet und beantwortet, die er verspricht	Deklariert, nicht begonnen

Die Spalte Status oben wird nicht von Hand geschrieben. Sie wird bei jedem Aufruf dieser Seite aus der Datenbank gelesen: Eine Quelle wird als in Gebrauch angezeigt, sobald ein veröffentlichtes Projekt dieser Art einen aufgezeichneten Lauf hat, und zeigt dann die Anzahl. Das ist dieselbe Regel, der jede andere Zahl auf dieser Website folgt, und sie bedeutet, dass niemand daran denken muss, diese Seite zu aktualisieren, wenn eine neue Quelle ihr erstes Ergebnis liefert.

Zwei Dinge unterscheiden ein Hugging-Face-Projekt von einem Repository, und beide werden mit dem Lauf erfasst statt geglättet. Es braucht einen GPU-Worker, daher sind die Kosten pro Versuch höher und sein Budget wird gesondert festgelegt. Und eine Model Card dokumentiert oft ein Code-Snippet statt einer Anwendung, daher lautet das verifizierte Verhalten "das dokumentierte Snippet hat eine Ausgabe erzeugt", nicht "das Produkt funktioniert": Die Seite des Laufs sagt mit genau diesen Worten, welcher Fall vorliegt, und der Score wird auf dieselbe Weise vergeben.

Die Tabelle sagt absichtlich "nicht begonnen" statt "demnächst". Eine Quelle gilt an dem Tag als in Gebrauch, an dem ein echter Lauf dieser Art mit seinem Nachweis aufgezeichnet wird, und keinen Tag früher. Bis dahin ist die Zeile eine Aussage über den Umfang, nie über Ergebnisse: Keine Seite zeigt einen Befund, eine Anzahl, eine Rangfolge oder eine Share-Karte für eine Quelle, die noch nicht gelaufen ist, und diese Tabelle ist der einzige Ort, an dem eine geplante Quelle genannt wird.

7. Eine Messung

1. Eine saubere Einwegmaschine (ihre genaue Umgebung wird veröffentlicht). Sie

nimmt keine eingehenden Verbindungen an und wird zerstört, wenn der Lauf endet. Ausgehender Netzwerkzugriff wird in dieser Edition nicht gefiltert; was einen Lauf begrenzt, sind die Einwegmaschine und die Regeln zum Modellschlüssel unterhalb der Liste. Die Maschine holt nur den fixierten Commit, nicht die Historie des Projekts, die nicht Teil des Tests ist.

2. Der Agent erhält eine Aufgabe: dieses Projekt zum Laufen zu bringen, gemäß

den veröffentlichten Standardanweisungen.

3. Ein Zeitlimit. Jeder Lauf erhält genau eines von drei Budgets (die Tabelle

unter der Liste), und das Budget eines Laufs wird auf seiner Laufseite angezeigt.

4. Drei unabhängige Läufe; das mittlere Ergebnis zählt. Liegen die drei

Ergebnisse mehr als 30% auseinander, wird der Satz als instabil markiert und für das Board dieses Zyklus beiseitegelegt.

5. Jeder Lauf speichert ein vollständiges Log und eine komplette

Terminalaufzeichnung, die mit den Ergebnissen veröffentlicht werden.

6. Desktopanwendungen werden auf einem virtuellen Display innerhalb der

Maschine gestartet (seit v1.1). "Gestartet" bedeutet, dass der Hauptprozess der Anwendung auf diesem Display startete und aktiv blieb oder auf einen Versions- oder Hilfebefehl antwortete. Es wird nichts angeklickt; gemessen wird, ob die Software auf einer frischen Maschine hochkommt, dieselbe Frage, die jedem anderen Projekt gestellt wird. Der Agent wird angewiesen, keine Bilder an sein Modell zu senden (seit v1.3): Das Standardmodell akzeptiert nur Text, und ein an eine Nachricht angehängter Screenshot beendete die Sitzung vor dem Bericht.

Die Zeitbudgets aus Punkt 3:

Stufe	Budget
standard	90 Minuten
heavy	120 Minuten
gpu	120 Minuten

Das Standardbudget betrug vor v1.3 45 Minuten: In der ersten Woche waren an einem Tag 36 von 38 Zeitüberschreitungen Builds, die bei verbrauchtem Budget noch liefen, also wurde es verdoppelt. Die Stufe heavy gibt es seit v1.2 für ein Projekt, das der Owner als heavy markiert oder dessen Repository laut GitHub größer als 500 MB ist, weil ein großes Spiel oder eine Desktopanwendung so lange zum Bauen braucht. Ein Projekt, das eine GPU benötigt, erhält dieselben 120 Minuten.

Die drei Werte oben sind keine Dekoration. scripts/check-ttl-methodology.sh liest diese Tabelle und vergleicht sie mit den Budgets, mit denen der Orchestrator tatsächlich konfiguriert ist, und make test schlägt fehl, wenn sie nicht übereinstimmen. Diese Prüfung gibt es, weil zwischen 2026-09-06 und 2026-09-11 das GPU-Budget im laufenden System 240 Minuten betrug, während diese Seite 120 angab, und nichts die beiden verglich (ISSUE-072).

Der Modellschlüssel. Ein Agent braucht einen Schlüssel, um sein Modell aufzurufen, und ein Lauf führt Code aus einem nicht vertrauenswürdigen Projekt aus, daher ist dieser Schlüssel die Zugangsberechtigung, deren Begrenzung sich am meisten lohnt. Für Agents, die ihr Modell über die Routing-Schicht von Argusic erreichen, erhält jeder Lauf einen eigenen Schlüssel, der nur für diesen Lauf erstellt wird. Ausgabenlimit für den Modellschlüssel jedes Laufs: 3 USD. Der Schlüssel wird gelöscht, wenn der Lauf endet, abgebrochen wird oder in eine Zeitüberschreitung läuft, und ein geplanter Bereinigungsjob löscht jeden Schlüssel, der zu keinem laufenden Job mehr gehört. Kann der Schlüssel eines Laufs nicht erstellt werden, wird der Lauf nicht gestartet und später erneut versucht; ein gemeinsamer Schlüssel wird nie ersatzweise verwendet. Agents, die den eigenen Dienst ihres Modellherstellers nutzen, rufen ihn mit einem gemeinsamen Schlüssel auf, den Argusic verwaltet, nicht mit einem Schlüssel pro Lauf; die Umstellung auf Schlüssel pro Lauf steht auf unserem Backlog. Die Limitzeile oben wird von scripts/check-cost-methodology.sh gelesen, das make test fehlschlagen lässt, wenn sie vom konfigurierten Wert abweicht, aus demselben Grund wie bei den Zeitbudgets.

8. Bewertung, von 100 Punkten

• Erfolgreiche Installation: 30
• Erfolgreicher Start oder erfolgreiche Tests: 30
• Fehlerbehebung: 20, im Verhältnis zu den aufgetretenen Fehlern, die gültig

behoben wurden

• Verifikationstiefe: 20 (real lauffähig verifiziert: 20; gegen Mock-Dienste

verifiziert: 12; nicht verifiziert: 0)

Das Ergebnis eines Laufs ist eines der folgenden:

Ergebnis	Bedeutung
pass_full	Lief und wurde real verifiziert
pass_mock	Lief, gegen Mock-Dienste verifiziert
fail	Wurde nicht installiert oder nicht gestartet
timeout	Zeit abgelaufen

Die vier Bewertungszeilen lassen manche Fälle offen. Sie werden hier geregelt und nicht nur im Code, denn eine Regel, die niemand lesen kann, ist eine Regel, die niemand prüfen kann. Die Bewertung ist ein deterministisches Programm mit Tests für jede der folgenden Regeln; zu keinem Zeitpunkt ist ein AI-Modell an der Bewertung beteiligt.

• Ging nichts schief, erhält die Fehlerbehebung die vollen 20 Punkte. Null

Punkte würden einen Agent dafür bestrafen, dass sich das Projekt zufällig sauber installieren ließ, und das misst das Projekt, nicht den Agent.

• Andernfalls ist die Fehlerbehebung der Anteil der aufgetretenen Fehler, die

behoben wurden, von 20 Punkten. Ein Lauf darf nie mehr behobene Fehler angeben als aufgetreten sind; ein solcher Lauf wird abgelehnt.

• Der Start setzt die Installation voraus: Ein Agent, der die Software nicht

installiert hat, kann sie nicht gestartet haben.

• Die Verifikationstiefe setzt den Start voraus: Ohne erfolgreichen Start gibt

es nichts zu verifizieren, daher erhält die Tiefe 0 Punkte.

• Installiert und gestartet, aber nicht verifiziert, ist kein Bestehen. Es

ergibt 80 von 100 Punkten und zählt trotzdem als Fehlschlag, denn die Frage ist, ob der Agent verifiziert hat, dass die Software läuft, und ein nicht verifizierter Start beantwortet sie nicht.

• Eine Zeitüberschreitung ergibt 0 Punkte in jeder Zeile. Es gibt keine

Teilpunkte: Der Agent ist nicht innerhalb desselben Limits fertig geworden, das jeder andere Agent hatte.

• Ein Lauf ohne vollständiges Log und vollständige Aufzeichnung ist ungültig und

wird wiederholt. Er wird nie bewertet und erreicht nie das Board.

9. Von vielen Läufen zu einem Board-Score

Die Bewertung beurteilt ein Paar aus Projekt und Agent. Das Leaderboard braucht eine einzige Zahl pro Agent, und wie diese zusammengeführt werden, ist eine methodische Entscheidung, daher wird sie hier festgehalten.

Der Board-Score eines Agents ist der mittlere Wert seiner mittleren Scores pro Projekt. Wir verwenden auch hier den mittleren Wert statt eines Durchschnitts, aus demselben Grund: Ein desaströses Projekt soll einen fähigen Agent nicht nach unten ziehen, und ein glückliches Projekt soll einen schwachen nicht nach oben heben.

Zwei Arten von Ergebnissen werden aus dieser Zahl ausgeschlossen, und beide werden trotzdem auf dem Board angezeigt, damit der Ausschluss sichtbar ist und nicht stillschweigend geschieht: als instabil markierte Ergebnisse (siehe den nächsten Abschnitt) und jedes Ergebnis zu einem Projekt, das als in Prüfung markiert ist (siehe Qualitätskontrolle der Umgebung).

Ein Agent, dessen Ergebnisse alle ausgeschlossen sind, hat keinen Board-Score. Er wird ohne Score unten angezeigt statt entfernt, denn ein Agent, der getestet wurde und nichts Verwertbares geliefert hat, ist selbst ein Ergebnis, und ihn zu verbergen würde das Feld unauffällig schönen.

Die Erfolgsquote zählt jeden Versuch, den ein Agent im Zyklus unternommen hat, einschließlich Fehlschlägen und Zeitüberschreitungen. Siehe Unabhängigkeit und keine Rosinenpickerei weiter unten.

10. Streuung und Instabilität

Die Streuung ist die Spanne der drei Läufe als Prozentsatz ihres mittleren Werts:

spread = (highest - lowest) / middle * 100

Ein Satz wird als instabil markiert, wenn die Streuung strikt größer als 30% ist. Genau 30% liegt nicht über 30% und bleibt auf dem Board. Aus der Formel ergeben sich zwei Randfälle:

• Ist der mittlere Wert 0, hat aber ein Lauf mehr als 0 Punkte erzielt, ist die

Streuung unbegrenzt und der Satz instabil: Ein Ergebnis, das einmal auftrat und die anderen beiden Male nicht, ist das am wenigsten reproduzierbare Ergebnis, das es gibt.

• Haben alle drei Läufe 0 Punkte erzielt, teilt die Formel durch null und hat

keinen Wert, daher ist die Streuung nach dieser Regel als 0 definiert und der Satz stabil. Ein gleichbleibender Fehlschlag ist eine reproduzierbare Messung und gehört als solche auf das Board.

11. Der Befund zum Projekt

Das Board rangiert Agents. Der Befund beantwortet eine andere Frage, über das Projekt selbst: Kann ein Neuling, in Gestalt eines AI agents, diese Software heute zum Laufen bringen?

Das Testen ist adaptiv, weil der Nachweis einseitig ist. Ein Bestehen beweist, dass das Projekt läuft; ein einzelner Fehlschlag beweist für sich allein nichts, weil er am Agent liegen kann statt am Projekt.

1. Zuerst läuft der Standard-Agent einmal. Jedes Bestehen beendet den Vorgang:

Ein vollständiges Bestehen ergibt "läuft", ein Bestehen gegen Mock-Dienste ergibt "läuft mit Mocks". Es gibt keinen Grund, etwas weiter zu testen, das bereits nachweislich läuft.

2. Ist er fehlgeschlagen, schließt ein Wiederholungsversuch mit demselben Agent

einen einmaligen Zufall aus.

3. Ist er weiterhin fehlgeschlagen, lautet der Befund "nicht verifizierbar", nie

"defekt": Argusic berichtet, was Agents leisten konnten, und sagt genau das (seit v1.3: zwei vollständige Versuche mit dem Standard-Agent entscheiden). Auf Anfrage kann ein stärkerer Agent laufen; geschieht das, macht sein Bestehen das Projekt zu "läuft" (der Datensatz zeigt, welcher Agent es verifiziert hat), und sein Fehlschlag entscheidet ebenfalls "nicht verifizierbar".

Ein vollständiger Versuch ist einer, dessen Aufzeichnung zeigt, wie der Agent bis zu seinem eigenen Ende oder bis zum Zeitlimit arbeitet. Ein Versuch, den die eigenen Werkzeuge von Argusic vorzeitig abgebrochen haben (ein Harness, der den Bericht des Agents nicht lesen konnte, ein Messfehler ohne Bezug zum Projekt), wird als ungültig markiert, mit dem Grund am Lauf gespeichert, bleibt mit seinem Nachweis veröffentlicht und zählt nicht.

Der Befund ist das beste Ergebnis, das irgendein Versuch erreicht hat:

• läuft: Ein Versuch lief und wurde real verifiziert.
• läuft mit Mocks: Der beste Versuch lief und wurde gegen Mock-Dienste

verifiziert, meist weil das Projekt echte Zugangsdaten von Drittanbietern braucht.

• nicht verifizierbar: kein Bestehen nach zwei vollständigen Versuchen

(oder nach dem stärkeren Agent, wenn einer lief). Die Seite sagt das und verlinkt das Log, das zeigt, wo jeder Versuch stehen blieb.

• noch nicht verifiziert: Das Testen ist noch nicht abgeschlossen.

Jeder Versuch wird mit seinem vollständigen Nachweis veröffentlicht, unabhängig vom Befund, mit einer Ausnahme: Eine Aufzeichnung, bei der nicht nachgewiesen werden kann, dass sie frei von gültigen Zugangsdaten ist, wird zurückgehalten, und ihr Lauf wird wiederholt (Abschnitt 17, "Sicherheitsschwärzung").

12. Was Argusic nicht misst

Um Missverständnisse zu vermeiden, sagen wir es deutlich. Argusic misst nicht die langfristige Qualität des Codes, den ein Agent schreibt, nicht die Sicherheit seiner Korrekturen und nicht die tiefe Produkterfahrung auf Feature-Ebene. Es misst eine Sache: die autonome Fähigkeit, echte Software zum Laufen zu bringen.

13. Unabhängigkeit und keine Rosinenpickerei

• Argusic nimmt kein Geld an, um seine Methodik, Bewertung oder Rangfolgen zu

ändern.

• Ein Compute-Sponsoring, falls vorhanden, kauft genau eine Sache: Das Modell

des Sponsors wird unter denselben Bedingungen wie jeder andere Agent in die Liste der getesteten Agents aufgenommen, und das Sponsoring wird neben den Ergebnissen offengelegt.

• Jeder Lauf jedes Agents zählt und wird veröffentlicht. Es gibt kein privates

Testen, nach dem nur das beste Ergebnis veröffentlicht wird. Steht ein Agent auf dem Board, sind alle seine Versuche des Zyklus dokumentiert.

14. Offenlegung des Harness

Der Harness (das Gerüst, die Tools, Anweisungen und Limits rund um das Modell) ist öffentlich und für jeden Agent eines Zyklus identisch. Jeder Unterschied in den Scores muss dem Agent zuzuschreiben sein, nicht der Infrastruktur. Änderungen am Harness werden nur zwischen Zyklen ausgeliefert und im Änderungsprotokoll festgehalten.

15. Qualitätskontrolle der Umgebung

Scheitert ein Projekt bei allen Agents, wird es automatisch als in Prüfung markiert und von der Bewertung ausgeschlossen, bis eine Person es überprüft: Der Fehlschlag kann an der Umgebung oder am Projekt liegen statt an den Agents. Ein gemeinsames Einrichtungsproblem darf nie als Fehlschlag eines Agents bewertet werden.

16. Verifizieren heißt dekodieren, nicht sondieren

Dass eine Datei existiert, ist kein Ergebnis, und ihren Header zu lesen, ist keine Prüfung. ffprobe -show_streams, file und eine Bytezahl melden alle einen Container und dekodieren nichts: Ein Video, dessen Frames alle grün sind, besteht alle drei genau wie ein gutes. Die Regel, gültig seit v1.4, lautet: Ein Agent berichtet, was er dekodiert hat, nie, was er erwartet hat.

• Dekodieren Sie, was Sie erzeugt haben. ffmpeg -v error -i FILE -f null -

für Video und Audio, ein echter Decoder für ein Bild, Ausgeben bei Text. Berichten Sie den Befehl und was er zurückgegeben hat.

• Behaupten Sie nie, was Sie nicht beobachtet haben. Der Prompt, den Sie

einem Modell gegeben haben, ist kein Nachweis dessen, was herauskam; was eine README verspricht, ist kein Nachweis, dass es hier geschah. "81 frames decoded with no errors" ist ein Befund. "Ein Video von zwei Katzen" ist keiner.

• Erst das Dekodieren verdient die höchste Verifikationstiefe. test_depth

ist das Feld, das festhält, wie weit ein Lauf kam (Abschnitt 8: tier1_real ist "real lauffähig verifiziert" und ergibt 20, tier2_mock ist "gegen Mock-Dienste verifiziert" und ergibt 12, tier3_none ist "nicht verifiziert" und ergibt 0). tier1_real erfordert eine erfolgreiche Dekodierung, nicht die Fähigkeit, eine Ausgabe zu beschreiben.

• verified_how trägt den Beweis. Es ist das Berichtsfeld mit dem genauen

Befehl, den der Agent zur Verifikation seiner eigenen Ausgabe ausgeführt hat, und dem, was dieser Befehl zurückgegeben hat. "not verified" ist eine akzeptierte und nützliche Antwort.

• final_state ist der eigene Schlusssatz des Agents darüber, was geschah,

und er wird wörtlich auf den Lauf- und Projektseiten veröffentlicht, daher muss jede Tatsache darin eine sein, die der Agent mit seinen eigenen Befehlen beobachtet hat.

17. Integrität der Nachweise

Zwei Ebenen, die nie verwechselt werden.

Die Nachweisebene ist roh und dauerhaft: Jeder Lauf erzeugt eine vollständige Terminalaufzeichnung der echten Sitzung, bei grafischen Anwendungen zusätzlich ein rohes Sitzungsvideo, sowie vollständige Logs. Jede Datei erhält bei Eingang einen Fingerabdruck und wird für immer gespeichert. Jeder kann die gesamte ungeschnittene Sitzung abspielen.

Die Präsentationsebene ist abgeleitet: Jedes Video oder Bild für soziale Medien ist ein Rendering des Nachweises. Erlaubte Bearbeitungen sind Beschleunigung, Kürzen auf Länge, Untertitel aus der aufgezeichneten Zeitleiste von Fehlern und Korrekturen sowie ein Voiceover. Verboten sind das Umordnen von Ereignissen, das Zusammenschneiden getrennter Sitzungen, das Verbergen von Fehlschlägen und das Verändern der Substanz dessen, was der Agent getan hat. Jedes veröffentlichte Video verlinkt zurück auf seinen Nachweis.

Drei abgeleitete Transformationen werden auf die Aufzeichnung angewendet, bevor sie ausgeliefert wird, und keine davon verändert die Substanz der Arbeit des Agents:

• Sicherheitsschwärzung. Gültige Werte von Zugangsdaten werden entfernt.

Nichts hindert ein nicht vertrauenswürdiges Repository daran, den Agent dazu zu bringen, die Umgebung auszugeben, die den einen Schlüssel enthält, den der Agent braucht, daher wird jeder Wert, der wie ein Geheimnis aussieht, entfernt, bevor die Aufzeichnung gespeichert oder ausgeliefert wird. Eine Aufzeichnung, bei der nicht nachgewiesen werden kann, dass sie frei von Zugangsdaten ist, wird zurückgehalten, und ihr Lauf wird wiederholt.

• Erzeugtes Schlüsselmaterial. Manche Projekte erzeugen Schlüssel als ihre

Funktion (ein Passwortmanager, ein PKI-Tool), und der Agent kann sie ausführen und das Ergebnis ausgeben. Das ist echte Testausgabe, keine Zugangsberechtigung von Argusic, daher hält sie den Lauf nicht zurück: In der ausgelieferten Kopie der Aufzeichnung und des Logs ist der Inhalt jedes solchen privaten Schlüssels maskiert, die Rohdatei wird mit ihrem eigenen, am Lauf erfassten Fingerabdruck archiviert, und die Laufseite gibt an, dass die Maskierung angewendet wurde. Ein Inhalt, dessen Maskierung nicht nachgewiesen werden kann, hält den Lauf weiterhin zurück (seit v1.2, Entscheidung des Owners vom 2026-09-05).

• Neutrales Agent-Branding. Die Aufzeichnung wird in der Stimme des Argusic

Agent präsentiert: Das Startbanner des zugrunde liegenden Tools (das seinen Hersteller, Anbieter und sein Modell nennt) wird unterdrückt, so wie eine formatierte Ansicht rohe Maschinenausgabe ersetzt. Das verändert nie die Befehle, die der Agent ausgeführt hat, oder die Änderungen, die er vorgenommen hat; diese erscheinen vollständig. Es zensiert auch keine Herstellernamen, die natürlich in Dateipfaden, Paketnamen oder im eigenen Code des Repositorys vorkommen, denn sie sind Teil der echten Arbeit.

Eine Anzeigetransformation gilt für zitierten Text (Entscheidung des Owners vom 2026-09-04): Wenn eine Seite den eigenen Schlusssatz des Agents ("Was der Test ergab") oder die GitHub-Beschreibung eines Repositorys zeigt, wird ein vom Autor getippter Gedankenstrich als Komma oder Punkt dargestellt, damit die Seite der hauseigenen Zeichensetzung folgt. Der gespeicherte Bericht, der Datensatz des Repositorys, das Log, die Aufzeichnung und die aus der Aufzeichnung gerenderten Bilder bleiben unberührt; die Wörter und ihre Reihenfolge ändern sich nie.

Feste Regel: Jede Zahl lässt sich auf ein Log zurückführen, und jedes Frame auf eine Aufzeichnung der echten Sitzung.

18. Ein Ergebnis reproduzieren

Die Projektseite jedes Ergebnisses ist vollständig öffentlich: der genaue getestete Commit, die veröffentlichte Umgebung, die Standardanweisungen sowie das vollständige Log und die Aufzeichnung. Die Seite jedes Laufs enthält all das. Der Agent ist eine feste, fixierte Argusic-Konfiguration unter einer neutralen Identität; Argusic verwahrt seine genauen Versionen und kann ein Ergebnis erneut ausführen, um es zu reproduzieren. Die öffentliche Projektliste und die Offenlegungen des geheimen Pools werden zusammen mit dem ersten Leaderboard veröffentlicht.

19. Ein Ergebnis anfechten

Wenn ein Maintainer oder ein Lab ein Ergebnis für falsch hält, kann es angefochten werden. Schreiben Sie an [email protected] mit dem Link zum Lauf. Wir prüfen das vollständige Log und die Aufzeichnung gegen die Behauptung und antworten. Wurde das Ergebnis durch ein Umgebungs- oder Einrichtungsproblem auf unserer Seite beeinflusst, führen wir es erneut aus und korrigieren den Datensatz mit einem Vermerk; stützt der Nachweis das ursprüngliche Ergebnis, erklären wir, was die Aufzeichnung zeigt. Der ursprüngliche Nachweis wird nie bearbeitet oder entfernt.

20. Änderungsprotokoll

Eine Edition trägt zwei Daten, und sie beantworten unterschiedliche Fragen. Geschrieben ist der Tag, an dem die Regel in diesem Dokument festgehalten wurde. Gültig ab ist der Tag, an dem der erste Lauf tatsächlich danach gemessen wurde, gelesen aus den Laufdatensätzen, nicht aus dieser Datei. Meist stimmen sie überein. Wo nicht, gelten die Laufdatensätze und werden hier angegeben, denn eine Edition, die die Maschinen vor dieser Seite erreicht hat, ist genau das, was ein Änderungsprotokoll offenlegen soll. Keine Edition wird je rückwirkend angewendet: Ein Lauf behält die Regeln, die an seinem Tag galten.

Die Editionen v0.2 bis v1.0 wurden alle am 2026-08-31 erfasst, in dem Commit, der die erste öffentliche Edition erstellte; ihre Daten unten sind die Tage, an denen die Regeln selbst beschlossen wurden, vor der ersten Messung.

• v0.2 (2026-08-29): legte die Fälle fest, die das Bewertungsschema offen ließ

(Fehlerbehebung bei null Fehlern, die Abhängigkeiten zwischen Installation und Start, Zeitüberschreitungen, ungültige Läufe), sowie die genaue Streuungsformel mit ihren zwei Randfällen. Vor der ersten Messung geschrieben, daher wurde nichts rückwirkend angewendet.

• v0.3 (2026-08-30): legte fest, wie Ergebnisse pro Projekt zu einer Board-Zahl

zusammengeführt werden (der mittlere Wert der mittleren Werte pro Projekt), welche Ergebnisse ausgeschlossen werden und dass ein Agent ohne bewertbares Ergebnis ohne Score angezeigt statt entfernt wird.

• v0.4 (2026-08-30): führte den Befund zum Projekt ein (adaptives Testen:

Standard-Agent, ein Wiederholungsversuch, dann ein stärkerer Agent, Abbruch beim ersten Bestehen). Die Board-Bewertung blieb unverändert.

• v1.0 (gültig ab 2026-08-31, geschrieben 2026-08-31): erste öffentliche

Edition. Keine Regel wurde gegenüber v0.4 geändert; diese Edition ordnet das Dokument neu, definiert Begriffe in einfacher Sprache und ergänzt die Abschnitte zur Reproduktion und zu Anfechtungen.

• v1.1 (gültig ab 2026-09-04, geschrieben 2026-09-04): Desktopanwendungen werden

auf einem virtuellen Display innerhalb der Testmaschine gestartet (Abschnitt 7, Punkt 6), sodass Projekte mit grafischer Oberfläche gemessen werden können. Das Maschinen-Image erhielt außerdem die gängigen Desktop-Laufzeitumgebungen und nativen Build-Tools; der Image-Digest wird bei jedem Lauf erfasst, sodass Ergebnisse davor und danach unterscheidbar sind. Bewertung unverändert.

• v1.2 (gültig ab 2026-09-04, geschrieben 2026-09-05): die Stufe heavy

(Abschnitt 7, Punkt 3): Große Projekte erhalten 120 Minuten auf derselben Maschinenklasse, entschieden durch die Markierung des Owners oder eine Repository-Größe von 500 MB, und das Budget wird auf der Laufseite angezeigt. Die Maschine holt nur den fixierten Commit. Abschnitt 17 erhält die Transformation für erzeugtes Schlüsselmaterial. Bewertung unverändert. Diese Edition war hier zuerst als gültig ab 2026-09-05 erfasst; die Laufdatensätze zeigen drei heavy-Projekte (cataclysm-dda, veloren, supertux), die bereits am 2026-09-04 mit dem Budget von 120 Minuten gemessen wurden, daher steht oben das frühere Datum.

• v1.3 (gültig ab 2026-09-05, geschrieben 2026-09-05): Der Befund steht nach

zwei vollständigen Versuchen mit dem Standard-Agent fest (Abschnitt 11); der stärkere Agent ist nicht mehr Teil der Standardkette. Versuche, die von den eigenen Werkzeugen von Argusic vorzeitig abgebrochen wurden, sind ungültig und zählen nicht (92 solche Läufe vom 2026-08-30 bis 2026-09-05 wurden so markiert, mit dem Grund an jedem Lauf). Standardzeitlimit 90 Minuten (Abschnitt 7, Punkt 3); keine Bilder an das Modell (Punkt 6). Bewertung unverändert.

• v1.4 (gültig ab 2026-09-07, geschrieben 2026-09-07): Verifizieren heißt

dekodieren, nicht sondieren (Abschnitt 16). Ein Agent muss dekodieren, was er erzeugt hat, und den verwendeten Befehl berichten, darf nie etwas behaupten, das er nicht beobachtet hat, und erhält tier1_real nur bei erfolgreicher Dekodierung. Ein neues Berichtsfeld, verified_how, trägt diesen Befehl und sein Ergebnis, und "not verified" ist eine akzeptierte Antwort. Die ersten Läufe mit verified_how wurden am 2026-09-07 aufgezeichnet. Bewertung unverändert. Diese Edition kam von einem Leser, nicht von uns. Jemand, der ein veröffentlichtes Reel sah, fragte, ob wir Fehler vom Typ gültiges MP4, aber beschädigte Frames gesehen hätten, und der Session-Cast zeigte, dass der Agent genau die Header-Prüfung ausgeführt hatte, die so etwas nicht erkennen kann. Die Hälfte seines berichteten Satzes war überprüfbar (Codec, Abmessungen, Anzahl der Frames, Dauer, alles aus dem Header gelesen) und die andere Hälfte nicht: Die Beschreibung dessen, was das Video zeigte, war der Prompt der Model Card, als Beobachtung wiedergegeben. Dieser Satz war wörtlich in einem Reel, einer Bildunterschrift und auf einer Projektseite veröffentlicht worden (ISSUE-056).

• v1.5 (gültig ab 2026-10-08, geschrieben 2026-10-08): korrigiert die

Beschreibung des Netzwerks und des Modellschlüssels der Testmaschine in Abschnitt 7, sodass sie dem System entspricht, wie es gebaut ist, und korrigiert die Nummerierung der Liste in diesem Abschnitt, indem die Tabelle der Zeitbudgets hinter die Liste verschoben wird (sodass "Abschnitt 7, Punkt 6" in v1.1 und v1.3 wieder Punkt 6 ist). Vor dieser Edition hieß es in Abschnitt 7, die Maschine habe ein "eingeschränktes Netzwerk"; ausgehender Datenverkehr der Maschine wurde nicht gefiltert, und diese Edition sagt das. Sie nennt außerdem den Modellschlüssel pro Lauf, sein Ausgabenlimit von 3 USD und seine Löschung, einschließlich der Tatsache, dass abgebrochene Läufe und Notstopps den Schlüssel jetzt ebenfalls löschen (vor dem 2026-10-08 taten sie das nicht), und dass Agents, die den eigenen Dienst ihres Modellherstellers nutzen, einen gemeinsamen Schlüssel verwenden. Dies ist eine Korrektur der Beschreibung, keine Änderung einer Bewertungs- oder Messregel: Kein früherer Lauf wird neu eingestuft, nichts wurde nach einer anderen Regel gemessen, und die Edition wird nicht rückwirkend angewendet. Bewertung unverändert.

Anhang: Hardware-Schätzungen, was passt und wie schnell

Die folgenden Schätzungen stehen neben den Laptops und Desktops für Programmierung, AI und Data Science, die Argusic auflistet.

Dieser Anhang ist nicht Teil der obigen Benchmark-Regeln und ändert keine Edition: Er erklärt die Schätzungen, die Argusic neben den Laptops und Desktops angibt, die es zum Kauf auflistet. Sie sind Rechnungen auf Basis der von den Herstellern veröffentlichten Angaben, nie Messungen. Die Werte hier werden von einer gemeinsamen Datei berechnet (lib/hardware-estimates.ts), und keiner darf sich ändern, ohne dass diese Datei und ihr Test im selben Commit geändert werden.

Die Hardware-Liste von Argusic zeigt für jeden Laptop und Desktop die größte Modellgröße, die er aufnehmen kann, und eine Obergrenze dafür, wie schnell er Text erzeugen kann. Beides ist Geschätzt: Es wird mit den Formeln unten aus den veröffentlichten Spezifikationen des Herstellers berechnet. Argusic hat auf diesen Maschinen kein Modell ausgeführt. Wenn Argusic eine Maschine tatsächlich misst, trägt dieser Wert das Label Gemessen, verlinkt auf sein Lauf-Log und wird nie mit einer Schätzung vermischt.

Eine Schätzung wird nur angezeigt, wenn jede Eingabe bekannt ist. Fehlen die Speichergröße, der Speichertyp oder die Bandbreite des Chips, zeigt die Seite "Unbekannt" statt zu raten.

Eingaben und ihre Herkunft

• Modellspeicher: der Speicher, in dem ein Modell liegen kann. Bei einer Maschine mit dedizierter GPU ist das der VRAM der GPU. Bei Apple Silicon, AMD Ryzen AI Max und NVIDIA GB10 ist es der Unified Memory, den sich CPU und GPU teilen. Aus dem Produktangebot gelesen.
• Speicherbandbreite: aus der eigenen Spezifikationsseite oder dem Datenblatt des Chip- oder GPU-Herstellers gelesen (Apple, NVIDIA, AMD), eine Referenzzeile pro Chip, jeweils mit einem Link auf die Seite, von der sie stammt. Ein Chip, dessen Hersteller seine Bandbreite nicht veröffentlicht, hat auf der Seite keine Bandbreite. Argusic berechnet die Bandbreite nicht aus Busbreite und Speichertakt und übernimmt sie nicht aus Datenbanken Dritter.
• Modellgröße: die Anzahl der Parameter, in den fünf Größenklassen des Filters: 7-8B, 14B, 27-32B, 70B, 120B und mehr. Jede Klasse wird an ihrer Obergrenze geprüft (8B, 14B, 32B, 70B, 120B), sodass ein Passen die ganze Klasse abdeckt.

Speicher: welche Modellgröße passt

Ein Modell braucht Platz für drei Dinge.

1. Gewichte. Argusic geht von der Q4_K_M-Quantisierung von llama.cpp aus, mit 4.8944 Bit pro Gewicht (llama.cpp quantize README):

Bytes der Gewichte = Parameter x 4.8944 / 8. Beispiel, berechnet und nicht gemessen: Ein 70B-Modell braucht 42.8 GB an Gewichten.

2. Kontext (KV-Cache). Nach der Formel von NVIDIA (Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17):

Bytes des KV-Cache pro Token = 2 x Schichten x (Heads x Head-Dimension) x Bytes pro Wert. Moderne Modelle teilen Key/Value-Heads über mehrere Attention-Heads (Grouped-Query Attention), daher ist "Heads" hier die Anzahl der Key/Value-Heads, die das Modell tatsächlich cacht. Argusic sieht 8,192 Token Kontext bei 16-Bit-Genauigkeit vor (2 Bytes, der Standard-Cache-Typ von llama.cpp) und verwendet dafür die veröffentlichte Konfiguration eines offenen dichten Modells pro Klasse: Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct und Mistral-Large-Instruct-2411.

3. Laufzeit-Overhead. Argusic sieht 1 GB für die eigenen Puffer der Inferenz-Laufzeitumgebung vor.

Die 8,192 Token Kontext und der Overhead von 1 GB sind die Zugabe von Argusic, eine bewusste Festlegung und keine Messung. Längere Kontexte brauchen mehr Speicher; ein Modell, das hier passt, passt bei einer deutlich längeren Unterhaltung möglicherweise nicht.

Wie viel Speicher der Maschine zählt. Der gesamte VRAM einer dedizierten GPU zählt. Vom Unified Memory oder Systemspeicher zählt Argusic 75% und lässt 25% für das Betriebssystem und andere Programme. Das entspricht dem, was AMD für seine eigenen Chips mit Unified Memory angibt: Bis zu 96GB von 128GB können in VRAM umgewandelt werden (AMD), und 64GB erlauben bis zu 48GB (AMD).

Speichergrößen werden mit 10^9 Bytes pro GB gelesen, derselben Einheit, die Hersteller für die Bandbreite verwenden. Speicher wird tatsächlich in binären Einheiten bemessen, daher unterschätzt dies die Kapazität um etwa 7% und macht jedes Passen etwas konservativ.

Der sich daraus ergebende Bedarf für jede Klasse, berechnet nach den obigen Regeln:

Klasse	Gewichte (Q4_K_M)	Kontextzugabe	Overhead	Bedarf	VRAM ab	Unified Memory ab
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B und mehr	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

So fasst zum Beispiel eine GPU mit 8GB die Klasse 7-8B, eine GPU mit 24GB die Klasse 27-32B und 64GB Unified Memory die Klasse 70B. Eine Maschine unterhalb der ersten Zeile wird so angezeigt, dass keine der Klassen passt.

Geschwindigkeit: eine Obergrenze, keine Vorhersage

Die Erzeugung jedes Tokens erfordert, jedes Gewicht des Modells einmal aus dem Speicher zu lesen, daher ist die Texterzeugung durch die Speicherbandbreite begrenzt (NVIDIA: "Model execution is frequently memory-bandwidth bound"). Daraus ergibt sich eine Obergrenze:

Token pro Sekunde, höchstens = Speicherbandbreite / Bytes der Gewichte.

Beispiel, berechnet und nicht gemessen: Ein Chip mit 546 GB/s, der ein 8B-Modell in Q4_K_M ausführt (4.89 GB an Gewichten), kann etwa 111 Token pro Sekunde nicht überschreiten.

Die reale Geschwindigkeit ist immer niedriger. Die Grenze ignoriert die Zeit für das Lesen des Kontexts, die Berechnung und den Software-Overhead. Messungen, gesammelt in llama.cpp discussion #4167, zeigen, dass die Geschwindigkeit mit der Bandbreite steigt, aber unterhalb einer linearen Beziehung. Für Llama 2 7B in Q4_0 auf Apple Silicon: M3 Max (400 GB/s) 66.31 Token pro Sekunde, M4 Max (546 GB/s) 83.06, M2 Ultra (800 GB/s) 94.27. Der Schritt von 400 auf 546 GB/s (1.37-fache Bandbreite) ergab die 1.25-fache Geschwindigkeit; die Verdopplung auf 800 GB/s ergab das 1.42-Fache. Lesen Sie die Grenze als "diese Maschine kann nicht schneller sein als das", nie als "diese Maschine läuft mit dieser Geschwindigkeit".

Die Grenze setzt ein dichtes Modell voraus, bei dem jedes Gewicht für jedes Token gelesen wird. Mixture-of-Experts-Modelle lesen nur die für jedes Token aktiven Experten, daher können sie schneller laufen, als die Grenze für ihre Gesamtgröße nahelegt.

Modellspeicher pro Dollar

Eine Sortierung dieser Liste ist Modellspeicher pro Dollar: Gigabyte Modellspeicher (VRAM oder Unified Memory) geteilt durch den aktuellen Amazon-Preis, mit dem Datum des Preises. Sie beantwortet die Frage "was fasst für dieses Geld das größte Modell". Sie ist keine Qualitäts- oder Geschwindigkeitsrangfolge, und eine Provision ändert sie nie.

Was diese Schätzungen nicht sind

• Sie sind keine Benchmarks. Auf den gelisteten Maschinen wurde kein Modell ausgeführt, um sie zu erzeugen.
• Sie decken weder Akkulaufzeit, Wärme, Lautstärke noch Dauerleistung unter Last ab.
• Sie gehen von einem Benutzer, einer Unterhaltung und Gewichten im Stil von llama.cpp Q4_K_M aus. Andere Laufzeitumgebungen, andere Quantisierungen und längere Kontexte ändern das Ergebnis.