Vierzigfache Kosten, null Prozentpunkte mehr Können: Was die Schicht um das Modell wirklich leistet

Dieselbe Maschine, andere Hülle

Am Donnerstag meldete Nvidia, sein Agentensystem AVO habe den interaktiven Reasoning-Benchmark ARC-AGI-3 vollständig gelöst. Das Bemerkenswerte war nicht die Zahl, sondern was dafür verändert wurde: nichts am Modell. Darunter arbeitet Claude Opus 5 — dasselbe Modell, das bei der ARC Prize Foundation mit 30,16 Prozent geführt wird. Verändert wurde ausschließlich die Schicht darum herum.

Für diese Schicht hat sich ein englischer Begriff durchgesetzt, den man schlecht übersetzen kann: Harness. Wörtlich das Geschirr, mit dem man ein Zugtier einspannt. Gemeint ist alles, was zwischen Ihrer Aufgabe und dem Modell steht: Was bekommt das Modell überhaupt zu sehen? Welche Werkzeuge darf es benutzen? Was passiert mit dem Ergebnis eines Werkzeugaufrufs? Wann gilt eine Aufgabe als erledigt, wann als gescheitert? Und was davon merkt sich das System bis zum nächsten Mal?

Das Modell ist der Motor. Der Harness ist alles andere am Fahrzeug. Die naheliegende Schlussfolgerung aus Nvidias Meldung lautet: Das Fahrzeug ist wichtiger als der Motor. Diese Schlussfolgerung ist verführerisch, sie wird gerade überall gezogen — und sie ist in der Form, in der man sie hört, falsch.

Was die sauberste Messung sagt

Im Juli haben Naman Vats und Oleg Golev eine Arbeit veröffentlicht, die genau das tut, was Nvidias Blogpost ausdrücklich nicht tut: eine kontrollierte Gegenüberstellung. Unter dem Titel „The Scaffold Effect in Coding Agents“ haben sie zwei Modelle — Qwen 3.6 Plus und MiniMax M2.5 — durch drei quelloffene Harnesses geschickt: Goose, OpenCode und OpenHands-SDK. Aufgabengrundlage waren 50 geschichtet ausgewählte Aufgaben aus Terminal-Bench Pro. Gleiche Modelle, gleiche Aufgaben, unterschiedliche Hülle.

Das Ergebnis in einem Satz aus der Zusammenfassung: „Harness choice induces up to a 40x difference in tokens per solved task, while paired within-model pass-rate differences remain 0-8 percentage points.“

Man muss diesen Satz zweimal lesen. Die Wahl des Gerüsts verändert den Verbrauch pro gelöster Aufgabe um bis zum Vierzigfachen. Die Trefferquote verändert sie um null bis acht Prozentpunkte — und die Autoren merken an, dass die Vertrauensbereiche bis auf den größten Abstand die Null einschließen, der Unterschied also statistisch meist gar nicht nachweisbar ist.

Das ist die unbequemste Zahl in dieser ganzen Debatte, und sie steht quer zu der Erzählung, die sich gerade etabliert. Der Harness macht Ihr System nicht klüger. Er macht es billiger oder teurer. Um den Faktor vierzig.

Hinzu kommt ein zweiter Befund, der praktisch fast noch wertvoller ist: Die Autoren finden charakteristische Fehlersignaturen, die sich über beide Modelle hinweg wiederholen — Goose scheitert typischerweise am Nachdenken, OpenHands-SDK an der Überprüfung oder an der Zugbegrenzung, OpenCode an Leerlaufschleifen bis zum Zeitablauf. Diese Muster hängen am Gerüst, nicht am Modell. Wenn Ihr Agent immer auf dieselbe Weise versagt, liegt das mit einiger Wahrscheinlichkeit nicht daran, welches Modell Sie gewählt haben.

Warum die Benchmark-Sprünge trotzdem echt sind

Wie passt das zu 30 gegen 100 Prozent? Es gibt keinen Widerspruch, sondern einen Unterschied in der Aufgabenart — und den sollte man verstehen, bevor man aus einer der beiden Zahlen eine Strategie ableitet.

