Kategorie: Tool-Tests

Ein Benchmark-Sieg klingt nach einem eindeutigen Ergebnis. Der Bericht „Agents on Rails“ vom 2. September 2026 zeigt etwas anderes: einen Gleichstand an der Spitze. Die Entscheidung fällt an einer Stelle, die beim Modellvergleich meist übersehen wird. Svyatoslav Kryukov und Artur Petrov haben 17 Modelle auf 21 Rails-Aufgaben geschickt, jede Aufgabe dreimal. Heraus kam kein Sieg der reinen Rechenleistung, sondern eine Frage von Werkzeug, Preis und Zeit.

Wer ein Modell für Ruby-on-Rails-Aufgaben auswählt, schaut meist auf die oberste Zeile des Leaderboards. Dort steht jetzt ein Unentschieden. Zwei Modelle erreichen 92 Prozent. Darunter liegt ein Kandidat, der für fünf Cent pro Lauf fast dasselbe leistet. Interessanter als der Spitzenwert ist der Abstand zwischen Preis und Ergebnis.

Ein KI-Coding-Agent arbeitet wie ein Geselle in einer gut sortierten Werkstatt. Es reicht nicht, dass am Ende ein Bauteil passt. Er muss auch das richtige Werkzeug von der Wand nehmen, statt sich mit Klebeband eine Eigenlösung zu biegen. Beides hält erstmal. Der Unterschied zeigt sich, wenn jemand die Konstruktion später anfassen muss.

Gleichstand an der Spitze: Claude Fable 5.1 zieht mit Claude Opus 5 nach

Claude Fable 5.1 ist einen Tag vor dem Bericht erschienen und landet direkt auf Augenhöhe mit dem bisherigen alleinigen Spitzenreiter. Beide Modelle lösen 58 von 63 Durchläufen, das sind 92 Prozent, und beide schaffen mindestens 20 der 21 Aufgaben wenigstens einmal. Der Unterschied liegt nicht in der Trefferquote, sondern im Aufwand dahinter. Fable 5.1 kostet 75 Dollar für alle 63 Läufe, Claude Opus 5 verlangt 120 Dollar. Auch bei der Zeit liegt das neue Modell vorn: 5,4 Minuten im Median gegen 9,7 Minuten.

Claude Fable 5 kam auf 57 von 63 Läufen, kostete 146 Dollar und brauchte 6,8 Minuten pro Durchlauf. Die Rechnung ist also rund 50 Prozent günstiger als beim Vorgänger und rund 40 Prozent günstiger als bei Opus 5. In der Spitzengruppe ist Fable 5.1 damit das schnellste Modell, auf Augenhöhe mit GPT-5.6 Sol. Ein Benchmark ist allerdings ein Prüfstand und keine Landstraße: Die Autoren betonen selbst, dass 63 Läufe eine kleine Stichprobe sind. In den Vorläufen lag Fable 5.1 bei etwa 95 Prozent, im offiziellen Durchlauf hatte es schlicht Pech.

Ein Detail abseits der Punktzahl ist wichtiger, als es aussieht. In der ersten Runde scheiterte Fable 5 an einer Aufgabe, die wie ein Pen-Test-Bericht formuliert war, und zwar in allen drei Versuchen. Fable 5.1 liest denselben Bericht und behebt jeden Befund. Ein Modell, das eine Sicherheitsaufgabe nicht mit einem Sicherheitsproblem verwechselt, ist im Alltag mehr wert als ein Prozentpunkt auf dem Leaderboard.

Rails API Recall: 41 Prozent und der Fall quote_column_name

Der Rails API Recall Benchmark misst etwas anderes als das reine Lösen von Aufgaben. Jede Aufgabe verweist auf eine bestimmte Rails-API, die eine ideale Lösung verwenden sollte. Eine selbst gebaute Ersatzlösung kann die Tests bestehen, aber sie ist nicht der Weg, den das Framework vorsieht. Hier liegt der Unterschied zwischen Code, der funktioniert, und Code, den das nächste Teammitglied ohne Zorn lesen kann. Bisher lagen die Werte in diesem Benchmark zwischen 8 und 35 Prozent.

Claude Fable 5.1 erreicht 41 Prozent. In Zahlen heißt das: In 26 der 63 Läufe erinnerte sich das Modell unaufgefordert an die passende API, 9 Mal fand sie sich in der Ausgabe, 20 Mal wurde sie übergangen, 8 Mal baute das Modell eine Eigenlösung. Claude Opus 5 kam auf 20 Treffer aus dem Stand, also 32 Prozent, dazu 14 gefundene APIs, 15 übergangene und 14 Eigenlösungen. Claude Fable 5 lag bei 21 unaufgeforderten Treffern, im Bericht mit 35 Prozent angegeben, dazu 6 gefundene APIs, 21 übergangene und 12 Eigenlösungen; drei Läufe endeten ohne Patch.

Die Verbesserung liegt nicht daran, dass ein neueres Modell neuere APIs kennt. quote_column_name ist fast so alt wie Active Record selbst, und kein vorheriges Modell hatte diese Methode unaufgefordert erwähnt. Es geht also nicht um frisches Trainingswissen, sondern um die Frage, ob ein Modell nachsieht, was an der Wand hängt, bevor es improvisiert. Für Teams, die KI-Modelle für Rails einsetzen, zählt am Ende diese Zahl: Der Agent schreibt Code, den später Menschen warten müssen.

GLM 5.3 Flash: Der Stealth-Kandidat aus der letzten Runde hat jetzt einen Namen

Das Modell, das in der vorigen Runde unter dem Codenamen ox-alpha antrat, ist enttarnt. Es handelt sich um GLM 5.3 Flash von Z.ai. Die Autoren haben den Stealth-Namen beerdigt und alle 63 Versuche unter dem echten Namen und dem echten Preis erneut laufen lassen. Das Ergebnis deckt sich mit den Vorabwerten: 52 von 63 Läufen, also 83 Prozent, bei Gesamtkosten von 3,31 Dollar. Das sind rund fünf Cent pro Durchlauf.

