Kategorie: Tool-Tests

KI-Agenten verbrauchen viele Tokens. Das wird teuer. Adam Jacob zeigt mit seinem Workflow „Swamp“, wie man den Verbrauch senkt – ohne Funktionseinbußen. Sein Ansatz ist eine Systemoptimierung, kein Hype.

Es ist ineffizient, KI für Aufgaben zu nutzen, die deterministisch lösbar sind. Swamp trennt das: Routinesachen erledigt deterministischer Code, knifflige Fälle das LLM.

Das Problem: Garfield und der teure Koordinator

Ausgangssituation ist ein Skill namens „Garfield“, entwickelt bei Sentry. Garfield prüft nach jeder Code-Änderung die Coding-Policy. Es ist intelligent, flexibel – und teuer. Eine typische Ausführung verbraucht etwa 4,5 Millionen Tokens, läuft 12 Minuten und setzt 23 Sub-Agenten ein. Das Herzstück ist ein Koordinator-Agent, der Sub-Agenten losschickt, Ergebnisse einsammelt und bewertet. Ein Loop aus nicht-deterministischen Entscheidungen, bewertet von einem ebenfalls nicht-deterministischen Koordinator. Ein ineffizienter Loop.

Garfield ist nicht schlecht, aber es nutzt das LLM für jeden Schritt. Viele Schritte – etwa das Prüfen von Mustern oder Konventionen – sind deterministisch lösbar. Sie brauchen kein LLM. Ein Parser oder Regex reicht. Das LLM dort einzusetzen ist teuer.

Die Lösung: Swamp – deterministische Koordination, gezielte Intelligenz

Adam Jacob entwickelte eine Erweiterung für sein Swamp-System, die den Garfield-Skill ersetzt. Statt eines Koordinator-Agenten organisiert deterministischer Code die Arbeit der Sub-Agenten. Diese werden nur gestartet, wenn wirklich Intelligenz gefragt ist – etwa bei Stil- oder Architekturbewertung. Die Ergebnisse jedes Sub-Agenten werden als versionierte, typisierte Daten gespeichert. Das schafft Transparenz und vermeidet teure Wiederholungen.

Das Ergebnis: Statt 4,5 Millionen Tokens werden nur noch rund 500.000 benötigt – eine Reduktion um den Faktor 8. Die Laufzeit sinkt von 12 auf 6,5 Minuten, die Anzahl der Agenten von 23 auf 3. Die Funktionalität bleibt identisch, inklusive einer zusätzlichen Risikobewertungsphase. Die Einsparung kommt daher, dass der koordinierende Overhead wegfällt. Der Koordinator war teuer, weil er non-deterministisch die Arbeit anderer non-deterministischer Prozesse bewertete. Swamp ersetzt ihn durch deterministische Logik.

Schritt für Schritt: Wie du selbst von Garfield zu Swamp wechselst

Eine Anleitung in fünf Schritten, um diesen Prozess nachzuvollziehen.

Schritt 0: Installation und Initialisierung

Installiere Swamp mit curl -fsSL https://swamp-club.com/install.sh | sh. Gehe ins Verzeichnis deiner Agenten und Skills und initialisiere: swamp repo init --tool codex. Der Parameter --tool gibt das Framework an.

Schritt 1: Verstehe das aktuelle Verhalten

Bevor du umbaust, verstehe genau, was der Skill tut. Adam Jacob las den Garfield-Skill von Hand und machte Notizen. Dann ließ er Codex den Skill analysieren und zusammenfassen – inklusive ASCII-Diagramme. So visualisierte er das Zusammenspiel von Koordinator und Sub-Agenten. Auch wenn du den Skill selbst geschrieben hast, lohnt eine zweite Meinung, um blinde Flecken zu vermeiden.

Schritt 2: Übersetze den Skill in eine Swamp-Erweiterung

Bitte einen Agenten – Codex oder Claude –, den Skill in eine Swamp-Workflow-Erweiterung zu übersetzen. Die Anweisung: „Übersetze den Garfield-Skill in eine Swamp-Erweiterung. Ziel ist, das Verhalten direkt in deterministischen Code zu übertragen. Beginne mit einem Plan, den ich prüfen kann.“ Wenn du Swamp noch nicht kennst, wirst du die Details vielleicht nicht sofort beurteilen können. Wichtig ist, dass der Plan die gewünschten Ergebnisse abbildet. Sobald der Plan steht, lass den Agenten implementieren und teste manuell.

Schritt 3: Black-Box-Testing und Messung

