Kategorie: KI-News

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

Du entdeckst eine Kiste voller alter 8-Bit-Spiele – die Cartridges sind da, aber kein Rechner. So ging es Mathematikern mit Java-Applets aus den Neunzigern: browserlesbare Digitalfossile. Terence Tao hat das Problem angepackt, nicht mit Schraubenzieher, sondern mit einem KI-Agenten. Das Ergebnis zeigt, wie Sprachmodelle Legacy-Code vereinfachen.

Tao begann 1999, Java-Applets für seine Kurse zu schreiben. Er visualisierte mathematische Objekte wie Honeycombs und Besicovitch-Mengen. Die Applets waren nützlich, aber zeitaufwendig. Mit der Zeit starb die Browserunterstützung – die Applets wurden nutzlos. Dann beauftragte er einen KI-Agenten, sie in JavaScript zu portieren. Der Agent erledigte zwei Dutzend Applets in wenigen Stunden.

Fast zu gut, um wahr zu sein? LLM-basierte Agenten bauen subtile Fehler ein. Tao fand nur einen Bug: ein Drag-Ereignis in einem Analysis-Applet. Der Agent identifizierte zwei Fehler im Originalcode. Netto-Null-Effekt. Die Applets sind sekundäre Hilfsmittel – das Risiko ist überschaubar. Der Präzisionsgrad ist gut.

Der Erfolg ermutigte Tao zu einem ehrgeizigeren Projekt: einer Vision von 1999, einem Visualisierungstool für die spezielle Relativitätstheorie – quasi Inkscape im Minkowski-Raum. Inkscape existierte noch nicht, sein Java-Code war zu komplex. Nach ein paar Stunden Programmieren im Dialog mit einem KI-Agenten war ein funktionierender Prototyp fertig. Tao nennt das Programmieren im Dialog mit dem Modell. Der Applet erlaubt interaktive Minkowski-Diagramme, inklusive Zeitdilatation und Längenkontraktion. Tao veröffentlichte Code und Dialog. Es ist eine Alphaversion.

Nach einem Blog-Beitrag über die Gilbreath-Vermutung ließ er den Agenten in wenigen Stunden eine interaktive Visualisierung erstellen. Der Prozess war schmerzfrei: in wenigen Stunden ein brauchbares Ergebnis. Früher wäre das ein kleines Forschungsprojekt gewesen. Heute entsteht es in einer Kaffeepause. Das Risiko von Fehlern bleibt, aber die Visualisierungen sind nicht mission-critical. Der Nutzen überwiegt.

KI-Coding-Agenten werden zu einem Werkzeug für digitale Restauration. Taos Experiment zeigt: auch zwei Jahrzehnte alte Codebasen lassen sich mit geringem Aufwand in moderne Sprachen überführen – mit niedriger Fehlerrate. Für Lehrer und Forscher eröffnet sich eine neue Möglichkeit: interaktive Visualisierungen in Stunden statt Wochen. Der Agent agiert als produktiver Assistent. Tao hat das demonstriert. Alte Applets werden zu Sprungbrettern für neue Ideen. Webseiten mit toten Java-Applets gehen zu Ende.

Die Frage ist nicht, ob KI-Agenten das können – sie haben es gezeigt. Sondern wie wir sicherstellen, dass die Visualisierungen mathematisch korrekt sind, wie wir die Prozesse dokumentieren und wie wir Plattformen zum Teilen schaffen. Tao hat einen Anstoß gegeben. Jetzt liegt es an uns, das Werkzeug zu nutzen. Ähnliche Anwendungen werden in anderen Bereichen folgen, in denen alter Code neues Wissen birgt.

Quelle: terrytao.wordpress.com

Du betreibst eine Webanwendung, alles läuft – bis die Datenbank nicht mehr reagiert. Kein SELECT, kein INSERT. Server hängt, Fehlerlogs laufen über. Wer eine PostgreSQL-Instanz betreut, kennt diese Momente. Sie haben oft vier Ursachen. Der Entwickler von pgrust, einer Neuimplementierung von Postgres in Rust, hat diese Problembereiche analysiert. Er beschreibt, warum sie zu Ausfällen führen – und wie sein Ansatz helfen könnte. Schauen wir uns die vier Punkte an.

1. VACUUM und Transaction ID Wraparound – die stille Gefahr