Damit liegt GLM 5.3 Flash auf demselben Niveau wie Grok 4.6, das ebenfalls 83 Prozent erreicht, aber zum Fünfzehnfachen des Preises. In der Rangliste steht Flash hinter Kimi K3 mit 90 Prozent und GPT-5.6 Sol mit 84 Prozent, auf Augenhöhe mit Grok 4.6 und vor dem großen GLM 5.3 mit 79 Prozent. Die Preis-Leistung von GLM 5.3 Flash ist hier keine Marketingfloskel, sondern eine Rechnung. Wer viele kleinere Rails-Aufgaben automatisiert, für den ist der Cent-Betrag pro Lauf relevanter als die letzten Prozentpunkte.

Wie der Agents-on-Rails-Benchmark aufgebaut ist

Alle Zahlen stammen aus dem üblichen Aufbau. Der Harness heißt lemans, es gelten Standard-Effort-Stufen, und jede der 21 atomaren Writebook-Aufgaben wird dreimal versucht. Die Prüfung ist versteckt, die Rohdaten liegen im Repository rails/ai-evals, die aktuellen Werte stehen auf der Agents-on-Rails-Seite. Jede Zahl lässt sich bis zum einzelnen Lauf zurückverfolgen.

Zwei kleinere Änderungen betreffen die Darstellung. Die Standard-Effort-Stufen, mit denen die Läufe stattgefunden haben, sind jetzt auf der Seite dokumentiert. Die Diagramme wurden zusätzlich überarbeitet, nach einer Anregung von Nate Berkopec: Egal was du vergleichst, die besseren Modelle erscheinen nun in der oberen rechten Ecke. Das klingt nach Kosmetik, macht aber den Vergleich zwischen zwei Kenngrößen auf einen Blick lesbar.

Der wichtigste Vorbehalt steht im Kleingedruckten. Drei Läufe pro Aufgabe sind ein Kompromiss zwischen Laufzeit und Aussagekraft, nicht mehr. An der Spitze steht ein Unentschieden, und beide Modelle wurden von derselben Aufgabe gestoppt. Der atomare Aufgabenkatalog wird langsam zu klein, weshalb die Autoren größere und realistischere Aufgaben für eine zweite Stufe vorbereiten.

Was das für die Auswahl eines KI-Coding-Agenten bedeutet

Drei Punkte bleiben für die Auswahl. Erstens: Der Spitzenplatz im Agents-on-Rails-Leaderboard ist derzeit geteilt, und die Entscheidung zwischen den beiden 92-Prozent-Modellen fällt über Preis und Laufzeit, nicht über Qualität. Claude Fable 5.1 liefert dieselbe Trefferquote für deutlich weniger Geld und in etwa der halben Zeit. Zweitens: Für Aufgaben, bei denen es nicht um Sekunden oder Centbeträge geht, ist GLM 5.3 Flash mit 83 Prozent für fünf Cent pro Lauf eine ernsthafte Option, nicht bloß eine Notlösung.

Drittens, und das wird beim Blick auf die reine Punktzahl übersehen: Der Rails API Recall entscheidet darüber, wie lange der erzeugte Code lebt. Ein Modell, das 92 Prozent der Aufgaben löst, aber regelmäßig an der Werkzeugwand vorbeigeht und Eigenlösungen baut, produziert Arbeit für später. Ein Modell mit etwas niedrigerer Trefferquote, das die vorhandenen Rails-APIs kennt, liefert dagegen Code, der sich in eine bestehende Anwendung einfügt, ohne sie zu verbiegen. Wer Claude Fable 5.1 für Rails-Aufgaben in einem gewachsenen Projekt einsetzt, sollte deshalb beide Zahlen nebeneinander lesen.

Die 41 Prozent von Claude Fable 5.1 sind kein Endstand, sondern eine Zwischenmarke. Sie zeigen, dass sich die Erinnerung an Framework-APIs messbar verbessern lässt. Bis die größeren Aufgaben der zweiten Stufe kommen, bleibt der Prüfstand ein kontrollierter Raum mit 21 Aufgaben und drei Versuchen. Was dort funktioniert, funktioniert noch nicht automatisch in deiner Anwendung.

Quelle: rubyonrails.org

Ist Apache Iggy ein schnelleres Kafka? Klingt einfach, ist es aber nicht. Beide Systeme verwalten Nachrichten in partitionierten, append-only Logs. Offsets, Consumer Groups, Replay – alles da. Doch bei der Frage, was eine „bestätigte Nachricht“ tatsächlich bedeutet, gehen die Wege auseinander.

Iggy ist eine Streaming-Plattform in Rust, im August 2026 vom Apache Incubator zum Top-Level-Projekt aufgestiegen. Piotr Gankiewicz hatte das Projekt Anfang 2023 begonnen, um Rust zu lernen. Der Name steht für Italienischer Windhund – kleiner, extrem schneller Hund. Die Herkunft erklärt einiges, aber nicht alles.

Iggy und Kafka teilen sich das Datenmodell

Iggy will das Event-Log nicht durch eine andere Abstraktion ersetzen. Wer mit Kafka gearbeitet hat, kennt das Speichermodell. Ein Iggy-Stream ist die oberste Ebene, darunter Topics und Partitionen. Jede Partition ist ein append-only Log mit Segmenten, Nachrichten haben Offsets. Ein Consumer lässt sich ab einem expliziten Offset, einer Zeitmarke, dem Anfang oder Ende des Logs starten oder ab der gespeicherten Consumer-Position des Servers.

Damit unterscheidet sich der Vergleich von Systemen wie Apache Fluss, die das Event-Log durch eine Datenbank oder Streaming-Tabelle ersetzen. Iggy behauptet nicht, Kafkas Abstraktion sei falsch. Es fragt, ob man dieselbe Abstraktion anders umsetzen kann. Genau dort wird es interessant: in den Entscheidungen unter der Haube.

Thread-per-Core statt JVM: Iggys Architektur

Kafka hat seinen Speicherpfad über Jahre optimiert: sequentielles Schreiben, aggressives Batching, OS-Page-Cache, Zero-Copy beim Ausliefern. Die Strategie: dem Betriebssystem nicht in die Quere kommen. Iggy geht einen anderen Weg. Seit Version 0.6.0 nutzt der Server eine Thread-per-Core-Architektur mit der compio-Runtime, die auf Linux mit io_uring arbeitet. Partitionen werden CPU-gepinnten Shards zugeordnet. Statt eines Work-Stealing-Executors, der Tasks zwischen Threads schiebt, hält jeder Shard seinen Teil der Last und läuft auf einem festen Core.