Bei den Aufgaben in Terminal-Bench Pro weiß das Modell im Wesentlichen, was zu tun ist; die Frage ist, wie effizient es dorthin kommt. Da hilft ein besserer Harness beim Verbrauch, nicht beim Können. ARC-AGI-3 dagegen setzt einen Agenten in eine Umgebung ohne Anleitung, ohne erklärte Regeln, ohne genanntes Ziel. Hier ist die eigentliche Arbeit, überhaupt herauszufinden, worum es geht — und das heißt: systematisch ausprobieren, sich merken, was nicht funktioniert hat, und nicht in dieselbe Sackgasse zurücklaufen. Genau das sind Leistungen des Gerüsts, nicht des Modells. Ein Modell ohne Gedächtnis wiederholt seinen Fehler beliebig oft.

Daraus folgt eine brauchbare Faustregel. Bei Aufgaben, die das Modell im Prinzip beherrscht, ist der Harness ein Kostenhebel. Bei Aufgaben mit langem Horizont und schwacher Rückmeldung ist er ein Fähigkeitshebel. Die Frage für Ihr Projekt ist deshalb nicht, ob der Harness wichtig ist, sondern welche der beiden Aufgabenarten Sie eigentlich haben. Die meisten Unternehmen haben die erste und optimieren, als hätten sie die zweite.

Die Forschung stützt diese Zweiteilung. Das Papier zu Harness-Bench wertete 5.194 Ausführungsverläufe über 106 Aufgaben aus und empfiehlt daraus, Fähigkeiten „at the model-harness configuration level rather than attributed to the base model alone“ zu berichten. Der Confucius Code Agent erreichte 59 Prozent auf SWE-Bench Pro und übertraf damit frühere Forschungs- und kommerzielle Werte „under identical repositories, model backends, and tool access“ — also bei fixiertem Modell. Und das quelloffene Agentless zeigt die Gegenrichtung: ein bewusst nicht-agentisches Verfahren aus drei festen Schritten, das ohne autonome Schleife hohe Werte erzielt. Mehr Autonomie ist nicht automatisch besser.

Die Gegenprobe: Wenn das Gerüst zur Bremse wird

Es gibt ein ernstzunehmendes Argument dagegen, in diese Schicht viel zu investieren, und es kommt von unerwarteter Seite: von den Modellanbietern selbst.

Anthropics eigene Empfehlung an Entwickler ist bis heute bemerkenswert zurückhaltend. „When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed“, heißt es dort, und deutlicher noch: „Frameworks can help you get started quickly, but don't hesitate to reduce abstraction layers and build with basic components as you move to production.“ Die Definition, die der Text gibt, ist entwaffnend schlicht: „Agents are typically just LLMs using tools based on environmental feedback in a loop.“

Dahinter steht ein Argument, das in der Fachwelt unter dem Namen bitter lesson läuft — die wiederkehrende Erfahrung, dass allgemeine Verfahren, die einfach mehr Rechenleistung nutzen, spezialisierte handgebaute Lösungen am Ende schlagen. Der Analyst Daniel Miessler hat dafür den Begriff des BLE-hobbled system geprägt: ein System, dessen sorgfältig gebaute Hilfskonstruktion sich in dem Moment in eine Fessel verwandelt, in dem das darunterliegende Modell besser wird. Seine Merkregel dazu lautet: „Don't confuse the 'what' with the 'how.'“ Wer nur beschreibt, was erreicht werden soll, profitiert automatisch vom nächsten Modell. Wer vorschreibt, wie es zu geschehen hat, muss bei jedem Modellwechsel nachziehen.

Aaron Levie, Chef von Box, formuliert dieselbe Erfahrung schärfer: „you have to be brutally unsentimental in your architecture … you need to ruthlessly jettison your prior tech“, weil die Modelle immer wieder das übernehmen, wofür man zuvor eine Krücke gebaut hat.

Und schon 2024 hat die Evaluationsorganisation METR gemessen, dass Verbesserungen nach dem Training einem Modell 26 Prozentpunkte brachten, während ihre eigenen Verbesserungen am Gerüst nur acht ergaben — statistisch nicht signifikant. Ihre damalige Warnung gilt unverändert: „it's easy to accidentally worsen performance by using slightly different prompting or scaffolding.“