Ein nützlicher Test für KI-generierten Code ist der Black-Box-Abnahmetest. Er gibt eine wiederholbare Methode für Verbesserungen und Regressionstests. Führe ihn in einem separaten Agentenkontext durch. Bitte den Agenten, einen Test zu schreiben, der alten Skill und neuen Swamp-Workflow ausführt und Token-Verbrauch, Ausführungszeit und Erfolgsquote misst. Der Agent erstellt dann eine Benchmarking-Suite, erzeugt eine Test-Codebase und führt die Tests durch. Die Ergebnisse sind aufschlussreich.

Adam Jacob maß zwei Testfälle. „contained-dry-run“ bestand: Garfield in 12,8 Minuten und 4,6 Millionen Tokens, Swamp in 6,6 Minuten und 506.000 Tokens. „payment-idempotency“ scheiterte in beiden Varianten – aber anders. Garfield scheiterte offen: es erklärte die Arbeit fälschlich für erfolgreich. Swamp scheiterte geschlossen: es meldete, die maximale Anzahl von Agenten sei erreicht. Das ist ein Vorteil deterministischer Systeme: Fehler werden gemeldet, nicht vertuscht.

Schritt 4: Refaktorisieren und Verfeinern

Die Messungen zeigen Optimierungsbedarf. Bei Garfield würde Adam Jacob die Fälle angehen, in denen der Workflow aufgibt, bevor alle Probleme gelöst sind. Er würde weitere Testfälle hinzufügen und prüfen, ob der Workflow mit größeren Änderungen zurechtkommt. Der Vorteil von Swamp: Änderungen sind einfach, weil der Workflow aus deterministischem Code besteht. Du misst, refaktorisierst, misst wieder – bis die Performance stimmt. Ein Kreislauf, den jeder Entwickler kennt.

Warum Swamp funktioniert – die Logik dahinter

Swamp ist effektiv, weil es deterministische Logik und KI-Intelligenz trennt. Statt das LLM in den heißen Pfad jeder Entscheidung zu stellen, erledigt deterministischer Code die meiste Arbeit – billig, schnell und vorhersagbar. Das LLM wird nur eingeschaltet, wenn es wirklich gebraucht wird. Das reduziert den Token-Verbrauch drastisch, ohne die Qualität zu beeinträchtigen. Weil die deterministischen Teile zuverlässig sind und die KI nur punktuell eingesetzt wird, sinkt auch die Fehlerrate. Der Workflow wird robuster.

Adam Jacob sagt: „Du nutzt den Agenten, um das Programm zu bauen, das die Notwendigkeit des Agenten minimiert.“ Das ist die Idee. Statt dem LLM jede Mikroentscheidung zu überlassen, erstellst du ein adaptives Modell des Problems. Die versionierten, typisierten Daten geben dir Transparenz über jeden Schritt. Du siehst, was die Sub-Agenten produziert haben, und kannst eingreifen. Das ist günstiger und kontrollierbarer.

Fazit: Ein pragmatischer Weg zu günstigeren KI-Workflows

Garfield und Swamp zeigen: Hohe Token-Kosten sind oft selbst verursacht. Wir neigen dazu, KI für Aufgaben zu verwenden, die einfacher Code erledigt. Adam Jacobs Ansatz kombiniert die Stärken beider Welten: deterministische Logik für das, was Computer schon immer konnten, und KI für das, was nur ein Modell leistet. Die Ergebnisse: achtmal weniger Tokens, doppelt so schnell, bessere Fehlermeldungen. Für Teams in der Produktion ist das eine effektive Optimierung und solide Systemarchitektur.

Quelle: adamhjk.com

Charles AZAM testete zwei KI-Modelle mit einem kniffligen Optimierungsproblem. Die Frage: Hilft der native /goal-Befehl, bessere Lösungen zu finden, oder ist er hinderlich? Die Ergebnisse zeigen, wann der Befehl nützt und wann er schadet.

Das Problem: Ein Netzwerk aus Glasfaser

Das Problem heißt KIRO, ein NP-schweres Optimierungsproblem aus der Netzwerkplanung. Es geht darum, in Grenoble, Nizza und Paris Verteilerpunkte und Endgeräte über Glasfaserkabel zu verbinden. Die Lösung muss aus redundanten Schleifen bestehen, die an Verteilerknoten hängen, mit kurzen Abzweigen von Masten. Jeder Mast darf nur einmal vorkommen, die Richtung der Kabel beeinflusst die Kosten. Ziel ist es, die gesamte Kabellänge zu minimieren.

Zur Einordnung: Der Suchraum ist astronomisch groß. Selbst wenn man nur die 532 Endgeräte in Paris auf 11 Verteilerknoten verteilt, gibt es 11^532 mögliche Zuordnungen. Eine konservative Abschätzung ergibt etwa 10^1223 Möglichkeiten. Die Anzahl der Atome im Universum wird auf 10^80 geschätzt.