Dazu unterhält Iggy einen eigenen, vorab allokierten Speicherpool und nutzt Vectored-I/O, um Nachrichtenpuffer gebündelt auf die Festplatte zu schreiben. Das Ziel: Vorhersagbarkeit. Bei Thread-per-Core wandert eine heiße Partition nicht durch alle Worker-Threads. Weniger Synchronisation im Datenpfad, weniger Cache-Invalidierung, weniger Allokationen. Das Projekt berichtet von deutlichen Verbesserungen bei den Tail-Latenzen.

Wichtig dabei: Kafka ist keine Anwendung, die ständig Nachrichtenobjekte allokiert. Ein großer Teil seiner Leistung kommt daher, den Payload in Ruhe zu lassen und dem Betriebssystem Caching und sequentielle I/O zu überlassen. Der Unterschied ist also nicht „Kafka ist langsam, Iggy ist schnell“, sondern: Kafka delegiert Speicher-Caching an den OS-Kernel, Iggy versucht, Ausführung und Speicherpfad selbst zu steuern.

Wann ist eine Nachricht wirklich sicher?

Hier wird es heikel für pauschale Leistungsvergleiche. Der Schreibpfad von Iggy vereinfacht: Nachrichten werden gepuffert, bis eine konfigurierbare Anzahl oder Größe erreicht ist – aktuell standardmäßig 1024 Nachrichten oder 1 MiB. fsync ist pro Topic einstellbar. Eine akzeptierte Schreiboperation und eine durable Schreiboperation sind nicht dasselbe.

Iggys Dokumentation stellt klar: Die Standardkonfiguration für einzelne Knoten bietet nur geringe Haltbarkeitsgarantien. Bei einem Crash oder Stromausfall können Nachrichten verloren gehen, wenn man die Haltbarkeits-Einstellungen nicht erhöht. Der Server stellt enforce_fsync und Flush-Schwellen zur Steuerung dieses Kompromisses bereit. Kafka hat dasselbe Grundproblem, aber eine andere Lösung. Kafka ruft nicht für jede Nachricht fsync auf, sondern verlässt sich für Produktions-Haltbarkeit in der Regel auf Replikation.

Eine Bestätigung des Producers bedeutet bei Kafka normalerweise mehr als „der Leader hat meine Schreiboperation angenommen“. Kafka pflegt den ISR – die Menge der synchronen Replikate, also Replikate, die mit dem Leader aufgeholt sind. Mit acks=all wird eine Schreiboperation erst bestätigt, wenn sie alle über min.insync.replicas festgelegten Replikate dieser Gruppe erreicht hat. Das macht einen Unterschied, wenn du Latenzen vergleichst. Ein Iggy-Producer, der auf eine lokale Schreiboperation wartet, und ein Kafka-Producer, der auf Replikation auf eine andere Maschine wartet, messen nicht dasselbe.

Was die veröffentlichten Zahlen wirklich aussagen

Für diesen Vergleich wurde bewusst kein eigenes Benchmark zwischen Kafka und Iggy durchgeführt. Die Zahlen aus dem Iggy-Projekt sind trotzdem lesenswert – vor dem Hintergrund aus dem letzten Abschnitt. In den FAQ berichtet das Projekt, die Thread-per-Core-Umstellung habe eine bis zu 92 Prozent bessere P9999-Tail-Latency und 18 Prozent mehr Durchsatz bei aktiviertem fsync gebracht. Die Website spricht von Millionen Nachrichten pro Sekunde mit Sub-Millisekunden-Tail-Latenzen auf einem einzelnen Knoten.

Das sind plausible Zahlen für das, was sie messen: die Effizienz einer Single-Node-Log-Engine unter Iggys eigenen Bestätigungs-Semantiken. Kein vollständiger Äpfel-zu-Äpfel-Vergleich mit Kafka. Solange Iggys erste Replikationsversion nicht ausgeliefert ist, lässt sich replizierte Haltbarkeit nicht gegen ein System ohne Replikation testen. Einzelknoten-Vergleiche sind möglich, Dritte haben sie veröffentlicht. Ein kürzlich von einem kommerziellen Iggy-Anbieter publiziertes Broker-Benchmark sieht Iggy bei Durchsatz und Tail-Latency deutlich vor Kafka. Trotzdem ist ein solcher Test nur aussagekräftig, wenn beide Systeme auf demselben Haltbarkeitspunkt sitzen: gepufferter Schreibvorgang, lokales fsync oder synchrone Replikation.

Kafka mit acks=all und drei Replikaten gegen einen einzelnen Iggy-Knoten mit Standard-Flush erzählt dir vor allem, dass die beiden Setups unterschiedliche Ausfälle überleben. Genau deshalb ist die P9999-Verbesserung interessant: Sie zeigt, was die Thread-per-Core-Umschreibung gegen Iggys eigene frühere Architektur gebracht hat. Bei diesem Vergleich bleibt wirklich alles andere konstant.

Replikation: Der große Unterschied und der Blick nach vorn

Lange war der ehrliche Vergleich kurz: Kafka hat Replikation, Iggy nicht. Das ändert sich gerade. Die Multi-Node-Clusterung basiert auf Viewstamped Replication (VSR) und ist im neuen Servercode bereits vorhanden. Im August 2026 wurde server-ng als Haupt-iggy-server übernommen, erste 0.9.0-edge-Builds erschienen. Laut Projekt ist die Serverseite weitgehend fertig: View Changes, State Transfer, Leader-Forwarding, Client-Session-Recovery, Node-Authentifizierung, TLS zwischen den Knoten und deterministische Simulationstests für Crashes und Netzwerkpartitionen sind implementiert.

Die verbleibende Arbeit liegt vor allem darin, alle SDKs auf das VSR-Wire-Protocol zu migrieren und gegen den Cluster-Server zu testen. Eine nützliche Unterscheidung: Replikation ist keine bloße Roadmap-Idee mehr, aber die erste stabile Version mit Replikation ist noch nicht erschienen. Die neueste offizielle stabile Version bleibt 0.8.0, obwohl 0.9.0 bereits durch Edge-Artefakte sichtbar ist. Der Unterschied zwischen Kafka und Iggy verschiebt sich damit von Existenz zu Reife. Kafkas Replikationsmodell läuft seit über einem Jahrzehnt in realen Systemen. Iggys VSR-Cluster nähert sich erst seiner ersten stabilen Version.