Wo die Bindung inzwischen sitzt

Wenn der Harness weder zuverlässig klüger macht noch dauerhaft überlegen bleibt — warum sollte er dann Ihre strategische Aufmerksamkeit verdienen?

Wegen des Gedächtnisses. Ein Modell ist zustandslos: Es weiß beim nächsten Aufruf nichts von diesem hier. Alles, was Ihr System über Ihre Abläufe, Ihre Ausnahmen und Ihre Eigenheiten gelernt hat, liegt zwangsläufig außerhalb des Modells — im Harness. LangChain hat diesen Punkt in einer Analyse mit dem Titel „Your Harness, Your Memory“ zugespitzt: Modelle lassen sich tauschen, angesammeltes Gedächtnis nicht. Harrison Chase beschreibt darin einen internen Assistenten, der nach versehentlicher Löschung aus derselben Vorlage neu aufgebaut wurde und danach deutlich schlechter arbeitete, weil er alle Präferenzen neu lernen musste.

Das verschiebt die Frage der Anbieterbindung um eine Etage. Jahrelang lautete die Sorge, man mache sich von einem Modellanbieter abhängig. Tatsächlich ist der Modellwechsel der einfachste Teil — quelloffene Harnesses wie der im August veröffentlichte DeepSeek-Harness, der als Steckplatzsystem gebaut ist und Anthropic, OpenAI, Bedrock, Vertex und Azure gleichermaßen anspricht, machen ihn zur Konfigurationsfrage. Schwer zu ersetzen ist das, was Ihr Gerüst über die Zeit angesammelt hat.

Wie viel technische Substanz in dieser Schicht steckt, zeigt eine Analyse von Claude Code: Sitzungen liegen als reine Anhänge-Protokolle vor, was Fortsetzen, Verzweigen und Zurückspulen erlaubt; vor jedem Modellaufruf durchläuft der Kontext eine fünfstufige Verdichtungskette; Unteragenten laufen in eigenen Kontextfenstern und geben nur eine Zusammenfassung zurück, damit der Hauptkontext nicht explodiert. Das ist kein Zubehör. Das ist das Produkt.

Was Sie daraus machen

Vier Konsequenzen, die sich aus dem Belegten ergeben und nicht aus der Erzählung.

Erstens: Fragen Sie bei jeder Benchmark-Zahl nach dem Gerüst. Ein Wert ohne Angabe des Harness ist keine Aussage über ein Modell. Nvidia selbst schreibt das in den eigenen Blogpost — die 100 Prozent spiegeln „the complete agent system, not only the underlying model“, und der Vergleich sei „not … a controlled ablation“.

Zweitens: Optimieren Sie den Harness auf Kosten, nicht auf Können. Der belegte Hebel ist Faktor vierzig beim Verbrauch und fast nichts bei der Trefferquote. Wählen Sie das Paar aus Modell und Gerüst deshalb nach Trefferquote unter einem Kosten- und Zeitbudget — genau das empfehlen Vats und Golev.

Drittens: Bauen Sie so wenig Gerüst wie möglich und so viel wie nötig. Jede handgebaute Hilfskonstruktion ist eine Wette darauf, dass das nächste Modell sie nicht überflüssig macht. Prüfen Sie diese Wetten in festen Abständen und reißen Sie ab, was gewonnen hat.

Viertens: Deckeln Sie den Verbrauch, bevor Sie ihn brauchen. Uber hat sein KI-Budget für 2026 nach vier Monaten aufgebraucht, ausgelöst durch die breite Einführung von Claude Code. COO Andrew Macdonald über den Zusammenhang zwischen Ausgaben und Ergebnis: „That link is not there yet.“ Bei einer Technik, deren Kosten je nach Gerüst um das Vierzigfache schwanken, ist eine Obergrenze pro Team keine Bürokratie, sondern die Voraussetzung dafür, überhaupt herauszufinden, was sie Ihnen wert ist.