Der Test: Sechs Modelle, zwei Modi, dreißig Minuten

AZAM ließ jedes Modell 30 Minuten rechnen, einmal im normalen Modus (Plain) und einmal mit aktiviertem /goal-Befehl. Der Befehl signalisiert: „Hier ist dein Ziel: Finde die kürzeste Gesamtkabellänge. Arbeite so lange, bis du es erreicht hast oder die Zeit abläuft.“ Gemessen wurde die Länge der gefundenen Lösung – niedrigere Werte sind besser. Als Benchmark diente AZAMs eigene, in C++ geschriebene Lösung.

Getestet wurden Claude Fable 5, Opus 4.8, Sonnet 5, Terra, Luna und GPT-5.6 Sol. Die Hauptvergleiche konzentrierten sich auf Fable und Sol, von denen jeweils drei vollständige Durchläufe pro Modus vorliegen. Alle Läufe liefen in einer Docker-Umgebung unter Harbor 0.1.43, mit maximaler Reasoning-Stufe und einem Timeout von 1900 Sekunden.

Die Ergebnisse: Fable dominiert, /goal ist ein zweischneidiges Schwert

Die Ergebnisse sind eindeutig: Claude Fable 5 ist GPT auf diesem Problem überlegen. Im Plain-Modus erreichte Fable durchschnittlich 32.386 Meter Gesamtkabellänge, Sol 34.261 Meter – ein Unterschied von fast 1.900 Metern. Fables Ergebnisse schwankten nur um 319 Meter, Sols um fast 2.000 Meter. Fable lieferte nicht nur durchschnittlich bessere, sondern auch verlässlichere Lösungen.

Beim /goal-Vergleich führte der Befehl in vier von sechs Durchläufen zu einer Verbesserung. Doch der Durchschnitt zeigt: Bei Fable stieg die Länge mit Goal um 759 Meter, bei Sol um 868 Meter. In den verbleibenden zwei Läufen gab es massive Verschlechterungen. Bei Fable sprang der Wert in einem Lauf von 32.446 auf 35.178 Meter (plus 2.732 Meter), bei Sol von 33.581 auf 39.371 Meter (plus 5.790 Meter). Der Median bewegte sich leicht in die richtige Richtung. /goal hilft häufig ein bisschen, schadet aber gelegentlich massiv. Die Gewinne sind klein, die Verluste können groß sein.

Warum ist das so? Ein Blick unter die Haube

AZAM untersuchte die Implementierung der /goal-Funktion in Claude Code und Codex. Obwohl der Befehl gleich heißt, steckt unterschiedliche Architektur dahinter. Bei Claude Code wird /goal als separater Evaluator realisiert. Nach jeder Antwort des Hauptmodells prüft ein kleineres Modell (Claude Haiku) anhand des Transkripts, ob das Ziel erreicht ist. Es kann keine Werkzeuge nutzen oder Dateien inspizieren – es sieht nur den Dialog. Bei Codex wird der Zielzustand persistiert und das Modell erhält spezielle Werkzeuge (create_goal, get_goal, update_goal). Das Modell entscheidet selbst, wann das Ziel erreicht ist, und bekommt bei Leerlauf eine Fortsetzungsaufforderung. Diese Architektur ist anfälliger für Fehleinschätzungen und kann dazu führen, dass das Modell zu früh aufgibt oder sich in eine falsche Richtung verbeißt.

Bei Optimierungsproblemen mit riesigen Suchräumen ist es nicht trivial zu erkennen, ob ein weiterer Schritt das Ergebnis verbessert oder verschlechtert. Ein Befehl, der einfach „mach weiter“ sagt, kann einen guten Algorithmus verstärken, aber auch einen schlechten weiter in die Irre führen. Die Qualität der Suchstrategie ist wichtiger als die Anzahl der Wiederholungen.

Was bedeutet das für die Praxis?

Blindes Vertrauen in einen /goal-Befehl ist nicht angebracht. Wenn du eine KI mit einer schwierigen Optimierungsaufgabe betraust, solltest du verstehen, wie der Goal-Mechanismus in deinem System funktioniert. Ein externer Evaluator, der nur den Dialog sieht, kann Fehlentscheidungen des Hauptmodells möglicherweise nicht korrigieren. Ein selbstbewertendes System kann sich in eine Sackgasse manövrieren und Ressourcen unnötig verbrauchen.

Der Benchmark zeigt auch, dass die Modellwahl entscheidend ist. Claude Fable 5 erwies sich auf diesem NP-schweren Problem als robuster und leistungsfähiger als GPT-5.6 Sol – unabhängig vom Goal-Modus. Die Kombination aus einem starken Modell und einer durchdachten Steuerung (ohne künstliche Goal-Vorgabe) führte zu den besten und verlässlichsten Ergebnissen.