Wenn du in Postgres eine Zeile löschst, wird sie nicht sofort physisch entfernt. Postgres markiert sie als gelöscht – das ermöglicht Rollbacks. Die Bereinigung übernimmt ein Hintergrundprozess namens VACUUM. Er liest alle Daten und entfernt die markierten Zeilen. Das klingt harmlos, birgt aber zwei Risiken. Erstens: VACUUM frisst I/O. Es konkurriert mit deinen Abfragen um die Festplattenbandbreite. Stell dir vor, du liest ein Buch, während jemand neben dir Seiten herausreißt – so ähnlich fühlt es sich für die Datenbank an. Du musst VACUUM richtig einstellen: aggressiv genug, um mit gelöschten Zeilen Schritt zu halten, aber nicht so aggressiv, dass es Queries ausbremst. Eine knifflige Balance, besonders ohne dedizierten Datenbank-Admin.

Das zweite Problem ist tückischer: Transaction ID Wraparound. Postgres vergibt pro Transaktion eine 32-Bit-ID – maximal vier Milliarden IDs. Sind alle verbraucht, müssen sie wiederverwendet werden. VACUUM markiert alte IDs, damit sie sicher recycelt werden. Hinkt VACUUM hinterher, schaltet Postgres die Datenbank komplett ab – sonst könnten Daten korrupt werden. Der Autor schätzt, dass dieser Mechanismus weltweit für tausende, wenn nicht zehntausende Ausfälle verantwortlich ist. pgrust plant zwei Lösungen: 64-Bit-Transaktions-IDs, die zwar Overhead pro Zeile bedeuten, aber den Wraparound praktisch auf unbestimmte Zeit verschieben. Außerdem wird eine Architektur ohne VACUUM diskutiert – ähnlich dem Undo-Log von Oracle. Der Ansatz ist vielversprechend, erfordert aber grundlegende Änderungen.

2. Connection Limits und Query Parallelism – wenn die Türen zu bleiben

Jede Postgres-Instanz hat eine Konfigurationsvariable für die maximale Anzahl gleichzeitiger Verbindungen. Wenn mehr Clients versuchen, sich zu verbinden, werden sie abgewiesen – die Datenbank ist nicht erreichbar. Simpel, aber die Falle lauert im Detail: Änderungen an diesem Grenzwert erfordern einen Neustart. Wer den Wert zu niedrig ansetzt, steht im Regen. Viele nutzen PgBouncer, einen Verbindungspooler, der das Problem mildert, aber nicht beseitigt. Warum ein Grenzwert? Der Grund liegt in der Prozess-Architektur von Postgres. Für jede neue Verbindung erzeugt Postgres einen Betriebssystem-Prozess. Prozesse sind teuer – sie brauchen CPU, Speicher und Zeit zum Starten. Das schränkt nicht nur die Parallelisierung zwischen Abfragen ein, sondern auch innerhalb einer einzelnen Abfrage. Denn wenn Postgres eine aufwendige Query parallel ausführen will, startet es ebenfalls mehrere Prozesse. Wegen der hohen Kosten tut es das nur bei wirklich langlaufenden Abfragen.

Seit Jahren wird über eine Umstellung auf ein Thread-Modell diskutiert, aber die Änderung ist so tiefgreifend, dass kaum jemand sie wagt. pgrust wurde von Anfang an mit Threads konzipiert. Der Autor betont, dass die Prozess-Architektur der Sicherheit dient: Prozesse sind stärker isoliert als Threads. Ein Fehler in einem Prozess reißt die anderen nicht mit. pgrust setzt auf die Speichersicherheitsgarantien von Rust zur Compile-Zeit, sodass diese Isolation nicht nötig ist. Das verspricht schnellere Verbindungsaufnahmen und effizientere Parallelisierung – ohne lästige Grenzwerte und Umwege über PgBouncer.

3. Bad Query Plans – wenn der Optimierer daneben liegt

Postgres besitzt einen Planer für Abfragen. Er analysiert die SQL-Query, zieht Statistiken über die Tabellen heran und wählt aus Dutzenden Algorithmen den vermeintlich schnellsten aus. Meist funktioniert das gut. Wenn der Planer daneben liegt, dann richtig. Der Unterschied zwischen einem guten und einem schlechten Ausführungsplan kann den Faktor 60.000 ausmachen: eine Query, die normalerweise 10 Millisekunden braucht, läuft plötzlich 10 Minuten. Das ist bekannt. Noch ärgerlicher: Postgres bietet kaum Möglichkeiten, den Planer direkt zu lenken. Während andere Datenbanken wie MySQL Planner Hints unterstützen, mit denen du für einzelne Queries den Algorithmus vorgeben kannst, fehlt diese Funktion in Postgres komplett. Die einzige Stellschraube ist das globale Abschalten bestimmter Algorithmen – ein grobes Werkzeug.