VSR ist durchaus eine ernstzunehmende Designentscheidung. Deterministische Simulationstests sind dieselbe Disziplin, mit der Projekte wie FoundationDB und TigerBeetle Vertrauen in ihren Konsenscode aufbauen. Wer das von Anfang an berücksichtigt, hat Ambitionen. Trotzdem sind eine Implementierung vor der ersten stabilen Version und ein System, das durch Produktionsausfälle geformt wurde, unterschiedliche Dinge. Für eine Produktionsentscheidung heute zählt diese Reifedifferenz mehr als die Frage, ob VSR auf dem Papier sauberer aussieht als Kafkas ISR-Modell.

Geht es um den Ausfall eines ganzen Rechenzentrums, wird Kafkas gesammelte Maschinerie zum Feature. broker.rack erlaubt es, Replikate über Racks zu verteilen. Iggy muss hier aufholen, und es bleibt abzuwarten, wie sich die VSR-Implementierung unter realen Bedingungen schlägt. Der aktuelle Stand: Die Systeme stimmen in der grundlegenden Datenmodell-Vorstellung überein, aber die Implementierungsentscheidungen führen zu unterschiedlichen Kompromissen. Für dich als Nutzer heißt das: Bevor du dich entscheidest, musst du genau definieren, welchen Ausfall deine bestätigte Nachricht überleben soll. Dann lässt sich beurteilen, ob das schnellere System wirklich das bessere ist.

Quelle: softwaremill.com

Was kann GPT-6 Astra? Eine neue Auswertung von Artificial Analysis liefert Antworten. Wir gehen die Zahlen durch und erklären, was sie konkret bedeuten. Token-Effizienz und Kosten stehen für den Verbrauch, Benchmark-Scores für die Leistung.

Coding-Agent-Index: Gleichauf mit der Konkurrenz

Der Coding Agent Index von Artificial Analysis misst, wie gut Modelle autonom Code schreiben. GPT-6 Astra kommt auf 67 Punkte – gleichauf mit Claude Opus 5 und Fable 5 im Claude-Code-Modus sowie mit Muse Spark 1.3. Nur Fable 5.1 liegt mit 70 Punkten klar vorne.

Die Token-Effizienz sticht heraus. Astra verbraucht nur ein Drittel der Tokens von GPT-5.6 Sol im gleichen Setup. Gegenüber Claude Opus 5 auf hoher Denkstufe ist es sogar fünfmal sparsamer. Heißt: Für dieselbe Coding-Aufgabe produziert das Modell deutlich weniger Text – in großen Projekten spart das Zeit und Geld.

Auch die Kosten pro Aufgabe haben sich verschoben. Im Max-Effort-Modus kostet Astra ungefähr so viel wie GPT-5.6 Sol, schneidet im Index aber zwei Punkte besser ab. Gegenüber Claude Fable 5, das eine ähnliche Punktzahl erreicht, halbiert sich der Preis pro Coding-Aufgabe. Effizienz plus Wettbewerbspreis machen Astra zu einer ernsten Option für automatisierte Softwareentwicklung.

Intelligence Index: Effizienz teuer erkauft

Im Intelligence Index bleibt GPT-6 Astra auf dem Niveau des Vorgängers. 61 Punkte, genau wie GPT-5.6 Sol. Fünf Punkte hinter Claude Fable 5.1 (max mit Fallback) und auch hinter Meta Muse Spark 1.3. Die allgemeine Denkfähigkeit hat sich nicht messbar verbessert.

Verbessert hat sich die Token-Nutzung. Etwa zehn Prozent weniger Ausgabe-Tokens pro Aufgabe im Max-Effort-Modus gegenüber GPT-5.6 Sol. Dieser Effizienzgewinn geht aber in der Preiserhöhung unter. GPT-6 Astra ist in der Preisgestaltung 2,5-mal teurer – pro Aufgabe zahlst du am Ende rund 75 Prozent mehr als beim Vorgänger.

Die OpenAI-Preisliste erklärt den Sprung. Pro Million Eingabe-Tokens verlangt das Unternehmen zehn Dollar statt vier, für Ausgabe-Tokens fünfzig statt zwanzig Dollar. Cache-Reads behalten den Rabatt von 90 Prozent, Cache-Writes erhalten einen Aufschlag von 25 Prozent. Damit ist GPT-6 Astra deutlich teurer als GPT-5.6 Sol – der Token-Vorteil verpufft auf der Rechnung.

Halluzinationen halbiert: Die Omniscience-Wende

Im AA-Omniscience-Benchmark, der Wissen und Halluzinationsneigung testet, senkt GPT-6 Astra die Halluzinationsrate im Max-Effort-Modus von 92 Prozent (Vorgänger) auf 51 Prozent. Fast eine Halbierung.

Dabei leidet die Genauigkeit nicht. Die Accuracy steigt gleichzeitig um vier Punkte. Viele Modelle reduzieren Halluzinationen, indem sie häufiger ganz schweigen. Astra schafft beides – mehr Präzision und mehr Zurückhaltung bei Unsicherheit.

Für faktenkritische Anwendungen zählt das. Recherche oder Code-Dokumentation profitieren direkt von niedrigen Halluzinationsraten. Offen bleibt, ob das Ergebnis in der Praxis mit langen Kontexten stabil bleibt.

Langzeitaufgaben: Fortschritt mit Nebenwirkungen

Im AA-Briefcase-Benchmark, der mehrwöchige Projekte mit Tausenden Quelldateien simuliert, gewinnt GPT-6 Astra etwa 80 Elo-Punkte gegenüber GPT-5.6 Sol. Der Zuwachs liegt vor allem bei den Rubrik-Scores und der analytischen Qualität. Die Präsentationsqualität dagegen nimmt ab – hier führt weiterhin GPT-5.6 Sol.

Anderswo sieht es gemischt aus. Bei Humanity’s Last Exam (Mathematik, Naturwissenschaften, Geisteswissenschaften) legt Astra sechs Punkte zu. Dafür verliert es rund 80 Elo im GDPval-AA v2, einem Benchmark für wirtschaftlich relevante Aufgaben aus 44 Berufen. Auch bei τ³-Banking, SciCode und AA-LCR sinken die Werte um zwei bis drei Punkte.