KI ist kein Allheilmittel. Selbst fortschrittliche Modelle stoßen bei kombinatorischen Optimierungsproblemen an ihre Grenzen. Der /goal-Befehl ist kein Turbo-Knopf, sondern ein Werkzeug, das je nach Problem und Implementierung sowohl nützen als auch schaden kann. Teste verschiedene Konfigurationen, vertraue auf Konsistenz und sei skeptisch gegenüber Features, die auf den ersten Blick wie ein einfacher Verstärker wirken. Die wahren Helden sind durchdachte Algorithmen und clevere Problemzerlegung – die KI hilft, sie schneller auszuführen, ersetzt aber nicht das Verständnis des Problems.

Quelle: charlesazam.com

Im Labor von NetSecOPEN zeigte ein Test: Die Cisco Secure Firewall 6160 lieferte so hohe Durchsatzwerte, dass die Testwerkzeuge an ihre Grenzen stießen. Die Firewall ist für das Verkehrsaufkommen der KI-Ära konzipiert. Bei eingeschalteter Sicherheitsinspektion übertraf sie die Messmöglichkeiten der Hardware. Netzwerkanforderungen haben sich gewandelt, Sicherheit muss skalieren, ohne zu bremsen.

Langsame Internetverbindungen durch strenge Firewalls sind ärgerlich. In Rechenzentren und bei KI-Workloads wird das zum geschäftskritischen Problem. Die Datenströme heutiger Anwendungen sind größer und anders. Ein großer CDN-Anbieter berichtet, dass KI-gesteuerte Bots mehr als die Hälfte aller Webanfragen ausmachen. Über die Hälfte des menschlichen Internetverkehrs ist Post-Quanten-verschlüsselt. Firewalls müssen riesige Datenmengen bewältigen und tief in verschlüsselte Verbindungen hineinschauen. Dabei darf die Performance nicht leiden. Die Cisco Secure Firewall zielt genau darauf ab.

Test: Werkzeuge erreichten ihre Grenzen, die Firewall nicht

NetSecOPEN prüft Netzwerksicherheitsprodukte unter realistischen Bedingungen. Bei der Cisco Secure Firewall 6160 erreichten die Testwerkzeuge ihre CPU-Grenze, bevor die Firewall ausgelastet war. Der Bericht nennt es einen „5X-Benchmark“: Die Firewall übertraf den bisherigen Durchsatzrekord um das Fünffache. Die genaue Obergrenze blieb unklar. Die gemessenen Werte: 269,59 Gbps für inspizierten HTTP-Durchsatz, 222,37 Gbps für inspizierten HTTPS-Durchsatz, bei 5,6 Millionen gleichzeitigen TCP/HTTPS-Verbindungen und 80.000 neuen HTTPS-Verbindungen pro Sekunde. Die Testwerkzeuge waren bei 95–98 % CPU-Auslastung. Die Firewall hätte mehr liefern können.

Die Architektur dieser Firewall ist für eine Welt gebaut, die viele Netzbetreiber erst erreichen werden. Herkömmliche Firewalls brechen bei steigendem Traffic ein oder deaktivieren die Inspektion. Die 6160 skaliert durch. Die Software-Fähigkeiten – SnortML zur Erkennung von Zero-Day-Angriffen und die Encrypted Visibility Engine (EVE) für risikobewusste Entschlüsselung – sind nicht auf dieses Modell beschränkt. Sie finden sich in der gesamten Cisco Firewall-Produktfamilie: physisch, virtuell oder in der Cloud.

Alle Bedrohungen gestoppt bei Volllast

Im Test blockierte die Firewall 100 % aller Bedrohungen. Bei maximalem Durchsatz und paralleler Inspektion kein einfaches Ergebnis. Die 5.388 Bedrohungsszenarien umfassten 1.380 öffentliche CVEs, 180 private CVEs, 3.809 Malware-Varianten und 19 Umgehungsversuche. Die Firewall erkannte und stoppte jede.

Diese Leistung basiert auf Talos-Bedrohungsintelligenz, dem weltweit größten Sicherheitsforscherteam, und SnortML. SnortML erkennt Muster im Datenverkehr, die auf Schadsoftware hindeuten, auch bei unbekannten Angriffen. EVE identifiziert riskanten Traffic in verschlüsselten Verbindungen, ohne die Verschlüsselung zu brechen – für TLS, QUIC, SSH und STUN. Privatsphäre und Sicherheit bleiben gewahrt.

Preis-Leistung: Höherer Schutz bei weniger Platz und Strom

