Coding Agents im Test: lokal gegen Claude Code und Codex

Wohin geht Ihr Quellcode?

Wer heute einen Coding Agent einsetzt, trifft eine Entscheidung, die selten offen ausgesprochen wird: Der komplette Quellcode eines Projekts wandert Datei für Datei zu einem Dienstleister in die Cloud. Für ein Werbeportal mag das gleichgültig sein. Bei einer Branchenlösung, in der zwanzig Jahre Fachwissen stecken, sieht die Sache anders aus.

Die naheliegende Alternative heißt: eigenes Modell, eigener Server, eigenes Haus. Nur taugt die auch etwas? Wir haben es gemessen, statt darüber zu spekulieren. Zwei frei verfügbare Modelle auf unserer eigenen Hardware gegen Claude Code und Codex, identische Aufgaben in einem echten Projekt, automatische Bewertung, 544 Durchläufe. Die Ergebnisse fielen uneinheitlich aus. In einigen Aufgaben liegt lokal gleichauf, in anderen weit zurück.

Was ein Coding Agent von einem Autovervollständiger unterscheidet

Der Begriff wird durcheinandergeworfen, also kurz zur Einordnung. Ein Autovervollständiger schlägt beim Tippen die nächsten Zeilen vor. Ein Coding Agent bekommt einen Auftrag in normaler Sprache, sucht sich die passenden Dateien selbst zusammen, ändert sie, führt Befehle aus, liest das Ergebnis und arbeitet weiter. Er arbeitet also eine Aufgabe ab, über mehrere Schritte hinweg, ohne bei jedem Zwischenstand nachzufragen.

Das ist der Grund, warum die Frage nach dem Standort so gewichtig geworden ist. Ein Vorschlagswerkzeug sieht ein paar Zeilen. Ein Agent sieht das Projekt.

Der Testaufbau

Für den Vergleich haben wir ein eigenes Prüfgerüst gebaut. Alle Kandidaten lösen dieselbe Aufgabe im selben Projektstand, bewertet wird automatisch: hauptsächlich über die vorhandenen Testfälle, ergänzt um den Umfang der Änderung. Ein Agent, der halb Rom umbaut, um eine Zeile zu reparieren, verliert Punkte.

Angetreten sind auf der einen Seite Claude Code und Codex, beides Cloud-Dienste. Auf der anderen Seite zwei frei verfügbare Modelle, die bei uns im Haus laufen, auf unseren KI-Servern, jedes auf einer eigenen Radeon Pro W7800: Ornith 35B und qwen3.8 27B.

Ein Unterschied im Aufbau wird später wichtig: qwen3.8 ist ein dichtes Modell, bei dem für jedes Wort alle 27 Milliarden Parameter rechnen. Ornith ist ein Expertenmodell, es hält 35 Milliarden vor, weckt pro Wort aber nur etwa drei davon. Das macht es zweieinhalbmal so schnell, kostet aber mehr Speicher, weil trotzdem alle Experten bereitstehen müssen.

Die Aufgaben stammen aus dem Alltag: eine Rechnung erzeugen, einen Fehler in einer Ratenplan-Berechnung finden, eine verzwickte Lagerlogik über 19 Dateien korrigieren, eine Oberfläche nach einer Bildvorlage nachbauen.

Ein Hinweis zur Lesart der Zahlen, der wichtiger ist, als er klingt: Alle Werte der lokalen Modelle sind Mediane aus zehn bis zwölf Durchläufen derselben Aufgabe. Für Claude Code und Codex steht je ein Lauf dahinter. Warum wir diesen Aufwand getrieben haben, steht gleich im Anschluss an die Ergebnisse, kurz gesagt: Einzelmessungen haben uns bei diesem Test dreimal in die Irre geführt.

Das Teilnehmerfeld auf einen Blick

Weil sich im Lauf der Messungen mehrere Einstellungen und eine neue Modellversion ergaben, sind es am Ende sieben Varianten geworden:

Variante	Läuft	Bauform	Parameter	Kontext je Anfrage	Speicher	Tempo	Bilder	Läufe
Claude Code	Cloud	—	—	sehr groß	—	—	ja	18
Codex	Cloud	—	—	sehr groß	—	—	ja	18
Ornith 1.5	lokal	Experten (MoE)	35 Mrd., davon 3 aktiv	131.072	42,2 GiB	77 Tok/s	ja	95
Ornith 1.0 (Vorgänger)	lokal	Experten (MoE)	35 Mrd., davon 3 aktiv	131.072	39,7 GiB	84 Tok/s	nein	163
qwen3.8 Q4 + Vorhersage	lokal	dicht	27 Mrd., alle aktiv	131.072	35,7 GiB	31 Tok/s	ja	63
qwen3.8 Q4 (ohne Vorhersage)	lokal	dicht	27 Mrd., alle aktiv	131.072	32,7 GiB	28 Tok/s	ja	148
qwen3.8 Q8 (höhere Auflösung)	lokal	dicht	27 Mrd., alle aktiv	131.072	43,0 GiB	23 Tok/s	ja	45

Fett gesetzt ist, was heute bei uns im Betrieb läuft. Zusammen sind es 544 Durchläufe.

Warum die Zeilen so unterschiedlich viele Läufe haben, ist selbst ein Stück der Geschichte. Wir haben nicht sieben Varianten geplant und der Reihe nach abgearbeitet, das Feld ist während der Messung gewachsen.

Angefangen haben wir mit dem, was im Sommer bei uns lief: Ornith in Version 1.0 und qwen3.8 in der kleineren Auflösung Q4. Beide haben deshalb die meisten Läufe auf dem Konto, 163 und 148, sie waren wochenlang der Normalzustand, und jede Zwischenfrage wurde an ihnen geprüft.

Dann kam die erste Überlegung: Bringt die höhere Auflösung Q8 bessere Ergebnisse? Das Modell ist dasselbe, nur werden seine Werte feiner gespeichert, naheliegend, dass es dadurch sorgfältiger arbeitet. Also 45 Läufe zusätzlich, um es zu prüfen. Das Ergebnis war eindeutig und für uns überraschend genug, dass wir ihm einen eigenen Beitrag gewidmet haben.

Kurz vor der Veröffentlichung brachte uns dann ein Beitrag bei heise auf eine Technik, die erst wenige Monate zuvor in der Software gelandet war, mit der wir unsere Modelle betreiben: Multi-Token Prediction. Die Modelle bringen dafür eigene Vorhersageköpfe mit, die man nur einschalten muss, versprochen wurde ein spürbarer Tempogewinn ohne Qualitätsverlust. Wie das im Detail funktioniert, hat heise an anderer Stelle ausführlich erklärt. Ein solches Versprechen wollten wir nicht ungeprüft im Artikel stehen lassen, also kamen 63 weitere Läufe dazu, was dabei herauskam, steht in unserem Beitrag zu Quantisierung und Vorhersage.