Solche Regressionen sind bei neuen Modellgenerationen normal. Ein Bereich verbessert sich, ein anderer leidet. Entscheidend ist, ob die gemischten Resultate für deinen konkreten Einsatz relevant sind.

Was das für deine Projekte heißt

Der GPT-6 Astra Benchmark zeigt eine ungleiche Entwicklung. Codierung: dank hoher Token-Effizienz ein starkes Paket aus Preis und Leistung. Allgemeine Intelligenz: knapp hinter den Spitzenmodellen – und der höhere Preis frisst die Token-Ersparnis auf.

Der größte Fortschritt ist die Halluzinationsreduktion. Dass ein Modell gleichzeitig genauer wird, ist bei aktuellen Systemen keine Selbstverständlichkeit. Dieser Punkt wiegt schwerer als die kleinen Schwankungen in einzelnen Benchmark-Kategorien.

Für Entwickler und Power-User heißt das: Einsatz genau abwägen. Bei Agenten-Projekten mit Code-Ausführung ist Astra eine ernsthafte Alternative, besonders wenn die Kosten pro Aufgabe im Fokus stehen. Für reine Denkaufgaben oder Textgenerierung bleibt GPT-5.6 Sol wirtschaftlicher.

GPT-6 Astra glänzt nicht überall, aber an den richtigen Stellen. Damit ist es ein nützlicher Baustein im aktuellen KI-Ökosystem. Bleibt abzuwarten, wie OpenAI die Preise in den nächsten Monaten anpasst.

Quelle: artificialanalysis.ai

„Alle drei Agenten wählen nur in 42 Prozent der Fälle dasselbe Werkzeug.“ Die Zahl stammt aus einer der bislang größten öffentlich zugänglichen Studien zum Entscheidungsverhalten von Coding-Agenten. Das Team von Armature, einem Anbieter von Wachstumsdiensten für Entwickler-Tools, hat dafür 16.893 Sitzungen mit Claude Code, Codex und Cursor ausgewertet. Die Daten stammen aus realen Repositories mit konkreten Aufgaben, nicht aus einer leeren Testumgebung.

Im Zentrum steht eine Frage, die bislang selten systematisch untersucht wurde: Wie wählen KI-Programmierassistenten aus, welche Bibliothek oder welcher Dienst in ein bestehendes Projekt integriert wird? Anders, als man denkt. Vor allem aber unterscheiden sich die drei Agenten oft deutlich.

Wer schon einmal einen Agenten beauftragt hat, eine Datenbank einzubauen oder einen E-Mail-Dienst anzubinden, kennt das Gefühl: Die Antwort wirkt simpel. Doch genau hier beginnt die eigentliche Arbeit. Die Auswahl entsteht aus Trainingsdaten, Websuchen, Kontextverständnis und manchmal Zufall. Wie viel dabei passiert, zeigt die Studie.

Wie die Studie aufgebaut war

Das Team von Armature hat 75 Repositories in zehn Programmiersprachen präpariert. Jedes enthielt realistische Frameworks, gefälschte Firmennamen und Lockfiles, die gegen echte Paketregister geprüft wurden. Die Aufgaben entsprachen typischen Anforderungen: eine Lösung für Rechnungsversand implementieren, ein Objektspeicher anbinden oder eine Auszahlungslösung integrieren.

Die Aufträge stammten von vier Profilen: einem Vibe-Coder ohne tiefe technische Erfahrung, einem Junior Engineer, einem Senior Engineer und einer Person aus einem Großkonzern mit strengen Compliance-Vorgaben. So testete Armature, ob die Formulierung des Prompts die Tool-Wahl verändert. Insgesamt entstanden 1.163 Prompt-Varianten.

Jeder Lauf lief in einer eigenen Sandbox. Zwischen drei Providern wurde rotiert, um Verzerrungen zu vermeiden. Dazu kam ein simulierter menschlicher Ansprechpartner, gesteuert über Gemini 3.7 Flash. Die Agenten konnten also nachfragen, bevor sie eine externe Lösung einbauten – anders als in reinen Autopilot-Läufen. Eine zweite Modell-Instanz bewertete, ob eine Sitzung gültig war und welcher Anbieter am Ende gewählt wurde.

Aus den 16.893 Sitzungen blieben 5.292 auswertbare Fälle in 18 Sektoren. Die übrigen Daten will das Team später veröffentlichen. Zur Einordnung: Armature verkauft selbst Wachstumsdienste für Entwickler-Tools. Ein gewisses Eigeninteresse lässt sich nicht ausschließen, auch wenn die vollständigen Traces öffentlich sind und eine eigene Überprüfung zulassen.

Verschiedene Agenten, verschiedene Quellen, verschiedene Antworten

Der erste große Unterschied zeigt sich in der Informationsbeschaffung. Cursor führte in zwei Dritteln der Sitzungen eine Websuche durch. Codex suchte fast immer – in 94 Prozent der Fälle –, nutzte jedoch häufig Operatoren wie site:, um gezielt vertrauenswürdige Domains anzusteuern. Claude Code vertraute dagegen meist dem eigenen Vortraining und suchte nur in etwa 30 Prozent der Fälle im Web. Wenn Claude Code aber suchte, dann gründlicher: Es besuchte dreimal so viele Seiten wie Codex.

Diese Strategien wirken sich direkt auf die Ergebnisse aus. Bei den Voice-Agenten etwa entschied sich Claude Code für Twilio, Codex wählte die OpenAI Realtime API, Cursor empfahl Vapi. Auch beim Eigenbau gibt es deutliche Differenzen: Claude Code implementierte in 19 Prozent der Fälle selbst eine Lösung, Codex und Cursor nur in jeweils 10 Prozent.

Der Agent, den du verwendest, ist kein neutraler Berater. Er bringt Präferenzen aus Trainingsdaten und bevorzugten Quellen mit. Sind sich zwei Agenten uneinig, lohnt es sich, genauer nachzufragen.

Der Kontext des Repositories beeinflusst die Auswahl stärker als die Marke