Die wirtschaftliche Nachricht: Cisco Secure Firewall 6160 bietet ein gutes Verhältnis von Preis zu Schutz bei KI-Workloads. Frühere Tests zeigten 2,5-mal mehr Preis-Leistung im Vergleich zu Wettbewerbern bei aktivierter Sicherheit. Die neuen Zahlen unterstreichen die Betriebskosten: Die Firewall benötigt bis zu 80 % weniger Rack-Platz und 60 % weniger Strom als vergleichbare Lösungen. Der Preis pro geschütztem Gigabit pro Sekunde liegt bei etwa einem Drittel des Wettbewerbsniveaus.

Für Unternehmen, die Rechenzentren für KI-Workloads rüsten, sind das praktische Zahlen. Weniger Rack-Platz bedeutet mehr Kapazität für Server und Speicher. Weniger Strom senkt CO₂-Bilanz und Kosten. Die Möglichkeit, Geräte zu einem Cluster mit bis zu 8 Tbps inspiziertem Durchsatz zu verbinden, erlaubt schrittweises Wachstum. Man kauft nicht die Maximalausbaustufe, sondern skaliert bei steigendem Traffic. Das ist wirtschaftlich klug und technisch sauber.

Was bedeutet das in der Praxis?

Vielleicht bist du kein Netzwerkadministrator. Aber die Prinzipien betreffen jeden, der digitale Dienste nutzt oder anbietet. Wenn Unternehmen ihre Netzwerke für KI-Anwendungen rüsten, darf Sicherheit nicht bremsen. Die Cisco Secure Firewall 6160 zeigt, dass hundertprozentiger Schutz möglich ist, ohne die Leistung zu drosseln – zu Kosten, die den Betrieb nicht belasten.

Die Autobahn-Analogie passt: Früher reichte eine vierspurige Straße, heute braucht es zwölf Spuren. Die Mautstelle muss alle Fahrzeuge prüfen, ohne Stau. Der Test zeigte: Die Firewall war schneller als das Testwerkzeug. In der Praxis bedeutet das: Unternehmen können auf die Sicherheit vertrauen, ohne Performance-Einbußen. In einer Zeit mit exponentiell wachsendem Datenverkehr durch KI-Agenten, verschlüsselte Ströme und viele vernetzte Geräte ist die Firewall für kommende Anforderungen ausgelegt.

Quelle: blogs.cisco.com

Welches KI-Modell hilft bei grossen Softwareprojekten? Die grossen Anbieter – OpenAI, Anthropic, SpaceXAI – versprechen bessere Frontend-Entwicklung, mehr Token-Effizienz, tiefere Zusammenarbeit. Was taugen diese Versprechen in der Praxis? Genau das hat Stephen M. Walker II mit einem praxisnahen Benchmark getestet: Basecamp Bench.

Walker hat nicht mit theoretischen Abfragen oder einfachen Code-Snippets gearbeitet. Er hat ein vollständiges, reales Produkt nachgebaut – die Basecamp-Projektmanagement-Oberfläche mitsamt Backend. Jedes getestete Modell startete im selben leeren Workspace, bekam dieselben Anforderungen, Mockups, Design-Tokens und API-Verträge. Das Ziel: zu sehen, wo die Modelle gut abschneiden, wo sie schwächeln und wo die Unterschiede klein sind. Das Ergebnis ist ein aufschlussreicher Vergleich.

Die Kandidaten und ihr Abschneiden

Fünf Modelle traten an: Fable 5 (Anthropic), Sonnet 5 (Anthropic), Grok 4.5 (SpaceXAI), GPT‑5.6 Sol (OpenAI) und GPT‑5.5 (OpenAI). Walker wertete in 20 Dimensionen aus – von funktionaler Vollständigkeit über API-Korrektheit bis hin zu Pixelgenauigkeit. Die zentrale Erkenntnis: Kein Modell gewinnt auf ganzer Linie. Der Spitzenreiter in der Gesamtwertung heisst Fable 5. Es erreichte 7,578 Punkte im Frontend und 8,392 im Backend – und liegt damit „innerhalb weniger Prozentpunkte der echten Basecamp-Implementierung“, wie Walker schreibt. Der Preis dafür: 85,87 $ Kosten und über zwei Stunden Bearbeitungszeit.

Auf der anderen Seite steht Grok 4.5. Es absolvierte beide Tracks in 37 Minuten für 9,30 $ – ein gutes Verhältnis von Geschwindigkeit zu Kosten. Dafür zeigen die Screenshots deutliche Layout-Probleme und fehlenden Feinschliff. Walker bezeichnet es als „stärkste Balance aus Geschwindigkeit, Kosten und funktionaler Tiefe“. Wer schnelle Prototypen braucht und Abstriche bei der Optik akzeptiert, findet hier eine gute Option.