Der Autor von pgrust berichtet von einem früheren Arbeitgeber, bei dem sie in der gesamten Datenbank Nested-Loop-Joins deaktivieren mussten, weil Postgres sie ständig nutzte und alle Queries ausbremste. Grund war oft der Umgang mit JSON-Daten. Für pgrust schwebt dem Entwickler ein adaptiver Query Planer vor, der ständig die Ausführungszeiten überwacht. Wenn eine Query, die normalerweise 10ms braucht, plötzlich 10 Sekunden benötigt, soll pgrust automatisch erkennen, ob der Plan gewechselt hat oder die Statistiken veraltet sind, und ohne menschliches Eingreifen korrigieren. Klingt futuristisch, aber der Autor ist optimistisch, dass dies realisierbar ist – es fehlt nur die konkrete Umsetzung.

4. JSON – scheinbarer Segen mit versteckten Fallstricken

Postgres liebt und hasst JSON. Es ist nützlich, um unstrukturierte Daten zu speichern und flexibel abzufragen. Aber die Schattenseiten sind massiv. Das größte Problem: Postgres sammelt für JSON-Spalten keine vernünftigen Statistiken. Für normale Datentypen wie Integer oder Text erhebt es Histogramme, häufigste Werte und mehr. Bei JSON schätzt der Planer pauschal, dass ein Filter auf eine JSON-Eigenschaft nur 0,1 % der Zeilen trifft – ein fixer Wert, völlig unabhängig von den tatsächlichen Daten. Der tatsächliche Anteil kann bei 80 % oder bei 0,0001 % liegen. Diese Fehleinschätzung führt zu schlechten Abfrageplänen. Wer mit großen JSON-Spalten gearbeitet hat, kennt das Gefühl, wenn Abfragen plötzlich explodieren.

Hinzu kommt, dass Postgres JSON nicht komprimiert. Werden in vielen Zeilen die gleichen Schlüssel und Werte verwendet, werden sie jedes Mal neu gespeichert. Das bläht die Datenbank auf. Der Autor von pgrust sieht zwei Ansatzpunkte: echte Statistiken für JSON-Spalten – das würde nach seiner Einschätzung 80 % der JSON-bedingten Probleme lindern. Es existieren bereits Patches, die in diese Richtung gehen; er möchte einen zur Serienreife bringen. Zweitens eine Wörterbuchkomprimierung (Dictionary Compression), um sich wiederholende JSON-Inhalte platzsparender abzulegen. Das könnte den Speicherverbrauch drastisch reduzieren und die I/O-Last verringern.

Was bleibt – und was pgrust konkret bedeutet

Die vier Punkte – VACUUM/Wraparound, Connection Limits, schlechte Query-Pläne und JSON – sind keine akademischen Probleme. Sie verursachen täglich Ausfälle in tausenden Unternehmen. Der Entwickler von pgrust hat sich vorgenommen, diese Schwachstellen mit einem technisch durchdachten Neuanfang zu adressieren. Der Fokus des Projekts liegt auf zwei Dingen: erstens Kompatibilität mit PostgreSQL – pgrust besteht bereits 96 % der offiziellen Regressionstests. Zweitens Stabilität und Fehlerbereinigung, damit die Datenbank ernsthaft eingesetzt werden kann. Erst danach sollen die architektonischen Verbesserungen kommen, beginnend mit den 64-Bit-Transaktions-IDs.

Für dich als Betreiber einer Postgres-Installation bedeutet das: Solange pgrust nicht produktionsreif ist, solltest du die genannten Fallstricke aktiv managen. Überwache deine VACUUM-Aktivitäten, setze PgBouncer ein, um Connection Limits zu puffern, analysiere regelmäßig deine Abfragepläne und meide JSON, wo möglich, oder schaffe dir Monitoring für plötzliche Performance-Einbrüche. Die Arbeit an pgrust zeigt, dass die Probleme erkannt sind und Lösungen existieren.

Quelle: malisper.me

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