Und schließlich veröffentlichte der Hersteller von Ornith mitten in unserer Testphase eine neue Version. Die haben wir ebenfalls durchgemessen, mit und ohne die neue Technik, zusammen 95 Läufe.

Das ist der ehrliche Grund für die ungleichen Zahlen: Bei einer Technik, die im Monatsrhythmus nachlegt, ist ein Test nie fertig, sondern nur an einem Punkt eingefroren. Wir haben den Punkt so spät wie möglich gelegt.

Vier Anmerkungen, weil hinter fast jeder Spalte eine Falle steckt:

Der Kontext je Anfrage ist nicht die Zahl aus dem Datenblatt. Alle diese Modelle können 262.144 Token, aber das ist ein gemeinsamer Topf, der auf gleichzeitige Anfragen aufgeteilt wird. (Wer mit den Begriffen Token und Kontextfenster wenig anfangen kann: Wir haben sie in einem eigenen Beitrag ohne Fachjargon erklärt.) Bei zwei Nutzern bleiben 131.072 pro Person, bei vieren nur noch 65.536. Davon gehen für einen Coding-Agenten rund 28.500 Token allein für Systemauftrag und Werkzeugbeschreibungen ab, bevor die erste Projektdatei geöffnet ist.

Speicher und Parameterzahl hängen nicht zusammen, wie man denkt. Ornith hat mehr Parameter als qwen3.8 und rechnet mit weniger davon, aber bereitstehen müssen alle, deshalb braucht es mehr Speicher. Ein Expertenmodell spart Rechenzeit, keinen Platz.

Die Speicherangaben gelten für diese Einstellung, nicht für das Modell an sich. Sie enthalten Gewichte, Bild-Encoder und den Zwischenspeicher für den Kontext. Wer den Kontext halbiert, kommt mit deutlich weniger aus.

Bei den Cloud-Diensten lassen wir die technischen Spalten leer. Welches Modell dort in welcher Größe rechnet, ist nicht öffentlich und ändert sich ohne Ankündigung. Zahlen zu nennen, die wir nicht nachmessen können, wäre in einem Messartikel unsauber.

Ein Hinweis noch zur Modellauswahl: Wir hatten zusätzlich zwei bekannte Modelle angetreten lassen und nach wenigen Läufen wieder herausgenommen, sie beherrschten das Aufrufen von Werkzeugen nicht zuverlässig genug, um über mehrere Schritte zu arbeiten. Ein Modell, das im Chat brilliert, taugt deshalb noch nicht als Agent. Achten Sie bei der Auswahl auf ausgewiesene Werkzeugunterstützung, sonst kaufen Sie Hardware für ein Modell, das im Agentenbetrieb nach fünf Minuten steht.

Die Testaufgaben

Die Aufgaben haben wir nicht erfunden, sondern aus unserem Alltag in der Softwareentwicklung abgeleitet, aus Dingen, die bei uns tatsächlich auf dem Tisch liegen. Jede läuft in einem echten Projekt mit Bestandscode und wird automatisch bewertet, hauptsächlich über Testfälle, die der Agent nicht zu sehen bekommt.

Rechnung erstellen. Umsatzsteuer je Position und einen Rechnungsrabatt ergänzen, mit verbindlichen Rundungsregeln. Die Einstiegsaufgabe: überschaubar, aber unbarmherzig, was Centbeträge angeht.

Ratenplan, Fehlersuche. Zwei unabhängige Fehler in einem Ratenzahlungsrechner finden, verschwindende Restcent und ein Überlauf bei Fälligkeitsterminen zum Monatsende. Die Ursachen liegen in zwei verschiedenen Dateien, und die vorhandenen Tests decken keinen der beiden Fälle ab.

Lagerlogik über 19 Dateien. Mehrere Fehler in einer Bestandsführung beheben. Der Auftrag nennt nur Symptome aus dem Support, weder wie viele Fehler es sind noch wo sie stecken. Das Sollverhalten steht nicht im Auftrag, sondern in einer Datei im Projekt, die erst gefunden werden muss.

Oberfläche nach Bildvorlage. Eine Oberfläche nachbauen, deren sämtliche Texte und Zahlen ausschließlich in einem Bild stehen. Ohne Bildverständnis ist die Aufgabe nicht zu bestehen, das war jedenfalls die Absicht, und sie hat uns später noch beschäftigt.

Dieselbe Aufgabe mit Anleitung. Identische Vorlage, identische Bewertung, aber zwei zusätzliche Sätze im Auftrag: Sieh dir die Vorlage direkt an, vermiss sie nicht. Schreib früh eine vollständige Fassung und verfeinere danach. Diese Variante zählen wir als eigene, vierzehnte Aufgabe. Sie liefert eines der überraschendsten Ergebnisse des ganzen Tests, dazu weiter unten mehr.

Wie die vier ausgingen

Aufgabe	Claude Code	Codex	qwen3.8 27B	Ornith 35B
Rechnung erstellen	100 %	100 %	100 %	100 %
Ratenplan, Fehlersuche	100 %	100 %	100 %	100 %
Lagerlogik, 19 Dateien	100 %	100 %	100 %	100 %
Oberfläche nach Bildvorlage	100 %	100 %	18 bis 100 %	18 bis 100 %

Alle Werte sind Prozent. Mediane aus mehreren Läufen derselben Aufgabe.

Bei den ersten drei Zeilen gab es keinerlei Streuung: Jeder einzelne Lauf erreichte die volle Punktzahl. Das ist kein gerundetes Ergebnis, sondern der Normalfall bei Aufgaben, die ein Modell wirklich beherrscht, entweder es kann sie, dann jedes Mal, oder es scheitert erkennbar.

Die letzte Zeile ist der Gegenfall. Dort steht keine Spanne im Sinne von „mal etwas besser, mal etwas schlechter": Die beiden lokalen Modelle lösten die Aufgabe in einem Teil der Läufe vollständig und im anderen Teil gar nicht, Werte dazwischen gab es praktisch nicht. Der Median sagt bei einem solchen Alles-oder-nichts-Muster wenig aus, aussagekräftiger ist, wie oft es klappte: bei qwen3.8 in 2 von 13 Läufen, bei Ornith in 5 von 6.

Alle sieben Varianten im Vergleich