Modell	Frontend	Backend	Gesamtzeit	Gesamtkosten
Fable 5	7,578	8,392	2:06:40	85,87 $
Sonnet 5	6,982	7,243	1:27:09	36,23 $
Grok 4.5	6,384	7,278	36:48	9,30 $
GPT‑5.6 Sol	5,765	7,310	59:48	15,13 $
GPT‑5.5	5,670	7,084	44:14	10,94 $

Frontend: Die letzten zehn Prozent sind die schwersten

Die Backend-Werte liegen dicht beieinander – fast alle Modelle registrieren die komplette Routen-Oberfläche, setzen Invarianten durch und liefern vertragskorrekte Antworten. Der grösste Unterschied zeigt sich im Frontend. Walker beobachtet, dass die Modelle hier zwischen Breite und Tiefe abwägen: „Die Abstände, Icons, Mikrointeraktionen und Übergänge, die ein Interface fertig wirken lassen – genau daran scheitern viele.“ Tom Cargill sagte dazu: „Die ersten 90 % des Codes verursachen die ersten 90 % der Entwicklungszeit. Die restlichen 10 % des Codes machen die anderen 90 % aus.“ Jeder weitere Punkt auf Walkers Skala ist schwerer zu erreichen. Von einer 5 auf eine 6 zu kommen ist relativ einfach. Von 8 auf 9 zu steigen verlangt ungleich mehr Tiefe.

Auffällig: GPT‑5.6 Sol schneidet im Frontend mit 5,765 deutlich schlechter ab als Fable 5, obwohl OpenAI dieses Modell speziell für Frontend-Arbeit bewirbt. Walker vermutet, dass Sol eher auf funktionale Korrektheit als auf visuelle Details optimiert ist. Sonnet 5 wiederum legt den Fokus auf „working, persistent workflows“ – also echte, durchgängig nutzbare Abläufe –, was ihm den zweiten Platz im Frontend einbringt.

Die Variabilitätsfalle: Ein einziger Run täuscht

Ein überraschender Befund: die Run-to-Run-Variabilität. Walker hat Sonnet 5 und GPT‑5.6 Sol jeweils fünfmal auf jedem Track gestartet. Die Ergebnisse schwankten deutlich: Bei Sonnet 5 Frontend reichte die Spanne von 6,178 bis 6,922, bei Sol von 5,780 bis 6,489. Die Mediane lagen bei 6,585 bzw. 6,026 – der Unterschied also geringer, als man nach den ersten Werten vermuten würde. Walkers Fazit: „Auf Frontend-Arbeit sind Sol und Sonnet 5 näher beieinander, als ihr Ruf vermuten lässt. Die beste Sol-Runde schlug die schlechteste von Sonnet, die schwächste Sol verlor gegen die beste von Sonnet.“ Das erklärt, warum Nutzer in Foren gegensätzliche Erfahrungen berichten – sie haben verschiedene Durchläufe erwischt.

Für dich als Entwickler heisst das: Eine einmalige Ausführung eines Modells sagt wenig. Du musst mindestens drei, besser fünf Durchläufe machen, um ein verlässliches Bild zu bekommen. Gerade bei kostengünstigen Modellen wie Grok 4.5 ist das auch finanziell machbar.

Was bedeutet das?

Basecamp Bench ist kein künstliches Konstrukt aus isolierten API-Calls. Es ist ein Gesamtarbeitsbenchmark, der die echten Herausforderungen der Softwareentwicklung abbildet: Anforderungen aus Screenshots und Design-Tokens extrahieren, eine kohärente Frontend-Oberfläche bauen, eine Backend-API mit korrekten Verträgen implementieren und beides so verzahnen, dass aus Einzelteilen ein funktionierendes Produkt wird. Die Modelle, die hier vorne liegen – Fable 5 für Qualität, Grok 4.5 für Geschwindigkeit und Wirtschaftlichkeit –, sind die, die du beachten solltest, wenn du deinen nächsten KI-Workflow planst.

Walker selbst weist darauf hin, dass er den Benchmark mit weiteren Modellen ergänzen wird – Gemini 3.5 Pro steht in den Startlöchern, und wenn die Gerüchte um GPT‑6 im Sommer stimmen, wird auch dieses getestet. Bis dahin liefert Basecamp Bench eine handfeste Entscheidungsgrundlage, die weit über Marketingversprechen hinausgeht. Die Zeit der einfachen Experimente ist vorbei. Die Ergebnisse zeigen, wo die Modelle wirklich stehen.

Quelle: smw.ai