Der bestehende Code hat großen Einfluss. Die Forscher stellten fest: Dieselbe Anfrage führte in verschiedenen Repositories zu völlig unterschiedlichen Gewinnern. Beim E-Mail-Versand wurde die identische Aufgabe in vier Programmiersprachen gestellt. In TypeScript-Projekten gewann Resend, in Python-Projekten Sendgrid, in Go-Projekten Postmark, in Java-Projekten Azure ACS.

Ähnlich deutlich wird das bei den Deployment-Plattformen. Vercel gewann nicht nur in TypeScript-Repositories, sondern in 100 Prozent der Fälle, wenn Next.js verwendet wurde. In Python-Projekten wurde Vercel dagegen nie empfohlen; dort dominierte Render.

Coding-Agenten bewerten nicht abstrakt, welcher Dienst der beste ist. Sie bewerten, welcher Dienst am besten in den vorhandenen Stack passt. Kontextlose Empfehlungen werden damit seltener. Für Anbieter heißt das: Sie müssen in möglichst vielen Ökosystemen präsent sein.

Bekanntheit ist keine Garantie für den Zuschlag

Die Studie zeigt eine auffällige Lücke zwischen Erwähnung und tatsächlicher Auswahl. Viele bekannte Anbieter tauchen in nahezu jedem Gespräch auf, werden aber kaum implementiert. PayPal wurde 139-mal erwähnt und nie gewählt; Stripe gewann in 124 dieser Sitzungen. Adyen kam auf 175 Erwähnungen, aber nur drei Zuschläge. LangChain war mit 194 Erwähnungen das meistgenannte Framework, wurde aber nur viermal ausgewählt. Netlify brachte es auf 152 Erwähnungen und sechs Zuschläge als Deployment-Plattform.

Auch bei Datenbanken ist das Muster eindeutig: Supabase wurde mit 242 Erwähnungen am häufigsten genannt, verlor aber fast immer gegen Neon. Die Gründe liegen oft nicht in der reinen Technik, sondern in der Darstellung. Mailgun verlor regelmäßig gegen Postmark, sobald die Agenten auf die kurze Datenaufbewahrung von nur einem Tag in der kostenlosen Stufe stießen. Supabase wurde häufig wegen des gebündelten Preismodells abgewählt, wenn die Entwickler nur eine Datenbank brauchten und nicht Auth, Storage und Realtime.

Diese Details entscheiden. Produktseiten, die klare Informationen liefern und keine überflüssigen Pakete schnüren, haben messbare Vorteile. Für Anbieter heißt das: Es reicht nicht, bekannt zu sein. Die Inhalte müssen so strukturiert sein, dass ein KI-Agent sie schnell versteht und in seine Entscheidung einbeziehen kann.

Dominanz in einigen Märkten, offene Rennen in anderen

Die aggregierten Ergebnisse zeigen, dass einige Märkte bereits klar verteilt sind. Bei Zahlungsdienstleistern gewann Stripe neun von zehn Sitzungen und verlor nur in spezifischen EU-regulierten Fällen, in denen Spezialisten wie Paddle oder Mollie besser abschnitten. Bei Datenbanken führte Neon mit 66 Prozent vor den nativen Angeboten der Cloud-Plattformen. Im Bereich Dateispeicherung dominierte Amazon S3 mit 45 Prozent, gefolgt von Azure und GCP mit jeweils 20 Prozent.

Andere Kategorien bleiben umkämpft. Bei E-Mail-Diensten liegen Resend und Postmark mit 35,6 Prozent und 27,4 Prozent Installationsrate dicht beieinander. Ähnlich knapp sind die Ergebnisse in neueren Bereichen wie Sandboxes, wo sich Präferenzen erst mit der Zeit herausbilden.

Die Übersicht ist für Entwickler nützlich, aber nicht als allgemeine Rangliste zu verstehen. Die Studie zeigt, dass die Wahl des Agenten das Ergebnis verändert. Ein Tool, das mit Claude Code zuverlässig gewählt wird, kann mit Cursor chancenlos sein. Wer auf Konsistenz angewiesen ist, sollte mehrere Agenten mit derselben Aufgabe testen – oder die Entscheidung selbst überprüfen.

Was Entwickler und Anbieter aus der Studie lernen können

Die Ergebnisse sind kein Grund, KI-Programmierassistenten zu misstrauen. Besser ist es, ihr Verhalten zu verstehen. Wer weiß, dass Claude Code seltener im Web sucht, dass Cursor stark von Websuchergebnissen abhängt und Codex gezielt Domains ansteuert, kann Prompts entsprechend formulieren. Gib dem Agenten Randbedingungen mit: Kostenlimits, regulatorische Anforderungen, bestimmte Cloud-Plattformen oder die Größe des Teams.

Ein Agent ohne Einschränkungen wählt oft den populären Anbieter. Einer mit klaren Kriterien wählt den passenderen. Die Studie hat das mehrfach belegt: Wenn Agenten auf die Aufbewahrungsdauer eines kostenlosen Plans stoßen, wechseln sie den Anbieter. Solche Details sind für Menschen nebensächlich, für eine automatische Entscheidung aber entscheidend.

Für Anbieter von Entwickler-Tools ist die Botschaft direkter: Code-Agenten sind längst zu zentralen Kaufberatern geworden. Wer von ihnen nicht gefunden wird, verliert Marktanteile – unabhängig von klassischem Marketing. Klare Produktbeschreibungen, transparente Preise und maschinenlesbare Informationen sind keine Kür, sondern Pflicht. Armature kündigt weitere Untersuchungen an. Die öffentlichen Traces lassen sich bereits jetzt selbst analysieren.

Die Auswahl eines Tools ist keine rein technische Frage mehr. Sie wird von den Denk- und Suchmustern der Coding-Agenten geprägt. Wer diese Muster versteht, schreibt bessere Prompts und baut bessere Produkte. Das zeigt sich bereits im nächsten Agenten-Lauf.

Quelle: armature.tech

Welches KI-Modell ist intelligent genug und trotzdem bezahlbar? Guido Imperiale, Staff Software Engineer bei OpenTeams und Dask-Maintainer, hat sich die vielzitierte Intelligence-vs.-Cost-Grafik von ArtificialAnalysis vorgenommen. In einem Beitrag beschreibt er, warum die offizielle Darstellung irreführt und wie eine ehrlichere Version aussieht.