Die Tabelle oben zeigt die vier Kandidaten, die heute bei uns laufen. Weil wir unterwegs auch ältere Modellstände und andere Einstellungen gemessen haben, hier dieselben vier Aufgaben über das gesamte Feld:

Variante	Punkte	schwächster bis bester Lauf	Zeit je Aufgabe	Läufe
Claude Code	100 %	100 – 100	106 s	4
Codex	100 %	100 – 100	172 s	4
Ornith 1.5 (aktuell)	100 %	18 – 100	512 s	18
qwen3.8 Q4 + Vorhersage (aktuell)	79,5 %	18 – 100	696 s	23
Ornith 1.0 (Vorgänger)	83,0 %	18 – 100	297 s	46
qwen3.8 Q4 (ohne Vorhersage)	89,2 %	18 – 100	934 s	48
qwen3.8 Q8 (höhere Auflösung)	79,5 %	18 – 100	956 s	16

Die Punkte sind der Durchschnitt der vier Aufgaben-Mediane, die Zeit der Median über alle Läufe. Dass die Spannen fast überall bei 18 beginnen, liegt an einer einzigen Aufgabe: der Bildvorlage. Bei den anderen dreien gab es über sämtliche Varianten hinweg keinen einzigen Lauf unter 100 Prozent.

Die Zeiten sind für die Bewertung unerheblich, aber aufschlussreich: Codex braucht im Median 172 Sekunden je Aufgabe, das schnellste lokale Modell 297. Der Faktor liegt bei knapp zwei, nicht bei zehn, wie viele erwarten.

Die dritte Zeile hat uns überrascht. Die Lagerlogik war die schwerste dieser vier: neunzehn Dateien, die Anzahl der Fehler unbekannt, die gültige Spezifikation erst zu finden. Ein 27-Milliarden-Modell auf einer einzelnen Grafikkarte löst sie vollständig, gleichauf mit beiden Cloud-Diensten. Es braucht dafür rund sechzehn Minuten gegenüber dreieinhalb bei Codex, aber es löst sie.

Die letzte Zeile hat es in sich und uns mehr Mühe bereitet als alle anderen zusammen. Dazu weiter unten ein eigener Abschnitt; vorweg nur so viel: Beide lokalen Modelle konnten diese Aufgabe zwischenzeitlich nie lösen, und der Grund lag nicht bei ihnen.

Sieben härtere Aufgaben

Weil drei von vier Aufgaben für alle Kandidaten zu bequem waren, haben wir nachgelegt. Die folgenden prüfen Dinge, die über das Lesen und Schreiben von Code hinausgehen. Urteilsvermögen, Sorgfalt, Umgang mit Widersprüchen.

Priorisierung unter Zeitdruck. Acht offene Meldungen, ein Zeitlimit, das erkennbar nicht für alle reicht. Zwei verursachen echten Schaden, gelöschte Belege, einbehaltenes Kundengeld —, die übrigen sechs sind Kosmetik. Die schweren Fälle stehen mitten in der Liste und sind nur am Inhalt zu erkennen.

Falsche Fährte. Ein Fehler, dessen naheliegende Ursache nicht die echte ist. Die auffällige Stelle trägt sogar einen TODO-Kommentar, ist aber korrekt, wer sie anfasst, macht Funktionierendes kaputt. Die naheliegende Schnellreparatur besteht die vorhandenen Tests und scheitert an der Sommerzeit.

Widerspruch dokumentieren. Eine neue Anforderung kollidiert mit zwei Dokumenten, die einander widersprechen: eine freigegebene Kalkulationsgrenze gegen eine später unterschriebene Kundenzusage. Verlangt ist nicht, den Widerspruch still aufzulösen, sondern ihn nachvollziehbar festzuhalten.

Nebenläufigkeit. Ein Fehler, der beim Lesen des Codes unauffällig aussieht und sich nur unter gleichzeitigem Zugriff zeigt: Lesen, Hochzählen und Schreiben sind drei getrennte Schritte. Der Prüftest startet acht echte Prozesse gleichzeitig.

Feature restlos ausbauen. Eine abgekündigte Versandart vollständig entfernen. Klasse, Registrierung, Konstante, Konfigurationsschlüssel, Dokumentation, Tests. Agenten sind stark im Hinzufügen und auffällig unvollständig im Entfernen; geprüft wird, ob wirklich keine Spur zurückbleibt.

Refactoring ohne Verhaltensänderung. Eine über Jahre gewachsene Preisformel lesbar machen, ohne das Ergebnis um einen Cent zu verschieben. Geprüft wird gegen 720 Ein- und Ausgabepaare aus der ursprünglichen Formel, die dem Agenten nicht vorliegen. Raten hilft nicht.

Projekt größer als das Kontextfenster. 450 Prüfklassen in 25 Bereichen, rund 472.000 Zeichen, mehr, als in das Kontextfenster irgendeines Kandidaten passt. Elf davon verstoßen gegen die Konventionen, in drei Mustern über alle Bereiche verstreut. Wie viele es sind, steht nirgends.

Die Ergebnisse der schweren Aufgaben

Aufgabe	Claude Code	Codex	qwen3.8 27B	Ornith 35B
Priorisierung unter Zeitdruck	100 %	100 %	100 % (schwächster Lauf: 32 %)	100 % (schwächster: 96 %)
Falsche Fährte	100 %	100 %	100 %	100 %
Widerspruch dokumentieren	100 %	94,7 %	100 %	100 % (schwächster: 95 %)
Nebenläufigkeit, 8 Prozesse	100 %	100 %	100 %	100 %
Feature restlos ausbauen	100 %	100 %	100 %	100 %
Refactoring ohne Verhaltensänderung	100 %	100 %	87 % (bester: 100 %)	100 %
Projekt größer als das Kontextfenster	100 %	100 %	100 %	100 %

Auch diese Aufgaben lösen inzwischen alle Kandidaten weitgehend vollständig, bei fünf von sieben ohne jede Streuung über alle Läufe. Auch die lokalen Modelle finden den Fehler, der sich nur zeigt, wenn acht Prozesse gleichzeitig auf dieselben Daten zugreifen. Wer erwartet hat, dass sich Cloud und Eigenbetrieb sauber in erste und zweite Liga sortieren, liegt falsch.

Zwei Zeilen verdienen einen Blick. Bei der Priorisierung reicht qwen3.8 zwar meistens an die volle Punktzahl heran, hat aber Ausreißer bis hinunter auf 32 Prozent, die Aufgabe hat ein hartes Zeitlimit, und wer sich verzettelt, kommt nicht mehr fertig. Beim Refactoring liegt qwen3.8 im Median bei 87 Prozent: In einem Teil der Läufe geriet die Formel zwar richtig, aber nicht sauber genug aufgeteilt.