Zwei KI-Programmierassistenten – Claude Code und OpenCode – unterscheiden sich enorm im Token-Overhead. Eine Messung zeigt, wie viel mehr Token Claude Code für den Overhead verbraucht und welche Auswirkungen das auf Kosten und Effizienz hat.

Der Tester hat beide Harnesses auf die gleiche Maschine und das gleiche Modell (Claude Sonnet 4-5) gesetzt. Dann hat er jede Anfrage und Antwort aufgezeichnet. Ergebnis: Claude Code schickt pro Anfrage rund 33.000 Token an Systemprompt, Tool-Schemas und anderen Vorlauf mit, bevor die Nutzeranfrage eintrifft. OpenCode kommt mit etwa 7.000 Token aus – weniger als ein Viertel. Das hat praktische Konsequenzen.

Die Messmethode: Ein Lauschangriff an der API

Um zu sehen, was die Harnesses wirklich senden, hat der Tester einen Logging Proxy zwischen die Programme und das Modell geschaltet. Dieser Proxy zeichnet zwei Dinge auf: das exakte JSON-Paket der Harness (Systemblöcke, Tool-Beschreibungen, Nachrichten) und die Verbrauchsdaten der API (Input-Token, Cache-Schreibvorgänge, Cache-Lesevorgänge, Output-Token). So wird die Kommunikation sichtbar.

Getestet wurde unter kontrollierten Bedingungen: leere Arbeitsverzeichnisse, keine MCP-Server, keine Benutzereinstellungen, keine Gedächtnisfunktion. Schritt für Schritt wurden Komponenten hinzugefügt – eine Anweisungsdatei, MCP-Server, Subagenten – um ihren Einfluss zu isolieren. Die Aufgaben reichten von der simplen Aufforderung „Antworte genau mit: OK“ bis zu einer mehrstufigen Schreib-Test-Korrektur-Schleife für ein FizzBuzz-Script.

Der Grund-Overhead: Warum Claude Code so viel mehr vorausschickt

Die erste Aufgabe war denkbar einfach: 22 Zeichen. Trotzdem unterschied sich die Größe der Anfragen deutlich. Claude Code packte einen Systemprompt aus drei Blöcken mit 27.344 Zeichen ein, dazu 27 Tool-Schemas mit fast 100.000 Zeichen und zusätzliche Erinnerungsblöcke (<system-reminder>). Das ergab nach Kalibrierung etwa 32.800 Token. OpenCode schickte einen Systemblock mit 9.324 Zeichen, 10 Tool-Schemas (20.856 Zeichen) und die Anfrage – insgesamt rund 6.900 Token.

Der größte Brocken bei Claude Code sind die Tool-Schemas. Claude Code bringt viele Werkzeuge mit – für Termine, Überwachung, Hintergrundprozesse. Diese werden alle beim Start geladen. OpenCode hat nur zehn klassische Programmierwerkzeuge. Das reduziert den Overhead.

Ohne Werkzeuge: Der reine Systemprompt

Um den Overhead der Tool-Beschreibungen zu isolieren, wurden beide Harnesses mit abgeschalteten Tools getestet. Ergebnis: Claude Codes Systemprompt allein wiegt 26.891 Zeichen (etwa 6.500 Token), OpenCode kommt auf 8.811 Zeichen (etwa 2.000 Token). Auch ohne Werkzeuge ist die Anleitung von Claude Code mehr als dreimal so umfangreich. Darin stecken Verhaltensregeln, Tonvorgaben, Sicherheitsrichtlinien und Umgebungsbeschreibungen.

Das hat eine praktische Konsequenz: Jede Anfrage startet bei Claude Code mit höherem Grundrauschen. Bei einem 200.000-Token-Kontextfenster sind 33.000 Token Overhead bereits ein Sechstel des Platzes, bevor Code im Gespräch ist. Bei OpenCode sind es etwa 3,5 Prozent. Das wirkt sich auf Kosten und den Platz für den Arbeitsinhalt aus.

Caching: Einsparpotenzial wird nicht immer genutzt

Moderne API-Anbieter bieten Prompt-Caching: Wenn sich Blöcke von Anfrage zu Anfrage nicht ändern, werden sie zwischengespeichert und zu einem Bruchteil der Kosten wieder eingelesen. Die Studie zeigt, dass OpenCode seinen Anfrage-Prefix in jeder gemessenen Sitzung byte-identisch hielt – ideal für Caching. Claude Code dagegen schrieb während einer Sitzung Zehntausende von Cache-Token immer wieder neu, obwohl die Aufgabe gleich blieb. Im Extremfall verursachte es auf der gleichen Aufgabe bis zu 54-mal mehr Cache-Schreibvorgänge als OpenCode. Cache-Schreibvorgänge werden zum vollen Satz berechnet; nur Cache-Lesungen sind günstig. Die Caching-Strategie beeinflusst die Kosten stark.