Du greifst nach einem nassen Glas. Deine Finger spüren sofort, ob es rutscht, und passen den Druck an, bevor es dir aus der Hand gleitet. Diese Bewegung ist für einen Roboter eine der kniffligsten Aufgaben. Humanoiden Maschinen fehlt genau diese Fähigkeit. Sie können laufen, aber an den Händen scheitern sie noch. Das norwegische Unternehmen 1X, das heute in Palo Alto sitzt, hat seinem Haushaltsroboter NEO neue Hände verpasst. Die sind das Spannendste an der Maschine.

Jede Hand verfügt laut 1X über 25 Freiheitsgrade: 22 in den Fingern und der Handfläche, drei weitere im Handgelenk. Das allein macht sie beweglich. Die taktilen Sensoren messen nicht nur Druck, sondern auch Scherkräfte. So merkt die Hand, wenn ein Glas rutscht, und verstärkt den Griff – bevor es auf den Boden knallt. Wired, das einen frühen Blick auf die Technik werfen durfte, bezeichnet die Bewegungen der Finger als „freaky fast“. Doch die Geschwindigkeit ist Nebensache. Wichtig ist, dass die Hand fühlen kann, was sie hält.

Fabrikroboter haben seit Jahren Greifer, aber die arbeiten mit immer gleichen Teilen an immer gleichen Positionen. Ein Zuhause ist das Gegenteil: Objekte tauchen in seltsamen Formen, nassen Oberflächen oder unvorhersehbarem Gewicht auf. Ein Robotergreifer, der nur zu- und aufklappen kann, ist hier nutzlos. 1X hat die Hände deshalb backdrivable konstruiert: Die Gelenke geben nach, wenn man sie drückt, statt starr zu bleiben. Ein Stoß wird nicht zum Kampf. Die Finger lassen sich über den menschlichen Bewegungsspielraum hinaus biegen und umschließen unförmige Gegenstände. Die Hülle ist nach IP68 zertifiziert und besteht aus lebensmittelechten Materialien – sinnvoll für den Einsatz in der Küche oder am Waschbecken.

Aber eine leistungsfähige Hand allein macht noch keinen tüchtigen Haushaltsroboter. NEO muss das Objekt erst erkennen, die richtige Griffart wählen und die Aufgabe in einer unordentlichen Umgebung wiederholen – ohne dass ihm jemand den Weg bereitet. Ein polierter Democlip beweist das nicht. 1X räumt selbst ein, dass die Autonomie noch ein laufendes Projekt ist. Für Aufgaben, die NEO nicht kennt, gibt es den „Expert Mode“: Ein menschlicher Operator übernimmt per Fernsteuerung. Das ermöglicht die Steuerung einer Flotte, bedeutet aber auch, dass eine fremde Person eine kamerabestückte Maschine in deinem Zuhause dirigieren kann. Datenschutzfragen bleiben offen.

Die Entwicklung von 1X ist kein Einzelfall. Das Unternehmen startete als Halodi Robotics in Norwegen und reiht sich damit in eine stille europäische Konkurrenz um den humanoiden Haushaltsroboter ein. Während manche Rivalen argumentieren, dass Heimroboter auf Beine und Finger ganz verzichten sollten, und andere die ganze Humanoid-Euphorie für überzogen halten, läuft unter der Oberfläche der Wettlauf um die funktionierende Roboterhand. NEO ist bereits vorbestellbar – gegen eine Anzahlung von 200 Dollar. Die Hände sind der überzeugendste Teil des Angebots. Der nächste Demo wird nicht das Finger-Trommeln zeigen, sondern NEO, wie es eine alltägliche Aufgabe vom Anfang bis zum Ende eigenständig erledigt.

Die Fortschritte bei der Sensorik und Beweglichkeit sind beachtlich. Trotzdem bleibt die Frage, ob die weiche, anpassungsfähige Greiftechnik in den rauen Alltag eines Durchschnittshaushalts halten kann. Ein Prototyp, der unter Laborbedingungen funktioniert, ist noch kein Serienprodukt, das mit Fett, Feuchtigkeit und Kinderhänden zurechtkommt. 1X hat einen wichtigen Schritt gemacht – den Beweis für Robustheit und Zuverlässigkeit bleibt das Unternehmen noch schuldig. Ob die Hände nicht nur fühlen, sondern auch dauerhaft funktionieren, muss sich erst zeigen.

Quelle: thenextweb.com