Alle sieben Varianten im Vergleich

Variante	Punkte	schwächster bis bester Lauf	Zeit je Aufgabe	Läufe
Claude Code	100 %	100 – 100	185 s	7
Ornith 1.5 (aktuell)	100 %	94,7 – 100	434 s	25
qwen3.8 Q4 (ohne Vorhersage)	100 %	31,5 – 100	694 s	77
Codex	99,2 %	94,7 – 100	137 s	7
Ornith 1.0 (Vorgänger)	99,0 %	84,0 – 100	212 s	79
qwen3.8 Q4 + Vorhersage (aktuell)	98,1 %	31,5 – 100	593 s	21
qwen3.8 Q8 (höhere Auflösung)	95,1 %	31,5 – 100	743 s	20

Hier liegen alle sieben Varianten innerhalb von fünf Prozentpunkten beieinander, bei Aufgaben, die eigens dafür gebaut wurden, die Spitzenkandidaten zu fordern. Der Unterschied zwischen Cloud und Eigenbetrieb ist an dieser Stelle keine Frage der Fähigkeit mehr, sondern eine der Verlässlichkeit: Die Cloud-Dienste liefern in jedem Lauf dasselbe, die lokalen Modelle streuen.

Und noch etwas fällt auf: qwen3.8 mit Vorhersage schneidet hier schlechter ab als ohne (98,1 gegen 100 Prozent). Der Grund ist nicht die Technik, sondern die Zahl der Läufe — 21 gegen 77. Ein einzelner schwacher Lauf wiegt bei wenigen Messungen viel schwerer. Genau diese Falle beschreibt der nächste Abschnitt.

Die letzte Zeile war lange die eigentliche Ausnahme: Ornith fand bei dem übergroßen Projekt hartnäckig nur zehn der elf gesuchten Stellen, über zwölf Läufe hinweg. Mit der im August erschienenen Nachfolgeversion ist auch das erledigt, ohne dass wir an unserer Seite etwas geändert hätten.

Und zwei Aufgaben zu Hausregeln

Zuletzt haben wir geprüft, ob Agenten Konventionen befolgen, die nicht im Auftrag stehen: kein empty(), kein Gleitkomma für Geldbeträge, jede Änderung protokolliert. Einmal stehen diese Regeln in den Projektdateien, die jeder Agent automatisch mitliest, einmal nur in einer Fertigkeit, die er selbst finden und aufrufen muss.

Aufgabe	Claude Code	Codex	qwen3.8 27B	Ornith 35B
Regeln in der Projektdatei	92,5 %	100 % (schwächster: 92 %)	100 %	100 %
Regeln nur als Fertigkeit hinterlegt	92,5 %	85 % (bester: 92 %)	100 %	92 %

Das ist die einzige Stelle im ganzen Test, an der die beiden lokalen Modelle vor den Cloud-Diensten liegen, und sie ist aufschlussreicher als jede andere.

Bei jedem einzelnen Abzug fehlte nämlich derselbe Punkt: der Eintrag ins Änderungsprotokoll. Der Code war jedes Mal korrekt, die Namensregeln eingehalten, das Gleitkomma-Verbot beachtet. Nur die Zeile in der Datei, in der jede Änderung dokumentiert werden soll, blieb leer. Claude Code hat sie in allen drei Läufen vergessen, Codex ebenfalls.

Das ist kein Fähigkeitsproblem, sondern eine Frage der Sorgfalt bei Nebenpflichten, genau das, was auch ein Mensch unter Zeitdruck als Erstes weglässt. Wer Dokumentationspflichten an einen Agenten delegiert, sollte sie also prüfen, unabhängig davon, welchen er einsetzt.

Warum ein einzelner Durchlauf nichts beweist

Diesen Abschnitt haben wir nachträglich eingefügt, weil er die unangenehmste Erkenntnis des Tests enthält, eine über unsere eigene Messerei.

Wir hatten zunächst jede Aufgabe einmal gestellt und die Ergebnisse notiert. Als die Zahlen zu eindeutig wirkten, ließen wir dieselben Aufgaben zehnmal laufen. Dasselbe Modell, derselbe Auftrag, derselbe Projektstand, nichts verändert. Die Ergebnisse für qwen3.8:

Aufgabe	schlechtester Lauf	bester Lauf	Median
Priorisierung unter Zeitdruck	32 %	100 %	100 %
Ratenplan, Fehlersuche	33 %	100 %	100 %
Lagerlogik, 19 Dateien	49 %	100 %	100 %
Widerspruch dokumentieren	63 %	100 %	100 %
Refactoring ohne Verhaltensänderung	67 %	100 %	100 %

Zwischen dem schlechtesten und dem besten Lauf derselben Aufgabe liegen bis zu achtundsechzig Prozentpunkte. Wer einmal misst, zieht mit gleicher Wahrscheinlichkeit die eine oder die andere Zahl, und schreibt danach einen Satz, der falsch ist.

Bei einer Aufgabe ist selbst der Median irreführend. Die Oberfläche nach Bildvorlage löste qwen3.8 in sechs von zwölf Läufen vollständig und in den anderen sechs überhaupt nicht; dazwischen lag kein einziges Ergebnis. Der Median weist 57 Prozent aus, einen Wert, den das Modell nie erreicht hat. Bei solchen Alles-oder-nichts-Aufgaben ist die ehrlichere Angabe, in wie vielen Läufen die Aufgabe gelöst wurde, so steht sie weiter unten auch in den Tabellen.

Uns ist das dreimal passiert, alle drei Fehlschlüsse standen in einer früheren Fassung dieses Artikels:

"qwen3.8 kann keine Entscheidung dokumentieren." Der erste Lauf ergab 62,7 Prozent, das Dokument blieb leer. Über zwölf Läufe liegt der Median bei 100 Prozent.

"qwen3.8 führt die vorhandenen Tests nicht aus." Beim Refactoring hatte es sich vertippt, das Projekt lief nicht mehr, ein einziger Testaufruf hätte es gezeigt. Stimmt für diesen Lauf. Der Median über elf Läufe ist 100 Prozent, der Fehler war die Ausnahme, nicht die Regel.

"Ornith fehlte der Platz." Bei dem übergroßen Projekt fand es nur zehn von elf Stellen. Wir sahen nach, entdeckten eine unglückliche Aufteilung des Kontextfensters, verdoppelten es und maßen erneut: 100 Prozent. Der Fall schien geklärt. Über zwölf Läufe zeigte sich jedoch, dass der Wert vor und nach der Umstellung identisch war, beide Male 92,7 Prozent. Die Verdopplung hatte bei genau der Aufgabe nichts bewirkt, für die wir sie vorgenommen hatten. Gelöst hat das Problem am Ende der Modellhersteller: Die Nachfolgeversion findet alle elf Stellen, ohne dass wir etwas geändert hätten.