ArtificialAnalysis testet Sprachmodelle mit denselben Benchmarks. Daraus berechnet die Website den Intelligence Index, einen Mittelwert aus einer kuratierten Auswahl von Benchmarks. Eine brauchbare Daumenpeilung dafür, wie leistungsfähig ein Modell insgesamt ist. Weil die Aufgaben für alle Modelle identisch sind, lässt sich außerdem messen, was eine einzelne Aufgabe auf dem jeweiligen Modell kostet. Diese beiden Größen setzt der bekannte Intelligence-vs.-Cost-Plot zueinander in Beziehung.

Warum die offizielle Intelligence-Kosten-Grafik Probleme macht

Der offizielle Plot zeigt nicht nur einzelne Modelle, sondern auch die Pareto-Frontier. Die Grenze, an der du für ein bestimmtes Intelligenzniveau den jeweils günstigsten Preis bekommst. Die Idee ist sinnvoll. Sie hilft zu vermeiden, dass du für triviale Aufgaben ein teures High-End-Modell nutzt, wenn ein kleines und billiges Modell genauso gut funktioniert.

In der Praxis hat die Grafik allerdings einige Schwächen. Imperiale beschreibt, wie ihn die offizielle Darstellung über längere Zeit immer mehr irritiert hat. Was auf den ersten Blick wie eine elegante Entscheidungshilfe aussieht, verschleiert bei genauerer Betrachtung die wirklich wichtigen Unterschiede.

Es ist wie beim Autokauf: Ein Sportwagen für 250.000 Euro ist schneller als ein Kleinwagen für 20.000 Euro. Für den Weg zur Arbeit brauchst du die zusätzliche Leistung meist nicht. Mit demselben Blick solltest du Sprachmodelle betrachten. Die offizielle Grafik zeigt zwar, wie viel Intelligenz du für dein Geld bekommst, aber sie macht nicht klar, wie viel du für den letzten Leistungsschub tatsächlich bezahlst.

Drei Schwächen der offiziellen Kostenachse

Die erste Schwäche ist die logarithmische Skala auf der Kostenachse. Eine logarithmische Darstellung ist die einzige Möglichkeit, auf einem einzigen Plot Modelle für 0,015 Dollar pro Aufgabe und Modelle für 3,69 Dollar pro Aufgabe zu zeigen. Der Preisunterschied zwischen diesen beiden Punkten liegt bei fast dem 250-Fachen. Auf der logarithmischen Achse wirken die Abstände zwischen den billigen Modellen aber genauso groß wie zwischen billigen und teuren. Jedes Gefühl dafür, wie extrem die Spannweite tatsächlich ist, geht verloren.

Der zweite Kritikpunkt betrifft die Preisquelle. ArtificialAnalysis verwendet die offiziellen Preise, die die Modellentwickler für ihre eigenen API-Angebote nennen. Bei vielen Modellen ist das in Ordnung, bei Open-Weight-Modellen führt es in die Irre. Open-Weight-Modelle sind Sprachmodelle, deren Gewichte offen heruntergeladen und weitergegeben werden dürfen. Für genau dieselben Modelle gibt es auf Plattformen wie OpenRouter oft deutlich günstigere Anbieter. Imperiale weist darauf hin, dass sich über OpenRouter viele Anbieter vergleichen lassen und du ohne großen Aufwand den günstigsten Preis für dieselbe Modellqualität bekommst.

Die dritte Schwäche betrifft lokale Modelle. Modelle, die auf einem eigenen Rechner laufen können, statt in einem Rechenzentrum. In der offiziellen Grafik erscheinen solche Modelle mit den Preisen, die ein Rechenzentrum für ihre Nutzung verlangen würde. Ein lokales Modell auf Consumer-Hardware ist über eine API aber oft so teuer, dass niemand es dort sinnvoll nutzen würde. Für reale Nutzerinnen und Nutzer ist der Rechenzentrumspreis nicht die relevante Zahl. Entscheidend sind die Stromkosten und die Anschaffungskosten der Hardware.

So sehen die korrigierten Diagramme aus

Imperiale hat daher die Daten von ArtificialAnalysis genommen und eigene Diagramme erstellt. In diesen Plots hat er die x-Achse von einer logarithmischen auf eine lineare Skala umgestellt. Dadurch wird sofort sichtbar, dass ein Modell für 3,69 Dollar pro Aufgabe in einer völlig anderen Preisklasse liegt als eines für 0,49 Dollar. Der Log-Maßstab hatte diesen Unterschied vorher weichgezeichnet.

Zusätzlich hat er bei mehreren Modellen die Preise durch günstigere Angebote von OpenRouter ersetzt. Das betrifft unter anderem Modelle wie Kimi K3, DeepSeek V4 Flash oder GLM-5.3. Für GLM-5.3-Flash hat er einen Punkt extrapoliert, weil die vorhandenen Benchmarks mit unterschiedlichen Denkstufen gemessen wurden. Ein weiteres Modell, Ornith-1.5-35B-A3B, hat er aufgenommen, obwohl dessen Intelligenzwert auf selbst berichteten Benchmarks der Entwickler beruht. In seinem Beitrag empfiehlt er, diesen Wert mit Skepsis zu betrachten.

Die Intelligenzachse in seinen Diagrammen liest sich so: Ein Punkt Unterschied ist für die meisten Nutzer kaum spürbar. Erst ein Unterschied von rund fünf Punkten macht eine spürbare Qualitätsdifferenz aus. Die Grafiken zeigen außerdem den Bereich, in dem Modelle extrem billig werden. Dieser Bereich liegt auf seinen Plots deutlich sichtbar unten links. Wer in diese Ecke hineinzoomt, findet Modelle, die so klein sind, dass sie heute sogar auf einem Smartphone laufen könnten.

Bei den besonders kleinen Modellen hat Imperiale die Kosten nicht über einen Rechenzentrumspreis berechnet, sondern über den Stromverbrauch bei lokaler Ausführung. Diese Modelle sind in seinen Diagrammen mit einem Blitzsymbol markiert. Der Vergleich zeigt: Sobald ein Modell auf eigener Hardware laufen kann, lohnt sich die Rechenzentrumsperspektive nicht mehr. Dann zählt vor allem, wie lange das Modell für eine Aufgabe braucht und wie viel Energie es dafür verbraucht.