Die Multiplikatoren: Wenn die Konfiguration wächst

Im echten Projekt kommen Anweisungsdateien und MCP-Server hinzu. Ein 72 Kilobyte großes AGENTS.md oder CLAUDE.md aus einem Produktiv-Repository fügt jeder Anfrage rund 20.000 Token hinzu – bei beiden Harnesses. Allerdings ignoriert Claude Code AGENTS.md und benötigt den Namen CLAUDE.md. Wer versehentlich die falsche Datei ablegt, spart Tokens, bekommt aber auch keine Anweisungen – ein verstecktes Problem. OpenCode liest beide Namen und packt den Inhalt in den Systemprompt, was die Basislinie fast vervierfacht.

MCP-Server (Model Context Protocol) geben dem Agenten zusätzliche Fähigkeiten. Selbst unauffällige, öffentliche Server ohne Anmeldedaten fügen pro Anfrage 1.000 bis 1.400 Token pro Server hinzu. Mit fünf Servern wächst die Werkzeugliste von 27 auf 69 bei Claude Code und von 10 auf 52 bei OpenCode. Produktivserver mit umfangreichen APIs können diese Zahlen leicht verdoppeln oder verdreifachen. Jeder dieser Token muss bei jeder Anfrage mitgeschickt werden – auch wenn er nicht genutzt wird.

Subagenten: Wenn mehrere Helfer die Kosten vervielfachen

Eine Funktion beider Harnesses ist die Delegation an Subagenten. Die Studie testete einen Auftrag direkt und dann mit zwei Subagenten. Direkt kostete der Auftrag 121.000 Token, mit Subagenten stieg der Verbrauch auf 513.000 Token – mehr als das Vierfache. Der Grund: Jeder Subagent lädt seinen eigenen Systemprompt und seine Werkzeuge bei jeder Runde neu. Der übergeordnete Agent bekommt nur das Endergebnis, aber die Kosten der Subagenten laufen unabhängig. Wer häufig delegiert, muss mit stark steigenden Token-Kosten rechnen.

Allerdings gibt es einen Lichtblick: Bei mehrstufigen Aufgaben (Schreiben, Testen, Korrigieren) kann Claude Code seine größere Basislinie ausgleichen, indem es mehrere Werkzeugaufrufe in einer einzigen Anfrage bündelt. Während OpenCode für jeden Schritt eine neue Anfrage sendet und jedes Mal den 7.000-Overhead erneut bezahlt, fasst Claude Code manchmal zwei Dateioperationen und zwei Scriptausführungen in einem Roundtrip zusammen. In einem Fall gelang es so, dass Claude Code mit 121.000 Token günstiger abschnitt als OpenCode mit 132.000 Token. Allerdings ist dieser Vorteil nicht stabil: Auf einem neueren Modell (Claude Fable 5) brauchte Claude Code plötzlich sechs Anfragen statt drei und landete bei 298.000 Token – gegen OpenCodes 133.000. Die Bündelung hängt vom Verhalten des jeweiligen Modells ab, nicht von der Harness selbst.

Praktische Bedeutung

Die Studie zeigt: Die reine Token-Anzahl ist kein einfacher Indikator für Effizienz. Wer kurze, isolierte Aufgaben hat – eine Datei lesen und zusammenfassen – fährt mit OpenCode deutlich günstiger. Wer komplexe Arbeitsabläufe mit vielen zusammenhängenden Schritten ausführt, kann von der Bündelung profitieren, aber das ist nicht garantiert. Wer stark auf Subagenten setzt oder viele MCP-Server anbindet, muss mit erheblichen Kostentreibern rechnen – unabhängig von der Harness.

Wichtig ist auch die Transparenz. Der EU AI Act verlangt in Artikel 12, das Verhalten von Systemen zu verstehen und zu protokollieren. Die Frage „Was sendet mein Agent?“ sollte datengestützt beantwortet werden können. Die Methode dieser Studie – ein Logging-Proxy zwischen Harness und Modell – eignet sich dafür. Wer KI-Agenten produktiv einsetzt, sollte diese Technik beherrschen, um Kostenfallen zu vermeiden.

Der Vergleich zwischen Claude Code und OpenCode ist keine einfache Ja/Nein-Empfehlung. Er zeigt: Die Architektur-Entscheidungen der Harness – wie viele Werkzeuge sie standardmäßig mitbringt, wie sie Caching nutzt und Anfragen bündelt – haben massiven Einfluss auf die Kosten. Man sollte diese Entscheidungen verstehen, bevor man einen Assistenten produktiv einsetzt.

Quelle: systima.ai