Und der vierte, der schwerste: Wochenlang hielten wir beide lokalen Modelle für unfähig, eine Bildvorlage zu lesen. Tatsächlich hatte unser eigenes Werkzeug ihnen das Bild nie gezeigt. Dazu unten ein eigener Abschnitt, es ist die lehrreichste Fehldeutung dieser ganzen Messreihe.

Für Sie hat das eine unmittelbare praktische Bedeutung: Wenn ein Anbieter oder ein Blogartikel ein Modell mit einer einzelnen Prozentzahl bewertet, wissen Sie jetzt, wie viel diese Zahl wert ist. Und wenn Sie selbst ein Modell für Ihr Haus prüfen, lassen Sie jede Aufgabe mehrfach laufen, bevor Sie danach entscheiden. Der Unterschied zwischen "das Modell kann es nicht" und "das Modell kann es meistens" ist genau der Unterschied zwischen einem und zehn Durchläufen.

Wo lokale Modelle abfallen, und wo wir uns geirrt haben

Der Abstand entsteht nicht bei der Qualität des geschriebenen Codes. Er entsteht beim Vorgehen, und bei der Betreuung, die ein lokaler Aufbau braucht. Der folgende Abschnitt ist zugleich das teuerste Lehrgeld dieser Messreihe.

Wir haben dem Modell die Augen zugehalten

Dieser Abschnitt stand hier schon zweimal, beide Male falsch. Was wir daraus gelernt haben, ist nützlicher als das ursprüngliche Ergebnis.

Die Aufgabe: Eine Oberfläche nach einer Bildvorlage nachbauen. Alle Texte und Zahlen stehen ausschließlich im Bild. Beide lokalen Modelle scheiterten daran über Wochen, während Claude Code sie in 69 Sekunden löste.

Die Protokolle waren kurios zu lesen. Statt hinzusehen, schrieb qwen3.8 zwanzig Minuten lang kleine Programme, die das Bild pixelweise vermaßen: Farbverteilungen je Region, zeilenweise Suche nach blauen Balken, Koordinaten von Textblöcken. Es befragte ein fremdes Texterkennungsmodell und ließ sich elf Behauptungen über den Bildinhalt einzeln bestätigen. Am Ende des Zeitlimits stand keine einzige geschriebene Datei.

Unsere Deutung damals: Das Modell kann zwar Bilder lesen, das hatten wir separat nachgewiesen —, benutzt die Fähigkeit im Agentenbetrieb aber nicht. Es sei, als vermesse jemand ein Foto mit dem Lineal, statt es anzuschauen.

Die Deutung war falsch. Das Modell hat nie ein Bild bekommen.

Aufgefallen ist es durch eine beiläufige Frage: Warum sagen die Modelle eigentlich, sie könnten keine Bilder sehen? Ein Mitschnitt der tatsächlich gesendeten Daten brachte es an den Tag. Statt des Bildes stand in der Nachricht dieser Text:

ERROR: Cannot read "bild.png" (this model does not support image input).
Inform the user.

Der Satz „ich kann keine Bilder sehen" stammte also nicht vom Modell. Unser eigenes Werkzeug hatte ihn ihm in den Mund gelegt. Und das Modell tat, was jeder vernünftige Mitarbeiter täte, dem man die Unterlagen vorenthält: Es versuchte, sich anders zu behelfen.

Die Ursache war ein einziges falsches Feld in einer Konfigurationsdatei. Wir hatten die Bildfähigkeit mit attachment: true hinterlegt. Das Feld existiert, aber der Agent wertet ein anderes aus:

"modalities": { "input": ["text", "image"], "output": ["text"] }

Was diese Zeile ausmacht, zeigt derselbe Test am selben Modell im Abstand einer Stunde:

	Ergebnis	Dauer
vorher	18 %	1200 Sekunden, Zeitlimit erreicht
nachher	100 %	85 Sekunden

Vierzehnmal schneller, und die Aufgabe gelöst statt gescheitert.

Wichtig für die Fehlersuche in eigenen Aufbauten: Bei einem dritten Modell, der Vorgängerversion von Ornith, änderte dieselbe Korrektur nichts. Das Modell blieb bei 37 Prozent. Der Grund: Es hat gar keinen Bild-Encoder, kann also wirklich keine Bilder lesen. Bevor man eine solche Falle sucht, muss man klären, ob das Modell die Fähigkeit überhaupt besitzt. Sonst repariert man an der falschen Stelle.

Zwei Modelle, zwei entgegengesetzte Bedürfnisse

Nach der Korrektur haben wir beide Bildaufgaben neu gemessen, einmal mit einer Vorgehensanleitung im Auftrag, einmal ohne. Die Anleitung besteht aus zwei Sätzen: Sieh dir die Vorlage direkt an, vermiss sie nicht. Schreib früh eine vollständige Fassung und verfeinere danach.

Kandidat	ohne Anleitung	mit Anleitung
qwen3.8 27B	18 %	100 %
Ornith 35B	100 %	37 %
Claude Code	100 %	100 %
Codex	100 %	100 %

Die beiden lokalen Modelle verhalten sich genau gegensätzlich, und das war die Überraschung dieser Messreihe.

qwen3.8 braucht die Anleitung dringend. Ohne sie erstickt es an der Aufgabe: In zwölf von dreizehn Läufen lief es ins Zeitlimit. Ein Bild kostet Kontext, und zwar viel; es wandert bei jedem weiteren Arbeitsschritt mit. Ohne Führung verliert sich das Modell darin.

Ornith verträgt sie nicht. Ohne Vorgaben löst es die Aufgabe vollständig, mit Vorgaben fällt es auf 37 Prozent. Warum, wissen wir nicht, plausibel ist, dass ein Modell, das ohnehin einen guten Weg wählt, durch eine abweichende Vorgabe eher gestört wird.

Für die Praxis heißt das etwas Unbequemes: Es gibt keine Prompt-Regel, die für alle lokalen Modelle gilt. Was dem einen hilft, schadet dem anderen, und zwar nicht ein bisschen, sondern um sechzig Prozentpunkte. Wer lokal arbeitet, muss den Auftrag am eigenen Modell ausprobieren, statt Ratschläge aus dem Netz zu übernehmen. Bei den Cloud-Agenten spielt es keine Rolle, die lösen die Aufgabe so oder so.

