Stellt euch vor, ihr ruft einen Coding-Agenten, und bevor der auch nur eine Zeile Code gesehen hat, hat er schon 33.000 Tokens verbraucht. Dreitausend fürs Setup, zehntausend für den System-Prompt, und der Rest für irgendwelche Metadaten, die keiner braucht. Genau das passiert bei Claude Code. Und es gibt einen Konkurrenten, der das mit 7.000 Tokens erledigt. Ein Faktor von fast fünf. Ausserdem: Ein Unternehmen hat seinen Produktions-Workflow auf GPT-5.6 umgestellt und die harten Zahlen sind da. 2,2 Mal schneller, 27 Prozent billiger. Und ein Paper von HuggingFace zeigt, warum KI-Agenten bei langen Aufgaben versagen, und wie man das mit einem separaten Gedächtnis-Agenten löst. Ich bin eure Lissy, das ist euer Daily AI News Update, los gehts.
Fangen wir mit einem Vergleich an, der jeden interessieren dürfte, der Coding-Agents nutzt. Die Firma Systima hat Claude Code und OpenCode gegeneinander antreten lassen und gemessen, wie viele Tokens jeder braucht, bevor er die eigentliche Aufgabe überhaupt gelesen hat. Das Ergebnis ist bemerkenswert. OpenCode schickt 7.000 Tokens vor dem ersten Prompt-Lesen. Claude Code schickt 33.000. Das ist ein Faktor von 4,7. Wo kommt der Unterschied her? Claude Code hat ein aufwendiges Setup: Tool-Definitionen, System-Prompts, Sandbox-Konfiguration, Metadaten für jede Anfrage. Das summiert sich. OpenCode ist minimalistischer gebaut, mit weniger Overhead, weniger Metadaten, weniger Setup-Kosten. Und das summiert sich bei jedem einzelnen Aufruf. Wenn ihr den ganzen Tag mit Coding-Agents arbeitet, sind das schnell hunderte von Aufrufen. Der Unterschied zwischen 7.000 und 33.000 Tokens pro Aufruf wird dann zu einem massiven Kosten- und Geschwindigkeitsunterschied. Ich finde, dieser Vergleich zeigt etwas Grundlegendes. Die Architektur des Coding-Agents bestimmt deine Kosten, nicht das Modell dahinter. Du kannst das beste Modell der Welt haben, aber wenn dein Agent 33.000 Tokens verschwendet, bevor er loslegt, bist du langsamer und teurer als jemand mit einem schlechteren Modell und besserer Architektur. Das ist ein Take, den ich wichtig finde, weil er den Fokus verschiebt. Weg von welches Modell ist besser, hin zu wie ist mein Setup optimiert.
Weiter im Thema Agent-Effizienz. Ein Unternehmen namens Ploy.ai hat seinen gesamten KI-Produktions-Workflow von einem Vorgängermodell auf GPT-5.6 umgestellt und die Ergebnisse veröffentlicht. 2,2 Mal schneller, 27 Prozent billiger. Das sind keine Benchmark-Zahlen aus einem Paper, sondern echte Produktionsdaten. Was mich daran freut: Es gibt immer mehr Unternehmen, die ihre Migration-Ergebnisse transparent machen. Das ist wertvoll, weil es uns zeigt, wo wir bei LLMs wirklich stehen. Der Wettbewerb zwischen den Modellanbietern ist noch lange nicht vorbei. Jedes Quartal kommen neue Modelle mit signifikant besseren Kosten und schnellerer Performance. Und das heisst für alle, die KI in Produktion betreiben: Es lohnt sich, regelmäßig zu migrieren. Ein Modell, das vor sechs Monaten optimal war, kann heute schon veraltet sein. Aber, und das ist der Haken, das gilt natürlich auch umgekehrt. Wenn dein Workflow stark von einem spezifischen Modell abhängig ist, mit Custom-Features, speziellen APIs, bestimmten Verhaltensweisen, dann wird der Wechsel teurer. Die entscheidende Frage ist also: welches Modell hat die beste Performance, und wie flexibel ist deine Architektur für den Wechsel.
Und jetzt zu einem Problem, das jeden betrifft, der schon mal mit einem KI-Agenten über mehrere Schritte gearbeitet hat. Nach einer Weile fängt der Agent an, Dinge zu vergessen. Ihr habt ihm vor zehn Schritten gesagt, welche Bibliothek er verwenden soll, und plötzlich verwendet er eine andere. Ihr habt erklärt, dass die Antwort in einem bestimmten Format kommen muss, und nach fünf Minuten ist das Format wieder falsch. Das ist kein Zufall, sondern ein bekanntes Problem aus der Forschung. Es heisst Behavioral State Decay. Je länger die Aufgabe, desto mehr relevante Informationen gehen im Kontextfenster unter. Bisher hat man das mit RAG gelöst, also mit einem externen Wissensspeicher, der auf Anfrage antwortet. Aber RAG ist reaktiv. Der Agent muss erst merken, dass er etwas vergessen hat, bevor er nachfragt. Ein neues Paper auf HuggingFace stellt eine komplett andere Architektur vor. Es heisst SETA, und der Kern ist ein separater Memory-Agent, der parallel zum Action-Agent läuft. Der Memory-Agent beobachtet, was der Action-Agent tut, und entscheidet dann proaktiv, ob er eine Erinnerung einspielt. Er sagt nicht erst, wenn der Action-Agent fragt: Pass auf, du hast vor zehn Schritten gelernt, dass dieser API-Endpunkt eine bestimmte Fehlermeldung wirft. Der Unterschied zu RAG ist fundamental: SETA pusht Information, bevor sie gebraucht wird. RAG wartet auf eine Query. Die Ergebnisse sind beeindruckend. Auf dem Terminal-Bench 2.0 verbessert SETA die Erfolgsquote um 8,3 Prozentpunkte. Auf dem taubench um 6,8 Prozentpunkte. Die Ablationen zeigen, dass genau die proaktive, selektive Intervention den Unterschied macht. Passiver Speicherzugriff bringt nur 2,1 Prozentpunkte, Always-On-Injection 4,5. SETA ist nicht nur besser, sondern auch effizienter. Was heisst das praktisch? Jeder, der KI-Agenten für längerlaufende Aufgaben baut, sollte sich diese Architektur anschauen. Sie ist ein Plug-and-Play-Konzept, kein neues Modelltraining, sondern ein zusätzlicher Agent, der observiert und eingreift.
Mistral hat ein neues Produkt vorgestellt, das in eine ganz andere Richtung geht. Robostral Navigate ist ein spezialisierter KI-Agent für Robotik-Navigation. Also nicht Chat, nicht Code, nicht Bilder, sondern Maschinen, die sich autonom durch Fabrikhallen, Lager oder vielleicht irgendwann öffentliche Räume bewegen. Das ist ein Nischenprodukt, keine Frage. Aber es zeigt, wohin Mistral strategisch will: weg von reiner Sprach-KI, hin zu spezialisierten Industrie-Agenten. Die Frage ist, ob sich dieser Fokus auszahlt oder ob die Konkurrenz von Nvidia Isaac und Google Robotics den Markt schon besetzt hat.
Und zum Abschluss eine Geschichte, die mich persönlich sehr gefreut hat. Der Mathematiker Terry Tao, Fields-Medaillist und einer der klügsten Köpfe unserer Zeit, hat einen Blog-Post über seine Erfahrungen mit Coding-Agents geschrieben. Er nutzt sie für Programmieraufgaben, die er früher selbst gemacht hat, und reflektiert, wie sich seine Arbeitsweise verändert. Wenn Terry Tao sagt, dass Coding-Agents kein Spielzeug mehr sind, dann hat das Gewicht. Weil Tao jemand ist, der keine Plattform braucht und keinen Hype produziert. Er schreibt einfach, was er beobachtet.
Worauf ich heute komme: Von den Tokenkosten eines Coding-Agents bis zum Gedächtnis eines Agenten, von Produktionsdaten eines Modells bis zu einem Mathematiker, der seine Werkzeuge neu denkt. Der rote Faden heute war die Effizienz und Qualität von KI-Agenten. Und was mir auffällt: Je mehr wir über Agenten lernen, desto klarer wird, dass die Architektur zählt, nicht nur das Modell. Ein schlanker Agent mit proaktivem Gedächtnis schlägt einen fetten Agenten mit besserem Modell. Das ist ein Prinzip, das sich durch den ganzen Tag zieht. Wenn euch die Folge gefallen hat, schreibt mir eine Mail, die Adresse steht in den Shownotes. Und wenn ihr selbst einen Agenten baut, der Dinge vergisst, dann sucht mal nach dem SETA-Paper. Servus, pfiat eich und bis morgen, eure Lissy.