Was lokal laufende Modelle wirklich kosten

Für seine lokale Kostenrechnung hat der Autor grobe Schätzungen verwendet. Er nimmt die Anzahl der Ausgabe-Token pro Aufgabe von ArtificialAnalysis. Dazu misst er die Decode-Geschwindigkeit auf lokaler Hardware, meist einer RTX 3090 von 2020, die heute gebraucht für etwa 1.400 Dollar zu haben ist. Aus der Differenz zwischen Spitzen- und Leerlauf-Leistungsaufnahme errechnet er den zusätzlichen Energiebedarf. Den Strompreis setzt er mit 0,2049 Dollar pro Kilowattstunde an, dem durchschnittlichen US-Haushaltsstrompreis von Mai 2026. Dazu kommen pauschal 15 Prozent für ungecachte Eingabe-Token und Wartezeiten bei Tool-Aufrufen.

Die Hardware selbst rechnet er bei kleinen Modellen mit null Euro, weil ein Rechner mit 64 Gigabyte Arbeitsspeicher oder eine RTX 3090 ohnehin ein brauchbares Arbeits- oder Gaming-Gerät ist. Für die meisten Menschen ist das keine reine KI-Investition. Bei dieser Berechnung fällt auf, dass der Unterschied zwischen verschiedenen lokalen Geräten nicht sehr groß ist. Ein Gerät mit weniger Leistungsaufnahme ist langsamer, arbeitet also länger an derselben Aufgabe. Am Ende gleichen sich die Stromkosten weitgehend an.

Diese Logik endet allerdings, sobald du deutlich mehr als 64 Gigabyte Arbeitsspeicher brauchst. Dann wird der Rechner zu einem Spezialwerkzeug, das die meisten Menschen ohne KI nicht anschaffen würden. Größere lokale Modelle sind also deutlich teurer als ihre Stromrechnung vermuten lässt. Imperiale hat die Hardwarekosten für diese Modelle deshalb extra aufgelistet:

Arbeitsspeicher	Hardware	Modelle
128 GB	Strix Halo (3.600 Dollar), DGX Spark (4.300 Dollar), Mac Studio M5 Max (5.100 Dollar), MacBook Pro M5 Max (7.150 Dollar)	Qwen3.8-Flash, GLM-5.3-Flash, DeepSeek-V4-Flash
256 GB	2x DGX Spark (8.700 Dollar), Mac Studio M5 Ultra (11.300 Dollar)	GLM-5.3-Flash, DeepSeek-V4-Flash
512 GB	2x Mac Studio M5 Ultra (22.600 Dollar)	GLM-5.3
2 TB	2x TensTorrent Galaxy Blackhole (320.000 Dollar)	Kimi K3

Modelle der 120-Milliarden-Parameter-Klasse laufen auf einem 128-GB-Strix-Halo zwar noch, aber die Hardware ist mit 3.600 Dollar deutlich teurer als ein normales Alltagsgerät. In seinem Diagramm hat Imperiale diese Modelle deshalb sowohl mit Rechenzentrumspreis als auch mit lokalen Stromkosten gezeigt. Beide Werte täuschen aber darüber hinweg, dass die eigentliche Hürde nicht die laufenden Kosten sind, sondern der einmalige Hardwarepreis.

Was die neuen Diagramme für die Praxis bedeuten

Die zentrale Erkenntnis aus Imperiales Diagrammen ist eine enorme Preisspanne zwischen den teuersten und den günstigsten Modellen. Modelle von Anthropic oder OpenAI sind inzwischen so teuer, dass selbst große Unternehmen genau rechnen müssen. Chinesische Modelle mit fast vergleichbarer Intelligenz kosten so wenig wie ein Mobilfunkvertrag. Auf der Intelligenzskala sind die Unterschiede da, aber der Preisunterschied ist in vielen Fällen unverhältnismäßig.

Ein Beispiel macht das deutlich: Fable 5.1 erreicht einen Intelligenzwert von 66 und kostet 3,69 Dollar pro Aufgabe. GLM-5.3 erreicht 60 Punkte und kostet 0,49 Dollar pro Aufgabe, also etwa 7,5-mal weniger. Der Unterschied zwischen diesen beiden Modellen ist vor allem für sehr anspruchsvolle Nutzer spürbar. Wer ein komplexes System entwickelt, wird die Differenz vielleicht bemerken. Für die meisten Menschen ist sie nicht erkennbar und nicht relevant.

Gehst du noch eine Stufe tiefer, findest du GLM-5.3-Flash mit hohen Denk-Einstellungen. Das Modell erreicht 55 Intelligenzpunkte und kostet mit 0,023 Dollar pro Aufgabe rund 160-mal weniger als Fable. Es wird sichtbar schwächer, wenn du ihm sehr komplexe Aufgaben stellst, etwa ein komplettes Softwareprojekt auf einmal umzusetzen. Für 90 Prozent der alltäglichen Aufgaben reicht dieses Modell locker aus.

Noch weiter unten beginnt der Bereich, in dem du nicht einmal mehr eine API brauchst. Ein Modell wie Qwen3.8-27B erreicht 52 Intelligenzpunkte und kostet in der lokalen Ausführung nur etwa 0,015 Dollar Strom pro Aufgabe. Das Modell läuft auf einem Rechner, den ein Enthusiast mit Gaming-Hardware ohnehin besitzt. Die Kosten sinken also nicht gleichmäßig mit der Intelligenz. Sie fallen dramatisch, sobald du bereit bist, mit einem etwas kleineren Modell zu arbeiten.

Die Plots von Guido Imperiale ersetzen keine eigenen Tests, aber sie helfen dir, die richtigen Fragen zu stellen. Bevor du ein teures KI-Modell in einen Workflow einbaust, solltest du wissen, welche Intelligenz deine Aufgabe wirklich braucht und was eine einzelne Aufgabe kostet. Nicht das teuerste Modell ist das beste, sondern das günstigste, das die Aufgabe zuverlässig löst. Pareto-Frontier heißt: Nimm nicht mehr, als du brauchst. Diese Haltung führt am Ende zu deutlich niedrigeren Kosten und einem klaren Blick auf den tatsächlichen Nutzen.

Quelle: openteams.com