Das Modell prüft seine Arbeit nicht immer nach

Beim Refactoring einer Preisformel benannte qwen3.8 eine Konstante um und vertippte sich an einer von zwei Stellen. Danach lief das Projekt überhaupt nicht mehr. Im Projekt liegt eine Testsuite, ein einziger Aufruf hätte den Tippfehler sofort gezeigt. Zwanzig Minuten lang umgebaut und kein einziges Mal nachgesehen, ob das Ganze noch läuft.

Das war einer von elf Läufen, in den übrigen löste dasselbe Modell dieselbe Aufgabe vollständig. Der Punkt ist deshalb nicht, dass lokale Modelle nie testen, sondern dass sie es unzuverlässig tun. Claude Code und Codex lassen nach jeder Änderung die Tests laufen, ohne dass man sie darum bitten muss. Diese Verlässlichkeit trennt die Kandidaten im Alltag deutlicher als die Qualität ihres Codes: Ein Fehler in einem von zehn Durchgängen ist genau der Fehler, den niemand sucht, weil die neun anderen Male alles gut ging.

Mehr Platz hilft, nur nicht überall

Die härteste Aufgabe im Feld war ein Projekt mit 450 Prüfklassen in 25 Bereichen, zusammen rund 472.000 Zeichen Quelltext. Das passt in kein Kontextfenster. Elf dieser Klassen verstoßen gegen die Hausregeln, in drei verschiedenen Mustern und über alle Bereiche verstreut. Wie viele es sind, steht nirgends.

Drei der vier Kandidaten trafen exakt die elf richtigen Dateien, ohne eine der 439 anderen anzufassen. Ornith fand nur zehn. Beim Nachsehen fiel uns eine unglückliche Einstellung auf: Ornith lief mit einem Gesamtkontext von 262.144 Token, aufgeteilt auf vier gleichzeitige Anfragen. Pro Anfrage blieben 65.536, abzüglich der Grundlast von 28.500 also rund 37.000 Token für die eigentliche Arbeit. Wir stellten auf zwei Anfragen zu je 131.072 Token um, maßen erneut, und bekamen 100 Prozent.

Damit schien der Fall erklärt, und in dieser Form stand er auch in unserer ersten Fassung. Die Wiederholungsläufe haben ihn widerlegt. Vor der Umstellung wie danach liegt Ornith bei dieser Aufgabe im Median bei 92,7 Prozent; die 100 Prozent waren ein guter Lauf, kein Fortschritt. Woran es tatsächlich hakt, wissen wir nicht, es ist jedenfalls nicht der Platz.

Wertlos war die Umstellung deshalb nicht, sie wirkte nur woanders:

Aufgabe	65k je Anfrage	131k je Anfrage
Widerspruch dokumentieren	89,3 %	100 %
Refactoring ohne Verhaltensänderung	93,3 %	100 %
Priorisierung unter Zeitdruck	97,8 %	100 %
Projekt größer als das Kontextfenster	92,7 %	92,7 %

Ausgerechnet die Aufgabe, für die wir den Kontext verdoppelt hatten, profitierte als einzige nicht. Drei andere schon.

Zwei Lehren stecken darin. Die erste betrifft die Beschaffung: Prüfen Sie, wie viel Kontext bei Ihrem Aufbau tatsächlich pro Anfrage ankommt. Ein Server, der 262.144 Token bereitstellt, aber vier Anfragen gleichzeitig bedient, gibt jeder einzelnen nur ein Viertel davon. Die Zahl im Datenblatt des Modells ist nicht die Zahl, die bei der Arbeit ankommt.

Die zweite ist unbequemer: Eine Erklärung, die nach der Umstellung durch eine bessere Messung bestätigt wird, ist damit noch nicht richtig. Wir hatten eine plausible Ursache, eine passende Gegenmaßnahme und ein bestätigendes Ergebnis, und lagen trotzdem daneben.

Die dritte kam erst durch Zeitablauf. Im August erschien eine neue Version desselben Modells. Sie findet alle elf Stellen, auf Anhieb und in jedem Lauf, ohne dass wir an unserem Aufbau irgendetwas geändert hätten. Was wie ein hartnäckiges Problem der eigenen Infrastruktur aussah, war schlicht eine Grenze des damaligen Modells. Bei einer Technik, die im Monatsrhythmus nachlegt, gehört diese Möglichkeit in jede Fehlersuche: Manchmal ist die richtige Maßnahme, sechs Wochen zu warten.

Die Formalie erfüllt, den Zweck verfehlt

Eine Aufgabe hat auch die Spitzenkandidaten erwischt. Eine neue Anforderung kollidierte mit zwei Dokumenten, die einander widersprachen: eine freigegebene Kalkulationsgrenze von 20 Prozent gegen eine später unterschriebene Kundenzusage von 25 Prozent. Verlangt war nicht, den Widerspruch still aufzulösen, sondern ihn nachvollziehbar festzuhalten. Worin er besteht, welche Stellen betroffen sind, wie entschieden wurde, warum.

Codex lieferte als Entscheidungsdokument genau eine Zeile: "Entscheidung: deckel". Den Code hatte es korrekt gedeckelt, das geforderte Format erfüllt, aber keine Fundstelle genannt, keine Begründung geliefert, den betroffenen Kunden nicht erwähnt. Die lokalen Modelle bestehen diese Aufgabe im Median vollständig, aber eben nicht durchgängig: qwen3.8 legte in einem von zwölf Läufen dieselbe Datei an und ließ sie leer.

Uns hat dieser Befund mehr beschäftigt als jede Prozentzahl: Ein Agent erfüllt zuverlässig, was geprüft wird. Was nur gemeint war, erfüllt er nicht. Wer Dokumentation vom Agenten erwartet, muss lesen, was drinsteht, und nicht abhaken, dass die Datei existiert.

Der versteckte Engpass ist das Kontextfenster

Ein technisches Detail mit direkter Wirkung auf die Beschaffung. Bevor ein Agent die erste Projektdatei öffnet, belegen sein Systemauftrag und die Beschreibung seiner 27 Werkzeuge bereits rund 28.500 Token. Bei einem Fenster von 32.000 Token bleiben 3.500 für die eigentliche Arbeit übrig. Nach vier bis sechs gelesenen Dateien ist Schluss.

Dazu kommt ein Verhalten der aktuellen Modellgeneration: Sie schreibt ihre Überlegungen in ein eigenes Feld, bevor sie antwortet. Wird der Platz knapp, denkt das Modell bis zum Anschlag, das Antwortfeld bleibt leer, und es ruft kein Werkzeug mehr auf. In unserem Mitschnitt endete ein Aufruf bei exakt 32.767 Token, Abbruchgrund "Länge", Antwort leer. Inhaltlich hatte das Modell die Aufgabe zu diesem Zeitpunkt gelöst, es benannte im Denkfeld beide gesuchten Fehler korrekt. Es kam nur nie zum Schreiben.

Wer lokal Agenten betreiben will, sollte deshalb 128k Kontext einplanen und nicht 32k. Das ist eine Hardwarefrage und gehört vor den Kauf geklärt, nicht danach. Details dazu stehen in unserer Übersicht zu lokaler KI.

Auflösung, Tempo, Platz, die Stellschrauben der eigenen Hardware

Wie fein ein Modell gespeichert wird, wie viele Anfragen sich eine Karte teilen und ob man ihm Vorhersageköpfe zuschaltet: An diesen drei Stellschrauben haben wir gedreht und jede einzeln vermessen. Kurz gefasst, die höhere Speicherauflösung kostet ein Fünftel Tempo und zehn Gigabyte, ohne dass eine Aufgabe dadurch besser gelöst würde. Die Vorhersageköpfe dagegen halbierten bei einem der Modelle die Zahl der Abbrüche, beim anderen bremsten sie.

Weil das eine eigene Geschichte ist und vor allem die Beschaffung betrifft, steht sie in einem separaten Beitrag: Q4 oder Q8, und was Multi-Token Prediction wirklich bringt.

Was dieser Test nicht misst

Ein Benchmark misst abgegrenzte Aufgaben. Jede von ihnen startete bei uns mit leerem Gedächtnis, frische Sitzung, nichts aus dem vorherigen Lauf. Das ist saubere Messmethodik und für lokale Modelle zugleich die Betriebsempfehlung: Weil ihr Kontextfenster begrenzt ist und alles Vorherige darin mitwandert, sollte man nach jeder erledigten Aufgabe von vorn anfangen. Wer die Sitzung weiterlaufen lässt, sammelt Ballast an, bis das Fenster voll ist und der Agent mitten in der Arbeit stehenbleibt.

Genau dieser Zuschnitt versteckt die größte Stärke der Cloud-Agenten. Mit ihren erheblich größeren Kontextfenstern arbeitet man stundenlang in einer einzigen Sitzung durch, quer über Aufgaben hinweg, ohne dass etwas verlorengeht. Projektkonventionen, frühere Entscheidungen, Gedächtnisdateien: alles einfach mitgeladen und dauerhaft präsent. Bilder reichen sie ohne Zutun an das Modell durch, die Falle, die uns wochenlang beschäftigt hat, gibt es dort schlicht nicht. Zusätzliche Fertigkeiten, die man ihnen als Werkzeug oder Anleitung mitgibt, greifen sie von selbst auf. Nichts davon prüft ein Test, der jede Aufgabe isoliert stellt. Unsere Messwerte zeigen deshalb die Untergrenze dessen, was Claude Code und Codex können, nicht die Obergrenze.

Bei lokalen Modellen muss man dieses Umfeld selbst bauen. Kontext bewusst leeren, die richtigen Dateien gezielt zuführen, jede Fähigkeit einzeln freischalten und prüfen, ob sie tatsächlich ankommt. Und dann für jedes Modell herausfinden, ob es Vorgaben braucht oder von ihnen gestört wird, eine Antwort, die bei unseren beiden genau entgegengesetzt ausfiel. Das ist Arbeit, die in der Cloud niemand hat.

Den Kern der Sache, Code verstehen und Code schreiben, beherrschen auch die kleinen lokalen Modelle. Woran es hapert, sind Ausdauer und Umfeld.

Was es kostet

Die Cloud-Dienste rechnen pro Entwickler und Monat ab, in der Größenordnung eines Mobilfunkvertrags. Bei drei Entwicklern fällt das kaum auf, bei fünfzehn wird es zu einer Position, die jährlich wiederkehrt und mit der Teamgröße wächst.

Dem gegenüber steht eine einmalige Anschaffung. Was so eine Maschine kostet, hängt vor allem am Speicher der Grafikkarten: Unsere Konfigurationen beginnen bei rund 6.800 Euro für 32 Gigabyte und reichen bis etwa 20.000 Euro für die Leistungsvariante mit 96 Gigabyte; wer nicht kaufen will, mietet ab 200 Euro im Monat. Die aktuellen Zahlen samt Wartung und Housing stehen auf unserer Übersicht zu KI-Servern.

Ein Wort zur Ehrlichkeit an dieser Stelle: Diese Preise korrigieren wir derzeit im Wochentakt nach oben. Grafikkarten und Arbeitsspeicher sind seit Monaten teurer geworden, und ein Ende ist nicht abzusehen. Wir halten die Seite so aktuell wie möglich, aber verbindlich ist am Ende immer das Angebot. Wer plant, sollte den Puffer eher großzügig ansetzen. Woran das liegt und warum Abwarten die Sache eher verschlimmert, haben wir gesondert aufgeschrieben: KI-Server jetzt bestellen.

Danach kosten die Läufe nur noch Strom, und dabei überrascht ein Detail viele: Der Server muss nicht durchlaufen. Unserer legt sich schlafen, wenn ihn niemand braucht, und wird bei einer Anfrage per Netzwerkpaket geweckt. Von der Anfrage bis zur fertigen Antwort vergehen so 19 Sekunden, Aufwachen und Modellladen eingerechnet.

Wir haben nachgemessen, was er in den drei Betriebszuständen tatsächlich aus der Steckdose zieht:

Zustand	Leistungsaufnahme
Standby, wenn niemand arbeitet	unter 5 W
bereit, Modell geladen, keine Anfrage	60 W
Volllast auf beiden Grafikkarten	706 W

Der Wert für die Volllast stammt aus einem Dauertest über fünfzehn Minuten, bei dem beide Karten gleichzeitig am Anschlag liefen, eine Belastung, die im Alltag praktisch nie auftritt. Im normalen Betrieb arbeitet eine Karte, das sind rund 380 Watt.

Für eine überschlägige Rechnung: Bei acht Stunden täglicher Nutzung mit gemischter Last und Standby in der übrigen Zeit landet man bei etwa 1,5 bis 2 Kilowattstunden am Tag. Das ist die Größenordnung eines Wäschetrockners, pro Woche, nicht pro Tag. Die verbreitete Annahme, eigene Hardware verbrenne rund um die Uhr Strom, stimmt so nicht.

Ehrlich dazu gehört die Kehrseite: Wer lokal rechnet, zahlt mit Wartezeit. Über alle Aufgaben hinweg braucht das jeweils schnellste lokale Modell rund dreimal so lange wie der schnellste Cloud-Dienst. Die Spanne reicht dabei von Faktor 1,6 bis Faktor 9,5, im günstigsten Fall sind es zweieinhalb gegen anderthalb Minuten, im ungünstigsten sechzehn gegen dreieinhalb.

Gemessen ist dabei die reine Arbeitszeit des Agenten: vom Absenden des Auftrags bis zu dem Moment, in dem die geänderten Dateien im Projekt liegen. Ob diese Zeit im Alltag wehtut, hängt davon ab, wie man arbeitet, wer den Auftrag abschickt und sich derweil anderem zuwendet, merkt den Unterschied kaum. Wer daneben sitzt und wartet, sehr wohl.

Was die Rechnung im Einzelfall ergibt, hängt an Teamgröße und Laufzeit. Wir rechnen das gerne konkret durch, die Grundlagen dazu stehen unter Kosten.

Fazit

Für Routinearbeit im Code sind lokale Modelle 2026 angekommen. Rechnungen, Fehlersuche, Nebenläufigkeit, eine Fachlogik über neunzehn Dateien, ein Projekt mit 450 Klassen: gelöst, vollständig, im eigenen Haus. Wer aus Datenschutzgründen zögert, zögert nicht mehr aus Qualitätsgründen mit.

Über alle vierzehn Aufgaben gemittelt sieht es am Ende so aus:

Kandidat	Mittel über alle Aufgaben	Läufe
Claude Code	98,9 %	18
Codex	98,5 %	18
Ornith 35B (lokal)	95,0 %	53
qwen3.8 27B (lokal)	93,2 %	63

Gewertet ist hier jeweils die Fassung, die heute bei uns im Betrieb läuft: Ornith in Version 1.5, qwen3.8 in Q4 mit zugeschalteter Vorhersage. Die älteren Modellstände und die anderen Einstellungen, die in den Tabellen weiter oben mitlaufen, sind hier nicht enthalten. Sie waren Zwischenschritte, keine Kandidaten.

Der Abstand beträgt vier bis sechs Prozentpunkte, bei einem Preisunterschied, der pro Entwickler und Jahr im dreistelligen Bereich liegt, und bei Code, der das Haus nicht verlässt.

Bei allem, was Umsicht verlangt, führen Claude Code und Codex weiterhin klar. Sie schauen sich eine Vorlage an, statt sie zu vermessen, und zwar jedes Mal, nicht in jedem zweiten Durchgang. Sie führen nach dem Umbau die Tests aus. Sie erkennen, wann eine Aufgabe eine Rückfrage verdient. Und sie halten einen ganzen Arbeitstag in einer Sitzung durch, weil ihr Kontextfenster das hergibt. Der Abstand kommt aus diesen Gewohnheiten und aus dem längeren Atem. Mit der Anzahl der Parameter hat er wenig zu tun.

Ein Unterschied zeigt sich erst, wenn man oft genug misst: Verlässlichkeit. Die Cloud-Agenten lieferten in jedem Durchgang dasselbe Ergebnis, die lokalen Modelle schwankten bei identischem Auftrag um bis zu achtundsechzig Prozentpunkte. Im Alltag ist das der spürbarere Unterschied als jeder Mittelwert: Ein Modell, das eine Aufgabe in neun von zehn Fällen löst, verlangt, dass jemand hinsieht.

Was dieser Test grundsätzlich nicht abbildet

Und hier liegt die wichtigste Einschränkung des gesamten Vergleichs: Wir haben abgegrenzte Einzelaufgaben gemessen. Jede startete mit leerem Gedächtnis, wurde erledigt, bewertet, verworfen. Das ist saubere Messmethodik, und es ist ausgerechnet die Disziplin, in der lokale Modelle am besten dastehen.

Der Alltag sieht anders aus. Dort arbeitet man stundenlang in derselben Sitzung: Ein Ticket führt zur nächsten Frage, aus der Antwort ergibt sich ein Blick in ein anderes Modul, dazwischen liegen Projektkonventionen, frühere Entscheidungen, ein Blick in die Dokumentation und drei weitere Dateien. Claude Code und Codex halten das durch. Sie ziehen sich aus mehreren Quellen gleichzeitig zusammen, was sie brauchen, behalten den Faden über Stunden und verlieren dabei nichts von dem, was am Anfang besprochen wurde.

Der Grund ist schlicht Platz: Ihr Kontextfenster ist ein Vielfaches dessen, was wir lokal bereitstellen können, im günstigsten Fall bringen unsere Modelle ein Viertel davon auf, und davon geht die Grundlast des Agenten schon ab. Ein lokales Modell arbeitet deshalb am besten in kurzen, frisch gestarteten Sitzungen mit einer klar umrissenen Aufgabe. Wer es wie einen Cloud-Agenten benutzt und stundenlang durcharbeitet, sammelt Ballast an, bis das Fenster voll ist und der Agent mitten in der Arbeit stehenbleibt.

Beides gleichzeitig gilt also: Für eine einzelne, klar gestellte Aufgabe liefern lokale Modelle eine Qualität, die zufriedenstellt, das zeigen die Zahlen oben deutlich. Für das durchgehende Mitdenken über einen ganzen Arbeitstag, quer über Tickets, Systeme und Quellen hinweg, sind die Cloud-Dienste weiterhin klar überlegen, und daran wird sich nichts ändern, solange der Unterschied beim Kontextfenster so groß ist.

Für die meisten Mittelständler ist der sinnvolle Weg deshalb kein Entweder-oder. Sensible Projekte lokal, anspruchsvolle Umbauten mit einem Cloud-Agenten, und für beides klare Regeln, welcher Code welchen Weg nimmt. Wie das im Team praktisch aussieht, zeigen wir unter KI für Entwicklungsteams.

Tipp: Prüfen Sie als Erstes, ob bei Ihrem Agenten überhaupt ankommt, was Sie ihm schicken. Uns hat ein einziges falsch benanntes Konfigurationsfeld wochenlang glauben lassen, unsere Modelle könnten keine Bildvorlagen lesen, dabei hatte das Werkzeug ihnen das Bild nie gezeigt. Lassen Sie danach jede Aufgabe mehrfach laufen, bevor Sie ein Modell beurteilen: Dasselbe Modell schwankte bei derselben Aufgabe zwischen 18 und 100 Prozent. Und beginnen Sie nach jeder erledigten Aufgabe eine frische Sitzung, damit das knappe Kontextfenster der Arbeit gehört und nicht dem Protokoll der letzten Stunde.