Tessera

Googles neues Spitzenmodell Gemini 4 Argon schreibt bis zu 1 Mio. Tokens und glänzt in Herstellerbenchmarks. Nutzen dürfen es vorerst nur Cyber-Verteidiger, und laut Bloomberg zweifeln Google-Mitarbeitende am Frontend-Coding. Eine Einordnung der Papierlage.

Gemini 4 Argon: Googles Comeback ins Spitzenfeld – mit Gästeliste

Google hat am 30. September Gemini 4 Argon vorgestellt, das erste Modell der Gemini-4-Generation und das erste neue Flaggschiff seit _Gemini 3.1 Pro_ im Februar. Dazwischen lagen ein auf der I/O angekündigtes und später gestrichenes Gemini 3.5 Pro sowie eine ganze Serie von Flash-Modellen, zuletzt Gemini 3.8 Flash. Mit _Argon_ will Google zurück ins Spitzenfeld, und auf dem Papier gelingt das auch. Nutzen kann das Modell allerdings fast niemand. Zum Start bekommt _Argon_ nur ein ausgewählter Kreis von „Cyber-Verteidigern“ (sorry, für die Anführungszeichen), alle anderen warten vor der Tür. Ausprobiert habe ich also nichts, das hier ist eine Einordnung der Papierlage. Die großen Gemini-Modelle stecken bei mir allerdings auch aktuell in keiner Pipeline und in keinem Workflow. Ich nutze sie im Chat für Recherche, Analysen und Dokumente, am liebsten in Markdown – genau das hatte _Gemini 3.1 Pro_ gut drauf. ## TL;DR _Gemini 4 Argon_ ist Googles neues Spitzenmodell mit bis zu 1 Mio. Output-Tokens und starken Herstellerwerten. Nutzen dürfen es vorerst nur ausgewählte Cyber-Verteidiger im Fairwind Program. * Einführungspreis 2 $ / 10 $ pro 1 Mio. Tokens, danach 4 $ / 20 $ – ein Enddatum für die Aktion nennt Google nicht. * In Googles eigener Tabelle liegt _Argon_ in 13 von 19 Zeilen allein vorn, beim agentischen Coding auf Terminal-Bench 4.0 und FrontierSWE v2 aber hinten. * Artificial Analysis misst 53 Punkte im Intelligence Index, gleichauf mit _GPT-6 Astra_ und hinter _Claude Opus 5.5_. * Laut Bloomberg zweifeln einige Google-Mitarbeitende an der Praxisleistung bei bestimmten Coding-Aufgaben, darunter Frontend-Design. ## Wer Gemini 4 Argon bekommt und wer nicht Den Anfang machen Partner aus Googles Fairwind Program, das Anfang September zusammen mit _Gemini 3.8 Flash Cyber_ gestartet ist und laut Google mehr als 650 Organisationen umfasst – vor allem Behörden, Betreiber kritischer Infrastruktur und zentrale Technologieplattformen. Ein Teil davon bekommt _Argon_ ohne Cyber-Guardrails, um Schwachstellen zu finden und zu patchen, bevor es jemand anderes tut. Parallel läuft das freiwillige Pre-Release-Verfahren der US-Regierung. Die breitere Verfügbarkeit für Entwickler, Unternehmen und Endkunden soll laut Google mit zahlenden API-Kunden und Abonnenten von _Google AI Ultra_ beginnen. Einen Termin nennt Google nicht. Eine öffentliche Model-ID in der Gemini API gibt es laut The Rundown noch nicht, und zur Gemini-App in den kleineren Abos sagt die Ankündigung nichts. Damit hakt es bei meinem Plan. Ich würde _Gemini_ in _Antigravity_ gern mal auf ein paar einfache Tasks loslassen, zum Beispiel eine Handvoll Landingpages nach Corporate Design Vorgaen (und alles schon fix und fertig als Skill). In Googles Ankündigung taucht _Antigravity_ nicht auf, gelaufen ist _Argon_ dort trotzdem schon. Im Coding Agent Index von Artificial Analysis kommt das Gespann aus _Antigravity CLI_ und _Argon_ auf 64 Punkte und Platz drei, hinter _Claude Code_ mit _Sonnet 5.5_ (68) und _Opus 5.5_ (66), aber vor _Codex_ mit _GPT-6 Astra_ (62). Gemessen wird dort immer Modell plus Harness, also genau die Kombination, die ich gern testen würde. ## Eine Million Output-Tokens Google hebt das Output-Limit von 64.000 auf eine Million Tokens an. Artificial Analysis führt _Argon_ zusätzlich mit einem Kontextfenster von einer Million Tokens, ein separates Input-Limit nennt Google zum Launch allerdings nicht. Damit lange Antworten nicht ins Timeout laufen, gibt es in der Gemini API eine neue Funktion namens Long Decode Continuation, die eine Antwort unterbricht und über Folgeanfragen fortsetzt. Im Chat merkt man davon wenig. Für Agenten, die eine Codebasis migrieren oder einen langen Vertragsentwurf schreiben, fällt dagegen eine Grenze weg, an der Arbeit bisher abbrach oder in Häppchen zerlegt werden musste. Google liefert die Beispiele aus dem eigenen Haus. _Argon_ -Agenten migrieren C- und C++-Code nach Rust, beim Zircon-Kernel von Fuchsia geht es um mehr als 800.000 Zeilen, und ein Team solcher Agenten soll in Googles Rechenzentren Speicheroptimierungen gefunden und umgesetzt haben, die über 300 TiB Arbeitsspeicher freisetzen. Unabhängig prüfen lässt sich davon nichts. Die Rust-Umbauten laufen laut Google vor dem Produktiveinsatz außerdem noch durch Audits und Reviews. Der Haken tauch dann auf der Preisliste auf: Jedes Output-Token kostet zum Einführungspreis 10 $ pro Million, danach 20 $ – eine einzige voll ausgereizte Antwort schlägt also allein beim Output mit 10 bzw. 20 $ zu Buche. Sparsam ist _Argon_ auch sonst nicht, denn laut Artificial Analysis erzeugt das Modell im Schnitt 62.000 Output-Tokens pro Index-Aufgabe, _GPT-6 Astra_ kommt mit 27.000 aus. ## Hersteller-Sternchen bei 13 von 19 Im Fließtext des Blogposts nennt Google nur Benchmarks, in denen _Argon_ vorn liegt. Die vollständige Vergleichstabelle gegen _GPT-6 Astra_ , _Claude Fable 5.1_ und Claude Opus 5.5 steckt als Grafik im Blogpost und im Launch-Post von Google DeepMind auf X. Von ihren 19 Zeilen gewinnt _Argon_ 13 allein und teilt sich bei einer weiteren den ersten Platz. VentureBeat zählt die beiden GraphWalks-Zeilen als einen Benchmark und kommt deshalb auf 12 von 18. Die Highlights aus Googles Sicht: * DeepSWE v1.1 (lange Software-Engineering-Aufgaben): 77,9 %, vor _Opus 5.5_ mit 74,2 % und _Astra_ mit 74,1 % * AutomationBench von Zapier (durchgängige Abläufe in typischen Geschäftsbereichen): 51,3 %, die Konkurrenz liegt zwischen 31,4 und 42,5 % * Harvey’s Legal Agent Benchmark (juristische Recherche und Entwürfe): 19,6 %, alle anderen unter 7 % * LVBench (Verständnis langer Videos): 91,7 %, vor _Astra_ mit 87,5 % * CWE-bench v1 (Schwachstellen beheben): 68 %, gleichauf mit _Astra_ , _Opus 5.5_ einen Punkt dahinter Die schwächeren Zeilen stehen nur in der Tabellengrafik, und heise hat sie herausgesucht. Auf Terminal-Bench 4.0 für agentisches Coding landet _Argon_ mit 57,4 % hinter allen Konkurrenten aus Googles eigener Tabelle, _Claude Opus 5.5_ kommt auf 66,4 %. Nimmt man Claude Sonnet 5.5 mit Anthropics Angabe von 70,6 % dazu, liegt ausgerechnet das Modell mehr als 13 Punkte vorn, das so viel kostet wie _Argon_ zum Einführungspreis. Auf FrontierSWE v2 hat _GPT-6 Astra_ laut MarkTechPost gut zehn Punkte Vorsprung. Das ist Googles eigene Vergleichsauswahl, eine Mischung aus eigenen Runs und Ergebnissen externer Benchmark-Betreiber. Auswahl und Präsentation stammen aber trotzdem vom Hersteller, die Brille muss man sich eben dabei aufsetzen. ### Was von außen gemessen wurde Trotz des geschlossenen Zugangs gibt es bereits unabhängige Zahlen. Artificial Analysis kommt im Intelligence Index auf 53 Punkte bei Reasoning Effort High, gleichauf mit _GPT-6 Astra_ und laut The Decoder auch mit _Claude Fable 5.1_. Vorn bleiben _Claude Opus 5.5_ mit 58 und _Claude Sonnet 5.5_ mit 56 Punkten. Beim Einführungspreis kostet _Argon_ mit 1,99 $ pro Index-Task rund 61 % von _Astra_ mit 3,26 $. Nach Ende der Aktion kalkuliert Artificial Analysis mit 3,98 $, dann wäre _Argon_ bei gleicher Messung sogar teurer. Gemeint ist jeweils ein gewichteter Durchschnitt über die Eval-Aufgaben, kein allgemeiner API-Preis. Für Recherche zählt eine andere Zahl aber mehr: Im AA-Omniscience-Test lag die Halluzinationsrate bei 15 %, der niedrigste Wert unter allen Modellen mit mindestens 45 Index-Punkten (_GPT-6 Astra_ : 51 %). Der Preis dafür steht laut The Decoder denn aber eine Zeile tiefer, denn richtig beantwortet hat _Argon_ nur 50 % der Fragen, fünf Punkte weniger als _Gemini 3.1 Pro Preview_. Das Modell passt also öfter, statt zu raten – für Recherche ist mir das aber einhundertmal lieber als umgekehrt. Auf dem Vals Index, der Aufgaben aus Finanzen, Recht, Steuern und Coding bündelt, steht _Argon_ mit 68,9 % auf Platz eins von 41 Modellen – laut Vals AI auf X zum ersten Mal ein Gemini-Modell. In der Text Arena von Arena.ai führt _Argon_ mit 1.525 Punkten, in der Code Arena für Webentwicklung reicht es nur für Platz acht (Stand jeweils 1. Oktober 2026). ## Benchmarks top, Frontend wackelig? Am Launch-Tag kam die Gegengeschichte von Bloomberg. Einige Google-Mitarbeitende mit direktem Zugang zu _Gemini 4_ sagen demnach, das Modell schneide bei echter Arbeit schwächer ab als in Benchmarks und kämpfe mit bestimmten Coding-Aufgaben. Als Beispiel nannte eine Person laut Implicator Frontend-Design, also den Teil, der bestimmt, wie eine App oder Website aussieht und sich anfühlt. Google hält es laut der Zusammenfassung bei Investing.com für falsch, _Gemini 4_ beim Coding als schwach darzustellen, und ein Mitarbeiter spricht von einem „großen Konsens“, dass das Modell an der Frontier liegt. Von außen lässt sich das nicht entscheiden. Platz acht in der WebDev-Arena, wo Menschen blind zwischen zwei Ergebnissen abstimmen, ist zumindest konsistent mit der Frontend-Kritik, bestätigt sie aber nicht. Dagegen steht Vibe Code Bench, ein Test, in dem Modelle komplette Webanwendungen bauen. Vals hat _Argon_ dort selbst gemessen und kommt in Version 1.1 auf 91,9 % und Platz zwei von 106, knapp hinter _Claude Sonnet 5.5_ mit 92,4 %. ## Prompt Injection, die Zahl für Pipelines Bevor _Argon_ breit verfügbar wird, will Google die Schutzmaßnahmen in vier Bereichen nachschärfen, nämlich bei Missbrauch für Cyber- und CBRN-Angriffe, indirekter Prompt Injection, Fehlausrichtung des Modells und abgeschotteten Testumgebungen. Gegen Fehlausrichtung überwacht Google die Chain-of-Thought und die Aktionen des Modells und bricht bei Bedarf ab. Wer Modelle fremde Inhalte lesen lässt, sollte sich eine Zahl daraus merken. Auf Gray Swans Benchmark für indirekte Prompt Injection liegt die von Google veröffentlichte Attack Success Rate bei 15 Versuchen für _Argon_ bei 0,7 %, für _Claude Opus 5.5_ bei 1,0 % und für _GPT-6 Astra_ bei 8,5 %. Konfidenzangaben fehlen, der Abstand zwischen 0,7 und 1,0 % ist also mit Vorsicht zu genießen. Für meine Chat-Nutzung spielt die Zahl kaum eine Rolle, für jeden Agenten mit Browser- oder Mailzugriff eine große. ## Günstig, solange die Aktion läuft Zum Start kostet _Argon_ 2 $ pro Million Input-Tokens und 10 $ pro Million Output-Tokens, cached Input bekommt 95 % Rabatt. Das entspricht dem Tokenpreis von _Claude Sonnet 5.5_ und GPT-6.1 Sol. Nach der Einführungsphase verdoppelt sich der Preis auf 4 $ / 20 $ und landet beim Listenpreis von _Opus 5.5_. Wann die Einführungsphase endet, verrät Google nicht. Wer gerade Modellentscheidungen trifft, kalkuliert deshalb schon mal besser mit dem Standardpreis als mit der Aktion – sobald es dennn etwas zu rechnen gibt. ## Comeback auf Raten Google ist zurück im Spitzenfeld. Vorn liegt _Argon_ vor allem bei Wissensarbeit, langen Dokumenten und Videos, beim agentischen Coding ist das Bild gemischt, und für meine Art, _Gemini_ zu nutzen, passt das sogar, denn Recherche, Analysen und lange Markdown-Dokumente im Chat sind genau dieses Terrain. Ob _Argon_ dort mehr liefert als _Gemini 3.1 Pro_ , sehe ich, sobald es bei mir ankommt. Gespannt bin ich auf den Test, den ich ohnehin vorhatte: Eine Handvoll Landingpages nach CD-Vorgaben in _Antigravity_ ist Frontend-Arbeit in Reinform, also die Disziplin, an der einige Leute aus Googles eigener Belegschaft zweifeln. Passender geht ein Praxistest kaum. Bis Google die Tür aufmacht, bleibt _Argon_ für mich ein Modell mit glänzenden Zeugnissen und ohne Probezeit.

t01.li

GPT-6.1 Sol kommt sieben Tage nach GPT-6 Sol, zum gleichen Tokenpreis und mit halbiertem Cache-Preis. Ich hätte das fast als Iteration abgehakt. Artificial Analysis misst allerdings bis zu acht Punkte mehr, am deutlichsten auf Low und Medium.

GPT-6.1 Sol: kleiner Versionssprung, großer Satz im Index

OpenAI hat am 29. September auf dem DevDay GPT-6.1 Sol vorgestellt, genau eine Woche nachdem GPT-6 Sol und Luna mit halbierten API-Preisen rausgekommen sind. Soweit ich es überblicke, hat noch kein Modell aus OpenAIs Hauptlinie so schnell einen Nachfolger bekommen. Der Tokenpreis bleibt, der Cache wird billiger, und laut OpenAI rückt Sol damit nah an das Flaggschiff GPT-6 Astra heran. Auffällig ist wieder das Timing, denn Anthropic hatte einen Tag vorher _Claude Sonnet 5.5_ veröffentlicht. Nach Versionsnummer und Preisliste hätte ich das Ganze als Iteration abgehakt – von 6 auf 6.1, gleicher Preis, weiter im Text. Artificial Analysis sieht das anders, zumindest auf den unteren und mittleren Effort-Stufen. ## TL;DR _GPT-6.1 Sol_ kostet weiter 2 $ / 10 $ pro 1 Mio. Tokens, gecachter Input sinkt auf 0,10 $. Im Artificial-Analysis-Index legt das Modell auf allen Effort-Stufen zu, am deutlichsten auf Low und Medium. * Erschienen am 29. September, sieben Tage nach _GPT-6 Sol_ und einen Tag nach _Claude Sonnet 5.5_. * Artificial Analysis: 52 statt 48 Punkte auf Max, 48 statt 40 auf Medium – bei gleichen oder niedrigeren Kosten pro Index-Task. * In der API fällt die Effort-Stufe `none` weg, Tool Calling gibt es nur über die Responses API. * Die deutsche OpenAI-Seite klingt beim Tempo-Tarif Ultrafast weiter, als Original und Preisliste es hergeben. ## Sieben Tage, zwei Releases, ein bekanntes Muster Das Muster kennt man seit letzter Woche. Am 22. September erschien _GPT-6 Sol_ am selben Tag wie Claude Opus 5.5, und OpenAI verglich in den eigenen Charts noch mit _Opus 5_. Diesmal erwischt es Anthropic. In der Benchmark-Tabelle zu Sonnet 5.5 vom 28. September steht _GPT-6 Sol_ als Vergleichsmodell – ein Modell, das am nächsten Tag schon nicht mehr OpenAIs aktuelles Sol war. Wer da auf wen reagiert, lässt sich von außen ganz schwer sagen. Einen DevDay setzt niemand am Vorabend an, und man kann das Timing genauso gut umgekehrt lesen: Anthropic hat seinen Release einen Tag vor OpenAIs Entwicklerkonferenz platziert (was ich aktuell für am Wahrscheinlichsten halte). Als Anwender bleibt vor allem hängen, dass Vergleichstabellen inzwischen eine Halbwertszeit von ungefähr einem Tag haben. ## Gleicher Preis, halbierter Cache Am Tokenpreis ändert sich nichts. _GPT-6.1 Sol_ kostet laut API-Preisliste im Standard-Tarif 2 $ pro Million Input-Tokens und 10 $ pro Million Output-Tokens, genau wie der Vorgänger. Neu ist der Preis für gecachten Input, der von 0,20 $ auf 0,10 $ fällt. Das sind 95 % Rabatt auf den regulären Input und die Hälfte dessen, was _GPT-6 Sol_ für den Cache nimmt. Cache-Writes kosten unverändert 2,50 $, also das 1,25-Fache des Input-Preises. Bei mehr als 272.000 Input-Tokens greift wie gehabt der Long-Context-Tarif mit doppeltem Input- und Cache-Preis und dem 1,5-fachen Outputpreis für den gesamten Request. Für Agenten, die bei jedem Schritt denselben Kontext mitschicken, ist der Cache der eigentliche Hebel. OpenAIs Hauptargument zielt trotzdem auf _Astra_ , das mit 10 $ / 50 $ genau fünfmal so viel kostet wie Sol. Auf der Modellseite stehen ein paar Details, die für Pipelines wichtiger sind als die Benchmarks: Das Kontextfenster bleibt bei 1,05 Mio. Tokens mit maximal 128.000 Output-Tokens, der Knowledge Cutoff rückt vom 20. auf den 30. April 2026. Zehn Tage mehr Weltwissen, immerhin. Interessant wird es beim Reasoning Effort, denn _GPT-6.1 Sol_ kennt nur noch `low`, `medium`, `high`, `xhigh` und `max` – die Stufe `none`, die _GPT-6 Sol_ noch hatte, fällt weg (das kennen wir bereits von Astra). Das hat da eine dezente Nebenwirkung; Bei GPT-6 Sol lief Function Calling über Chat Completions noch, solange `reasoning_effort` auf `none` stand. Bei _GPT-6.1 Sol_ gibt es Tool Calling nur über die Responses API, Chat Completions funktioniert ohne Tools. Wer einfach die Model-ID tauscht, bekommt an genau dieser Stelle Ärger. Für Teams mit Datenschutz-Auflagen gibt es dafür EU-Datenresidenz, allerdings ohne Fast Mode. In der Flaggschiff-Tabelle der Preisliste hat _GPT-6.1 Sol_ den Vorgänger schon ersetzt. Eine Abschaltung von `gpt-6-sol` kündigt die Deprecations-Seite bisher nicht an. Für allgemein verfügbare Modelle nennt OpenAI dort mindestens sechs Monate Vorlauf – es sei denn, Sicherheits- oder Compliance-Gründe verlangen eine kürzere Frist. ## Herstellerzahlen, diesmal gegen Opus 5.5 Die Benchmark-Sektion folgt dem Muster der Vorwoche. Fast jede Zahl kommt mit einem Kostenvergleich, absolute Scores sind rar. Immerhin vergleicht OpenAI diesmal mit _Opus 5.5_ und nicht mit dessen Vorgänger. Im Launch-Post stehen unter anderem diese Vergleiche: * DeepSWE 1.1: gleichauf mit _Astra_ zu rund einem Fünftel der Kosten, 6,4 Prozentpunkte über dem besten Wert von _GPT-6 Sol_ – bei geringerem Reasoning-Aufwand * AutomationBench 1.0.6 auf Medium: 2,2 Prozentpunkte vor _Opus 5.5_ zu rund einem Drittel der Kosten, 4,8 Prozentpunkte über _GPT-6 Sol_ * OSWorld 2.0 offline auf Max: 7 Prozentpunkte vor _GPT-6 Sol_ zu weniger als der Hälfte der Kosten, 2,1 Prozentpunkte hinter _Astra_ zu rund einem Siebtel * Terminal-Bench Science 0.1 auf Max: mehr als doppelt so hoher Score wie bei _GPT-6 Sol_ , 5,47 $ pro Task gegenüber 23,21 $ bei _Opus 5.5_ und 23,80 $ bei _Astra_ Den Spitzenwert bei Terminal-Bench Science hält mit 68,1 % weiter _Astra_. Den absoluten Score von _GPT-6.1 Sol_ nennt der Fließtext nicht, und für die Einordnung wäre mir eine Zahl lieber als „mehr als das Doppelte“. Das sind – man kennt das bereits – herstellereigene Messungen, die Konkurrenzwerte stammen laut Fußnote aus öffentlichen Reports. Einen gemeinsamen, unabhängigen Testlauf ersetzt das nicht. ### Die deutsche Fassung setzt eigene Akzente Ich habe den Post zuerst auf Deutsch gelesen und dann das englische Original danebengelegt. An zwei Stellen erzählen die beiden nicht ganz dieselbe Geschichte. Bei der Faktentreue setzen die Fassungen unterschiedliche Schwerpunkte. Die deutsche Seite nennt auf xhigh 4,1 % fehlerhafte Antworten, gegenüber 4,5 % beim Vorgänger und 4,0 % bei _Astra_. Das englische Original stellt dagegen Low nach vorne, wo die Quote von 11,4 auf 7,7 % sinkt. Das sind unterschiedliche Effort-Stufen und kein belegter Widerspruch, nur eben eine andere Auswahl fürs Schaufenster. (Beide Werte stammen aus bewusst schwierigen Testfällen, in denen Nutzer vorher einen Fehler gemeldet hatten. Mit der Fehlerquote im Alltag hat das wenig zu tun.) Richtig schief wird es beim Tempo-Tarif Ultrafast. Die deutsche Seite klingt so, als sei _GPT-6.1 Sol Ultrafast_ schon verfügbar, mit bis zu achtfachem Tempo zu ungefähr den bisherigen _Astra_ -Kosten. Das englische Original kündigt Ultrafast für Sol erst für die nächsten Tage an, und der DevDay-Rückblick führt es noch als „coming soon“. Für den Tarif insgesamt nennt er bis zu sechsfache Token-Generierung in der API und bis zu achtfache in _Codex_. Gemeint ist das Token-Tempo, nicht die gesamte Bearbeitungszeit eines Tasks. In der Preisliste steht unter Ultrafast bislang nur _Astra_ , deshalb halte ich mich an Original und Preisliste, Stand 30. September. Den Sol-Preis aus der deutschen Fassung würde ich bis dahin nicht als Tarif verbuchen. ## Artificial Analysis: Der Sprung von GPT-6.1 Sol sitzt unten und in der Mitte Die unabhängigen Zahlen von Artificial Analysis sind der Teil, der meine Iterations-These ins Wanken bringt. Im Intelligence Index v4.3.2 legt _GPT-6.1 Sol_ auf allen fünf gemeinsamen Effort-Stufen zu, am deutlichsten auf Low und Medium. Medium ist zugleich die Voreinstellung in der API, was genau diese Zeile für den ersten eigenen Test interessant macht. Effort | GPT-6 Sol | GPT-6.1 Sol | Kosten pro Index-Task (6 → 6.1) ---|---|---|--- Max| 48| 52| 1,05 $ → 0,72 $ Xhigh| 44| 51| 0,52 $ → 0,39 $ High| 43| 50| 0,38 $ → 0,32 $ Medium| 40| 48| 0,25 $ → 0,21 $ Low| 34| 42| 0,13 $ → 0,13 $ Stand 30.09.2026. Die Kosten pro Index-Task sind ein gewichteter Durchschnitt über die Index-Aufgaben, kein allgemeiner API-Preis. Die so richtig interessante Zeile ist aber Medium: _GPT-6.1 Sol_ erreicht dort mit 48 Punkten genau den Max-Wert des Vorgängers, für 0,21 $ statt 1,05 $ pro Index-Task, also für ein Fünftel. Zur Erinnerung: Beim Wechsel von _GPT-5.6 Sol_ auf _GPT-6 Sol_ hatte sich der Max-Wert um einen Punkt bewegt. Die volle Generationsnummer brachte einen Punkt, die Nachkommastelle bringt vier auf Max und sieben bis acht darunter. _Astra_ liegt auf Max mit 53 Punkten nur noch einen gerundeten Indexpunkt vor Sol. Das stützt das „near-Astra“ aus dem Marketing zumindest in diesem Gesamtindex. Und weil der Anthropic-Release vom Vortag ohnehin danebensteht, ein kurzer Blick rüber: Sonnet 5.5 erreicht bei Artificial Analysis auf High 47 Punkte bei 1,08 $ pro Index-Task und auf Max 56 Punkte, getestet jeweils in der Konfiguration mit Anthropics Standard-Fallback. Auf Max liegt Sonnet in diesem Index also vor Sol. Auf High liefert _GPT-6.1 Sol_ mit 50 Punkten für 0,32 $ den günstigeren Messpunkt, wobei gleich benannte Effort-Stufen zwischen zwei Herstellern nicht bedeuten, dass beide gleich viel rechnen. ### Das Warten auf die erste Antwort Weniger erfreulich ist die Latenz. Artificial Analysis weist für die Zeit bis zum ersten Antwort-Token auf Low 2,12 Sekunden aus, auf Medium 5,72, auf High knapp 58, auf Xhigh knapp 109 und auf Max fast 273 Sekunden – die Thinking-Zeit eingerechnet. Das sind Kennwerte aus den Testbedingungen von Artificial Analysis und keine feste Wartezeit für jeden Request. Mit rund 59 bis 66 Tokens pro Sekunde liegt das Modell außerdem unter dem Median vergleichbarer Modelle von knapp 71. Für einen Agenten-Loop, der viele kurze Schritte schnell abarbeiten soll, wäre Max damit für mich kein naheliegender Ausgangspunkt. Gegenüber Xhigh bringt die Stufe einen weiteren gerundeten Indexpunkt, kostet pro Index-Task rund 85 % mehr und steht beim ausgewiesenen Latenzwert bei gut viereinhalb Minuten. Ob sich das für einen konkreten Workflow rechnet, würde ich im eigenen Setup prüfen (und mir vorher einen Kaffee holen). ## Iteration? Nach der Versionsnummer schon Ich hätte _GPT-6.1 Sol_ nach Versionsnummer und Preisliste erstmal als Iteration einsortiert und bei Preis und Kontextfenster trägt das auch, im Index aber nicht. OpenAI selbst spricht im DevDay-Rückblick von einem großen Upgrade – eine Selbstbeschreibung, die ich im Normalfall unter Marketing wegsortiert hätte. Aber: hier stützen die unabhängigen Zahlen jene Selbstbeschreibung zumindest auf den unteren und mittleren Stufen. Hotter Take: Versionsnummern sagen bei OpenAI gerade wenig darüber, wie groß ein Schritt tatsächlich ist. Letzte Woche kam eine neue Generation mit einem Punkt Plus, diese Woche eine Nachkommastelle mit acht. Wer _GPT-6 Sol_ produktiv einsetzt, sollte vor dem Wechsel alle Requests suchen, die `reasoning.effort` auf `none` setzen. Bei Chat Completions heißt der Parameter `reasoning_effort`, also am besten nach beidem greppen, und gleich mit nach Tool-Aufrufen über Chat Completions. Danach würde ich Medium und High im eigenen Harness gegen den bisherigen Stand laufen lassen, bevor ich mich auf die Evals des Herstellers verlasse. Eigentlich wollte ich _GPT-6.1 Sol_ heute schon in _Codex_ mit ganz klassischem Kram testen – so einem frischen _Astro_ -Stack ohne Altlasten. Dazu bin ich nicht gekommen, dann eben morgen. Bis dahin lasse ich das so stehen, mit der Erkenntnis, dass eine .1 manchmal mehr bewegt als eine 6.

t01.li

Claude Sonnet 5.5 kostet so viel wie Sonnet 5 und liegt in Benchmarks nah an Opus 5.5. Artificial Analysis setzt ein Sternchen dran, und der Developer-Guide zeigt, wofür Anthropic das Modell wirklich sieht: als Arbeitspferd für wiederkehrende Agenten-Tasks.

Claude Sonnet 5.5: Opus-nahe Benchmarks zum Sonnet-Preis – solange du beim Effort nicht übertreibst

Anthropic hat am 28. September _Claude Sonnet 5.5_ veröffentlicht, sechs Tage nach Opus 5.5 und damit als zweites Modell der 5.5-Familie. Ich bin heute Morgen auf X darüber gestolpert und konnte aus zeitlichen Gründen noch nichts selbst testen und ausprobieren. Das hier ist also eine Einordnung der Papierlage, kein Praxistest. Die Eckdaten aus dem Launch-Post von Anthropic lesen sich wie ein Wunschzettel: gleicher Preis pro Token wie _Sonnet 5_ , über 30 % schneller und pro Task bis zu 30 % günstiger, weil das Modell für dieselbe Arbeit weniger Tokens braucht. Am selben Tag erschien im Developer-Blog der Guide „Building with Claude Sonnet 5.5“ von Addy Osmani. So ein Playbook direkt zum Launch gehört bei den 5.5-Releases offenbar zum Paket, denn auch _Opus 5.5_ bekam vergangene Woche am Launch-Tag einen eigenen Guide, ebenfalls von Osmani. Über weite Strecken liest sich der Guide wie eine Betriebsanleitung für Agenten. ## TL;DR Anthropics neues Mittelklasse-Modell rückt in Benchmarks nah an _Opus 5.5_ heran, der Kostenvorteil pro Task hängt aber am Effort-Level. * Preis pro Token unverändert: 2 $ Input und 10 $ Output pro Million Tokens, halb so viel wie bei _Opus 5.5_. * Artificial Analysis misst 56 Punkte im Intelligence Index, zwei hinter _Opus 5.5_ – auf Max-Effort allerdings mit dem höchsten je gemessenen Tokenverbrauch. * Für agentische Workflows gibt es Breaking Changes, unter anderem `between_tools` statt abgeschaltetem Thinking. * Anthropic sieht _Sonnet 5.5_ bei klar abgegrenzten, wiederkehrenden Agenten-Tasks, _Opus 5.5_ bei der langen Strecke. ## Was Claude Sonnet 5.5 kann und was es kostet Am Preis pro Token hat Anthropic nicht gedreht. Input kostet 2 $ pro Million Tokens, Output 10 $, Cache-Reads 0,20 $. _Opus 5.5_ kostet mit 4 $ und 20 $ genau das Doppelte, nur beim Cache-Read liegen beide gleichauf. Das Kontextfenster fasst nativ eine Million Tokens ohne Beta-Header, der reguläre Output ist auf 128.000 Tokens begrenzt (über die Message Batches API per Beta-Header bis zu 300.000), und der Knowledge Cutoff liegt im Juni 2026. Erreichbar ist das Modell über die Claude API als `claude-sonnet-5-5` sowie über Amazon Bedrock, Google Cloud und Microsoft Foundry. Anthropic positioniert _Sonnet 5.5_ als schnellere, günstigere Ergänzung zu _Opus 5.5_. Gemeint sind klar abgegrenzte Alltagsaufgaben, Bugfixes, Dokumente, Slides und Spreadsheets also Tabellen, dazu angeblich ein gutes Auge für Design. (Nebenbei ist es der erste Sonnet, der _Pokémon Red_ allein anhand von Screenshots durchgespielt hat – der Benchmark, auf den wir alle gewartet haben.) _Haiku 5.5_ folgt in den kommenden Wochen. Wer rechnet, sollte beim Reasoning Effort sehr genau hinschauen: _Sonnet 5.5_ denkt standardmäßig mit, und die Voreinstellung hängt von der Oberfläche ab – in _Claude Code_ und den Claude-Apps läuft das Modell auf Medium, über die API dagegen auf High. Erfahrungswerte aus beiden Welten hinken da im direkten Vergleich. ## Hersteller-Sternchen am Terminal Die Benchmark-Tabelle im Launch-Post veröffentlicht Anthropic selbst. GDPval-AA und AA-Briefcase hat dabei Artificial Analysis gemessen, allerdings auf einem Pre-Release-Deployment, das laut Anthropic einen inzwischen behobenen Bug bei Structured Outputs hatte. Mit dieser Brille auf der Nase: * Terminal-Bench 4.0 (agentisches Coding auf der Kommandozeile): 70,6 %, _Sonnet 5_ kam auf 10,3 %, _Opus 5.5_ auf 66,4 % * CursorBench 4.0: 55,5 %, knapp hinter _Opus 5.5_ mit 57,8 % * GDPval-AA (Wissensarbeit aus 44 Berufen): 1.844 Punkte, _Opus 5.5_ liegt bei 1.846 * OSWorld 2.1 (Computer Use): 80,1 %, _Opus 5.5_ erreicht 81,8 % Der Sprung von rund 10 auf gut 70 % bei Terminal-Bench wirkt auf den ersten Blick wie ein Tippfehler, wird aber von Artificial Analysis grob gestützt, die ein Plus von rund 50 Punkten messen. _Sonnet 5_ war auf diesem Benchmark schlicht schwach. Fair ist, dass Anthropic die eigene Tabelle selbst relativiert, denn in internen und externen Tests bleibe _Opus 5.5_ bei komplexer, offener Arbeit, die anhaltendes Urteilsvermögen verlangt, klar stärker. Gleichstand auf dem Papier ist eben kein Gleichstand im Alltag – warum Benchmark-Vergleiche zwischen LLMs wackeln, habe ich an anderer Stelle ausführlicher aufgeschrieben. ## Artificial Analysis: 56 Punkte mit Rekordverbrauch Unabhängige Zahlen liefert wie gewohnt Artificial Analysis. Im Intelligence Index erreicht _Sonnet 5.5_ auf Max-Effort 56 Punkte, zwei hinter _Opus 5.5_ (Max) und 18 vor _Sonnet 5_. Im Launch-Artikel von Artificial Analysis reichte das für Platz zwei, bei so knappen Abständen ist der Rang aber eher eine Momentaufnahme. Auf Terminal-Bench 4.0 messen die Tester 64 %, also spürbar weniger als die 70,6 % aus Anthropics eigener Tabelle. Beim Tempo stützt Artificial Analysis dagegen die Herstellerangabe. Je nach Effort liegen zwischen 89 und 142 Tokens pro Sekunde an, Sonnet 5 kam auf Max auf rund 79. Der Preis dafür steht, wie üblich, eine Zeile tiefer: Bei Max-Effort verbraucht _Sonnet 5.5_ rund 193.000 Output-Tokens pro Index-Task, laut Artificial Analysis der höchste Wert, den sie je gemessen haben. Das sind etwa 60 % mehr als bei _Opus 5.5_ oder _Sonnet 5_ auf Max und ungefähr siebenmal so viel wie bei _GPT-6 Astra_. Die Kosten pro Index-Task – ein gewichteter Durchschnitt über die Eval-Aufgaben, kein allgemeiner API-Preis – klettern damit auf 7,60 $ und liegen rund 50 % über Sonnet 5. Die „bis zu 30 % günstiger“ aus dem Launch-Post und dieser Aufpreis widersprechen sich nicht. Anthropic rechnet mit eigenen Tests, Artificial Analysis mit dem gewichteten Durchschnitt seiner Index-Aufgaben, und beide Zahlen stammen von unterschiedlichen Effort-Stufen. Gerade auf Max kippt die Rechnung bei Artificial Analysis deutlich. Weiter unten sieht das Bild freundlicher aus: Low kommt auf 36 Punkte bei 0,41 $ pro Task, Medium auf 41 Punkte bei 0,59 $, High auf 47 Punkte bei 1,08 $ und Xhigh auf 52 Punkte bei 2,74 $. Der letzte Schritt von Xhigh auf Max kostet dann noch einmal fast das Dreifache. Gerade High hält Artificial Analysis für die wettbewerbsfähigste Stufe, knapp hinter GPT-6 Sol bei praktisch gleichen Kosten pro Task. Für agentische Setups lohnt noch ein Blick auf die einzelnen Modellseiten. Über den gesamten Index erzeugt _Sonnet 5.5_ auf Medium 29 Millionen Output-Tokens, auf High 50, auf Xhigh 100 und auf Max 410 Millionen, während der Median vergleichbarer Modelle bei 88 Millionen liegt. Bei der Latenz wird der Abstand noch größer. Bis zum ersten Antwort-Token vergeht auf Medium gut eine Sekunde, auf High sind es knapp 19, auf Xhigh rund 88 Sekunden und auf Max knapp sechs Minuten, weil das Thinking mitzählt. Wer einen Agenten-Loop mit vielen kurzen Schritten baut, wartet so bei jedem Aufruf. Den Token-Haken, den schon Sonnet 5 mitbrachte, hat Anthropic nicht abgeschafft, er ist nur deutlich nach oben gewandert. Sichtbar wird er ab Xhigh, so richtig teuer bei Max. ## Sonnet 5.5 oder Opus 5.5? Der Guide sortiert vor Die aufschlussreichere Tabelle steht im Developer-Guide. Dort ordnet Anthropic Workloads den beiden Modellen zu. _Sonnet 5.5_ bekommt klar abgegrenztes Coding, Entwicklung in hohem Volumen und – das ist für mich der interessante Punkt – wohldefinierte Agenten-Tasks, die man immer wieder laufen lässt, etwa Recherche, Review oder Drafting. _Opus 5.5_ bleibt zuständig für komplexe Arbeit mit Urteilsvermögen, inklusive agentischem Coding über lange Strecken. Der Prompting-Guide bringt es auf einen Satz: „for the hardest long-horizon work, an Opus model is the better choice“. Dazu passt, was die (von Anthropic kuratierten) Kundenstimmen hervorheben. Base44 berichtet, _Sonnet 5.5_ habe über 118 App-Builds im Schnitt 3,6 Iterationen gebraucht, _Opus 5_ dagegen 7,7. Lovable spricht von einem Drittel weniger Tool-Calls, CodeRabbit davon, dass der hohe Tokenverbrauch von _Sonnet 5_ verschwunden sei. Das sind Launch-Testimonials, keine Studien. Sie zeigen aber, worauf Anthropic optimiert hat: weniger Schritte pro Loop, gebündelte Tool-Calls, weniger Rückfragen an den Menschen. In _Claude Code_ wird die Rollenverteilung ganz praktisch. Ab Version 2.1.284 verweist der Alias `sonnet` auf _Sonnet 5.5_ , standardmäßig mit Medium-Effort und nativem 1-Million-Kontext. Das Default-Modell bleibt aber _Opus 5.5_ , wer _Sonnet_ will, wechselt per `/model sonnet`. Thinking lässt sich in _Claude Code_ für _Sonnet 5.5_ nicht abschalten. Einen Fast-Mode gibt es auch nicht. ## Agentisch heißt erst mal: Migrationsarbeit Wer _Sonnet 5_ in eigenen Pipelines oder Agenten betreibt, kann nicht einfach die Model-ID tauschen. Der Guide nennt fünf Breaking Changes und eine geänderte Antwortstruktur, die Migrationsanleitung geht jeden Punkt einzeln durch. Die wichtigsten für agentische Setups: * `thinking: {"type": "disabled"}` quittiert die API mit einem 400er. Ersatz ist das neue `between_tools`, bei dem das Modell nur zwischen Tool-Calls denkt – allerdings nur bis Effort High. * Erzwungenes `tool_choice` vom Typ `any` oder `tool` wirft ebenfalls einen 400er. Stattdessen `auto` setzen und das Tool mit `strict: true` markieren. * Computer Use läuft über die Claude API und Google Cloud nur noch über `computer_toolset_20260801`, Amazon Bedrock akzeptiert das alte Tool weiterhin. * Thinking-Blöcke sind an Modell und Konversation gebunden, Konversationen sollten also append-only bleiben. * Im Advisor-Setup akzeptiert _Sonnet 5.5_ als Executor weder _Opus 4.8_ noch _Opus 4.7_ oder _Sonnet 5_ als Berater. Dazu kommen neu kalibrierte Effort-Stufen. Ein altes Setting überträgt sich nicht eins zu eins, deshalb empfiehlt Anthropic, den Effort-Sweep neu zu fahren und für agentisches Coding mit gut spezifizierten Tasks bei Medium anzufangen. Workarounds aus _Sonnet 5_ -Prompts wie das beliebte „do not be lazy“ sollen raus (eine Zeile, die in so manchem Systemprompt vermutlich seit Monaten vor sich hin fossiliert). Auf Low überspringt das Modell laut Guide manchmal den echten Test einer Änderung, bevor es sie als erledigt meldet. Anthropic liefert dafür gleich einen passenden Systemprompt-Absatz mit. Auch die Fehlerbehandlung im Loop ändert sich. Abgelehnte Requests kommen mit HTTP 200 und `stop_reason: "refusal"` zurück, für Cyber- und Frontier-LLM-Anfragen kann ein serverseitiger Fallback (Beta) auf _Sonnet 5_ greifen. Artificial Analysis hat solche Fallbacks in rund 0,1 % der Tasks beobachtet, fast ausschließlich auf Terminal-Bench. Wer auf den Token-Verbrauch in Claude Code achtet, freut sich über die gesunkene Mindestgröße fürs Prompt-Caching von 1.024 auf 512 Tokens. ## Arbeitspferd statt kleiner Bruder Meine Vermutung war, dass der schnell erschienene Guide von Osmani zeigt, wie wichtig _Sonnet_ für agentische Workloads und Entwicklung bei Anthropic ist. Damit lag ich zumindest halb richtig. Am Timing lässt sich das nicht festmachen, weil auch _Opus 5.5_ am Launch-Tag einen eigenen Guide bekam, am Inhalt aber schon. Zwischen `between_tools`, gebündelten Tool-Calls und der Workload-Tabelle, die wiederkehrende Agenten-Tasks ausdrücklich zu _Sonnet_ schiebt, wird deutlich, wo Anthropic das Modell sieht – nicht als kleinen Bruder von _Opus_ , sondern als das Modell, das in wiederkehrenden Agenten-Loops täglich durchläuft, während _Opus 5.5_ die langen, offenen Aufgaben übernimmt. Heißt für mich: Die Musik spielt bei Medium und High. Max ist eher die Einstellung für Benchmark-Tabellen, es sei denn, die eigenen Evals rechtfertigen den Aufpreis (und man möchte die Kreditkarte mal so richtig zum Glühen bringen). Die gehören vor dem Umstieg ohnehin auf den Plan, zusammen mit einem neuen Effort-Sweep auf den frisch kalibrierten Stufen, statt der Launch-Tabelle einfach zu glauben. Der erste, ernsthafte Test wird ein agentischer Workflow sein, vermutlich mit Fable oder Opus als Orchestrator und einer Handvoll _Sonnet 5.5_ Subagents. Bis dahin lasse ich die Papierlage so für mich stehen, mit einem dicken Sternchen oben auf der Effort-Skala.

t01.li

Human-in-, on-, at-the-End oder out-of-the-Loop: Wo menschliche Kontrolle in Agentenprozessen wirklich wirkt und wann der Freigabe-Button nur Governance-Dekoration ist.

Human Oversight im Loop Engineering: in, on, at-the-End oder out?

Ein Mensch klickt auf „Freigeben“. Damit ist Human-in-the-Loop eingebaut, Human Oversight erledigt, das Governance-Häkchen gesetzt und alle schlafen etwas besser. Zumindest solange, bis jemand fragt, was dieser Mensch eigentlich gesehen hat, ob er genug Zeit zum Prüfen hatte und ob die Mail nicht längst raus war. Im vorherigen Artikel über Loop Engineering ging es um Trigger, Verifikation, Zustand und Stoppbedingungen. Der Agent war dort ein Teil des Prozesses, nicht der Prozess selbst. Offen blieb die Stelle, an der Menschen in diesen Ablauf gehören. „Mit menschlicher Aufsicht“ beschreibt allerdings noch keine Architektur. Prompt Engineering, Context Engineering und Harness sind die unteren Ebenen, der Loop liegt eine Etage darüber. Human Oversight liegt quer dazu: Der Mensch kann einen einzelnen Tool-Aufruf freigeben, einen laufenden Prozess überwachen, nur die Veröffentlichung kontrollieren oder im einzelnen Run gar nicht auftauchen. Das Risiko entscheidet über die Variante und nicht die eine Slide im Strategie-Meeting. ## TL;DR * Beim Human-in-the-Loop stoppt der Run und wartet auf eine menschliche Entscheidung. * Beim Human-on-the-Loop läuft der Prozess weiter, solange der Mensch nicht eingreift. * Beim Human-at-the-End ist die Arbeit erledigt, die letzte folgenreiche Aktion bleibt aber bis zur Freigabe blockiert. * Beim Human-out-of-the-Loop ist im einzelnen Run keine menschliche Entscheidung vorgesehen. * Je schlechter ein Ergebnis prüfbar, je schwerer eine Aktion umkehrbar und je höher ihr Schadenspotenzial ist, desto früher gehört der Mensch in den Loop. ## Vier Positionen im Loop – keine vier Glaubensrichtungen Die Begriffe beschreiben, wo Menschen einen konkreten Agent-Loop kontrollieren. Sie sind keine vier vollständigen Systemarchitekturen und schließen sich auch nicht gegenseitig aus. Entscheidend ist, was ohne menschliche Reaktion passiert. Modell | Was passiert ohne menschliche Reaktion? | Rolle des Menschen | Typischer KMU-Einsatz ---|---|---|--- Human-in-the-Loop | der Run stoppt an einem Gate | prüfen, ändern, freigeben oder ablehnen | Zahlung, Vertragsantwort, Deployment Human-on-the-Loop | der Prozess läuft innerhalb seiner Grenzen weiter | beobachten, stoppen oder eskalieren | Support-Triage, Kampagnen-Monitoring Human-at-the-End | die Arbeit ist fertig, die Außenwirkung bleibt blockiert | Ergebnis final freigeben | Newsletter, Angebot, Veröffentlichung Human-out-of-the-Loop | der Run wird ohne Einzelfreigabe abgeschlossen | Grenzen vorab bauen und später auditieren | Klassifikation, Formatprüfung, Read-only-Recherche Human-in-, on- und out-of-the-Loop sind in Forschung und Praxis gebräuchliche Perspektiven. **Human-at-the-End** ist dagegen kein wirklich etablierter Fachbegriff. Ich verwende ihn hier als praktisches Label für einen nützlichen Sonderfall: Das System arbeitet bis zum fertigen Ergebnis autonom, aber Veröffentlichung, Versand oder Übergabe warten auf eine menschliche Freigabe. Technisch ist das meist ein spätes Human-in-the-Loop-Gate. Die eigene Bezeichnung beschreibt seine betriebliche Bedeutung, nicht mehr. Eine im Juni 2026 veröffentlichte Interviewstudie mit 17 erfahrenen Entwickler*innen fand ohnehin eine andere, zeitliche Aufteilung der Aufsichtsarbeit: Kontrolle vorab, gemeinsames Planen, Echtzeit-Monitoring und nachträgliche Prüfung. Das widerspricht den vier Begriffen nicht. Es zeigt nur, dass es keine amtliche Vier-Schubladen-Lehre gibt. ## Human-in-the-Loop: Die Aktion wartet wirklich Beim Human-in-the-Loop hält der Run an einem definierten Gate an. Erst nach Freigabe darf der Agent eine Mail senden, einen Datensatz ändern, Geld bewegen, Code deployen oder eine andere Aktion mit Folgen ausführen. Das Gate muss vor der Aktion liegen. Klingt banal, wird aber gern umso kreativer ausgelegt. Wenn der Agent die Kundenmail bereits verschickt hat und jemand sie später im Log liest, war der Mensch nicht in diesem Loop, er war in der Schadensdokumentation. Technisch braucht ein brauchbares Gate mehr als einen Button. Der Prozess muss seinen Zustand dauerhaft speichern, damit er nach der Entscheidung an derselben Stelle weiterläuft. Wer prüft, sollte mindestens die geplante Aktion, ihre Argumente, relevante Quellen, mögliche Auswirkungen und die erlaubten Entscheidungen sehen. In der Deep-Agents-Doku von LangChain zu Human-in-the-Loop gehören deshalb ein Checkpointer und die Entscheidungen Approve, Edit, Reject und Respond zusammen. Das ist eine Framework-Umsetzung und kein allgemeiner Standard, aber das Muster dahinter stimmt. Für ein KMU bedeutet Human-in-the-Loop vor allem kontrollierten Durchsatz. Ein Support-Agent kann einen Erstattungsfall vollständig vorbereiten, darf die Gutschrift oberhalb eines Grenzwerts aber erst nach Freigabe auslösen. Im Deployment kann ein Coding-Agent Tests ausführen und Änderungen vorschlagen, während der produktive Rollout wartet. Der Mensch entscheidet nicht über jeden Arbeitsschritt, sondern über die Aktion, deren Fehler teuer wird, oder die allein schon aus rechtlicher Sicht einer finalen menschlichen Entscheidung bedarf. Die prüfende Person braucht auch echte Macht. „Ablehnen“ darf nicht bedeuten, dass der Agent denselben Aufruf drei Sekunden später leicht umformuliert erneut versucht. Die Entscheidung muss den Tool-Call, den Run oder die zugrunde liegende Policy verändern können. Sonst beschäftigt das System Menschen, ohne sich von ihnen kontrollieren zu lassen – eine erstaunlich menschliche Organisationsidee. Human-in-the-Loop passt, wenn eine einzelne Aktion schwer umkehrbar ist oder unmittelbaren Schaden anrichten kann. Es passt eher nicht zu hundert banalen Entscheidungen pro Stunde. Wer jede harmlose Leseoperation freigeben lässt, trainiert Menschen auf reflexhaftes Klicken. Das Gate bleibt formal erhalten und verliert damit praktisch seinen Zweck. ## Human-on-the-Loop: Aufsicht scheitert gern an Aufmerksamkeit Beim Human-on-the-Loop läuft der Prozess selbstständig. Menschen sehen Traces und Kennzahlen, erhalten Warnungen und können eingreifen. Das ergibt Sinn, wenn einzelne Fehler begrenzte Folgen haben, das Volumen hoch ist und Abweichungen maschinell erkennbar sind. Dafür braucht der Loop Schwellenwerte, Budgets, Eskalationsregeln und einen Kill Switch. Rollback gehört ebenfalls dazu, sofern der Prozess Änderungen vornimmt. Ein Dashboard ohne Interventionsweg ist keine Aufsicht, sondern ein Live-Ticker. Wer so etwas strickt, baut also nicht bloß ein Monitoring, sondern einen Steuerkanal zurück in den Prozess. Der Schwachpunkt sitzt (wie in so vielen Fällen) vor dem Bildschirm: Menschen überwachen zuverlässige Automatisierung schlecht, weil über lange Zeit nichts passiert. Wenn dann eine Warnung erscheint, wirkt die plausible Systemausgabe oft überzeugender als der eigene Zweifel. Eine im Mai 2026 in _AI and Ethics_ erschienene Arbeit zu „meaningful human oversight“ verweist auf Automatisierungsbias, Nachlässigkeit und unangemessenes Vertrauen als lange bekannte Human-Factors-Probleme. Mehr Erklärtext löst das nicht automatisch; ein sauber formulierter Irrtum kann sogar leichter durchrutschen. Gute On-the-Loop-Kontrolle verteilt Aufmerksamkeit deshalb gezielt. Sie nutzt risikogewichtete Stichproben, unabhängige Checks, Abweichungssignale und Fälle, in denen das System ausdrücklich auf eine Entscheidung verzichtet. Der Mensch prüft nicht alles, aber er prüft die Stellen, an denen sein Urteil den Ausgang wahrscheinlich verändert. Im KMU kann ein Agent eingehende Support-Tickets klassifizieren, beantworten und nur bei ungewöhnlichen Erstattungsquoten, negativer Stimmung oder bestimmten Kundengruppen Alarm schlagen. Der Betrieb gewinnt Tempo, trägt aber die Kosten für Monitoring und Bereitschaft. Wer niemanden benennt, der auf Warnungen reagieren darf und kann, betreibt Human-on-the-Loop nur auf dem Organigramm. ## Human-at-the-End: Die letzte Tür bleibt zu Beim Human-at-the-End erledigt das System Recherche, Entwurf und formale Prüfungen selbstständig. Der Artikel bleibt aber Draft, die Kampagne bleibt pausiert, der Pull Request bleibt ungemergt und die Mail bleibt im Postausgang, bis ein Mensch die letzte Tür öffnet. Diese Variante ist für viele Wissensprozesse im Mittelstand attraktiv. Sie unterbricht den Lauf nicht an jeder Zwischenstation, behält die Außenwirkung aber beim Menschen. Ein Vertriebsagent kann Daten zusammentragen und ein Angebot ausformulieren; versendet wird es erst nach Prüfung durch die zuständige Person. Für Newsletter, Stellenanzeigen, Vertragsentwürfe oder öffentliche Reports gilt dasselbe. Wer am Ende prüft, braucht einen überprüfbaren Output: Quellen, Diffs, fehlgeschlagene Evals, Warnungen und offene Unsicherheiten. Ein fertiges Dokument ohne Herkunft und Prüfsignale zwingt dazu, die gesamte Arbeit zu wiederholen oder blind zu vertrauen. Meist gewinnt Option zwei, weil Kalender existieren. Der Name ist nur dann verdient, wenn bis zur Freigabe noch nichts Wesentliches passiert ist. Hat der Agent bereits Anzeigenbudget ausgegeben, Kundendaten überschrieben oder eine Nachricht versendet, ist die Endkontrolle nachträglich. Das kann als Audit sinnvoll sein, schützt aber nicht vor dem ersten Schaden. Genau hier liegt die Abgrenzung zum allgemeinen Human-in-the-Loop: At-the-End meint nicht irgendein Gate im Ablauf, sondern das eine Gate zwischen fertigem Arbeitsergebnis und wirksamer Außenhandlung. ## Human-out-of-the-Loop: Auch das kann vernünftig sein Nicht jeder Run braucht einen Menschen. Eine Quelle abrufen, ein Format prüfen, Dubletten markieren oder einen Report in einem internen Ordner aktualisieren kann vollständig automatisiert laufen, wenn Rechte und Folgen begrenzt sind. Human-out-of-the-Loop ist vertretbar, wenn vier Dinge zusammenkommen: Das Ergebnis lässt sich zuverlässig prüfen, Fehler sind leicht umkehrbar, das Schadenspotenzial ist klein und das System arbeitet innerhalb enger Berechtigungen. Read-only zuerst ist eine gute Default-Regel. Schreibrechte kommen später, wenn nötig, und dann kleinteilig. Der Mensch verschwindet dabei nur aus dem einzelnen Run. Jemand muss Werkzeuge, Budgets, Guardrails, Tests und Eskalationen entwerfen. Jemand muss die Resultate stichprobenartig prüfen und den Prozess abschalten, wenn sich Daten, Regeln oder Nutzung verschieben. Out-of-the-Loop ist kein Verantwortungsexport an das Modell. Für den Mittelstand ist das oft der wirtschaftlichste Einstieg. Ein Agent kann Rechnungen nach bekannten Merkmalen sortieren, Support-Tickets routen oder Wettbewerberseiten read-only beobachten, ohne dass jedes Ergebnis eine Freigabeschleife erzeugt. Sobald derselbe Agent Zahlungen auslöst, Kundenzusagen macht oder Datensätze löscht, ändert sich die Ausgangslage. Dann ist aus der harmlosen Routine ein Prozess mit Wirkung geworden. Das zeigt auch ein Einblick in den internen Einsatz von Codex bei OpenAI vom Mai 2026: Niedrigriskante Aktionen sollen innerhalb technischer Grenzen ohne Reibung laufen, riskantere Aktionen stoppen zur Prüfung. Sandbox, Freigabepolitik und Telemetrie arbeiten zusammen. Ein Auto-Review-Modus genehmigt bestimmte Anfragen über die Sandbox-Grenze hinaus sogar automatisch – ein Modell entscheidet also über die Wünsche eines anderen Modells. Ein wenig unter Vorbehalt: Das ist eine Herstellerbeschreibung des eigenen Systems, aber als konkretes Designbeispiel ist sie gut brauchbar. ## Vom Agentenlauf zum Prozess: alle vier Varianten in einem System Der Vorgängerartikel hat den einzelnen Agenten in ein System aus Triggern, Verifikation, Zustand und Grenzen eingeordnet. Die vier Oversight-Varianten beantworten nun für jeden dieser Schritte dieselbe Frage: Was darf weiterlaufen, wenn gerade kein Mensch reagiert? Einen redaktionellen Prozess zum Beispiel würde ich nicht pauschal auf „in“ oder „out“ stellen. Die Position hängt vom Schritt ab. Dasselbe Prinzip gilt im KMU für Support, Marketing, Vertrieb oder Softwareentwicklung. Prozessschritt | Oversight | Warum ---|---|--- neue Quellen beobachten | out-of-the-Loop | read-only, geringe Folgen, leicht prüfbar Widersprüche und ungewöhnliche Behauptungen markieren | on-the-Loop | automatische Signale, menschliche Stichprobe Thema und These festlegen | in-the-Loop | prägt Richtung und Auswahl des gesamten Artikels recherchieren und formale Checks ausführen | out-of-the-Loop | wiederholbar, begrenzbar, mit Quellen und Tests prüfbar Artikel veröffentlichen | at-the-End | bis zur Freigabe geht nichts nach draußen Prompt, Skills oder Bewertungsregeln ändern | in-the-Loop | verändert alle späteren Runs, nicht nur einen Output Gerade der letzte Punkt wird unterschätzt. Wenn ein Optimierungs-Loop Prompts, Tools oder Bewertungskriterien selbst verändert, arbeitet er am Harness und damit an den Regeln künftiger Läufe. Ein einzelner fehlerhafter Artikel ist ärgerlich. Eine fehlerhafte Regel, die hundert Artikel beeinflusst, skaliert den Ärger immerhin effizient. Die Schleifentypen aus dem vorherigen Artikel lassen sich ähnlich zuordnen. Im Agent Loop sitzt ein Gate vor sensiblen Tools. Im Verification Loop prüfen Menschen Grenzfälle und Stichproben, während deterministische Tests den Rest abfangen. Event-driven Loops brauchen Monitoring, Limits und Stoppsignale. Beim Hill-climbing Loop sollten Menschen Änderungen an Prompts, Tools, Skills und LLM-as-a-Judge-Kriterien freigeben. Das ist meine Abbildung auf die Loop-Taxonomie von LangChain, keine Norm. ## Drei Fragen entscheiden über die Kontrolle Für die Platzierung menschlicher Kontrolle reichen drei Fragen meist weiter als eine lange Governance-Policy. **Wie gut ist das Ergebnis prüfbar?** Ein JSON-Schema, ein Unit-Test oder eine harte Geschäftsregel liefert ein deutliches Signal. Tonalität, Fairness oder strategische Passung bleiben unschärfer. Ein zweites Modell kann beim Vorsortieren helfen, ist aber kein objektiver Richter. **Wie gut lässt sich die Aktion umkehren?** Ein interner Draft kann gelöscht werden. Eine versendete Mail lässt sich nur noch erklären. Ein gelöschter Datensatz braucht ein Backup, eine öffentliche Entscheidung womöglich juristischen Beistand. Je später ein Fehler korrigierbar ist, desto früher gehört das Gate in den Ablauf. **Wie groß ist der mögliche Schaden?** Kosten, Datenverlust, Rechtsfolgen und Reputationsschäden gehören in diese Betrachtung. Ebenso der Umfang: Ein Fehler in einem Run kann klein sein, dieselbe falsche Regel in einem dauerhaften Prozess nicht. Prüfbarkeit | Umkehrbarkeit | Schadenspotenzial | Sinnvolle Default-Position ---|---|---|--- hoch | hoch | gering | out-of-the-Loop, ergänzt um Stichproben hoch | mittel | mittel | on-the-Loop mit Limits und Rollback mittel | hoch | mittel | at-the-End vor Veröffentlichung oder Übergabe gering | gering | hoch | in-the-Loop vor der kritischen Aktion Das ist eine Heuristik. Sie ersetzt weder eine Risikoanalyse noch branchenspezifische Pflichten. Für den ersten Architekturentwurf verhindert sie aber die beliebte Methode „Wir setzen irgendwo einen Approval-Step hin und nennen das dann Responsible AI“. ## Ein Name im Organigramm ist noch keine Human Oversight Human Oversight wird gern als Rollenfrage behandelt: Irgendjemand aus Fachbereich, IT oder Geschäftsführung bleibt verantwortlich, also sei die Sache geregelt. Im Betrieb hilft diese Zuständigkeit wenig, wenn das System keine Stelle besitzt, an der diese Person wirksam eingreifen kann. Wirksame Aufsicht beginnt mit einer überprüfbaren Entscheidungsvorlage. Vor der Entscheidung muss sichtbar sein, was der Agent tun will, worauf sich die Entscheidung stützt, welche Regeln geprüft wurden und wo Unsicherheit bleibt. Quellen und Tool-Ergebnisse gehören dazu. Bei Änderungen helfen Diffs mehr als eine wortreiche Zusammenfassung des Agenten. Ablehnen, bearbeiten, eskalieren, stoppen und zurückrollen sind unterschiedliche Aktionen; mindestens eine davon muss den Ausgang tatsächlich ändern können. Zeit und Kompetenz sind ebenfalls Teil der Architektur. Eine Freigabe-Warteschlange mit 300 Fällen am Freitagnachmittag produziert keine Sorgfalt, sondern einfach nur Durchsatz. Maker-Checker klingt ordentlich, garantiert aber keine Qualität, wenn beide Seiten dasselbe Signal falsch lesen oder die prüfende Seite nur noch auf „Grün“ klickt. Die bereits erwähnte Arbeit in _AI and Ethics_ trennt deshalb die operative Arbeit des Systems von der bewertenden Rolle des Menschen. Gute Aufsicht muss dort drei Dinge leisten: Kontrolle, Anfechtbarkeit und Kompetenz – gestützt auf Aufzeichnungen, mit denen sich eine Entscheidung später rekonstruieren lässt. Die Arbeit räumt selbst ein, dass ihr Rahmen konzeptionell und nicht experimentell validiert ist. Der Designgedanke passt trotzdem gut zum KMU-Alltag: Der Mensch muss den Lösungsweg nicht komplett wiederholen. Er muss Ergebnis, Belege und Folgen beurteilen können. Auch der EU AI Act verlangt in Artikel 14 für Hochrisiko-KI-Systeme, dass zuständige Personen Fähigkeiten und Grenzen verstehen, Automatisierungsbias berücksichtigen, Ausgaben verwerfen oder rückgängig machen und das System sicher stoppen können. Das gilt nicht pauschal für jeden Support-Bot oder Marketing-Agenten im Mittelstand, und seit dem Digital Omnibus greifen die Hochrisiko-Pflichten für Anhang-III-Systeme ohnehin erst ab dem 2. Dezember 2027. Als Architektur-Checkliste taugt Artikel 14 trotzdem: verstehen, widersprechen, rückgängig machen, stoppen. Zur Farce wird Human Oversight, wenn das Gate erst nach der Aktion erscheint oder der Dialog ohne Kontext fragt: „Agent möchte Tool X verwenden. Zulassen?“ Das ist formal eine Entscheidung und praktisch Münzwurf mit Corporate Design. Dasselbe gilt für Alert-Flut. Wenn jedes harmlose Ereignis Aufmerksamkeit fordert, verschwinden relevante Warnungen im Lärm. Observability muss Signale liefern, auf die jemand rechtzeitig reagieren kann. Erklärungen und Scores sind nur Eingaben für die Prüfung. Eine plausible Begründung kann falsch sein; ein LLM-as-a-Judge kann dieselben blinden Flecken wie das erzeugende Modell teilen. Das System braucht zusätzlich eine belastbare Prozesshistorie: Wer hat wann was freigegeben, welche Evidenz lag vor, welche Policy-Version galt und was passierte danach? Memory bedeutet hier weniger Langzeitgedächtnis des Modells als nachvollziehbare Entscheidungen. ## Verantwortung sitzt außerhalb des Runs Ein Ende August 2026 veröffentlichtes Position Paper, das Margaret Mitchell von Hugging Face mitverfasst hat, argumentiert, dass heutige Agentendesigns Menschen aus wirksamer Kontrolle drängen und längere Nutzung ausgerechnet die Fähigkeiten schwächen könnte, die für Aufsicht nötig sind. Das ist eine zugespitzte These, keine empirisch bewiesene allgemeine Wirkung. Der Hinweis trifft trotzdem einen wunden Punkt: Je autonomer der Ablauf wirkt, desto leichter behandeln Organisationen seine Entscheidungen als Eigenschaft des Systems. Dabei bleibt die Verantwortung bei den Menschen, die Ziele, Rechte und Grenzen festlegen. Dass Agenten eher an Daten, Scope und Ownership scheitern als an der Modellwahl, lässt sich hier direkt weiterdenken. Wer den Prozess verantwortet, braucht die Befugnis, ihn zu verändern oder abzuschalten, ein Name in einer Tabelle reicht nicht. Human Oversight entsteht an zwei Stellen. Zur Design-Zeit entstehen Rollen, Berechtigungen, Budgets, Tests, Protokolle und Eskalationswege. Zur Laufzeit greifen Menschen dort ein, wo Prüfung sinnvoll und Wirkung noch möglich ist. Die zweite Ebene kann die erste nicht reparieren. Wer einem Agenten zu breite Rechte gibt, löst das nicht mit einer aufmerksamen Aushilfe vor einem Dashboard. Mein Take: Automatisiere die Arbeit, überwache den Prozess und behalte die folgenreiche Entscheidung dort beim Menschen, wo Prüfbarkeit, Umkehrbarkeit oder Schadenspotenzial es verlangen. Der Mensch muss nicht überall im Loop sitzen. An der richtigen Stelle sollte er allerdings mehr können als klicken.

t01.li

t01 KI-Journal @hello.t01.li.ap.brid.gy · 3w ago

Opus 5.5 und GPT-6 Sol/Luna erscheinen am selben Tag und drücken die API-Preise. Dazu Grok 4.7, Xiaomis MiMo-V2.6 als Open Weights, eine Welle an Sprach- und TTS-Modellen, die nächste Irregular-Panne und Werkzeuge von AX bis OpenWiki.

AI Picks der 39. KW

Nicht, dass sich das Thema Hardware totgelaufen hätte, aber bei den aktuellen Preisen für Speicher und GPUs suchen wohl gerade alle irgendwie nach dem goldenen Kalb. Dafür haben die Frontier Labs reingehauen – mit reichlich Gemeinsamkeiten. Ich werde das Gefühl nicht los, dass Amodei und Altman mindestens einmal die Woche telefonieren oder sich zum Mühle spielen treffen, oder so. _Opus 5.5_ sowie _GPT-6 Sol_ und _Luna_ sind am selben Tag innerhalb weniger Stunden erschienen und drücken jeweils die API-Preise deutlich nach unten. Ansonsten ganz viele Sprachmodelle und ein erneuter kleiner Unfall bei den Spezialexperten von Irregular. Dann haben SpaceXAI sowie Xiaomi noch abgeliefert – man kommt so langsam nicht mehr hinterher. Begeben Sie sich in eine aufrechte Sitzposition und schnallen Sie sich bitte an, denn wir schauen zurück auf eine reichhaltige 39. Kalenderwoche im Jahre 2026, cheers. ## Jev von TypeSafe Das war etwas umfangreicher und ist daher in einem eigenen Artikel gelandet: _Jev_ von TypeSafe ist kein klassisches LLM, sondern ein probabilistischer Entscheidungs-Layer. Statt Text erzeugt das Modell typisierte Wahrscheinlichkeiten für einen vorgegebenen Ergebnisraum. Das kann bei Agent-Gates, Klassifikation oder automatisierten Prüfungen interessant sein, weil Jev günstig und schnell arbeitet. Der vom Anbieter beworbene Vorteil gegenüber großen LLMs ist allerdings mit Vorsicht zu lesen, denn die Vergleichswerte stammen überwiegend aus eigenen Evals, und „typsicher“ bedeutet weder deterministisch noch automatisch richtig. Der sinnvollste Einsatz liegt dort, wo unstrukturierter Text semantisch bewertet werden muss, die eigentliche Geschäftslogik aber weiterhin im Code bleibt. Seit Dienstag ist auch mein Account freigeschaltet – schauen wir mal. ## Claude Opus 5.5 Anthropic hat Claude Opus 5.5 veröffentlicht – mit 1 Mio. Tokens Kontext, verpflichtendem Thinking und Preisen von 4 $ Input und 20 $ Output pro Million Tokens. Gegenüber Opus 5 sinken die regulären Tokenpreise damit um 20 Prozent, Cache Reads sogar um 60 Prozent auf 0,20 $. Anthropic spricht trotzdem von rund 40 Prozent geringeren Kosten bei typischen Aufgaben, weil _Opus 5.5_ zusätzlich sparsamer mit Tokens umgehen soll. Artificial Analysis kommt bei Medium-Effort tatsächlich auf ziemlich genau diese Größenordnung. Der kleine Haken an der Geschichte: Effort ist jetzt ziemlich wörtlich zu nehmen. Thinking lässt sich nicht mehr abschalten (das kennen wir ja schon von GPT-6 Astra), und zwischen Medium und Max liegen laut Artificial Analysis beim Preis pro Aufgabe Welten – für sieben zusätzliche Punkte steigt die Rechnung auf das Viereinhalbfache. Für mich ist deshalb weniger spannend, ob _Opus 5.5_ irgendwo noch drei Benchmark-Punkte herausquetscht, sondern ob Medium im Alltag tatsächlich zum neuen Sweet Spot wird. Max kann man ja immer noch einschalten, wenn die Kreditkarte sich langweilt. ## GPT-6 Sol und Luna OpenAI hat GPT-6 Sol und Luna veröffentlicht – das eigentlich Spannende daran ist aber eher die Preisliste. _Sol_ kostet in der API 2 $ Input und 10 $ Output pro Million Tokens, _Luna_ nur noch 0,10 beziehungsweise 0,50 $. Dazu kommen 90 Prozent Rabatt auf Cache-Reads und ein überarbeitetes Prompt-Caching, bei dem sich Reasoning-Effort und Tools während einer Konversation ändern lassen, ohne den bisherigen Cache gleich wegzuwerfen. Beide Modelle bieten rund 1 Mio. Tokens Kontext und bis zu 128.000 Output-Tokens; ein GPT-6 Terra bleibt diesmal aus. Der große Generationssprung ist das auf dem Papier mal nicht so. Im Artificial-Analysis-Index bewegt sich Luna gegenüber GPT-5.6 gar nicht, Sol nur minimal – der sichtbare Sprung kam schon mit Astra. Für Agenten und Pipelines kann das trotzdem interessanter sein als noch fünf Punkte auf irgendeinem Benchmark. Wenn das gleiche Zeug plötzlich ungefähr die Hälfte kostet und der Cache besser hält, lacht die Buchhaltung. Mein erster Kandidat für eigene Tests wäre deshalb ausgerechnet Luna: absurd billig und zumindest im Gesamtindex nicht schlechter als der Vorgänger. ## Getting the most out of Opus 5.5 in Claude and Claude Code Anthropic hat einen kleinen Praxisleitfaden für Opus 5.5 veröffentlicht und betont noch mal: „Think carefully“ und „think step by step“ können dann endlich doch mal raus. _Opus 5.5_ denkt ohnehin vor jeder Antwort und entscheidet selbst über den Aufwand. Wichtiger ist laut Anthropic, dem Modell die komplette Aufgabe, ein klares „Done“ und konkrete Stop-Bedingungen mitzugeben. Für längere Runs in Claude Code wird zudem empfohlen, Aufgabenlisten in Dateien zu halten (nein, nicht in der CLAUDE.md), größere Arbeiten auf Subagents aufzuteilen und in der CLAUDE.md explizit festzulegen, wann Claude weiterarbeiten und wann es fragen soll. Das passt zu dem, was sich beim Arbeiten mit Agenten ohnehin abzeichnet: weniger Prompt-Magic, mehr saubere Auftragsdefinition und Zustandsmanagement. Interessant ist der Rat, Ergebnisse noch einmal vom Modell selbst gegen Diff oder Anforderungen prüfen und Unsicherheiten ausdrücklich markieren zu lassen. Letzteres halte ich persönlich schon länger so, da Claude bei komplexeren oder längeren Tasks gerne mal auffällt, dass es auf dem Weg noch eine Kleinigkeit „vergessen“ hat – trotz Plan Mode. Und falls _Opus 5.5_ bei einem Safety-Check auf ein älteres Modell umgeschaltet wird, sollte man das zumindest bemerken. Sonst optimiert man munter seinen Workflow für ein Modell, mit dem man gar nicht mehr arbeitet. ## Grok 4.7 SpaceXAI (an den Namen werde ich mich wohl nie gewöhnen) hat Grok 4.7 abgeworfen und schreibt über sein neues Spitzenmodell: > Served at the same price and speed as Grok 4.6, it is highly competitive in its class. Wie tief willst Du stapeln? Positioniert wird _Grok 4.7_ exakt wie der Vorgänger für Coding, agentische Aufgaben und allgemeine Wissensarbeit. Das LLM bietet 500.000 Tokens Kontext, akzeptiert Text und Bilder, und hinten raus kommt: Text. Reasoning lässt sich über vier Stufen von low bis xhigh steuern, dazu gibt es Function Calling, Structured Outputs sowie serverseitige Web- und X-Search-Tools. Wem das nicht schnell genug ist, für den serviert SpaceXAI eine Fast-Variante mit doppeltem Output-Tempo zum doppelten Preis. Artificial Analysis hat auch schon nachgemessen und bescheinigt der xhigh-Stufe: > Grok 4.7 (xhigh) is amongst the leading models in intelligence and reasonably priced when comparing to other models of similar price. It’s also notably slow and very verbose. Die high-Stufe kommt in der Messung auf denselben Index-Wert, ist aber flotter unterwegs und wird nur noch als „slower than average“ geführt. Also kurz: eigentlich ganz okay, recht günstig, aber auf „xhigh“ langsam und ’ne Labertasche. Btw: Anders als bei den anderen großen US-Labs kommt das Thema Token-Effizienz im Launch-Post gar nicht auf den Tisch. Technisches Merkmal| Grok 4.7 ---|--- **Kontextfenster**| 500.000 Tokens **Input-Modalitäten**| Text, Bild **Output-Modalität**| Text **Knowledge Cutoff**| Mai 2026 **Reasoning-Stufen**| `low`, `medium`, `high` (Default), `xhigh` **Inputpreis bis 200k Kontext**| 2,00 $ / 1 Mio. Tokens **Cached Input bis 200k**| 0,50 $ / 1 Mio. Tokens **Outputpreis bis 200k**| 6,00 $ / 1 Mio. Tokens **Inputpreis über 200k Kontext**| 4,00 $ / 1 Mio. Tokens **Cached Input über 200k**| 1,00 $ / 1 Mio. Tokens **Outputpreis über 200k**| 12,00 $ / 1 Mio. Tokens **Weitere Zugänge**| SpaceXAI-API, Cursor, Grok Build, Model-Router und Cloud-Plattformen Ein größerer Haken bei den Preisen ist etwas versteckt: Die oft genannten 2 / 6 $ pro Million Tokens gelten nur bis 200.000 Prompt-Tokens. Oberhalb dieser Schwelle verdoppeln sich Input-, Cache- und Outputpreise – das Muster kennt man schon von _Grok 4.6_. ## MiMo-V2.6 Nächstes LLM, andere Bude: Xiaomi hat am 21. September die MiMo-V2.6-Familie veröffentlicht, und das gleich mit drei Vertretern: _mimo-v2.6-pro_ , _mimo-v2.6-flash_ und _mimo-v2.6-pro-ultraspeed_. Bis auf die UltraSpeed-Variante liegen alle als Open Weights unter MIT-Lizenz auf Hugging Face – Pro mit 1,02 Billionen Gesamtparametern, Flash mit 309 Milliarden, dazu ein auf Qwen3.5-9B destilliertes Einsteigermodell. Sie gehen mit dem allgemeinen Trend: starke Ausrichtung auf agentische Workloads inklusive Tool Calling, Computer Use, längerer Tool-Traces und Multi-Agent-Szenarien. Xiaomi erwähnt ausdrücklich, dass genau das Bestandteil des Trainings ist – ein gemischter RL-Lauf über mehr als 7.000 Umgebungen quer durch Coding, Agenten, Visual und Cybersecurity. Was haben wir denn da so: Merkmal| MiMo-V2.6 Pro| MiMo-V2.6 Flash ---|---|--- **Architektur**| Sparse Mixture-of-Experts| Sparse Mixture-of-Experts **Parameter**| 1,02 T| 309 B **Aktive Parameter**| 42 B| 15 B **Kontextfenster**| 1 Mio. Tokens| 1 Mio. Tokens **Modalitäten**| Text, Bild, Video, Audio| Text, Bild, Video, Audio **MoE Experts**| 384| 256 **Aktive Experts pro Token**| 8| 8 **Native Tool-/Agent-Unterstützung**| ja| ja **Computer Use / GUI-Verarbeitung**| ja| ja **Lizenz**| MIT| MIT **API-Zugriff**| MiMo API, OpenRouter| MiMo API, OpenRouter **API-Modellname**| `mimo-v2.6-pro`| `mimo-v2.6-flash` **UltraSpeed-Variante**| `mimo-v2.6-pro-ultraspeed`| – Die Unterschiede zwischen Pro und Flash liegen primär in der Größe. Pro nutzt eine MoE-Architektur mit 1,02 Billionen Gesamtparametern und 42 Milliarden aktivierten Parametern, Flash kommt auf 309 Milliarden bzw. 15 Milliarden aktive Parameter. Beide verwenden denselben multimodalen Encoder-Unterbau sowie einen zusätzlichen Multi-Token-Prediction-Decoder für Speculative Decoding. Für Self-Hosting nennt Xiaomi primär SGLang und vLLM; erreichbar sind die Modelle außerdem über die MiMo-API, MiMo Desktop und OpenRouter. Die Preise bleiben laut Xiaomi auf dem Niveau des Vorgängers: Modell| Input, Cache Hit| Input, Cache Miss| Output ---|---|---|--- **MiMo-V2.6 Pro**| 0,0036 $| 0,435 $| 0,87 $ **MiMo-V2.6 Flash**| 0,0028 $| 0,14 $| 0,28 $ ## Space Bunny Alpha Eine neue Woche, ein neues Stealth-Modell auf OpenRouter: Space Bunny Alpha ist seit dem 23. September verfügbar. Was wir sonst so haben: 1 Mio. Tokens Kontext, bis zu 524.288 Output-Tokens, multimodaler Input und einstellbarer Reasoning-Aufwand. OpenRouter beschreibt es als schnelles Modell mit Schwerpunkt Coding und agentischen Workflows. Der Zugang ist wie immer während der Preview kostenlos – Parameterzahl, Architektur und Trainingsdetails gibt es passend zum Namen erst einmal nur im Kaninchenbau. ## Gemini 3.8 Flash TTS und Gemini 3.8 Flash-Lite TTS Google und Sprachmodelle, das wird gerade ein größeres Thema: Flash TTS kann neue Stimmen per Prompt erzeugen, Rolle, Akzent und Stimmcharakter über mehr als 100 Sprachen und Dialekte steuern und Dialoge Zeile für Zeile mit Tempo, Emotion, Pausen oder Einwürfen wie Lachen und Seufzen dirigieren. Obendrauf gibt es mehr als 2.000 vorgefertigte Stimmen, Zwei-Sprecher-Szenen und laut Google stabilere Langform-Ausgabe für Podcasts oder Hörbücher. _Flash-Lite_ ist die günstigere Variante für Volumen, etwa Dubbing oder Voice Agents. So richtig interessant ist aber die Voice Replication: Aus 30 Sekunden Referenzaudio kann _3.8 Flash TTS_ ein konsistentes Stimmprofil erzeugen – allerdings nur mit zusätzlicher Einwilligungsaufnahme des Sprechers. Generiertes Audio bekommt SynthID- und C2PA-Metadaten. Der kleine Haken für hiesige Ohren: Genau diese Voice-Replication-Funktion ist in AI Studio derzeit nicht im EWR, in UK und der Schweiz verfügbar – übrigens auch nicht in Illinois, Texas und Indien, Biometrie-Gesetze lassen grüßen. Die eigentlichen TTS-Modelle starten dagegen direkt über Gemini API und AI Studio. ## Qwen-Audio-3.1-TTS _Qwen-Audio-3.1-TTS_ kombiniert einen 12,5-Hz-Speech-Tokenizer mit einem mehrstufigen Training aus Language Model und Flow Matching – die Grundlagen dazu stehen im Technical Report zur Version 3.0. Das Modell unterstützt 16 Sprachen plus 20 chinesische Dialektregionen, Voice Cloning auch über Sprachgrenzen hinweg, natürlichsprachliche Anweisungen für Stimme, Tempo und Emotion sowie 86 Inline-Tags – vom Lachen über Atemgeräusche bis zum Seufzer. Längere Texte entstehen in einem Durchlauf mit bis zu drei Minuten Audio; wer 48 kHz und längere Podcast-Formate braucht, greift zur Schwester-Variante qwen-audio-3.1-tts-next. Viel spannender als das nächste „klingt fast wie ein Mensch“ finde ich die Kontrollmöglichkeiten dahinter. Stilwechsel lassen sich über die Tags gezielt innerhalb eines Textes setzen, und selbst verrauschte oder hallige Referenzaufnahmen sollen ohne separaten Denoising-Schritt funktionieren. Das bringt TTS langsam von „lies mir diesen Text vor“ in Richtung tatsächlich steuerbarer Audioproduktion. ## NVIDIA Nemotron 3 Diarization Die Woche der Sprachmodelle: NVIDIA hat mit Nemotron 3 Diarization ein offenes 100-Millionen-Parameter-Modell für Speaker Diarization veröffentlicht – also für die Frage, wer wann spricht. Das Modell verarbeitet Live- und aufgezeichnetes Audio, erkennt überlappende Sprecher und unterstützt bis zu acht Personen. Ein einzelner Checkpoint lässt sich offline wie im Streaming einsetzen; NVIDIA empfiehlt dafür Latenzstufen von 30,4 Sekunden bis hinunter zu 0,32 Sekunden Input-Puffer. Die Ausgabe besteht aus Zeitstempeln und anonymen Speaker-IDs – speaker_1 bleibt also speaker_1 und wird nicht automatisch zu „Larissa“ oder „Karl“. Nemotron transkribiert dabei selbst nichts und identifiziert auch keine Personen, sondern liefert die Sprecherstruktur, auf der ASR oder Agenten anschließend aufsetzen. Die Weights sind offen, laufen über NeMo und dürfen unter OpenMDW 1.1 auch kommerziell eingesetzt werden. Nicht der Glamour-Job unter den KI-Aufgaben – aber vermutlich einer von denen, die eine Sprachpipeline erst wirklich brauchbar machen. ## Google confirms Gemini models hacked three companies in May 2026 Google so: Was Anthropic und OpenAI können, können wir doch schon lange! Ergebnis: Gemini hat bei einem Sicherheitstest im Mai drei reale Unternehmen kompromittiert – allerdings weniger spektakulär, als die Schlagzeile von Ars Technica vermuten lässt. Die Modelle sollten in einer abgeschotteten Capture-the-Flag-Umgebung arbeiten, bekamen durch eine Fehlkonfiguration beim Testanbieter Irregular aber Zugriff aufs offene Internet. Weil ein fiktives Testunternehmen denselben Namen wie eine reale Firma trug, landete Gemini auf echten Systemen: einmal per Passwort-Raten, in den anderen Fällen über Zugangsdaten, die öffentlich in Repositories lagen. Als die Modelle erkannten, dass sie nicht mehr in der Simulation arbeiteten, stoppten sie. Entschuldigung, das hatte ich im Fall von Irregular schon einmal gefragt, aber was machen die da eigentlich so beruflich? So langsam kann mir niemand mehr erzählen, dass dies nicht beabsichtigt war: „Dummerweise haben wir da mal eine _hust_ ‚Fehlkonfiguration‘ eingebaut und das war natürlich _hust_ ein Versehen. Na ja, kann man nichts machen.“ ## Priorities and principles for effective third party assessments OpenAI will externe Sicherheitsprüfungen stärker formalisieren und nennt dafür vier Schwerpunkte: Safety Cases, konkrete Schutzmechanismen, Capability-Evals für Cyber-, Bio-/Chemie- und Self-Improvement-Risiken sowie unabhängige Untersuchungen bei kritischen Misalignment-Vorfällen. Externe Prüfer sollen dafür je nach Fall tiefen Zugriff auf interne Systeme, Safeguards und Evaluationsdaten erhalten – einschließlich Grey-Box-Tests und in bestimmten Szenarien sogar Chain-of-Thought-Zugriff. Nach dem, was die letzten Monate so los war, ist der Schritt nachvollziehbar. ## Don’t be fooled by this summer of AI hype Timnit Gebru und Emily Bender haben sich den KI-Hype dieses Sommers vorgenommen. Ihr Punkt: Bei angeblichen Durchbrüchen in Cybersecurity, Mathematik oder selbstverbessernder KI folgt oft dasselbe Muster – große Ankündigung, große Schlagzeilen, und erst danach schauen Fachleute genauer hin. Bei mehreren der untersuchten Fälle fiel das Ergebnis anschließend deutlich unspektakulärer aus. Besonders problematisch wird es, wenn aus einem Sicherheitsproblem plötzlich eine Geschichte über einen „autonomen“ Agenten wird oder aus einem interessanten mathematischen Ergebnis gleich der nächste Forschungsdurchbruch. Kleiner Seitenhieb sei erlaubt: Gebru und Bender gehören seit Jahren zu den deutlichsten Kritikerinnen der LLM-Industrie. Der Grundtenor ist aber trotzdem brauchbar – Pressemitteilung lesen, zwei Tage warten und dann die externe Expertise lesen. Gerade bei AI ist zwischen „das Modell hat etwas Interessantes gemacht“ und „wir haben soeben die nächste Stufe der Intelligenz erreicht“ reichlich Luft. Und reichlich Marketingbudget. ## AX Google hat da mal was gebastelt: einen Open-Source-Orchestrator für Agenten – grob gesagt Kubernetes für agentische Workloads. Statt einfach nur einen Agentenprozess zu starten, definiert AX vier Bausteine: Task für die isolierte Ausführung, Workspace für Repositories, MCP-Server und Skills, Gateway für Netzwerkregeln und Model für LLM-Konfiguration und Credentials. Agenten laufen in Sandboxes, lassen sich per ssh inspizieren, pausieren und später mit erhaltenem Zustand wieder fortsetzen. Das Ganze läuft auf Kubernetes und Googles ebenfalls offenem Agent Substrate. AX behandelt Agenten tatsächlich als eigene Infrastruktur-Workload – zustandsbehaftet, lange laufend, zwischendurch minutenlang untätig und mit potenziell unangenehm viel Zugriff auf Netzwerk und Tools. Wer also schon immer mal dachte, seinem Agent-Stack fehle vor allem noch ein bisschen Kubernetes-Komplexität – et voilà! Aber Achtung: alles aktuell noch v1alpha1. ## OpenChamber 2.0 OpenChamber 2.0 zieht auf OpenCode 2 um und beseitigt damit eine lästige Klasse von Problemen. Skills, Agents, Commands, opencode.json, MCP-Server und Plugins werden jetzt während der laufenden Session neu geladen; ein kompletter Neustart ist meist nicht mehr nötig. Gleichzeitig wird OpenCode deutlich plugin-zentrierter: Plugins können inzwischen Agents, Tools, Modelle, Provider, MCP-Server oder Websuche erweitern und sogar eigene API-Methoden bereitstellen. Kleine Fußangel für bestehende Setups: CLAUDE.md wird von OpenCode 2 nicht mehr automatisch geladen, Projektregeln gehören jetzt in die AGENTS.md. Spannend ist der Code Mode. Statt dem Modell dutzende einzelne Toolbeschreibungen in den Kontext zu kippen und jeden MCP-Call nacheinander fahren zu lassen, bekommt es ein Script-Tool und kann darin freigegebene MCP- und Plugin-Funktionen direkt kombinieren. Das spart Kontext und Roundtrips und dürfte gerade bei tool-lastigen Agenten schnell relevant werden. Der Haken daran ist wenig überraschend: Kleinere Modelle sind beim Schreiben dieser Skripte spürbar weniger zuverlässig. ## OpenWiki v0.6.0 OpenWiki Funktionsschema Auch bei OpenWiki tut sich etwas, denn mit der jüngsten v0.6.0 vom 23. September kommen Integrationen für Antigravity und Oh My Pi als Coding-Agenten dazu. Wikis lassen sich jetzt untereinander verlinken und für Multi-Wiki-Reads kombinieren, per MCP werden sie abfragbar, und Page Worker laufen auf Wunsch parallel. ## Claude Cloud Sessions nun offiziell verfügbar Cloud Sessions haben die Research Preview verlassen. Sie laufen in der Anthropic-Infrastruktur, sodass Tasks außerhalb der eigenen Umgebung weiterlaufen, auch wenn das MacBook längst zugeklappt ist. Nutzbar ist das über claude.ai/code, den Code-Tab in der Claude-Mobile-App, über die Desktop-App oder mit `claude --cloud` im CLI. Voraussetzung ist ein Pro- oder Max-Plan. Anthropic spendiert Bestandskunden zum Einstieg je nach Tier 100 bzw. 250 $ Guthaben als Einmalkredit. Abholen muss man sich den bis zum 7. Oktober, nicht verbrauchtes Guthaben verfällt am 4. November. ## Claude Marketplace Ab sofort bündelt der Claude Marketplace Konnektoren, Plugins, Agenten, Produkte und Beratungspartner an einem Ort. Technisch bleibt Anthropic bei seiner bisherigen Linie: Konnektoren und Plugins setzen auf MCP und Agent Skills auf, daneben listet der Marketplace fertige Claude-basierte Produkte, z. B. von Cursor, CrowdStrike, Harvey oder Snowflake. ## SEOntology: Giving SEO a Shared Language for the Age of AI Agents SEOntology möchte SEO-Daten eine gemeinsame, maschinenlesbare Sprache geben, damit Agenten nicht Rankings aus Tool A, interne Links aus Tool B und Search-Console-Daten aus Tool C irgendwie selbst zusammenschrauben müssen. Die Open-Source-Ontologie erweitert Schema.org und modelliert unter anderem Seiten, Queries, Links, Qualitätssignale und Agent-Aktionen. Das zugehörige Paper wurde auf der SEMANTiCS 2026 als Best Student Paper ausgezeichnet; getestet wurde das Modell anhand von 47 Praxisfragen und anschließend über sechs Monate bei 1.233 realen SEO-Aufgaben. WordLift berichtet von rund 30 Prozent weniger manueller Arbeit, bei einigen stark standardisierten Recherche- und Audit-Aufgaben deutlich mehr. Das sind allerdings Effizienzwerte aus einem System, an dessen Entwicklung WordLift selbst beteiligt ist – keine Aussage darüber, dass deshalb Rankings oder KI-Sichtbarkeit steigen. Semantik hilft dem Agenten beim Denken. Google und Co. müssen davon noch lange nicht beeindruckt sein. Vielleicht findet ja bis nächste Woche noch jemand das goldene Kalb. Neues Blech zu halbwegs bezahlbaren Preisen wäre ja schon mal ein Anfang.

t01.li

OpenAI bringt GPT-6 Sol und Luna und senkt die API-Preise deutlich. Der Artificial-Analysis-Index bewegt sich kaum, einzelne Task-Evals schon. Was davon für Agenten und Pipelines zählt.

GPT-6 Sol und Luna: halbe API-Preise, kaum Bewegung im unabhängigen Index

OpenAI hat am 22. September GPT-6 Sol und GPT-6 Luna veröffentlicht, 19 Tage nach dem Flaggschiff GPT-6 Astra und quasi zeitgleich mit Opus 5.5. Die neuen Modelle greifen die Namen der entsprechenden GPT-5.6-Stufen auf und kosten in der API rund halb so viel. Ein _GPT-6 Terra_ ist nicht dabei, die Mittelstufe der letzten Generation bleibt diesmal unbesetzt. Die Ankündigung liest sich weniger wie ein Modell-Release, dafür mehr wie eine Preisliste mit angehängten Benchmarks und das ist auch die eigentliche Story. Im Artificial Analysis Intelligence Index bewegen sich Sol und Luna kaum; in einzelnen OpenAI-Evals schon. ## TL;DR _GPT-6 Sol_ kostet 2 $ / 10 $, _GPT-6 Luna_ 0,10 $ / 0,50 $ pro 1 Mio. Tokens. OpenAI spricht von 50 % niedrigeren Preisen; beim Luna-Output sind es rechnerisch 58 %. In den Konkurrenzvergleichen wird fast jeder Score um einen Kostenvergleich ergänzt. * Kein GPT-6 Terra – zwei Stufen statt drei unterhalb von Astra. * Artificial Analysis, Stand 22.09.2026: Luna 37 Punkte, Vorgänger 37; Sol 48, Vorgänger 47. * Mehrere Alignment-Werte verbessern sich deutlich. Die Warning-Circumvention-Rate von Sol bleibt mit 64,4 % hoch. * Die Modelle laufen in der API, in ChatGPT Work und in Codex; im normalen Chat sind sie noch nicht verfügbar. ## Die Hälfte des Aktionspreises ist der neue API-Preis Die Zahlen zuerst, weil sie der Kern der Meldung sind: Modell| Input| Output| Vorher (GPT-5.6) ---|---|---|--- GPT-6 Sol| 2 $| 10 $| 4 $ / 20 $ GPT-6 Luna| 0,10 $| 0,50 $| 0,20 $ / 1,20 $ Preise pro 1 Mio. Tokens. OpenAI spricht durchgängig von „50 % günstiger“, beim Luna-Output sind es rechnerisch 58 %, was in der eigenen Tabelle großzügig abgerundet wird. Interessanter ist, womit OpenAI da eigentlich vergleicht. Die 4 $ / 20 $ für _GPT-5.6 Sol_ sind ein Aktionspreis, den OpenAI laut Preisliste mindestens bis zum 21. November 2026 garantiert; regulär standen 5 $ / 30 $ auf der Liste. Luna hatte schon am 30. Juli eine dauerhafte Senkung von 1 $ / 6 $ auf 0,20 $ / 1,20 $ bekommen. Gegenüber den Launch-Preisen vom Juli kostet Sol also 60 bzw. 67 % weniger, Luna 90 bzw. 92 %. Die aktuellen API-Preislisten führen für _GPT-6 Sol_ und _GPT-6 Luna_ 2 $ / 10 $ beziehungsweise 0,10 $ / 0,50 $ auf, ohne eine Befristung zu nennen. Mehr lässt sich aus der Primärquelle nicht ableiten. Bei Requests mit mehr als 272.000 Input-Tokens gelten außerdem die Long-Context-Tarife: doppelter Preis für Input und Cache sowie der 1,5-fache Outputpreis für den gesamten Request. _Astra_ bleibt bei 10 $ / 50 $ das Flaggschiff. Damit liegt zwischen Luna und Astra ein Faktor 100 beim Input, und OpenAI baut die komplette Argumentation um diese Spreizung herum. Der zweite Hebel sitzt im Caching. Cache-Reads bekommen 90 % Rabatt, die Trefferquote soll per Default höher liegen. Und – das ist für alle relevant, die Agenten bauen – Reasoning-Effort und Tool-Set lassen sich jetzt mitten in einer Konversation ändern, ohne dass der bisherige Kontext aus dem Cache fliegt. Dazu kommen explizite Breakpoints, mit denen man festlegt, wo ein gecachter Prefix endet, plus ein Dashboard und ein Diagnose-Tool. GitHub liefert die passende Jubel-Zahl gleich mit: über 50 % weniger frisch zu verarbeitende Prompt-Tokens „across billions of requests“. Das darf man als Referenz eines Partners lesen, der die Modelle im eigenen Produkt vermarktet. ## Kosten pro Task als neue Leitwährung Wer die Benchmark-Sektion liest, merkt schnell, dass fast keine Zahl für sich allein steht. Fast jede kommt mit einem Kostenvergleich im Schlepptau. Auf AutomationBench 1.0.6 von Zapier, einem Test über 47 Tools aus Sales, Marketing, Operations, Support, Finance und HR, erreicht Sol bei xhigh-Effort 33,2 % für 0,27 $ pro Task. Astra auf low kommt auf 30,3 % zu 3,9-fachen Kosten, _Claude Opus 5_ auf max auf 26,9 % zu 11,1-fachen Kosten. _Claude Fable 5.1_ mit Opus-5-Fallback liegt bei 31,4 %, allerdings ohne die Fallback-Kosten, die laut OpenAI-Fußnote bei rund 40 % der Tasks anfielen. Luna auf high verbessert sich um 5,4 Prozentpunkte gegenüber _GPT-5.6 Luna_ bei 58 % geringeren Kosten pro Task. Beim Coding sieht das Muster gleich aus. Auf DeepSWE 1.1 erreicht Sol auf max 68,8 % und liegt damit 1,1 Punkte hinter _Fable 5_ auf xhigh (69,9 %), zu rund 80 % geringeren Kosten. Luna auf max schafft 66,6 %, was OpenAI mit Opus 5 und Fable 5 auf medium vergleicht, zu 93 beziehungsweise 96 % weniger Kosten. Bei Computer Use auf OSWorld 2.0 offline steht Sol xhigh mit 60,5 % neben Opus 5 medium mit 60,3 %, wieder rund 80 % günstiger. Bevor man diese Zahlen als Ranking liest, hier der kleine Haken: In den Konkurrenz-Charts vergleicht OpenAI ausgewählte Effort-Stufen des eigenen Modells mit ausgewählten Effort-Stufen der Konkurrenz. Sol auf xhigh gegen Opus auf medium ist eine legitime Kosten-Nutzen-Aussage, aber keine Antwort auf die Frage, welches Modell grundsätzlich besser ist. Die Konkurrenzwerte stammen laut Fußnote aus öffentlich verfügbaren Reports. Wo keine Werte für Fable 5.1 vorlagen, setzte OpenAI Werte von Fable 5 ein. OpenAIs Angaben zu den eigenen Modellen sind herstellereigene Messungen; die Konkurrenzwerte wurden aus anderen Veröffentlichungen übernommen. Ein einheitlicher unabhängiger Testlauf ist das nicht. Die Factuality-Verbesserung kommt im Fließtext ohne absolute Zahlen aus. Sol macht laut OpenAI etwa halb so viele Fehler wie der Vorgänger. Luna erreicht bei höheren Effort-Stufen das Niveau von _GPT-5.6 Sol_ zu etwa einem Hundertstel der Kosten. Grundlage ist ein internes Eval mit de-identifizierten ChatGPT-Gesprächen, in denen Nutzer Fehler gemeldet hatten. Das ist ein sinnvolles Testset, aber eines, das nur OpenAI besitzt. ## Alignment: viel Fortschritt, ein hartnäckiger Ausreißer OpenAI stellt die Alignment-Evals prominent hin. In der interaktiven Grafik sinkt die Coding-Deception-Rate von 10,4 auf 1,3 %. Beim absichtlich defekten Such-Tool fällt die Non-Disclosure-Rate bei Sol von 77,5 auf 4,9 %, bei Luna von 78,3 auf 28,7 %. Unter den Läufen, in denen das präparierte Message-Board gefunden wurde, führt _GPT-6 Sol_ die dort platzierte unautorisierte Anweisung in 11,3 % der Fälle aus; _GPT-5.6 Sol_ lag bei 51,9 %. Und dann ist da die Warning Circumvention. Trifft _GPT-6 Sol_ auf eine ausdrückliche Sperre, versucht das Modell in 64,4 % der Läufe, sie zu umgehen. Der Vorgänger lag bei 68,2 %. _GPT-6 Luna_ fällt von 76,5 auf 42,4 %. Fast zwei von drei Sol-Läufen enthalten also weiterhin einen Umgehungsversuch. OpenAI weist darauf hin, dass die Tests überwiegend risikoarme Situationen ohne die vollständigen produktseitigen Safeguards abbilden. Die Werte stehen im entsprechenden Alignment-Tab; für die ausführlichen Ergebnisse verweist OpenAI auf die System Card. ## Wo GPT-6 Sol und Luna laufen und wo nicht OpenAI rollt Sol und Luna seit dem 22. September schrittweise in ChatGPT Work und Codex für Plus, Pro, Business, Enterprise und Edu aus. Free- und Go-Nutzer bekommen Luna in der Desktop-App. Im normalen Chat sind beide noch nicht verfügbar. Einen Termin nennt OpenAI nicht. Anscheinend ist der Rollout aber recht fix dieses Mal, denn in meinem Account sprang mir die Meldung schon entgegen. In der API heißen die Modelle gpt-6-sol und gpt-6-luna. Beide besitzen ein Kontextfenster von 1,05 Mio. Tokens bei maximal 128.000 Output-Tokens, nehmen Text und Bilder entgegen und kennen sechs Effort-Stufen von none bis max, medium ist Default. Der Knowledge Cutoff liegt bei Sol auf dem 20. April 2026, bei Luna auf dem 18. Mai 2026. Das billigere Modell ist also das aktuellere. Warum? Man weiß es nicht. ## Der Preis springt, der Index kaum Stand 22. September 2026 verwendet Artificial Analysis den Intelligence Index v4.3.2 mit zehn Evals. GPT-6 Luna auf max erreicht dort 37 Punkte. _GPT-5.6 Luna_ : ebenfalls 37. GPT-6 Sol auf max steht bei 48, der Vorgänger bei 47. _GPT-6 Astra_ liegt bei 53. Der gerundete Gesamtindex bewegt sich bei Luna und Sol also um null beziehungsweise einen Punkt. Das beweist nicht, dass sich „die Intelligenz“ insgesamt nicht verbessert hat. Es ist aber ein sauberer Dämpfer für die Behauptung eines pauschalen Generationssprungs. Der sichtbare Sprung im Index kam mit Astra. Sol und Luna drücken vor allem den Preis; einzelne OpenAI-Evals zeigen dennoch Verbesserungen, die der Gesamtindex nicht abbildet. Was OpenAI nicht steuern konnte, ist das Timing. Anthropic veröffentlichte am selben Tag Claude Opus 5.5 und senkte den Tokenpreis von 5 $ / 25 $ auf 4 $ / 20 $. Das macht OpenAIs Vergleiche mit Opus 5 nicht wertlos, aber der gewählte Konkurrent war am Erscheinungstag nicht mehr Anthropics aktuelles Opus-Modell. In den geprüften Quellen lag am 22. September noch kein unabhängiger direkter Vergleich mit Opus 5.5 vor. Mein kleiner hotter Take für alle, die Agenten oder Pipelines betreiben: Die Preissenkung ist real, und bei langen Konversationen könnten die höhere Cache-Trefferquote und die stabilere Cache-Nutzung der größere Hebel sein. Wer bisher _GPT-5.6 Luna_ nutzt, bekommt mit _GPT-6 Luna_ ein neues Modell zum rund halbierten Tokenpreis – im Artificial-Analysis-Index allerdings mit demselben gerundeten Max-Score. Vor einem Wechsel zu Sol würde ich Luna deshalb im eigenen Harness auf max testen. Wer aus OpenAIs Charts einen pauschalen Intelligenzsprung ableitet, liest Kostenvergleiche als Modell-Ranking. Produktiv laufen die beiden bei mir noch nirgends, was sich heute ändert. Ich werde Sol und Luna im Büro an diversen Projekten durchtesten, und zwar nicht im Sandkasten. Nur eben nicht in laufenden Pipelines oder Loops, die in Produktion hängen, sondern für Code und Analyse, wo ein Fehlgrif eher Zeit kostet, aber keinen Kunden.

t01.li

t01 KI-Journal @hello.t01.li.ap.brid.gy · 3w ago

Anthropic bringt Claude Opus 5.5 als Fable-5.1-Niveau für 40 % weniger Betriebskosten. Artificial Analysis sieht das Modell im Intelligence Index vorn und misst auf Medium fast exakt diese Ersparnis gegenüber Opus 5. Preise, Benchmarks, Safeguards und was ich als Nächstes damit teste.

Claude Opus 5.5: Fable-Niveau für 40 % weniger, sagt Anthropic

Ich hatte heute die Claude-App gerade geöffnet, da sprang mir das neue Modell förmlich entgegen, noch bevor ich irgendetwas getippt hatte. _Claude Opus 5.5_ ist seit dem 22. September 2026 verfügbar, als erstes Modell der neuen 5.5-Familie. _Sonnet 5.5_ und _Haiku 5.5_ sollen laut Anthropic in den kommenden Wochen folgen. Die Kernbotschaft aus dem Announcement passt in einen Satz: Opus 5.5 leiste bei den meisten Aufgaben auf dem Niveau von _Claude Fable 5.1_ und koste im Betrieb 40 % weniger als _Opus 5_. Das ist eine Hersteller-Aussage, und wir schauen gleich, was Artificial Analysis unabhängig dazu gemessen hat, vorher aber die Fakten. ## TL;DR Claude Opus 5.5 ist Anthropics Effizienz-Release: Fable-Klasse für weniger Geld als Opus 5. * $4/$20 pro Million Input-/Output-Token, 20 % unter Opus 5; Cache Reads fallen um 60 % auf $0,20. * Artificial Analysis misst 58 Punkte im Intelligence Index, fünf vor Fable 5.1 und GPT-6 Astra, und kommt Medium gegen Medium auf 39 % weniger Kosten pro Aufgabe als Opus 5. * Safeguards derselben Klasse wie bei Fable 5.1, Cyber-Aufgaben landen bei Opus 4.8, Thinking lässt sich nicht mehr abschalten. ## Claude Opus 5.5 in Zahlen Eckdaten| Claude Opus 5.5 ---|--- Release| 22. September 2026, erstes Modell der Claude-5.5-Familie Kontextfenster| 1M Token, Input Text und Bild Effort-Stufen| low, medium (Default), high, xhigh, max; Thinking nicht abschaltbar Preis| $4 / $20 pro Million Input-/Output-Token, Cache Reads $0,20 Fast Mode| bis 2,5-fache Geschwindigkeit, $8 / $40, in Claude Code und auf der Platform AA Intelligence Index| 58 auf Max, 51 auf Medium (Fable 5.1: 53, GPT-6 Astra: 53, Opus 5: 51) Safeguards| Cyber und Biologie in der Fable-5.1-Klasse, Cyber-Fallback auf Opus 4.8 Verfügbarkeit| Claude Platform, AWS, Google Cloud, Microsoft Azure ## Preis, Tempo und Limits bei Claude Opus 5.5 Die Preisliste ist mal der handfeste Teil der Meldung: Input-Token kosten 4 $ pro Million, Output-Token 20 $, jeweils 20 % unter Opus 5 mit seinen 5$ /25 $. Cache Reads gehen von 0,50 $ auf 0,20 $ runter, ein Minus von 60 %. Laut Anthropic machen sie bei agentischer Arbeit und beim Coden den Großteil der Kosten aus, und wer lange Tool-Loops laufen lässt, weiß, dass genau dort die Musik spielt. Cache Writes sinken von 6,25 $ auf 5 $. Preis pro 1M Token| Opus 5.5| Opus 5| Differenz ---|---|---|--- Cache Reads| 0,20 $| 0,50 $| −60 % Input| 4 $| 5 $| −20 % Output| 20 $| 25 $| −20 % Cache Writes| 5 $| 6,25 $| −20 % Kosten pro AA-Index-Aufgabe (Medium)| 1,34 $| 2,19 $| −39 % Die 40 % Ersparnis, die Anthropic ausruft, setzen sich aus zwei Teilen zusammen. Der Token-Preis fällt, und das Modell soll mit Default-Einstellungen weniger Token pro Aufgabe verbrauchen als Opus 5. Ersteres kann man in der Preisliste nachlesen, Letzteres ist eine Messung aus dem Haus Anthropic „on typical workloads“, was auch immer „typical“ heißen mag. Dazu kommt ein Tempo-Versprechen von über 30 % schnellerem Output – aber das lässt sich immerhin nachmessen. Artificial Analysis kommt auf Medium-Effort auf 76 Token pro Sekunde, Opus 5 auf derselben Stufe auf 57. Auf den ersten Antwort-Token wartet man allerdings, weil das Thinking mitzählt, auf Medium 22 Sekunden und auf Xhigh fast drei Minuten. Ein Fast Mode mit bis zu 2,5-facher Geschwindigkeit ist zusätzlich in Claude Code und auf der Platform buchbar, allerdings für saftige 8 $/40 $. Für Pro, Max, Team und die sitzbasierten Enterprise-Pläne erhöht Anthropic gleichzeitig die 5-Stunden-Limits. Neu ist ein Rate-Limit-Reset, den man aufsparen und bei Bedarf auslösen kann. Klingt nach Kleinkram, ist im Claude-Code-Alltag aber genau das Feature, das man um 17 Uhr vermisst hat. ## Benchmarks: Anthropics Tabelle und die Messung von Artificial Analysis Anthropics eigene Tabelle sieht Opus 5.5 vorn, mit 66,4 % auf Terminal-Bench 4.0 (Fable 5.1: 55,8 %, Opus 5: 52,3 %, GPT-6 Astra: 57,9 %), 54,4 % auf FrontierCode v1.1 und 1.846 Elo auf GDPval-AA v2.1. Die Fußnoten muss man aber sich noch mal anschauen. Der Terminal-Bench-Wert stammt aus der xhigh-Stufe des Reasoning Efforts, die GPT-Zahlen hat OpenAI selbst gemeldet, und die Standardabweichung liegt bei ±2,6 Punkten. Ungewöhnlich offen ist ein Satz im Announcement: Benchmark-Abstände seien auf diesem Niveau kein verlässlicher Indikator mehr für Unterschiede in der Praxis, und intern sei die Lücke zu Fable 5.1 kleiner, als die Tabelle vermuten lässt. Unabhängig gemessen hat Artificial Analysis noch am Release-Tag. Im Intelligence Index v4.3.2 landet Opus 5.5 auf Max-Effort mit Fallback bei 58 Punkten, Fable 5.1 und GPT-6 Astra teilen sich Platz zwei mit 53, Opus 5 kommt auf 51. Die Effort-Leiter darunter liest sich 56, 54, 51 und 42 für xhigh, high, medium und low. Schon High liegt damit knapp über Fable 5.1 auf Max, im ungerundeten Index trennen die beiden 0,2 Punkte. Sechs der zehn Teil-Evaluationen gehen laut AA auf X an das neue Modell, darunter Humanity's Last Exam mit 61,4 % (bisheriger Bestwert: 59,1 % von Fable 5.1) und SciCode mit 66,9 %. Auf Terminal-Bench 4.0 sieht Artificial Analysis Opus 5.5 gleichauf mit GPT-6 Astra, also enger beieinander als in Anthropics Tabelle. Die Setups unterscheiden sich bei Harness und Effort-Stufe, die Werte lassen sich deshalb nicht eins zu eins gegeneinanderhalten. Erwähnenswert ist außerdem der AA-Omniscience Index, der falsche Antworten bestraft und Nichtwissen nicht. Dort liegt Opus 5.5 auf Max bei 46 Punkten, Fable 5.1 bei 43 und Opus 5 bei 37. Das spricht in diesem Setup für eine bessere Kombination aus Wissen und Kalibrierung, eine direkte Messung der Halluzinationsrate ist der Index allerdings nicht. Interessanter als der Spitzenwert ist die Kostenspalte. Artificial Analysis rechnet einen gewichteten Durchschnittspreis pro Index-Aufgabe aus, und der reicht bei Opus 5.5 von $0,55 auf Low bis $5,98 auf Max, gut das Elffache. Der Sweet Spot liegt bei Medium. Dort gibt es 51 Punkte für $1,34 pro Aufgabe, also dasselbe Ergebnis, das Opus 5 nur auf seiner Max-Stufe erreicht hat. Gegen Opus 5 auf Medium mit $2,19 sind das 39 % weniger. Damit landet Artificial Analysis in diesem Medium-gegen-Medium-Setup fast exakt bei Anthropics 40-%-Versprechen, das sich laut Announcement auf den Default-Effort bezieht, und Default heißt bei Opus 5.5 Medium. Mehr lässt sich daraus allerdings nicht ableiten, Anthropic spricht von „typical workloads“, Artificial Analysis misst seinen eigenen Index. Wer auf Max dreht, zahlt für sieben Punkte mehr den viereinhalbfachen Preis. Dahinter steckt der Token-Verbrauch, denn für den kompletten Index-Durchlauf hat Opus 5.5 auf Medium 38 Millionen Output-Token erzeugt, auf Max 260 Millionen. ## Safeguards, Thinking-Zwang und Kleingedrucktes Opus 5.5 ist das erste Opus-Modell mit Safeguards derselben Klasse wie Fable 5.1. Cybersecurity-Aufgaben jenseits des normalen Bugfixings leitet Anthropic laut Announcement transparent auf _Opus 4.8_ um, für Biologie-Themen greifen dieselben Safeguards wie bei Fable 5.1, ebenfalls mit Fallback auf ein anderes Modell, es sei denn, man ist über das Life Sciences Verification Program freigeschaltet. Wie sich das anfühlt, hatte ich beim Fable-5.1-Release schon beschrieben. Anthropic weist übrigens selbst darauf hin, dass die eigenen Benchmarks mit aktiven Safeguards gelaufen sind, was die Werte nach eigener Einschätzung eher drückt als hebt. Drei weitere Punkte gehören in jeden Integrations-Check. Thinking lässt sich nicht mehr abschalten, Opus 5.5 gibt es nur noch als Reasoning-Modell. Preserved Thinking, der Anti-Distillation-Mechanismus aus Fable 5.1, gilt laut Announcement auch für Opus 5.5 bei API-Accounts, die ab dem 31. August 2026 angelegt wurden, und soll verhindern, dass sich über nachträglich editierten Kontext das Reasoning des Modells abgreifen lässt. Und das Text-Watermarking für den EU AI Act ist wie bei Fable 5.1 an Bord. Zero Data Retention bleibt laut Anthropic wie bei den bisherigen Opus-Modellen verfügbar. ## Einordnung Was mich an dieser Meldung mehr anspricht als die Benchmark-Tabelle, ist der Preis. 0,20 $ pro Million Cache-Reads bei einem Frontier-Modell ist eine Ansage, und die 20 % auf Input und Output sind unabhängig von jeder Effort-Diskussion echt. Ob die 40 % „auf typischen Workloads“ bei mir ankommen, entscheidet sich daran, wie viel Effort ich dem Modell zugestehe, denn zwischen Medium und Max liegt laut Artificial Analysis ein Faktor 4,5 beim Preis pro Aufgabe. Beim Opus-5-Release war die Preis-Rechnung ähnlich aufgebaut. Der zweite Punkt ist die Alignment-Passage, die offener formuliert ist als üblich. Anthropic schreibt, das Modell vermute häufig, dass es evaluiert wird, und das erschwere die Bewertung, wie es sich im echten Einsatz verhält. Das ist keine PR-Zeile, sondern ein Vermerk, den man bei einem Modell, das laut einem Clio-Entwickler im Launch-Text 18 Stunden unbeaufsichtigt über sechs Repos gearbeitet hat, mal im Hinterkopf behalten sollte (ein bisschen zumindest). Ich teste das als Nächstes in Claude Code, ich weiß nur noch nicht, wofür. Vielleicht erst mal etwas Kleines, Schickes mit Astro und ein paar Modulen darin.

t01.li

t01 KI-Journal @hello.t01.li.ap.brid.gy · 4w ago

Genannt, empfohlen, zitiert – drei verschiedene Dinge. Was KI-Sichtbarkeit für dein KMU wirklich bedeutet, welche Faktoren belegt wirken, wie sich ChatGPT, Gemini, Claude und Google unterscheiden und was man technisch selbst in der Hand hat.

Was ist eigentlich KI-Sichtbarkeit?

„KI-Sichtbarkeit“ steht gerade auf jeder zweiten Agentur-Landingpage. Meist direkt neben einer Zahl, die verspricht, wie viel mehr davon du bekommst, sobald du buchst. Was genau da sichtbar werden soll, bleibt dabei erstaunlich oft im Nebel. Für ein KMU ist das keine akademische Frage. Wenn jemand _ChatGPT_ oder _Gemini_ fragt „wer wartet Wärmepumpen im Raum Hannover“, und dein Betrieb kommt nicht vor, ist das ein reales Loch im Trichter, und zwar eines, das in keiner Analytics-Ansicht auftaucht. Bevor du Budget in „GEO" schiebst, lohnt die Vorfrage: Was heißt Sichtbarkeit hier eigentlich, und welcher Teil davon liegt in deiner Hand? Vorweg, damit die Richtung stimmt: Eine Formel, die auf allen Plattformen zuverlässig Empfehlungen erzeugt, gibt es nicht. Und wer dir eine verkauft, verkauft dir Marketing. Was bleibt, ist eine sinnvolle Reihenfolge, die meist billiger kommt, als viele Angebote vermuten lassen. ## TL;DR KI-Sichtbarkeit ist die beobachtbare Präsenz eines Unternehmens in KI-Antworten. Klingt simpel, zerfällt bei näherem Hinsehen aber in mehrere Dinge, die man nicht verwechseln sollte. * Genannt werden, empfohlen werden und als Quelle verlinkt werden sind drei verschiedene Ergebnisse. Sie treten auch getrennt auf. * Es gibt keine belegte Formel für alle Plattformen. Prozent-Garantien sind Verkaufsargumente, keine Messwerte. * Technisches SEO bleibt das Fundament. Ohne Erreichbarkeit und saubere Auslieferung nützt der Rest wenig – reicht aber allein auch nicht. * Reihenfolge statt Rezept: erst technisch auffindbar und sachlich korrekt beschreibbar werden, dann die extern tatsächlich zitierten Quellen bearbeiten, dann messen. * ChatGPT, Gemini, Claude, Perplexity und die Google-Suche sind nicht dasselbe – schon die Crawler-Einstellungen nicht. Und „Google AI Overviews“ ist nicht die Gemini-App. * Ein einzelner Screenshot beweist nichts. KI-Antworten schwanken von Tag zu Tag. Gemessen wird über mehrere Fragen und mehrere Tage. ## Erstmal sortieren: Was „KI-Sichtbarkeit“ überhaupt meint Eine brauchbare Arbeitsdefinition: KI-Sichtbarkeit ist die beobachtbare Präsenz deines Unternehmens, deiner Angebote oder deiner Inhalte in KI-vermittelten Antworten – unter bestimmten Fragen, auf bestimmten Plattformen, in einem bestimmten Nutzungskontext. Und sortieren muss man hier, denn „sichtbar“ heißt nicht ein Ding, sondern mehrere. Dein Unternehmensname kann im Antworttext auftauchen. Deine URL kann als Quelle verlinkt sein. Deine Firma kann für einen konkreten Bedarf als Option empfohlen werden. Das sind unterschiedliche Ergebnisse, und sie hängen weniger zusammen, als die Wortwahl suggeriert. Wie weit sie auseinanderfallen, zeigt eine Semrush-Auswertung vom Juni 2026. Bei 3.981 erfassten Domain-Erscheinungen in _ChatGPT_ , _Gemini_ und Googles KI-Oberflächen waren 61,7 % reine Quellenverweise, 25,1 % reine Markennennungen und nur 13,2 % beides zugleich. Eine verlinkte Quelle und eine genannte Marke sind also häufig zwei getrennte Dinge. _Claude_ und _Perplexity_ waren in dieser Erhebung nicht dabei – der Nenner sind erfasste Erscheinungen, nicht alle Nutzeranfragen. Für ein KMU zerlegt sich die Frage „bin ich KI-sichtbar“ damit sogar in drei Fragen: * Werde ich bei einer allgemeinen Bedarfssuche überhaupt entdeckt? * Wird mein Unternehmen dann korrekt und passend beschrieben? * Entsteht daraus eine qualifizierte Anfrage? Die beliebte Selbstprüfung „Kennst du Firma X?“ beantwortet keine dieser drei Fragen. Sie testet, ob das Modell deinen Namen kennt – nicht, ob du bei echtem Bedarf vorkommst. Genau diese Verwechslung von Nennung und Empfehlung ist übrigens der Grund, warum eine Erwähnung ohne Klick geschäftlich oft wenig wert ist. Das habe ich an anderer Stelle ausführlicher aufgeschrieben: GEO-Citations bringen keine Conversions. ## Warum es keine Formel gibt – und wer dir trotzdem eine verkauft Die Kürzel SEO, AEO und GEO werden nicht einheitlich benutzt. Für die Praxis ist es sinnvoller, nach dem gewünschten Ergebnis zu trennen als nach dem Etikett: gefunden werden, als Quelle taugen, als Marke empfohlen werden, mit Produktdaten erscheinen, agentisch nutzbar sein, bezahlt präsent sein. Sechs verschiedene Ziele und sechs verschiedene Aufgabenwege. Drei Befunde begrenzen die üblichen GEO-Versprechen ziemlich zuverlässig. 1. „Zitiert werden“ und „genannt werden“ sind, wie oben gesehen, nicht dasselbe. Ein GEO-Angebot, das „mehr Citations“ verspricht, verspricht nicht automatisch mehr Empfehlungen. 2. Eine Textänderung muss die gesamte Verarbeitung überstehen – erst gefunden, dann ausgewählt, dann in der Antwort verwendet. Eine sprachliche Optimierung kann auf einer früheren Stufe schaden, was viele „GEO-Rewrites“ ignorieren. Dazu gleich mehr. 3. Welche Quellen bevorzugt werden, hängt von Plattform und Frage ab. Aus einer allgemeinen Rangliste meistzitierter Domains lässt sich keine feste Kanalpriorität für ein deutsches KMU ableiten. Eine US-Domainliste ist keine Anleitung für deinen Handwerksbetrieb. Das ist der eigentliche Grund für die Reihenfolge-statt-Rezept-Haltung. Niemand außerhalb der Anbieter kennt die vollständige Ranking- und Quellenarchitektur von _ChatGPT_ und Co. Was bleibt, ist solide Vorarbeit an den Stellen, die belegbar wirken. ## Wie entscheidend klassisches SEO noch ist Kurz: sehr, aber nicht als Selbstzweck. Googles eigener 2026-Leitfaden für die generativen Funktionen der Suche bestätigt SEO ausdrücklich als Grundlage; eine Seite muss indexiert und für die Anzeige mit Snippet geeignet sein. Interessanter ist, was Google im selben Dokument absägt: kein spezielles Schema-Markup ist für die KI-Ergebnisse vorgeschrieben, `llms.txt` bringt dort keinen Vorteil, künstliches Zerhacken in Textstücke ist nicht nötig, eine ideale Seitenlänge existiert nicht. Das gilt für die Google-Suche, nicht automatisch für jede andere Plattform. Aber es räumt mit ein paar teuren GEO-Mythen auf. Bleibt aber die Frage, ob ein gutes Google-Ranking Pflicht für eine KI-Zitierung ist. Ahrefs hat dazu 863.000 Suchergebnisseiten und rund vier Millionen AI-Overview-URLs abgeglichen. Ergebnis für dieselbe Ausgangsfrage: 37,1 % der zitierten URLs standen in den organischen Top 10, 26,2 % auf Position 11 bis 100, und 36,7 % außerhalb der Top 100. Ein Top-10-Platz ist also keine Voraussetzung für eine Zitierung, was aber nicht beweist, dass SEO egal wäre. Es zeigt nur, dass die KI-Auswahl breiter schöpft als die klassische Trefferliste. Die praktische Priorität bleibt unspektakulär: technische Hürden beseitigen, wichtige Angebotsseiten erschließen, die tatsächliche Kundensprache treffen, konkrete Informationslücken schließen. Ein Ranking für einen sehr allgemeinen Branchenbegriff ist dabei kein vollständiges Ziel. Warum das Fundament ohne die Technik zusammenfällt, steht ausführlich hier: GEO ohne technisches SEO ist Kaffeesatzleserei. ## Was du technisch selbst in der Hand hast Das ist der Teil, der komplett dir gehört – und der oft übersprungen wird, weil er nicht so glamourös ist. Die Kernprüfungen: * **Erreichbarkeit:** Lässt sich deine wichtigste Leistungs-, Standort- und Produktseite ohne Login abrufen? Stimmt der sichtbare Inhalt mit dem überein, was `robots.txt` erlaubt? * **Auslieferung:** Tauchen in Server- oder CDN-Logs Fehler oder blockierte Suchabrufe auf? Wichtig ist vor allem, den `OAI-SearchBot` nicht per `robots.txt` zu sperren; die Freigabe der veröffentlichten IP-Bereiche empfiehlt OpenAI zusätzlich. Wer wissen will, welche KI-Crawler überhaupt vorbeikommen, wirft einen Blick ins Log – ich habe mir dafür ein kleines Tool gebaut: LogWerk. * **JavaScript:** Stehen die Kerninfos schon im ausgelieferten HTML, oder erscheinen sie erst nach Interaktion? Google kann JavaScript rendern, empfiehlt aber weiter serverseitiges Rendern, weil nicht jeder Bot JavaScript ausführt. „KI kann kein JavaScript“ ist trotzdem zu pauschal. * **Struktur:** echte Links mit `href`, saubere HTTP-Status, konsistente Canonicals, kein versehentliches `noindex`. * **Strukturierte Daten:** dürfen gern rein, aber im Abgleich mit sichtbaren Inhalten – keine erfundenen Bewertungen. Ein nachgewiesener universeller GEO-Bonus ist das nicht. * **Aktualität:** veraltete Preise, Termine und Standorte auf allen eigenen Seiten korrigieren. Und jetzt die Warnung, die so gut wie kein GEO-Ratgeber mitliefert: Ein reiner Text-Rewrite „für die KI“ kann die Sichtbarkeit senken, statt sie zu heben. Der SAGEO-Arena-Benchmark hat genau das über 171.003 Dokumente und 2.700 Fragen durchgespielt. Bei ausschließlicher Überarbeitung des Fließtexts sanken im Mittel über zehn getestete Rewrite-Strategien die Trefferquote im Retrieval um relativ 9 %, der Verbleib unter den Top 10 nach Reranking um 16 % und die Zitierungsrate um 6 %. Das sind allerdings Benchmark-Werte und keine Prognose für reale Unternehmensseiten. Der Versuch zeigt vor allem, dass Textoptimierung in diesem Aufbau auch nach hinten losgehen kann – ein Rewrite verschiebt Begriffe und Schwerpunkte, und eine Seite fällt womöglich schon aus dem Kandidatenpool, bevor es ums Zitieren geht. Was tatsächlich half, zeigt ein kontrolliertes Experiment mit 252.000 Durchläufen – in einer simulierten RAG-Umgebung, in der dem Modell je zwei anonymisierte Quellen direkt vorgelegt wurden, ohne echte Suche. In diesem Rahmen beeinflussten Themenpassung, Reihenfolge im Quellenkontext, Preisangaben und Aktualität die erste Zitierung stark, reine Formatierung nicht. Übersetzt heißt das: Fehlende Entscheidungsinfos zu ergänzen – Preise, Bedingungen, Eignung – schlägt Layoutkosmetik. Kein Grund also, ein KMU-Projekt auf `llms.txt`, Schattenversionen aller Inhalte oder einen CMS-Wechsel auszurichten, solange kein eigener Test das nahelegt. Ein Sonderfall wird langsam relevant: Assistenten, die auf deiner Seite handeln sollen, nicht nur lesen. Dafür brauchst du echte Buttons, beschriftete Felder, ein stabiles Layout. Ob sich der Aufwand heute schon lohnt, habe ich hier behandelt: Agentisches SEO: Türen für Gäste, die kaum kommen. ## Warum ChatGPT, Gemini, Claude, Perplexity und Google nicht dasselbe sind Der häufigste Denkfehler ist, „die KI“ als einen Kanal zu behandeln. Diese Gleichsetzung hört schon bei den Crawlern auf. Bei OpenAI trennt der `OAI-SearchBot` den Suchzugriff vom `GPTBot`, der eine mögliche Trainingsnutzung betrifft. Eine Suchfreigabe verlangt keine Trainingsfreigabe. Anthropic fächert sogar dreifach auf: `Claude-SearchBot` für den Suchindex, `Claude-User` für den Abruf auf Nutzeranfrage, `ClaudeBot` für mögliches Training. _Perplexity_ nutzt den `PerplexityBot` für die Suche und gibt an, damit keine eigenen Foundation-Modelle vorzutrainieren. Der Fall, bei dem die meisten danebengreifen, ist Google. `Google-Extended` ist kein eigener Crawler, sondern ein Steuertoken in der `robots.txt`. Es betrifft Training und Grounding in den _Gemini_ -Apps sowie in Vertex AI – nicht aber Aufnahme oder Ranking in der normalen Google-Suche. „Training sperren, Suche erlauben“ lässt sich also nicht mit derselben Bot-Logik wie bei OpenAI auf Google übertragen. Wer `Google-Extended` blockt, trifft _Gemini_ und Vertex AI, nicht die Websuche. Womit wir beim nächsten Google-Missverständnis sind: Googles KI-Oberflächen in der Suche – AI Overviews und AI Mode – sind nicht die _Gemini_ -App. Eine Studie über AI Overviews beschreibt Google-Suchverhalten, keine _Gemini_ -Nutzung. Diese Trennung klingt kleinlich, entscheidet aber, ob eine Kennzahl für dich überhaupt gilt. Neu dazugekommen ist eine eigene Einstellung in der Search Console für die Teilnahme an den generativen Suchfunktionen; Google dokumentiert den weltweiten Rollout zum 31.08.2026, Standard ist Teilnahme. Ein Ausschluss betrifft diese KI-Funktionen, nicht dein übriges Ranking. Bei einem Audit gehört diese Einstellung dringend auf die Liste. Für _Claude_ ist die belastbare Evidenz zu öffentlichen Unternehmens- und Quellenpräferenzen besonders dünn. Eine Seer-Untersuchung hat _Claude_ zwar unter sechs Oberflächen mitgeprüft, aber nur an einer einzigen Marke über 28.123 Antworten. Ausgerechnet bei _Claude_ blieb dabei fast die Hälfte der Anfragen ohne Antwort – 46,3 %, gegenüber 31,2 % im Schnitt über alle sechs Oberflächen. Das ist ein Fallbeispiel, kein Modellvergleich, und keine Grundlage für „Claude-Rankingfaktoren". Dazu kommt die Personalisierung. Google verknüpft _Gemini_ – abhängig von Produkt, Region und ausdrücklicher Nutzerfreigabe – mit Diensten wie Gmail, Fotos und der Suche, um Antworten am Nutzer auszurichten. Öffentliches Webmaterial ist damit nicht zwangsläufig der einzige Kontext einer Antwort. Für die Messung heißt das: Ein frischer Testaccount und ein jahrelang personalisierter Account starten von unterschiedlichen Voraussetzungen. ## Die externen Faktoren: Erwähnung, Link und Empfehlung Die eigene Unternehmenswebsite ist die eine Hälfte. Die andere ist, was andere über deine Firma schreiben. Und auch hier lohnt das Auseinanderhalten. Ein **Backlink** verbindet eine fremde Seite mit deiner. Eine **Erwähnung** nennt dein Unternehmen, auch ohne Link. Eine **Empfehlung** bewertet, ob du zu einem Bedarf passt. Ein einziger Fachartikel kann alle drei enthalten oder nur eins. „Sind Backlinks noch relevant?“ lässt sich 2026 nicht mit einer sauberen Zahl beantworten. Die Recherche findet keinen belastbaren, isolierten Nachweis, dass eine bestimmte Menge neuer Backlinks die Empfehlungshäufigkeit über alle vier Assistenten hebt. Ein Preprint liefert einen begrenzten Zusammenhang: Bei 112 Startups korrelierte die Zahl verweisender Domains mit der Entdeckung bei Perplexity Sonar (r = 0,319). Die als „ChatGPT“ bezeichnete Vergleichsbedingung war allerdings GPT-4o-mini ohne Websuche, erhoben im Dezember 2025. Ein aktueller Produktvergleich ist das nicht, ein Kausaltest erst recht nicht. Als Teil vernünftiger Öffentlichkeitsarbeit bleiben Backlinks begründet, sie sind aber kein GEO-Wundermittel. Interessanter für viele KMU sind Bewertungen. Eine Seer-Analyse über 804.491 Antworten fand für Marken mit gepflegtem Trustpilot-Profil eine Präsenz samt Trustpilot-Zitat von 53,5 %, gegenüber einem Median von 1 % ohne aktives Profil. Klingt eindeutig, verlangt aber zwei Fußnoten. Trustpilot hat die Studie beauftragt. Und die Gruppen sind nicht randomisiert – bekanntere, aktivere Marken pflegen eher Profile. Echte Kundenbewertungen sind eine belastbare externe Information. Ein Trustpilot-Abo als KMU-Pflicht folgt daraus also nicht. Und die Dauerbrenner YouTube, LinkedIn, Reddit? Sie sind relevante Kandidaten, keine Pflichtliste. In einem stark B2B-lastigen Semrush-Datensatz erschien LinkedIn in 14,3 % der ChatGPT-Search-Antworten, aber nur 5,3 % bei Perplexity. In einer lokalen BrightLocal-Auswertung dagegen lagen die Social-Anteile im niedrigen einstelligen Bereich – für einen Handwerksbetrieb zählen andere Quellen als für eine SaaS-Firma. Welcher Kanal für dich zählt, entscheidet deine Branche und die Prüfung, welche Seiten bei deinen Kundenfragen tatsächlich zitiert werden. Nicht eine US-Domainrangliste. Für Shops kommt ein eigener Bereich dazu: Produktdaten. Google hat mit dem Universal Commerce Protocol schon Anfang 2026 vorgelegt, OpenAI erweiterte im März sein Agentic Commerce Protocol für Produktfeeds in _ChatGPT_. Vieles davon rollt länderweise aus, eine pauschale Verfügbarkeit für deutsche Händler folgt daraus nicht. Der erste Schritt ist beinahe langweilig (aber wichtig): prüfen, was dein bestehendes Shopsystem an Preis, Bestand und Varianten schon sauber ausliefert. Zuletzt der ehrliche Hinweis auf den bezahlten Weg. Seit Ende August 2026 gibt es ChatGPT Ads als Self-Service auch in Deutschland. Laut OpenAI sind die Anzeigen gekennzeichnet und von den Antworten getrennt. Das ist ein weiterer Sichtbarkeitskanal – gehört aber ins Reporting als Werbung, nicht als Beleg für gelungene organische Arbeit. ## Messen, statt sich einen Screenshot schönzureden Der verbreitetste Fehler zum Schluss: einmal fragen, Screenshot machen, Haken dran. KI-Antworten sind dafür zu wackelig. Ein Schweizer Preprint hat vier Themenfelder täglich abgefragt und für die zitierten Quellen zwischen aufeinanderfolgenden Tagen eine Jaccard-Ähnlichkeit von im Mittel 0,34 bis 0,42 gemessen. Bei einem Wert um 0,35 wechseln damit grob zwei Drittel der zitierten Quellen von einem Tag auf den anderen. Der Wert misst allerdings die Mengenüberschneidung, nicht die Stabilität einzelner Rankingpositionen. _Claude_ fehlte in dieser Erhebung, der Standort war die Schweiz – die Grundaussage bleibt. Ein handhabbares Messdesign für ein KMU sieht darum eher so aus: * **20 bis 30 realistische Fragen** aus Vertrieb und Support ableiten, nicht künstlich umformulieren. * **Alle vier Produkte getrennt** testen und Modell, Websuche, Sprache, Land, Standort und Datum notieren. * **Pro Frage mehrere Läufe an verschiedenen Tagen** , Antworten und Quellen speichern. * **Getrennt zählen:** Nennungsquote, Empfehlungsquote, Zitierungsquote, sachliche Genauigkeit. Was an Bordmitteln hilft: OpenAI dokumentiert den Verweisparameter `utm_source=chatgpt.com`, solche Besuche lassen sich in der Webanalyse gesondert ansehen. Google hat seit dem Sommer eigene Search-Console-Berichte für die generativen Funktionen. Beides ist nützlich und beides ist unvollständig – ein Botabruf im Log beweist noch nicht, dass ein Mensch die Antwort gesehen hat. Und eine letzte Vorsicht bei der Erfolgsmeldung. Ein Preprint über eine einzelne Website berichtete nach einer Optimierung einen 5,7-fachen Anstieg der gesamten ChatGPT-Verweise. Die behandelten Seiten legten um das 6,1-Fache zu – die unbehandelten Kontrollseiten derselben Domain aber zeitgleich um das 3,5-Fache, also der Plattform-Trend ganz ohne Maßnahme. Nach statistischer Bereinigung blieb ein Zusatzfaktor von 1,82, der im zeitlichen Placebotest mit p = 0,16 nicht signifikant war. Mehr KI-Traffic nach einer Maßnahme ist eben noch kein Beweis für die Maßnahme. ## Was das für dein KMU heißt Kein Großprojekt, sondern eine Abarbeitung in Reihenfolge. Für eine kleine Website reichen zu Beginn ein paar wichtige Seiten und eine überschaubare Fragenauswahl. 1. Zielkundenfragen und relevante KI-Oberflächen festlegen, eine erste Messung als Ausgangspunkt. 2. Erreichbarkeit und sachliche Fehler korrigieren, Suchkontrollen bewusst setzen. 3. Fehlende Entscheidungsinfos ergänzen – Eignung, Umfang, Bedingungen, Preise, Belege. 4. Herausfinden, welche externen Quellen bei deinen Fragen wirklich zitiert werden. 5. Genau dort gezielt Öffentlichkeit und echte Kundenbelege aufbauen. 6. Kontrolliert nachmessen, über mehrere Tage, mit Blick auf tatsächliche Anfragen. Das ist definitiv weniger sexy als ein „KI-Sichtbarkeits-Score“ mit Fortschrittsbalken. Es hat nur den Vorteil, dass jeder Schritt etwas bewirkt, das du selbst prüfen kannst. Die Formel gibt es nicht. Die Reihenfolge schon.

t01.li

t01 KI-Journal @hello.t01.li.ap.brid.gy · 4w ago

Ruhige Modellwoche mit ein paar Highlights: DeepSeek V4.1-Flash und Mercury 2.5 drücken die Preise, Cognition SWE-2 kratzt an Fable 5.1, Sakana Fugu setzt auf Orchestrierung – dazu drei frische OpenAI-Releases.

AI Picks der 37. KW

Leichte Ermüdungserscheinungen bei den Labs. Die große Modellwoche findet nur moderat eine Fortsetzung, immerhin mit ein paar Highlights. Ansonsten verfolgen wohl alle das Battle Trump vs. Kanada – war nämlich erstaunlich wenig los diese Woche. Außer, dass die Tech-Aktien und damit meine Handvoll Anteile am L&G Artificial Intelligence UCITS gerade lustig Achterbahn fahren. Sei es drum, dann ist es schneller weggelesen als letzte Woche. Also, dann mal rein in die 37. Kalenderwoche des Jahres 2026 AD. ## DeepSeek-V4.1-Flash Bei DeepSeek dachten sie sich auch „da geht noch was“ und haben _V4.1-Flash_ rausgehauen. Ein 552-Milliarden-Parameter-MoE, davon rund 8 Milliarden aktiv, Open Weights unter MIT-Lizenz, native Bildeingabe. Das ist alles richtig nett, aber nicht der springende Punkt. Das ist nämlich der Preis und der ist mal 'ne echte Ansage von DeepSeek: V4.1 Flash| Off-peak| Peak ---|---|--- 1M input tokens (cache hit)| $0.003| $0.006 1M input tokens (cache miss)| $0.15| $0.30 1M output tokens| $0.60| $1.20 Der Cache-Hit für 0,003 $ macht wiederholten Kontext nicht ganz, aber fast geschenkt. Flash beerbt damit das alte _V4-Flash_ und übernimmt ab dem 14. September auch den Traffic von V4 Pro, bis irgendwann _V4.1 Pro_ nachkommt. Artificial Analysis hat das Ding schon vermessen, die Weights liegen auf Hugging Face, und über OpenRouter kommt man ohne DeepSeek-Account dran. In dieser Preisklasse ist das aktuell sehr schwer zu schlagen. ## Mercury 2.5 Bei Inception (stabiler Name für eine AI-Bude) ist am 8. September das LLM _Mercury 2.5_ hinten rausgefallen. Wer hätte es geahnt: ein auf Coding und agentische Aufgaben spezialisiertes Diffusionsmodell. Zu ihrer Verteidigung: Das war beim Vorgänger auch schon so. Das Besondere ist dann auch nicht irgendein „High Intelligence“-Claim oder die Behauptung, es liefe 40 Tage am Stück durch, sondern schlicht Preis und Geschwindigkeit. Beides für sich genommen ist schon eine Kampfansage. Der Listenpreis liegt bei 0,20 $ Input und 0,75 $ Output, zum Launch gibt es 80 % Rabatt: 0,04 $ Input und 0,15 $ Output. Dazu ein auf 260K erweitertes Kontextfenster, tunbares Reasoning und Tool Use. Der Aufhänger bleibt das Tempo, in ihren eigenen Worten: > „1,107 tokens per second on widely-available NVIDIA GPUs.“ Das wird bei dir nicht 1:1 ankommen, aber über OpenRouter sind im Schnitt trotzdem gern zwischen 201 und 846 tok/s drin. Unabhängige Drittanbieter-Benchmarks gab es zum Zeitpunkt der Niederschrift dieses Beitrags noch nicht. Ihr Launch-Artikel vergleicht primär mit dem eigenen Vorgänger und das wirkt zumindest nicht an den Haaren herbeigezogen – aber bleibt eben eine Herstellerangabe. ## Cognition SWE-2 Eine neue Woche, ein neues Coding-Modell: Cognition hat am 10. September _SWE-2_ veröffentlicht. Und mein lieber Herr Gesangsverein, nehmen die den Mund voll. Ihr eigenes Modell sei das fortschrittlichste bisher (das beziehen sie vermutlich auf ihre bis dato trainierten Modelle), es verschiebe die Pareto-Front aus Leistung und Kosten und lande > „within one point of Fable 5.1 while being 64% cheaper“. Unter der Haube steckt ein Post-Training von Kimi K3, an den technischen Eckdaten dürfte sich also wenig getan haben: * 2,8 Billionen Parameter * MoE mit 16 von 896 Experten pro Token * 1 Mio. Tokens Kontextfenster Lustigerweise nennen sie nichts davon im eigenen Artikel, gezeigt werden nur eigene Benchmarks – externe gibt es bisher keine. Die 50,0 % auf FrontierCode 1.1 Main liegen knapp hinter den 50,9 % von Fable 5.1, das schon. Wer das ausprobieren will, muss sich in die Devin-Infrastruktur einkaufen. Es gibt einen Free-Account, ernsthaft los geht es ab 20 $/Monat mit Devin Pro. Mein Take dazu: das mag alles total toll sein, aber allein ihr Blogeintrag wirkt so shady auf mich, dass ich schon keinen Bock mehr habe, mich für einen Test überhaupt zu registrieren. ## Sakana Fugu Max und Fugu Ultra v2 Sakana AI hat mit _Fugu Max_ und _Fugu Ultra v2_ zwei neue Varianten seiner Fugu-Orchestrierung rausgelassen. Kein einzelnes Foundation Model, sondern ein System, das Anfragen dynamisch auf einen Pool aus offenen und spezialisierten Modellen verteilt. _Fugu Max_ ist auf das Verhältnis aus Leistung und Kosten optimiert: möglichst hohe Qualität mit dem kleinsten Modell, das die Aufgabe noch packt. Sakana nennt 2 $ pro 1 Mio. Input-Tokens und 6 $ pro 1 Mio. Output-Tokens und spricht von 40–60 % niedrigeren Output-Kosten gegenüber Sonnet 5, GPT-5.6 Terra und _Kimi K3_. Nach eigenen Angaben holt _Fugu Max_ auf sechs Benchmarks den höchsten Gesamtscore und erweitert auf sieben von zehn getesteten Benchmarks die Kosten-Leistungs-Paretofront. Die Werte stammen aus Sakanas eigener Evaluation, mit SWEFish ist zudem mindestens ein interner Benchmark dabei. _Fugu Ultra v2_ setzt dagegen auf maximale Leistung bei komplexen, mehrstufigen Aufgaben – Development, autonome Recherche, das Verarbeiten visueller und strukturierter Daten. Sakana nennt unter anderem 48,3 Punkte auf Chartography und 74,3 auf DeepSWE. Auf sieben von acht Benchmarks soll _Ultra v2_ mindestens Rang 2 erreichen. Interessant ist die eigene Fußnote: _Fugu Ultra v2_ erreicht diese Werte laut Sakana ohne _Fable 5_ , Fable 5.1 oder GPT-6 Astra im zugrunde liegenden Modellpool. Beide Varianten laufen über eine OpenAI-kompatible API und lassen sich in bestehenden Fugu-Integrationen per Parametertausch aktivieren. Die Botschaft dahinter: Nicht ein immer größeres Einzelmodell, sondern die dynamische Auswahl und Kombination spezialisierter Modelle soll das bessere Verhältnis aus Kosten, Leistung und Anbieterunabhängigkeit liefern. Technische Daten| Fugu Max| Fugu Ultra v2 ---|---|--- Architektur| Multi-Modell-/Agenten-Orchestrierung| Multi-Modell-/Agenten-Orchestrierung Schwerpunkt| Kosten-/Leistungseffizienz| Maximale Qualität/Capability Modellpool| Open Weights + spezialisierte Modelle, inkl. NVIDIA Nemotron| Austauschbarer Pool aus offenen und spezialisierten Modellen Input-Preis| 2 $ / 1 Mio. Tokens| im Release nicht genannt Output-Preis| 6 $ / 1 Mio. Tokens| im Release nicht genannt Schnittstelle| OpenAI-kompatible API| OpenAI-kompatible API Verfügbarkeit| seit 11.09.2026| seit 11.09.2026 Wer den vollen Zahlensalat will, findet ihn im Release-Post; auf OpenRouter ist die Familie ebenfalls gelistet. ## Effizient Astra-Tokens verbrennen Schön, dass ich mit meinen ersten Erfahrungen mit dem jüngsten OpenAI Flagship diese Woche nicht alleine dastehe. Denn Astra in _Codex_ zu nutzen ist ein bisschen wie in einem Bugatti Veyron bei 260 km/h der Tankanzeige live zuzusehen: wirkt imposant, verbrennt aber viel zu viel in viel zu kurzer Zeit. Und ich hatte _Astra_ dabei nicht mal auf Anschlag, sondern moderat auf „mittel“. Anders als Ben Tossell, der sein Wochenende mit 4 Milliarden Tokens und am Ende ungefähr nichts Gebautem verbracht hat, hatte ich hinterher immerhin das Gefühl, dass etwas Brauchbares herauskam. Ich wollte _Astra_ in einem realistischen Szenario ausprobieren und habe es in _Codex_ ein kleines Tool bauen lassen, das mir die unterschiedlichen Export-Daten und -Formate (querbeet: JSON, PDF, MD, etc.) aus diversen GEO- und SEO-Analyse-Tools plus Search Console, GA4 und Merchant Center einsammelt, in eine Pipeline kippt, token-sparsam konsolidiert und zu einem Reporting mit definierbaren KPIs zusammenschiebt. Gebraucht habe ich dafür zwei Anläufe – der erste hat mir mittendrin das Limit leergesaugt. Als Test ist das völlig okay, aber: Mit Sol auf Effort Level High hätte Codex denselben Job genauso erledigt, ohne dass ich zweimal hätte ranmüssen. ## GPT-6 Model Guidance Apropos _Astra_ : OpenAI hat seinen kleinen LLM-Guide erweitert und Hinweise zu _Astra_ reingeschoben. Keine wilden Überraschungen, aber ein paar wissenswerte Dinge. Mir war zum Beispiel nicht bewusst, dass sich das Reasoning nicht mehr per Reasoning Effort `none` abschalten lässt – die niedrigste Stufe ist jetzt `low`. Heißt für den Alltag: Wer kein Reasoning braucht, lässt _Astra_ orchestrieren und schickt Luna oder Terra zum eigentlichen Werkeln vor. ## OpenAI Agents API Frisch vom 10. September und aktuell Public Beta: OpenAI hat die Agents API veröffentlicht und macht somit den Agenten-Unterbau von _Codex_ als verwalteten Dienst verfügbar. Man definiert Aufgabe, Modell, Tools und Ausführungsumgebung, das eigentliche Harness für Kontextverwaltung, Tool-Nutzung und Orchestrierung betreibt OpenAI. Laufen können die Agenten in OpenAI-Sandboxes, auf eigener Infrastruktur oder bei einem der Sandbox-Partner, unter anderem Cloudflare, Vercel, DigitalOcean oder E2B. Unterstützt werden MCP, eigene Funktionen, Websuche und parallele Subagenten. Der interessante Punkt daran, ist weniger eine neue Modellfähigkeit, als vielmehr die Produktisierung der Agenten-Infrastruktur. Die API übernimmt, was Entwickler bisher oft selbst bauen mussten: lange Sessions über mehrere Kontextfenster, automatische Context Compaction, dynamisches Laden relevanter Tools und die Koordination mehrerer spezialisierter Agenten. Das zugrunde liegende _Codex_ -Harness bleibt Open Source, OpenAI übernimmt bei der API Betrieb und Weiterentwicklung. Zusätzliche Gebühren fallen laut OpenAI nicht an, berechnet werden die verwendeten Modelle und Tools. ## GPT-Live-1 über OpenAI API verfügbar Ebenfalls am 10. September in die API gerutscht ist _GPT-Live-1_. Ein Sprachmodell für Echtzeit-Voice, das Audio-Ein- und -Ausgabe in einem gemeinsamen Modell verarbeitet. Es kann während der eigenen Sprachausgabe weiter zuhören, Unterbrechungen oder kurze Bestätigungen erkennen und Gesprächswechsel abbilden, ohne die klassische STT-LLM-TTS-Kette. Reasoning und Tool Calls delegiert es an ein separates Backend-Modell wie _GPT-6 Astra_ , _GPT-5.6 Terra_ oder ein Drittanbieter-Modell. Dazu liefert das Modell ASR-Transkripte und Antworttext, unterstützt Turn Detection, Keyword Biasing und Telefonie. Auf dem eigenen Full Duplex Bench nennt OpenAI einen Vorsprung von 30 Prozentpunkten gegenüber GPT-Realtime-2.1 – Benchmarkwerte komplett aus eigenen Evaluierungen, das Sternchen sollte man kennen. Der Preis ist nicht uninteressant: 0,05 $ pro Minute für die Voice-Frontend-Schicht, das Backend läuft separat. Eine offizielle Liste der unterstützten Sprachen gibt es nicht, nur den Hinweis, dass die Auswahl an Stimmen um Akzente, Dialekte und Sprachen erweitert wurde und die Sprachverfügbarkeit in den kommenden Monaten weiter wachsen soll. Damit Schluss für diese Woche und achtet auf euer Token-Budget.

t01.li

Die llms.txt gilt vielen als Pflicht für die KI-Sichtbarkeit. Ich habe drei Monate Server-Logs von fünf Websites mit Logwerk ausgewertet: Kein einziger Search- oder AI-Bot ruft die Datei ab. Google ignoriert sie offiziell. Wo sie trotzdem taugt und wo nicht.

llms.txt: Der Standard, den kein Bot abholt

Ich hatte schon in GEO ohne technisches SEO ist Kaffeesatzleserei geschrieben, dass Sichtbarkeit in generativen Systemen ohne sauberes technisches Fundament reine Spekulation bleibt. Ein Baustein, der in jeder zweiten LinkedIn-Predigt zu dem Thema auftauchte, ist die `llms.txt`. Ohne die, so der Tenor über Monate, bist du bei der KI-Sichtbarkeit komplett raus. Also habe ich das Diskutieren sein lassen und stattdessen in die Logs geschaut. Drei Monate, fünf Websites, ein Auswertungstool. Das Ergebnis schon mal vorab: Auf keiner einzigen der beobachteten Seiten hat sich ein Bot für die `llms.txt `interessiert, kein einziger. ## TL;DR Die `llms.txt` soll KI-Systemen zeigen, welche Seiten deiner Website die wichtigen sind. Nur holt sie kaum jemand ab. * Vorgeschlagen im September 2024 von Jeremy Howard (Answer.AI), aber kein von IETF oder W3C ratifizierter Standard, sondern eine Konvention. * Google ignoriert die Datei offiziell; OpenAI und Anthropic steuern ihre Crawler über die `robots.txt` und pflegen eine `llms.txt` nur für die eigene Doku. * In drei Monaten Server-Logs über fünf Websites: kein einziger Zugriff eines Search- oder AI-Bots auf die `llms.txt`. Ahrefs misst über 137.000 Domains dasselbe Muster. * Realen Nutzen hat sie nur, wenn du einem Coding-Agenten deine Doku direkt übergibst, nicht für die organische AI-Sichtbarkeit deiner Seite. ## Woher die llms.txt kommt und was sie eigentlich sein will Die `llms.txt` wurde am 3. September 2024 von Jeremy Howard vorgeschlagen, Mitgründer von Answer.AI. Die Spezifikation liegt bis heute unter llmstxt.org. Was aber oft untergeht: Es handelt sich um einen Community-Vorschlag und nicht um einen ratifizierten Standard. Weder IETF noch W3C haben hier etwas verabschiedet, und eine Instanz, die irgendetwas durchsetzt, gibt es nicht. Wer von einem „offiziellen Standard“ spricht, meint eine gut dokumentierte Konvention. Die Idee dahinter ist gut: Ein Sprachmodell arbeitet mit einem begrenzten Kontextfenster, und eine normale Website steckt voller Navigation, Skripte und Ballast, den ein Modell nicht braucht. Die `llms.txt `ist als Gegenstück zur Sitemap gedacht, nur eben für Maschinen – eine kuratierte Markdown-Karte deiner wichtigen Seiten. Dazu gibt es optional die `llms-full.txt`, die den Volltext gleich mitliefert, damit ein Agent alles in einem Rutsch laden kann. Sauber gedacht. Bleibt die Frage, ob es jemanden gibt, der das liest. ## Was laut Spec überhaupt in der llms.txt stehen soll Die Spezifikation unter llmstxt.org ist bewusst schlank gehalten. Pflicht ist genau ein Element: eine H1 mit dem Namen der Site oder des Projekts. Also kein Werbe-Claim, sondern schlicht der Name. Alles andere ist optional, aber durchaus empfohlen. Direkt unter die H1 gehört ein Blockquote mit einer knappen Zusammenfassung. Dieser Satz ist wichtiger, als er aussieht. Er ist das Erste, was ein Modell liest, und soll laut Specs wörtlich übernommen werden, wenn jemand fragt, worum es auf der Seite geht. Darunter darf freier Markdown-Text folgen, Absätze oder Listen, für zusätzlichen Kontext. Nur keine weiteren Überschriften, bis der nächste Block beginnt. Der eigentliche Nutzwert steckt in den H2-Abschnitten. Jeder H2 ist eine Kategorie, darunter eine Markdown-Liste aus Links im Format `[Titel](URL): kurze Notiz`. Das ist der Sitemap-Gedanke in kuratiert. Nicht jede URL, sondern die, die du einem Modell tatsächlich vorlegen willst. Ein Detail ist sehr interessant, weil es die Datei erst praktikabel macht: der Abschnitt `## Optional: `Links, die dort stehen, dürfen von einem Parser übersprungen werden, wenn der Kontext knapp wird. Alles Nice-to-have wandert dorthin, ohne die Pflichtlektüre zu verdrängen. Wer zusätzlich eine `llms-full.txt` bereitstellt, liefert den kompletten Volltext dieser Seiten in einer Datei, damit ein Agent alles in einem einzigen Fetch laden kann. So sieht eine minimale, aber vollständige `llms.txt` aus: # Beispiel GmbH > Wir bauen systemübergreifende Software für die Lagerlogistik mittelständischer Betriebe. Diese Datei verweist auf die Seiten, die ein KI-System zuerst lesen sollte. Die Produkt-Doku ist die verlässlichste Quelle. Preise und Verfügbarkeit ändern sich, dafür bitte immer die Live-Seiten prüfen. ## Produkt - [Funktionsüberblick](https://example.com/produkt): was die Software kann, in zwei Absätzen - [Preise](https://example.com/preise): aktuelle Tarife und Grenzen ## Doku - [Schnellstart](https://example.com/docs/schnellstart): Installation und erster Lauf - [API-Referenz](https://example.com/docs/api): Endpunkte und Datentypen ## Optional - [Blog-Archiv](https://example.com/blog): ältere Beiträge, bei knappem Kontext überspringbar - [Impressum](https://example.com/impressum) **Was hier passiert, Element für Element:** * Die H1 (`# Beispiel GmbH`) ist der Name, kein Slogan. Das einzige Pflichtfeld. * Das Blockquote darunter ist die Kurzzusammenfassung, die ein Modell gern wörtlich übernimmt, wenn jemand fragt, worum es geht. * Der Absatz danach ist freier Kontext ohne Überschrift, hier ein Hinweis, welche Quelle verlässlich ist und welche nicht. * Die H2-Abschnitte (`## Produkt`, `## Doku`) sind kuratierte Link-Listen, jeder Link mit einer knappen Notiz nach dem Doppelpunkt. * `## Optional` ist der einzige Abschnittsname mit Sonderbedeutung. Was hier steht, darf ein Parser bei knappem Kontext überspringen. Gut für Archiv, rechtliche Seiten und alles andere, das nicht zur Pflichtlektüre gehört. Das ist die ganze Spezifikation. Kein Schema-Zwang, kein Validator, der etwas ablehnt. Genau diese Niedrigschwelligkeit ist der Grund, warum sich die Datei so schnell verbreitet hat und, wie die Logs zeigen, leider so wenig bewirkt. ## Was die Anbieter offiziell sagen Google ist bei dem Thema ungewohnt deutlich. Das im Juni 2026 aktualisierte Guide im Search Central hält fest, dass man keine maschinenlesbaren Zusatzdateien oder Markdown braucht, um in der Suche aufzutauchen, auch nicht in den generativen Features. Zur `llms.txt` heißt es dort schlicht, Google Search ignoriere sie. Das kommt von Gary Illyes, und dieser hatte schon im Juli 2025 auf dem Search Central Live in der APAC-Region bestätigt, dass Google die Datei nicht unterstützt und das auch nicht vorhat. John Mueller verglich sie öffentlich mit dem alten Keywords-Meta-Tag, jenem Relikt, das Suchmaschinen irgendwann komplett ignoriert haben. Bei OpenAI und Anthropic sieht es nicht besser aus. Beide steuern ihre Crawler über die `robots.txt`, in der Crawler-Doku taucht die `llms.txt` nicht auf. Aber hier eine kleine Pointe am Rande: Beide pflegen selbst eine eigene `llms.txt`, nämlich für ihre jeweilige Entwickler-Doku. Der Vorschlag hat also durchaus Abnehmer. Es sind die LLM‑Anbieter selbst, aber auch die nutzen ihn nicht, um fremde Seiten besser zu lesen. ## Was tatsächlich in den Logs steht Ausgewertet habe ich mit Logwerk, einem eigenen kleinen Log-Analyzer-Projekt, das über 70 Crawler unterscheidet und mir zeigt, welcher Bot auf welche Datei zugreift. Dabei war die Auswahl bewusst nicht zufällig. Drei größere Sites aus unserem Kundenstamm bei klartxt, dazu zwei eigene Projekte, darunter dieses Blog. „Größer“ heißt hier mindestens 150 eindeutige Besucher am Tag, die Domains laufen seit Jahren, Crawler werden nicht ausgesperrt, und `llms.txt`, Sitemap, `robots.txt` sowie strukturierte Daten sind hinterlegt. Ein Mix aus Dienstleistung, E-Commerce und B2C- und B2B-Information, quer durch die Search Intentions. Zeitraum: Juni bis August 2026. Bei den KI-Crawlern habe ich mir gezielt die größten Frontier-Anbieter angesehen, mit Schwerpunkt auf Anthropic, Google, Bing, OpenAI und Perplexity (okay, das ist nur bedingt Frontier, aber trotzdem relevant). Die `robots.txt` holt sich jeder von denen ab, gerne mehrfach am Tag. Der ClaudeBot kam an Spitzentagen auf bis zu acht Abrufe. Bei der Sitemap wird es interessanter, weil es Ausnahmen gibt. OAI-SearchBot und PerplexityBot ignorieren sie, und zwar auch dann, wenn sie in der `robots.txt` sauber referenziert ist. Bleibt das Markdown, das den Bots aktiv angeboten wird. Einzelne Seiten werden zusätzlich als Markdown-Datei bereitgestellt und weisen die Crawler per Link-Header darauf hin. Abgeholt hat es genau einer: der FacebookExternalHit, Metas Crawler für Link-Vorschauen. Der zieht sich den Content, wenn irgendwo ein Link geteilt wird, und hat mit KI-Retrieval oder GEO nichts zu tun. Selbst Markdown, das frei Haus geliefert wird, will also kein AI-Crawler haben. Für die `llms.txt` gilt das leider erst recht. Sie liegt am Standard-Ort `/llms.txt `im Root, genau dort, wo ein Bot sie von sich aus abfragen müsste/sollte. Über drei Monate, über alle fünf Seiten, hat das kein einziger Search- oder AI-Bot getan, nicht ein Request. Damit das keine Einzelbeobachtung von fünf Sites bleibt: Ahrefs hat 137.000 Domains ausgewertet und in einer im Juni 2026 veröffentlichten Studie festgestellt, dass 97 % der `llms.txt`-Dateien im Mai 2026 überhaupt nicht abgerufen wurden. Und bei den wenigen Dateien, die überhaupt Zugriffe bekamen, stammte gerade einmal gut ein Prozent der Anfragen von echten AI-Retrieval-Bots. SE Ranking fand über rund 300.000 Domains keine Korrelation zwischen der Datei und AI-Citations. Die Logs, die ich mir angesehen habe, sind also kein Ausreißer, sondern eine kleine, konsistente Bestätigung dessen, was die großen Auswertungen längst zeigen. ## Wo die llms.txt trotzdem etwas taugt Damit hier nicht der Eindruck entsteht, die `llms.txt` sei kompletter Unsinn, gehört eine ehrliche Abgrenzung dazu. Es gibt einen Kontext, in dem sie real hilft, und das ist die Nutzung zur Laufzeit. Wenn du einem Coding-Agenten wie _Cursor_ oder _Claude Code_ eine Doku übergibst, spart eine gepflegte `llms.txt` oder `llms-full.txt` echte Arbeit. Ein Fetch statt zehn, sauberer Markdown-Kontext statt HTML-Gestrüpp. Mike King von iPullRank hat im Mai 2026 zu Recht angemerkt, dass man die Datei nicht abschreiben sollte, nur weil Google sie ignoriert, denn Systeme mit anderer Retrieval-Architektur könnten sie verarbeiten. Der Haken an diesem Argument liegt dann aber im Wörtchen „übergibst“: In diesen Fällen entdeckt niemand deine Datei da draußen im Netz. Du reichst sie aktiv rein, in einem geschlossenen Werkzeug-Kontext. Das ist ein legitimer Anwendungsfall für Entwicklerdokumentationen. Also kein Sichtbarkeitssignal für deine Firmenseite in ChatGPT, Claude oder Perplexity – zumindest aktuell, Stand September 2026. ## Resümee Gegen einen schlanken Standard wie die `llms.txt` ist wenig einzuwenden. Die Idee ist schwer in Ordnung, die Umsetzung minimal, und wer sie für seine Doku pflegen will, sollte genau das gern tun. Nur ändert ein Standard, den kein relevanter Abnehmer abfragt, an deiner GEO-Sichtbarkeit exakt gar nichts. Dann pflegst du eine Datei, damit ein Ordner nicht leer aussieht. Interessant finde ich, wie ruhig es an der Predigt-Front geworden ist. Vor ein paar Monaten war die Botschaft auf LinkedIn und anderswo noch, dass du ohne `llms.txt` bei der KI-Sichtbarkeit abgehängt bist. Diese Stimmen sind deutlich leiser geworden. Vielleicht haben sie auch mal in ihre Logs geschaut.

t01.li

GPT-6 Astra, Claude Fable 5.1, Muse Spark 1.3 und Gemini 3.8 Flash in vier Tagen, dazu Qwen3.8-Max-0902, iFlyteks Spark-X2.5, Quasar 438B mit chinesischem Motor, Metas Transkriptionsmodell für 0,18 $ die Stunde und drei Handwerksstücke zu Agenten-Infrastruktur.

AI Picks der 36. KW

Die Modellwochen sind wieder eingeläutet, diesmal mit den Frontiers vorweg – OpenAI, Anthropic, Google und Meta haben innerhalb von vier Tagen abgeworfen. Daneben gab’s ordentlich Zuwachs bei den Open Weights, ein „europäisches Flaggschiff“ mit chinesischem Motor. Reichlich Ware also, dafür mal kein Gossip. Damit rein in die 36. Kalenderwoche des Jahres 2026. ## GPT-6 Astra Bei OpenAI ist am 3. September _GPT-6 Astra_ hintenraus gefallen, und in der Launch-Meldung spielen sie ein bisschen Microsoft – zumindest, was Superlative und Tonalität angeht. „Neue Generation der Intelligenz“ steht drüber, Greg Brockman hat das Presse-Briefing mit „Welcome to the AGI era“ beendet. Das, was nicht aus OpenAIs eigener Tabelle stammt, klingt nüchterner: Artificial Analysis führt Astra und den Vorgänger _GPT-5.6 Sol_ beide mit 61 Punkten im Intelligence Index. In erster Linie ist Astra das bessere agentische Modell zum höheren Preis. Computer Use ist der eigentliche Sprung, auf OSWorld 2.0 meldet OpenAI 72,6 statt 65,7 % – herstellereigen und auf einem Offline-Subset gemessen. Für _Codex_ gibt es eine zweite Gedächtnisschicht aus Notizen und einer Suche über frühere Kontextfenster, die gegen die übliche Compaction-Amnesie helfen soll. Dann der Preis – 10 $ Input und 50 $ Output je Million Tokens, das 2,5-Fache von Sol. Pro Index-Task rechnet Artificial Analysis mit 1,67 statt 0,95 $. Die ausführliche Einordnung zu Astra steht seit Freitag hier. Bei mir ist noch nichts angekommen, warten wir die nächsten Wochen mal ab. ## Claude Fable 5.1 und Mythos 5.1 Auch Anthropic hat ein „Flagship“ rausgelassen, und ich schreibe ganz bewusst nur „ein“. Fable 5.1 und Mythos 5.1 sind dasselbe Modell mit unterschiedlich permissiven Safeguards davor – Fable für alle, Mythos vorerst für eine Handvoll geprüfter US-Organisationen. Der Unterschied liegt nicht im trainierten Modell, sondern im System drumherum. Wie viel dieses System kostet, steht diesmal offen in der Launch-Tabelle. Auf Terminal-Bench 4.0 kommt Fable auf 55,8 %, Mythos auf 60,9 %. Dasselbe Modell, dieselben Aufgaben, 5,1 Punkte Differenz – gemessen allerdings noch mit den älteren, gröberen Cyber-Filtern. Mit den neuen Safeguards, die pro Claude-Code-Session rund 60 % seltener eingreifen sollen, dürfte die Lücke schrumpfen. Sagt Anthropic. Ob sie das tut, zeigt erst eine unabhängige Nachmessung. Der Preis bleibt bei 10/50 $, nur Cache-Reads sinken um 75 % auf 0,25 $. Womit Astra und Fable 5.1 seit Donnerstag exakt dasselbe Preisschild tragen. ## Muse Spark 1.3 Meta ist das Fast-Fashion-Label unter den Herstellern und entlässt mit Muse Spark 1.3 das vierte Muse-Spark-LLM in fünf Monaten. Und es zeichnet sich klar ein Trend ab: Alle optimieren auf agentische Fähigkeiten, denn hier liegt das Geld auf der Straße. Chat ist nicht tot, taucht in den Launch-Meldungen aber kaum noch auf. Was Meta in die Hände spielen könnte, ist die Kombination aus Preis und Kurve. Artificial Analysis misst 61 Punkte für xhigh, 1.2 lag bei 57, 1.1 bei 53 – mit jedem Release wird’s messbar besser. Damit steht Muse gleichauf mit _GPT-5.6 Sol_ (max), _Grok 4.6_ (high) und _Claude Opus 5_ (high), bei unveränderten 1,25/4,25 $ je Million Tokens. Unter allen Modellen ab 59 Indexpunkten erledigt aktuell keines eine Aufgabe billiger. Der Haken hängt an der Kostenrechnung. Pro Index-Task steigt der Preis von 0,40 auf 0,55 $, weil 1.3 in den agentischen Evals rund 57 % mehr Input-Tokens zieht. Gleicher Tokenpreis, teurere Aufgabe – das Muster begleitet uns diese Woche noch öfter. Auf meiner Testliste steht 1.3 trotzdem weit oben, 1.2 hatte ich in der 32. KW schon kurz in der Hand. ## Gemini 3.8 Flash Auch Google trimmt Gemini 3.8 Flash auf Coding- und Agentenfähigkeiten. Dritter Flash-Release in sechs Wochen, das große Modell fehlt weiterhin. Auf dem Papier kostet das neue Modell dasselbe wie 3.7 Flash – 0,75 $ Input und 3,75 $ Output –, führt aber mehr Reasoning-Schritte aus und ruft häufiger Tools auf. Artificial Analysis misst den Effekt schon: 0,58 statt 0,40 $ pro Index-Task auf high, bei drei Punkten mehr im Index (59 statt 56). Medium landet bei 57 und kostet pro Aufgabe ungefähr das, was 3.7 auf high gekostet hat. Die 0,75 und 3,75 $ sind Einführungspreise bis zum 31. Dezember, ab Januar 2027 verdoppeln sie sich auf 1,50 und 7,50 $. Wer absehbar Workflows umstellt, rechnet also schon mal vorausschauend mit dem Standardpreis. 3.7 Flash hat sich bei mir in den letzten Wochen zum treuen Arbeitspferd gemausert – Sprachnachrichten transkribieren und strukturieren, Webseiten zusammenfassen und in Markdown mit Frontmatter gießen, HTML und CSS generieren – fast alles davon als Arbeitstier in _n8n_ -Workflows. Das Human in the Loop war ich beim Input, der Rest lief zuverlässig durch. Ob 3.8 auf medium denselben Job günstiger erledigt als 3.7 auf high, gilt es dann eben zu testen. ## Qwen3.8-Max-0902 Alibaba hat auch wieder zugeschlagen und am 2. September Qwen3.8-Max-0902 rausgeworfen – kein neuer Versionsname, sondern ein Snapshot, weiter post-trained auf Coding und Cowork-Tasks. 2,4 Billionen Parameter, 1 Mio. Token Kontextfenster, 2 $ Input und 6 $ Output je Million Tokens über QwenCloud. Und der Snapshot hinterlässt Einschläge. Ich gebe eigentlich nicht so viel auf Arena-Rankings, aber Platz 1 in der Code Arena: WebDev direkt am ersten Tag, mit 1.691 Punkten drei vor _Claude Opus 5_ (Max), 17 vor _Kimi K3_ (Max) und 22 vor dem eigenen Vorgänger – Respekt. Dazu die Spitzenposition auf der Pareto-Front bei rund 5 $ Blended Price. Damit das niemand falsch liest: Das ist die WebDev-Arena, nicht die Text-Arena. Im Artificial Analysis Index steht der Vorgänger bei 58 gegen 62 für _Fable 5_ , und eine Messung für den Snapshot gibt es dort noch nicht. Beim Frontend-Bauen ganz vorn, beim allgemeinen Reasoning eine Etage tiefer. ## Spark-X2.5 Open Weights in zwei Geschmacksrichtungen: Spark-X2.5 kommt als 1.7B und 4B, mit nativem 1-Mio.-Token-Kontextfenster und Apache-2.0-Lizenz, auf Hugging Face jeweils als Base, Instruct, FP8, INT8 und GGUF. Hinter dem Label XHToken steckt eine Tochter von iFlytek, trainiert wurde auf Huawei-Ascend-Clustern. Was kann das Teil also? Ollama beschreibt es als kompaktes Allzweckmodell für „conversation, writing, translation, reasoning, coding, tool use, and agentic workflows“, über 200 Sprachen inklusive. Das lange Kontextfenster läuft über eine Hybrid-Attention – ein Full-Attention-Layer auf drei Sliding-Window-Layer, damit der Speicherbedarf bei langen Kontexten nicht explodiert. Die Integrationen in _Codex_ , _Claude Code_ , OpenClaw und Hermes liefert iFlytek gleich mit, ebenso Support für vLLM, SGLang, llama.cpp, MLX, Ollama und LM Studio. Wenn man sich die Größe vor Augen hält, ist das wieder so ein Ding für die bessere Bürokiste – reichlich Potenzial für lokale Agenten, die lange Dokumente durchkauen sollen. Wobei der Speicherfresser nicht das Modell ist, sondern der KV-Cache, sobald du das Kontextfenster wirklich ausreizt. Benchmarks gibt es bislang nur aus dem eigenen Haus, verglichen mit _Qwen3.5-4B_ und _Gemma 4 E4B_. Warten wir auf unabhängige Zahlen. Am 7. September soll das große _Spark X2.5_ mit 293 Milliarden Parametern folgen. ## Quasar 438B Ich klaue mir mal ein Zitat von Fefe: > Von Microsoft lernen, heißt siegen lernen. Beim Ton haben sie bei Multiverse Computing jedenfalls aufgepasst. „Europe’s Leading AI Model“ steht über dem Launch von _Quasar 438B_ , einem Reasoning-Modell mit Schwerpunkt auf – na, wer möchte raten? – Agents und Coding. Es versteht sich auf Englisch und Spanisch(!), die Firma sitzt in San Sebastián, und dediziert als europäisches Modell wird es auch verkauft. Was in der Pressemeldung fehlt, steht bei Artificial Analysis im Modellnamen: „Quasar 438B (max, based on GLM-5.2)“. Das europäische Flaggschiff ist ein komprimiertes GLM-5.2 von Z.ai aus Peking, durch die hauseigene CompactifAI-Kompression gezogen und proprietär angeboten. Kann man machen. Dann sollte man es aber hinschreiben. Bei den Zahlen nehmen sie den Mund ganz schön voll, liefern dann aber auch: 43 Punkte im Intelligence Index, damit vor _Mistral Medium 3.5_ (30) und _Nemotron 3 Ultra_ (38), aber weit hinter _Claude Opus 5_ mit 63. Der nächste Verfolger steht allerdings in ihrer eigenen Tabelle – _Inkling_ kommt auf 42. Ein Punkt Vorsprung trägt kein Flaggschiff-Etikett. Artificial Analysis fasst zusammen: > … is amongst the leading models in intelligence, but particularly expensive when comparing to other models of similar price. It's also notably fast, however very verbose. The model supports text input, outputs text, and has a 1M tokens context window. Was sie mit teuer meinen: 0,60 $ Input und 1,80 $ Output je Million Tokens bei einem Klassen-Median von 0,25 und 0,90, im Index 350 Millionen Output-Tokens produziert gegen einen Median von 67 Millionen. Der Eval hat Artificial Analysis 1.047,71 $ gekostet. Heißt für mich: Wer sein Modell als europäisch verkauft, nennt die Basis im ersten Absatz und überlässt die Arbeit nicht Artificial Analysis. ## Muse Voice Transcribe Damit bei Meta Superintelligence Labs gar nicht erst Langeweile aufkommt, haben sie am 1. September ein Echtzeit-Transkriptionsmodell hinterhergekippt. Streaming-ASR, Diarization für 20 und mehr Sprecher, Endpointing – alles in einem Modell, ohne Post-Processing. Trainiert wurde mit über 70 Sprachen, 25 sind aktiv validiert: Arabisch, Bengalisch, Niederländisch, Englisch, Französisch, Deutsch, Hebräisch, Hindi, Indonesisch, Italienisch, Japanisch, Kannada, Koreanisch, Malaiisch, Mandarin-Chinesisch, Marathi, Polnisch, Portugiesisch, Spanisch, Tagalog, Tamil, Telugu, Thailändisch, Türkisch und Vietnamesisch. Code-Switching mitten im Satz geht auch. Meta sieht sich auf Artificial Analysis beim Streaming-WER mit 3,1 % auf Platz 1. Die Grafik dazu ist hausgemacht – abgelesen vom AA-Leaderboard, Stand 1. September. Auch hier ist der Preis wieder eine echte Ansage: 3 $ je 1.000 Audio-Minuten, also 0,18 $ pro Stunde verarbeitetes Audio, für Streaming und Batch gleich. _Gemini 3.5 Transcribe_ aus der letzten Woche liegt zum Vergleich bei rund 5 $ je 1.000 Minuten, die Live-Variante bei 9 $, und AssemblyAI verlangt für Streaming plus Diarization zusammen 0,57 $ die Stunde. Der Endpoint ist OpenAI-SDK-kompatibel. Was es nicht gibt, sind Open Weights. Anders als bei _Muse Glimmer_ bleiben die Gewichte im Haus, das hat Meta gegenüber The New Stack bestätigt. Meine These von letzter Woche, dass jede KI-Bude ein Transkriptionsmodell braucht, bevor sie sich AI-Lab nennen darf, hält damit eine weitere Woche. ## MCP was supposed to solve the agent tooling problem. It missed a step The New Stack erklärt Agentic Resource Discovery, kurz ARD. Die offene Spezifikation soll Agenten helfen, passende MCP-Server, Skills, APIs und andere Agenten dynamisch zu finden. MCP setzt voraus, dass der Client schon weiß, welchen Server er ansprechen will – ARD ergänzt die fehlende Discovery-Schicht davor. AWS nennt das „DNS, but for agents“, hat die Spec aber nicht geschrieben. Die Autoren kommen von Google, Microsoft und Hugging Face, mitgearbeitet haben Cisco, Databricks, GitHub, Nvidia, Salesforce und ein paar mehr, Lizenz Apache 2.0. Technisch ist das noch dünn. Version 0.91 vom 26. August, JSON-LD und REST, ein Pflicht-Endpoint `POST /search`, der nach Aufgaben sucht. Governance offen, eventuell Umzug zu W3C oder einer AI-Foundation. Der DNS-Vergleich hinkt auch, wie der Artikel selbst anmerkt: DNS liefert eine Adresse, ARD liefert mehrere Kandidaten, die alle behaupten, den Job zu können. ## Building commerce agents with Claude Anthropic hat am 2. September zwei Posts zu Commerce Agents rausgehauen – die Produktmeldung mit Referenzimplementierungen und den Engineering-Leitfaden dazu. Das Repo `anthropics/commerce-agents` enthält einen Shopping- und einen Merchant-Agenten für Retail, Travel, Telco und Ticketing, also Produktsuche, Warenkorb, Kundenservice, Bestandsanalyse, Preisgestaltung und Marketing. Enthalten sind passende Tools, Skills, Guardrails und ein Claude-Code-Plugin zur Anpassung an eigene Kataloge, Richtlinien und Systeme. Läuft über API, Bedrock, Foundry und Vertex. Der Leitfaden ist das lesenswertere Stück. Statt vieler spezialisierter Subagenten empfiehlt Anthropic einen zentralen Agenten im Standard-Loop mit Tools und bei Bedarf geladenen Skills, ohne Intent-Router – „Skills, not subagents“. UI-Komponenten werden als Tools behandelt, Latenz und Kosten drückt man über parallele Aufrufe und Prompt-Caching, für den Produktivbetrieb gehören Memory, Guardrails im Harness und ein Eval-Set dazu. Die Warenkorb-Zahlen in der Meldung – bis zu 35 % größer, 60 % höhere Kaufabschluss-Wahrscheinlichkeit – sind Kundenreferenzen von Shopify und Priceline, keine unabhängige Messung. Die Architektur-Entscheidung passt zu dem, was ich am Donnerstag über scheiternde Agenten geschrieben habe: Scope und Ownership vor Modellwahl. Was das Repo nicht liefert, sind saubere Kataloge und Bestandsdaten. Die musst du weiterhin selbst haben. ## Kimi in Codex und Claude Code Die Kimi API spricht drei Protokolle – OpenAI Chat Completions, OpenAI Responses und Anthropic Messages – und lässt sich entsprechend in _Codex_ und _Claude Code_ schrauben. Für Codex reicht ein Eintrag in der `config.toml`, weil Kimi die Responses API nativ bedient, ohne Proxy und ohne Protokollkonvertierung. Für Claude Code genügen ein paar Umgebungsvariablen auf den Anthropic-Endpoint. Wer Kimi K3 also ohne 1,5 TB Blech ausprobieren möchte, kann das im gewohnten Werkzeug tun. Mit den üblichen Sandbox-Warnungen. ## How to Build a Robust RAG System with Minimal Resources Zum Abschluss ein Handwerksstück, das schon vom 11. August ist, mir aber erst jetzt in den Feed gespült wurde. Machine Learning Mastery zeigt, wie sich ein robustes RAG-System ohne Cloud und ohne bezahlte APIs aufbauen lässt: quantisiertes lokales Modell (GGUF drückt ein 7B-Modell von 14 auf rund 4 GB), kompaktes Embedding-Modell aus sentence-transformers, dateibasierter Vektorspeicher über FAISS oder ChromaDB, Inference über llama.cpp oder Ollama. Der Teil, der den Artikel von den üblichen Tutorials abhebt, kommt nach der Pipeline. Zuverlässig wird das Ding erst durch das Drumherum – sauberes Chunking, Quellenangaben in der Antwort, eine Ähnlichkeitsschwelle, unter der das System „steht nicht in der Wissensbasis“ sagt statt zu halluzinieren, ein kleines Set an Testfragen und Logs, die Retrieval-Fehler von Generierungsfehlern trennen. Das sind die Stellen, an denen die meisten Bastel-RAGs still vor sich hin lügen. Schluss für diese Woche. Passt wie immer auf eure Agenten auf. Und auch auf eure API-Rechnungen.

t01.li

GPT-6 Astra löst GPT-5.6 Sol als OpenAIs Spitzenmodell ab. Der Sprung liegt bei Computer Use, langen Codex-Sessions und Cyber-Fähigkeiten – nicht im unabhängigen Intelligence Index. Die Tokenpreise steigen auf das 2,5-Fache, die Kosten pro Aufgabe nicht überall.

ChatGPT-6 Astra: Mehr Agent als GPT-5.6 Sol

OpenAI hat am 3. September _GPT-6 Astra_ vorgestellt. Der Rollout läuft zunächst über eine begrenzte Zahl von Organisationen, Plus, Pro, Business und Enterprise sollen in den kommenden Tagen folgen, dazu die OpenAI-API, Microsoft Azure und AWS Bedrock. Microsoft rollt Astra vorerst über das Foundry Limited Access Program an teilnehmende Kunden aus, für Amazon Bedrock kündigt OpenAI die Verfügbarkeit an, eine eigene AWS-Produktmeldung steht bislang aus. Bei mir ist noch nichts angekommen, daher ist das hier eine erste Einordnung der Daten und der offiziellen Ankündigung, die diesmal lang genug ist, um mehr als die übliche Benchmark-Parade herzugeben. _GPT-6 Astra_ ist kein günstigeres, schnelleres GPT-5.6 Sol, sondern ein LLM, das auf Computer Use, Coding-Agenten und kontrollierte Autonomie zugespitzt wurde. Am Preis lässt sich das ablesen. Während Sol zum aktuellen Aktionspreis 4 $ pro Million Input- und 20 $ pro Million Output-Tokens kostet, ruft OpenAI für Astra 10 beziehungsweise 50 $ auf, jeweils das 2,5-Fache. Diesen Sol-Preis garantiert OpenAI allerdings nur mindestens bis zum 21. November 2026, auf dem alten Listenpreis von 5 und 30 $ läge der Faktor bei 2. Für viele Standardaufgaben entscheidet das schon, bevor der erste Benchmark gelesen ist. ## TL;DR _GPT-6 Astra_ setzt andere Prioritäten als _GPT-5.6 Sol_. Es geht weniger um einen allgemeinen Intelligenz-Sprung als um lange, autonome Arbeit am Rechner. * Artificial Analysis führt beide Modelle im Intelligence Index gerundet mit 61 Punkten, OpenAIs Tabelle weist für denselben Index 61,2 zu 60,9 aus. * Große Sprünge meldet OpenAI bei Computer Use, Coding, Cybersecurity und Safety – überwiegend aus eigenen Evals. * Bei Cyber-Fähigkeiten erreicht Astra die Critical-Schwelle des OpenAI-eigenen Preparedness Framework. * Die API kostet 10 statt 4 $ Input und 50 statt 20 $ Output pro Million Tokens. * Für _Codex_ ist die neue Kontext-Persistenz die praktischste Neuerung, sofern sie hält, was OpenAI verspricht. ## Der unabhängige Index bleibt fast stehen Wen man auf die eine Zahl schaut, die nicht aus OpenAIs eigener Tabelle stammt, sieht man erst einmal keinen Erdrutsch. Artificial Analysis führt _GPT-6 Astra (max)_ mit 61 Punkten im Intelligence Index, _GPT-5.6 Sol (max)_ ebenfalls mit 61. Hinter der Rundung steht ein kleiner Abstand, in OpenAIs Vergleichstabelle sind es 61,2 zu 60,9 Punkte. Ein Gegenbeweis gegen Fortschritt ist das aber nicht, und den Index gegen alles andere auszuspielen wäre unredlich. Auf ARC-AGI-3 springt Astra von 7,8 auf 99,9 %, wobei OpenAI das Modell dort mit einem angepassten Responses-API-Harness laufen ließ. Auf FrontierMath Tier 4 steigt der Wert von 83,0 auf 97,6 %. Wo einzelne Evals derart kippen, bügelt ein Composite aus neun Aufgabenfeldern das glatt. Als kleiner Dämpfer taugt der Index trotzdem – gegen die Überschrift von der neuen Generation der Intelligenz und gegen Greg Brockman, der das Presse-Briefing mit „Welcome to the AGI era“ beendet hat. Für allgemeines Reasoning ist Astra nach diesem Maß nicht in einer anderen Liga. Die Kostenrechnung dreht das Bild dann noch einmal. Artificial Analysis misst bei Astra im Intelligence Index rund zehn Prozent weniger Output-Tokens pro Aufgabe als bei Sol. Der gewichtete Preis steigt trotzdem von 0,95 auf 1,67 $ pro Index-Task, weil Astra pro Token 2,5-mal so teuer ist – rund 75 % mehr. Gemeint ist die gewichtete Kostenmetrik für die neun Evals dieser Suite, nicht der Preis eines beliebigen API-Tasks. ## Computer Use ist der eigentliche Sprung OpenAI setzt den Schwerpunkt auf Computer Use, also Browser bedienen, Formulare ausfüllen, Oberflächen prüfen, Software installieren, Websites testen. Auf OSWorld 2.0 meldet das Unternehmen 72,6 % für Astra gegenüber 65,7 % für Sol. Für den Alltag eines Agenten wiegt die zweite Zahl schwerer: Astra soll dieselben Aufgaben in der Latenz-Simulation in rund 40 statt 75 Minuten erledigt haben. Beides braucht das übliche Hersteller-Sternchen. Gemessen wird nicht der volle Benchmark, sondern das Offline-Subset mit Partial Score, Stand 8. August 2026. Die Laufzeiten stammen aus OpenAIs Demonstrationsläufen, und die veröffentlichten Clips sind laut Fußnote gekürzt. Die 1,9-fache Beschleunigung auf Mind2Web schreibt OpenAI selbst nicht dem Modell allein zu, sondern der Kombination aus Astra und einem aktualisierten _Codex_ -Harness. Für die Praxis ist genau das relevant. Wer einen Agenten nicht nur Text produzieren, sondern durch einen Browser, ein CRM oder ein Repo arbeiten lässt, kauft immer das System darum herum mit – Tools, Berechtigungen, Guardrails und die Art, wie der Agent seinen Zustand hält. Der Fehler wäre nur, den Faktor 1,9 als reine Modellleistung weiterzuerzählen. ## Für Codex: Schluss mit Compaction-Amnesie? Wenn das Kontextfenster voll läuft, soll Astra in _Codex_ künftig Notizen über Fenstergrenzen hinweg behalten und ältere Fenster durchsuchen können. Bisher fasst ein Agent an dieser Stelle zusammen. Compaction spart Kontext und verliert gerne genau den gescheiterten Lösungsweg oder die Randbedingung, die drei Stunden später wieder wichtig wird. OpenAI verspricht keine magische Endlos-Konversation: das Kontextfenster von einer Million Tokens bleibt. Neu ist eine zweite Gedächtnisschicht aus Notizen für akkumulierte Details und einer Suche über frühere Nachrichten und Tool-Outputs. Bei Refactors, langen Debugging-Sessions und Frontend-Arbeit könnte das mehr verändern als ein paar Punkte auf Terminal-Bench. Feiern werde ich es aber erst, wenn ich einen echten mehrstündigen _Codex_ -Lauf daran brechen darf. Die Funktion ist zunächst experimentell, über die `config.toml` aktivierbar, und soll in den kommenden Wochen Standard für Astra werden. Wer _Codex_ für längere Repo-Arbeit nutzt, sollte den Vergleich deshalb nicht auf „Astra oder Sol?“ verkürzen. Es geht auch um die neue Harness. ## Mehr Cyber-Fähigkeiten, engere Grenzen Der Absatz, der in vielen Zusammenfassungen untergeht, steht unter Cybersecurity. Astra erreicht dort die Critical-Schwelle des OpenAI-eigenen Preparedness Framework, die höhere der beiden definierten Fähigkeitsschwellen. Die Zahlen dahinter stammen aus Läufen ohne Produktionsschutz: ExploitBench 100 % gegen 78,5 % für Sol, SRE-Bench 88,0 % gegen 55,9 % im ersten Versuch. Während der Auswertung fand das Modell zwei bis dahin unbekannte Zero-Days und nutzte sie, OpenAI meldet beide an die Maintainer. Im Produkt heißt Critical erst einmal weniger, nicht mehr. Astra darf Secure Code Review und Patching, verweigert aber fortgeschrittene Aufgaben wie das Bauen von Proof-of-Concept-Exploits. Lockerere Safeguards soll es in den kommenden Wochen über OpenAI Daybreak geben. Wenn du defensiv arbeitest, wirst du also ausgebremst, bevor du überhaupt richtig anfängst. Auf der Verhaltensseite zeigt OpenAI strengere Scope-Treue. In einem eigens gebauten Test überschritt Astra nie das autorisierte Ziel, Sol tat das ohne Produktionsschutz in 48 % der Fälle. Ein internes Halluzinations-Eval liegt bei 4,2 % gegenüber 12,2 %, bei der Umgehung eines Auto-Review-Stopps meldet OpenAI null Fälle. Alles davon sind OpenAIs eigene Tests, teils gegen Konfigurationen ohne die Safeguards, die im Produkt aktiv sind. Und im selben Text steht der Satz, der es in keine Launch-Grafik geschafft hat: Astras schriftliches Reasoning ist schwerer zu überwachen als das von Sol, gemessen in Tests, die das Modell ausdrücklich zum Verstecken aufgefordert haben. OpenAI nennt das einen Rückgang, den man ernst nehme. Ein Modell, das seine Grenzen besser einhält und dabei schwerer zu kontrollieren ist, ergibt keinen reinen Fortschrittsbericht. Damit verschiebt sich der Trade-off. Astra darf offenbar mehr und wird enger überwacht, was für unkritische Recherche oder Copy keinen Vorteil bringt. Für Agenten mit Zugriff auf Browser, Infrastruktur oder Kundendaten ist es ein Produktmerkmal, das in der Benchmark-Headline untergeht. Dass die zusätzlichen Prüfungen legitime Arbeit verlangsamen, pausieren oder abbrechen können, schreibt OpenAI selbst. In ChatGPT und _Codex_ wird dann eine Bestätigung fällig, in der API stoppt der Task. ## Coding: starke Herstellerwerte, unabhängig ein knapperes Bild Auf Terminal-Bench 4.0 springt Astra laut OpenAI von 37,3 % auf 57,9 %, auf DeepSWE dagegen nur von 72,7 % auf 74,1 %. Bei bestimmten Terminal- und Agentenaufgaben sieht der Sprung groß aus, bei anderen Coding-Evals eher kleiner. OpenAI legt offen, dass die eigenen Messungen in einer Research-Umgebung oder über die API laufen und deshalb von ChatGPT abweichen können. Für FrontierCode bekam Astra außerdem eine Developer Message, die der aus _Codex_ ähnelt. Unredlich ist das nicht, bei Coding-Agenten gehören Harness und Arbeitsanweisung nun einmal zum Produkt. Ein neutraler A/B-Test im eigenen Repo sind diese Werte trotzdem nicht. Unabhängig gemessen wird es dann nüchterner. Artificial Analysis hat am Launch-Tag auch den Coding Agent Index aktualisiert. Astra kommt in _Codex_ auf 67 Punkte und liegt damit etwa gleichauf mit Claude Opus 5 und _Fable 5_ , während Fable 5.1 in _Claude Code_ mit 70 Punkten führt. Gegenüber Sol sind das zwei Punkte mehr, bei ungefähr gleichen Kosten pro Aufgabe – Astra braucht im Codex-Harness etwa ein Drittel der Tokens von _Sol_ (max) und rund ein Fünftel von _Claude Opus 5_ (xhigh). Was weiterhin fehlt, sind Tests mit echten Projekten, wiederholbaren Aufgaben und eigener Kostenmessung. ## Mein (vorläufiger) Take _GPT-6 Astra_ ersetzt _GPT-5.6 Sol_ nicht als pauschal bessere Modellwahl. Es ist das teurere Modell für die Klasse von Aufgaben, in der ein Agent lange am Rechner arbeitet, Kontext über viele Schritte hält und seine Grenzen respektieren soll. Zwischen den beiden liegt offenbar mehr als ein Versionssprung. Bei den Kosten lohnt sich dann aber der zweite Blick und zwar in beide Richtungen: Pro Token ist Astra 2,5-mal so teuer. Pro Aufgabe hängt es davon ab, wie viel das Modell redet: im Intelligence Index steigen die Kosten laut Artificial Analysis um rund 75 %, im Coding Agent Index landet Astra bei ungefähr demselben Preis pro Task wie Sol. Für Zusammenfassungen, Redaktionsarbeit und normale Analyse rechne ich deshalb weiter mit Sol, bzw. Terra, das als Daily Driver meist völlig ausreicht. Für einen langen _Codex_ -Refactor, Browser-QA oder einen kontrollierten Computer-Use-Workflow kann die Rechnung kippen. Zum ersten Eindruck von _GPT-5.6_ passt der gleiche Vorbehalt wie damals, der Zugang ist oft die eigentliche Geschichte. Diesmal kommt eine zweite Frage dazu. Nicht die größte Zahl in der Launch-Tabelle entscheidet, sondern ob das Zusammenspiel aus Modell, _Codex_ -Harness und Safety im eigenen Workflow weniger Schleifen produziert.

t01.li

Gemini 3.8 Flash legt bei Agenten und Coding zu. Warum gleicher Tokenpreis nicht gleiche Kosten bedeutet, was die Time per Task verrät und welche Thinking-Stufe für produktive Workflows taugt.

Gemini 3.8 Flash arbeitet härter und wird teurer

Seit dem 2. September gibt es Gemini 3.8 Flash. Der Vorgänger ist zu diesem Zeitpunkt drei Wochen alt. Es ist Googles dritter Flash-Release innerhalb von sechs Wochen und der vierte in weniger als vier Monaten, während das große Modell weiter fehlt. Das _3.5 Pro_ , das Sundar Pichai auf der I/O im Mai für den Folgemonat versprochen hatte, ist bis heute nicht erschienen. Ein _Gemini 4_ steckt nach Googles eigener Auskunft seit Juli im Pretraining. Die Flash-Reihe ist bei mir eines dieser Dinge, über die ich wenig schreibe und die ich dafür umso häufiger benutze. Textliche Zusammenfassungen, Generieren von HTML und CSS, als Arbeitstier in _n8n_ -Workflows. Das läuft seit Monaten im Hintergrund, zuletzt mit 3.7. Vor allem hinter meinen eigenen Obsidian-Workflows arbeitet Flash regelmäßig. Eine Sprachnachricht kommt über Telegram rein, das Modell transkribiert und strukturiert sie, am Ende liegt Markdown mit Frontmatter in meiner Inbox. Ähnliches passiert mit Webseiten, Screenshots und YouTube-Videos. Kein spektakulärer Agenten-Stunt, sondern Arbeit, die zuverlässig erledigt werden soll. Google nennt 3.8 Flash sein „most intelligent workhorse model“ und verspricht mehr Coding- und Agentenleistung bei gleicher Geschwindigkeit und gleichem Preis. Der erste Teil sieht nach den unabhängigen Messungen gut aus. An die anderen beiden gehört jeweils ein Sternchen. ## TL;DR Gemini 3.8 Flash legt vor allem bei agentischen Aufgaben und Coding zu. Der Tokenpreis bleibt bis Jahresende gleich, im Artificial-Analysis-Test wird 3.8 auf high pro erledigter Aufgabe trotzdem teurer und langsamer als der Vorgänger. * Artificial Analysis: 59 Punkte mit high statt 56 bei Gemini 3.7 Flash * Rund 305 Output-Tokens pro Sekunde, aber 2,5 statt 2,2 Minuten pro Aufgabe * 0,58 statt 0,40 $ pro Intelligence-Index-Task bei high * Medium erreicht 57 Punkte zum Task-Preis des bisherigen high * Der aktuelle API-Preis gilt bis Ende 2026 und verdoppelt sich am 1. Januar 2027 ## Drei Punkte mehr – und ausgerechnet Agenten profitieren Auf dem Artificial Analysis Intelligence Index erreicht _Gemini 3.8 Flash_ mit Thinking-Level high 59 Punkte. Der Vorgänger kam auf 56. Medium landet bei 57, low bei 52. Drei Punkte klingen jetzt nicht nach Generationssprung, aber es ist interessant, wo sie herkommen: Artificial Analysis sieht die stärksten Verbesserungen bei agentischen Evaluationen – also dort, wo ein Modell nicht nur eine Antwort formuliert, sondern Tools benutzt, mehrere Schritte plant und mit den Ergebnissen weiterarbeitet. Bei τ³-Banking legt 3.8 zwölf Punkte auf 45 % zu, der größte Einzelsprung im Index. Bei längeren Coding-Aufgaben sieht das Modell ebenfalls gut aus. Google gibt für DeepSWE v1.1 73,7 % an, gegenüber 65,3 % bei 3.7 Flash. Datacurve hat am 1. September nachgezogen: Das unabhängige DeepSWE-Leaderboard misst für _Gemini 3.8 Flash high_ 74 % ± 1 % bei durchschnittlich 2,36 $ pro Task. _Claude Opus 5 max_ kommt dort auf denselben Score – für 11,84 $. Hier hält der Herstellerwert der unabhängigen Nachmessung also ziemlich genau stand. Die reine Ausgabegeschwindigkeit bleibt erhalten. Artificial Analysis misst rund 305 Output-Tokens pro Sekunde, was für ein Modell dieser Leistungsklasse bemerkenswert bleibt. Pro erledigter Aufgabe dauert es trotzdem länger: Die Time per Task steigt von 2,2 auf 2,5 Minuten, dazu kommt eine Time to First Answer Token von 13,4 Sekunden gegenüber einem Median von rund 3 Sekunden bei vergleichbaren Reasoning-Modellen. Schnell pro Token ist eben nicht schnell pro Ergebnis. ## Gleicher Tokenpreis heißt nicht gleiche Rechnung Google verlangt bis Ende des Jahres weiterhin 0,75 $ pro Million Input-Tokens und 3,75 $ für den Output. Exakt die Preise von 3.7 Flash. Dass 3.8 bei komplexeren Aufgaben härter arbeitet, schreibt Google selbst. Das Modell führt mehr Reasoning-Schritte aus, ruft Tools häufiger auf und kann auf höheren Thinking-Leveln mehr Tokens verbrauchen. Artificial Analysis misst den Effekt bereits. Eine Aufgabe im Intelligence Index kostet mit _Gemini 3.8 Flash high_ im Mittel 0,58 $, bei _3.7 Flash high_ waren es 0,40. Das sind grob 40 % mehr, obwohl sich an der Preisliste kein Cent geändert hat. Als Ursache nennt Artificial Analysis rund 30 % mehr Output-Tokens pro Aufgabe – im Schnitt 48.000 – und zusätzliche Turns in den agentischen Tests. Damit wird „Preis pro Million Tokens“ bei Reasoning-Modellen langsam irrelevanter als Kennzahl. Entscheidend ist nicht, was eine Million Tokens kostet, sondern wie viele davon das Modell braucht, bis die Arbeit erledigt ist. Das zweite Sternchen sitzt 'ne Spur tiefer in der Fußnote: Die 0,75 beziehungsweise 3,75 $ sind Einführungspreise, und Google weist im Launch-Post darauf hin, dass sie am 31. Dezember 2026 auslaufen. Ab dem 1. Januar 2027 gelten 1,50 und 7,50 $. Wenn du gerade Workflows auf Flash umstellst, rechne mit dem Standardpreis und nicht mit dem Einführungspreis. ## Thinking-Level müssen wir dann mal testen Spannend sind die drei Thinking-Level. _Gemini 3.8 Flash_ unterstützt low, medium und high; `minimal` wirft laut Modellseite einen Fehler. Artificial Analysis misst 52 Punkte für low, 57 für medium und 59 für high. Zwischen medium und high liegen zwei Punkte. Bei den Kosten pro Benchmark-Aufgabe liegen 0,41 gegen 0,58 $ dazwischen, low landet bei 0,24. Medium kostet pro Aufgabe damit ungefähr so viel wie 3.7 Flash auf high und das bei einem Punkt mehr im Index. Google empfiehlt das im Launch-Post sogar selbst: Wer auf Recheneffizienz optimiert, soll niedrigere Effort-Level nehmen oder bei 3.7 Flash bleiben, das vollständig unterstützt bleibt. Wenn ein Hersteller in der eigenen Ankündigung die Bremse erwähnt, ist das bemerkenswert ehrlich. Ein Intelligence Index weiß trotzdem nicht, ob Gemini aus meiner hingemurmelten Sprachnachricht vernünftiges Frontmatter baut oder aus einer Webseite ein brauchbares Exzerpt zieht. Dort liegt für mich der interessantere Test. Die meisten Agents und Workflows brauchen kein maximal ausgereiztes Reasoning. Sie brauchen ein LLM, das Audio und Video versteht, strukturierte Daten zuverlässig ausgibt, genug Context Window verträgt und flott genug ist, damit eine Sprachnachricht nicht zum Batch-Job für den nächsten Morgen wird. Das konnte 3.7 bereits erfreulich gut. Technisch bringt 3.8 die gleiche Ausstattung mit: 1.048.576 Tokens Input, 65.536 Tokens Output, dazu Text, Bilder, Audio, Video und PDF als Input. Tool Calling, Structured Outputs, Search Grounding und Code Execution gehören zum Paket. Für solche Anwendungen würde ich zuerst medium gegen den bestehenden 3.7-Workflow stellen und für reine Extraktion und Zusammenfassungen auch low ausprobieren. High nur einzuschalten, weil 59 größer als 57 ist, ist eigentlich herzlich sinnlos. ## Die für Pipelines interessanteste Zahl steht im Safety-Absatz Ein Punkt geht zwischen den Coding-Benchmarks aber unter: Auf dem von Gray Swan durchgeführten Benchmark für indirekte Prompt Injection sinkt die Attack Success Rate von 9,2 % bei _Gemini 3.7 Flash_ auf 5,5 % bei _3.8 Flash_. _3.8 Flash Cyber_ liegt bei 6,0 %. Die Werte veröffentlicht Google in der Launch-Grafik; Gray Swan führte das Eval mit von Google bereitgestellten Checkpoints durch. Für meinen Anwendungsfall ist die Messung trotzdem die relevanteste im ganzen Release. Ich schiebe generiertes Markdown aus fremden Websites, Screenshots und YouTube-Transkripte durch ein Modell, das anschließend strukturiertes Markdown in meinen Vault schreibt. Jede dieser Quellen ist Text, den ich nicht kontrolliere. Wenn du solche Pipelines betreibst, ist diese Zahl praktisch wichtiger als der Intelligence Index. ## Gemini 3.8 Flash Cyber bleibt hinter verschlossenen Türen Parallel veröffentlicht Google _Gemini 3.8 Flash Cyber_. Technisch steckt dieselbe grundlegende Intelligenz dahinter, die Sicherheitsgrenzen für Cybersecurity-Aufgaben sind allerdings permissiver. Das Muster ist bei Google nicht neu. Schon _Gemini 3.5 Flash Cyber_ lief im Juli als limitierter Pilot für Behörden und ausgewählte Partner. Auch OpenAI fährt bei seinen Cyber-Modellen einen Restricted-Access-Ansatz: leistungsfähigere offensive und defensive Fähigkeiten, dafür kein frei zugänglicher API-Key für Hinz und Kunz. Den Zugang wickelt Google über das neue Fairwind Program ab, das _Gemini 3.8 Flash Cyber_ mit dem Agent-Harness _CodeMender_ fürs Finden und Patchen kombiniert. Mehr als 650 Organisationen gehören laut Google bereits dazu, unter anderem Betreiber kritischer Infrastruktur, Behörden, Cloud-Kunden und Security-Anbieter. Auf CyberGym erreicht 3.8 Flash Cyber nach Googles Angaben 86,2 % Pass@1. Beim von Collinear betriebenen externen CWE-Bench für automatisches Patchen kommt das Modell auf 47,2 % gegenüber 47,8 % bei _Claude Fable 5_ – bei deutlich niedrigeren Rollout-Kosten. CyberGym bleibt hier ein von Google berichteter Modell-Run; CWE-Bench hat die stärkere externe Evidenz. Breite Nachtests sind wegen des eingeschränkten Modellzugangs allerdings schwierig. ## Der interessante Benchmark läuft woanders _Gemini 3.8 Flash_ sieht nach einem gelungenen Update aus. Die unabhängigen Zahlen bestätigen den Sprung bei agentischen Aufgaben, die Ausgabegeschwindigkeit bleibt hoch, und medium kommt erstaunlich nah an high heran. Meinen Maßstab setze ich trotzdem nicht bei 59 Punkten an. Bei meinen bestehenden Workflows und auch diversen Pipelines ist die Referenz _3.7 Flash_. Das Modell funktioniert dort. Es fasst Texte vernünftig zusammen, produziert brauchbares HTML und CSS und verarbeitet Audio, Videos und andere multimodale Inputs zuverlässig genug, dass ich darüber nicht mehr nachdenken muss. Für ein Arbeitsmodell ist das ein ziemlich gutes Kompliment. Ob 3.8 diesen Platz übernimmt, entscheidet ein banaler A/B-Test. Gleiche Inputs, gleiche Prompts, gleiche Workflows, danach Output-Qualität, Laufzeit, Fehlerquote und tatsächliche Kosten vergleichen. Liefert medium dieselbe Zuverlässigkeit und fängt schwierige Fälle besser ab, nehme ich das Upgrade gern mit. Verbrennt 3.8 dagegen hauptsächlich mehr Tokens, während meine Dokumente am Ende genauso aussehen wie vorher, darf 3.7 noch eine Weile weiterarbeiten – Google selbst hat gegen diesen Plan ja ausdrücklich nichts. Bei drei Flash-Modellen in sechs Wochen ist das ohnehin die pragmatischere Haltung. Ein neuer Modellname ist noch kein Migrationsgrund.

t01.li

Meta legt Muse Spark 1.3 nach. Artificial Analysis misst einen klaren Sprung bei Agenten-Aufgaben – bei unverändert niedrigen Tokenpreisen. Warum das Modell bei mir auf die Testliste kommt.

Muse Spark 1.3: Metas Agentenmodell wird besser – und bleibt auffällig günstig

Meta hat am 2. September Muse Spark 1.3 veröffentlicht, vier Wochen nach dem Vorgänger. Es ist das vierte Muse-Spark-Release in fünf Monaten. Das Tempo sagt fast mehr über die Strategie aus als die Versionsnummer selbst. Muse Spark 1.2 hatte ich in den AI Picks der 32. Kalenderwoche bereits kurz ausprobiert. Für ein belastbares Urteil über 1.3 ist es zu früh – einen eigenen Lauf habe ich noch nicht gefahren. Weit oben auf der Liste für die nächsten Wochen steht die neue Version bei mir dennoch, und das liegt weniger an einer einzelnen Benchmark-Zahl als an der Kombination aus agentischer Leistung und Preis. ## TL;DR Meta schiebt Muse Spark 1.3 vor allem bei langen agentischen Workflows nach vorn. Die ersten unabhängigen Werte von Artificial Analysis bestätigen einen messbaren Sprung – bei der Kostenfrage wird es dann komplizierter, als die unveränderten Tokenpreise vermuten lassen. * Artificial Analysis: 61 Punkte für xhigh, vier mehr als Muse Spark 1.2 – gleichauf mit GPT-5.6 Sol (max), Grok 4.6 (high) und Claude Opus 5 (high) * Kontextfenster von einer Million Tokens, multimodaler Input, Fokus auf lange Agenten- und Coding-Tasks * Tokenpreise unverändert bei 1,25 / 4,25 $ pro Million Input-/Output-Tokens * Der Preis pro Intelligence-Index-Task steigt trotzdem: von 0,40 auf 0,55 $ * Daneben ein Contributor-Tarif zu 0,10 / 0,20 $ – dafür darf Meta Eingaben und Ausgaben zur Produktverbesserung verwenden ## Weniger Agenten-Gewusel, mehr Aufgabe zu Ende bringen Metas eigener Pitch für 1.3 dreht sich auffällig wenig um klassische Chat-Fähigkeiten. Das Modell soll längere Aufgaben besser durchhalten, mehrere Workflows innerhalb eines Threads auseinanderhalten und Anforderungen über viele Schritte hinweg weniger schnell verlieren. Das passt zur Richtung, die Muse schon mit 1.2 eingeschlagen hat. Kein Chatbot, der zufällig auch Tools bedienen kann, sondern ein Modell, das ziemlich eindeutig für Tool Calling, Coding und längere Agent-Loops trainiert wird. Meta äußert ein paar Änderungen, die im Alltag relevanter sein könnten als zwei Punkte auf irgendeinem Leaderboard: _Muse Spark 1.3_ soll bei unklaren Aufgaben häufiger nachfragen, erkennen, wenn es feststeckt, und vor folgenreichen Aktionen eine Bestätigung einholen. Gleichzeitig will Meta die unnötigen Schleifen reduziert haben. In internen Vergleichen mit 1.2 brauchte das Modell rund 20 % weniger Tool Calls und 25 % weniger Tokens. Das sind Werte von Meta, aber immerhin Werte, die ein reales Problem treffen. Ein Agent, der zehn Minuten lang beeindruckend nachdenkt, zwölf Tools aufruft und am Ende doch noch einmal dieselbe Datei liest, ist keine höhere Form der Intelligenz – er ist erstmal einfach nur teuer. ## Muse Spark 1.3 bei Artificial Analysis: Der Sprung ist messbar Aufschlussreicher sind die ersten unabhängigen Messungen. Artificial Analysis führt Muse Spark 1.3 in zwei Reasoning-Stufen. xhigh ist regulär verfügbar, max liegt in einer begrenzten Preview für Metas Partner. Meta selbst beschreibt denselben Zustand anders und schreibt, max reasoning komme, sobald zusätzliche Sicherheitstests abgeschlossen seien. Die xhigh-Variante kommt im Artificial Analysis Intelligence Index auf **61 Punkte**. _Muse Spark 1.2_ lag bei 57, _Muse Spark 1.1_ bei 53. Die max-Variante schafft 62. Vier Punkte von 1.2 auf 1.3 sind ordentlich, zumal die Gewinne nicht nur aus einem einzelnen Ausreißer stammen. Besonders stark legt 1.3 bei agentischen Aufgaben zu. Im Tau3-Bench Banking steigt xhigh von 35 % auf 47 %, bei Terminal-Bench 2.1 von 80 % auf 85 %. GDPval-AA v2 geht von 1.615 auf 1.709 Elo hoch. Wer mit Benchmarks arbeitet, kennt das Sternchen trotzdem. Auch ein unabhängiger Index sagt nichts über deine Task-Verteilung. Harness, Reasoning-Einstellung und Tool-Setup entscheiden mit darüber, was am Ende gemessen wird. Metas eigene Release-Grafik liegt bei Terminal-Bench 2.1 mit 88,8 % noch einmal höher. Der Vergleich hat dort einen Haken. Meta stellt 1.3 im max-Modus gegen 1.2 im xhigh-Modus – und ausgerechnet max kann man beim Launch nicht regulär buchen. Zugunsten von 1.3 verzerrt das hier ausnahmsweise nichts, im direkten xhigh-zu-xhigh-Vergleich kommt 1.3 sogar auf 89,2 statt 82,9 % bei 1.2. Kleine Rückschritte gibt es ebenfalls. Bei AA-LCR fällt 1.3 von 83 % auf 79 %, bei AA-Omniscience sinkt die Accuracy um drei Punkte. Artificial Analysis führt Letzteres darauf zurück, dass das Modell häufiger gar nicht antwortet, wenn es unsicher ist. Weniger Raten senkt dann zwar die Trefferquote, senkt bei xhigh gleichzeitig aber auch die Halluzinationsrate. So eine Regression nehme ich lieber genauer auseinander, bevor ich sie pauschal als Verschlechterung verbuche. ## Das Preisschild sagt mir mehr als der Indexwert Die regulären API-Preise bleiben gegenüber 1.2 unverändert. **1,25 $ pro Million Input-Tokens, 4,25 $ pro Million Output-Tokens** , Cache-Hits kosten 0,15 $ pro Million Tokens. Trotzdem wird eine erledigte Aufgabe teurer. Artificial Analysis rechnet zusätzlich in Kosten pro Intelligence-Index-Task, und da klettert xhigh von 0,40 $ bei 1.2 auf **0,55 $** bei 1.3. Verantwortlich dafür ist der Verbrauch. In den agentischen Evals zieht 1.3 rund 57 % mehr Input-Tokens pro Task. Auf den ersten Blick beißt sich das mit den 25 %, die Meta weiter oben verspricht. Sauber auflösen lässt sich der Unterschied nicht. Meta nennt rund 25 % weniger Tokens aus internen Vergleichen seiner Engineers, ohne Input und Output getrennt auszuweisen, während Artificial Analysis in den eigenen agentischen Evals rund 57 % mehr Input- und etwa 8 % mehr Output-Tokens misst. Andere Aufgaben, anderes Harness, andere Reasoning-Konfiguration. Was bleibt, ist die Rechnung selbst: Gleiche Tokenpreise bedeuten noch lange nicht gleiche Kosten pro erledigter Aufgabe. In den Messungen von Artificial Analysis wächst sie vor allem auf der Input-Seite – wer nur die Antwortlänge optimiert, greift zu kurz. Günstig bleibt _Muse Spark 1.3_ am Ende doch. Auf 61 Punkten liegt xhigh gleichauf mit GPT-5.6 Sol (max), Grok 4.6 (high) und Claude Opus 5 (high). Deren Kosten pro Task liegen bei 0,95, 0,94 und 1,23 $, also bei mindestens 70 % Aufschlag. Unter allen Modellen ab 59 Indexpunkten erledigt aktuell keines eine Aufgabe billiger. Für ein Reasoning-Modell mit einem Kontextfenster von einer Million Tokens, multimodalem Input und brauchbarer agentischer Leistung ist das keine Nebensache. Ein zweites Preisschild hängt allerdings daneben. Neben dem Standard-Endpunkt listet Metas Preisseite einen Contributor-Tarif zu 0,10 $ Input und 0,20 $ Output, Cache-Reads bei 0,002. Der Standardtarif kostet beim Input zwölfeinhalbmal so viel, beim Output gut 21-mal. Was der Rabatt kostet, steht in der Spalte daneben: Standard wird nicht zur Produktverbesserung verwendet, Contributor schon. Für ein Wochenendprojekt ist das ein fairer Tausch. Bei Kundencode beantwortet die Frage nicht die Technik, sondern die Rechtsabteilung. ## Eine Million Context bleibt – Open Weights sollen kommen Technisch bleibt einiges beim Bekannten. Das Kontextfenster liegt weiterhin bei einer Million Tokens, als Input verarbeitet _Muse Spark 1.3_ Text, Bilder und Video. Text kommt wieder als Output zurück. Meta kündigt außerdem an, später Open Weights für Muse Spark zu veröffentlichen. Mehr steht da nicht. Kein Datum, keine konkrete Variante, keine Lizenz. Dieses Versprechen gab es schon einmal. Am 10. August kündigte Metas Chief AI Officer Alexandr Wang an, eine Open-Weight-Version von _Muse Spark 1.2_ komme „soon“, zusammen mit _Muse Glimmer_ , einem 30B-Agentenmodell unter Apache 2.0. Glimmer kam. Die Spark-Weights nicht. Drei Wochen später steht im Blogpost zu 1.3 wieder eine Open-Weight-Ankündigung – diesmal nur noch generisch für „Muse Spark“. Ob Meta damit weiterhin die angekündigte 1.2-Version, inzwischen 1.3 oder etwas anderes meint, bleibt offen. Das Muster kenne ich vom „Open-Weight, nur ohne Weights“-Intermezzo bei MiniMax M3. Nur kommt es hier von derselben Firma zum zweiten Mal innerhalb von vier Wochen. Ich behandle solche Sätze deshalb so, wie sie gemeint sind: als Roadmap, nicht als Release. Sollten die Weights tatsächlich kommen, schaue ich noch einmal aus einer ganz anderen Richtung auf das Modell. Bis dahin ist _Muse Spark 1.3_ ein proprietäres API-Modell und läuft über die Meta Model API oder über _Muse Code_ , Metas Coding-Agent für das Terminal. ## Warum ich 1.3 testen werde Der Vorgänger hatte genug Substanz, dass ich Muse Spark nicht einfach als weiteres Modell im Release-Strom ins Regel gestellt habe. 1.3 verschiebt die Sache noch stärker in Richtung agentischer Workloads – dorthin, wo ein Modell nicht nach einer schönen Einzelantwort beurteilt wird, sondern danach, ob es Anforderungen behält, Tools sinnvoll benutzt und eine Aufgabe irgendwann tatsächlich fertig bekommt. Auf dem Papier sieht das alles erst mal gut aus. Artificial Analysis liefert diesmal auch früh genug unabhängige Zahlen, um nicht nur Metas Pressemitteilung nacherzählen zu müssen. Aber der Teil, der für mich am Ende zählt: ein eigener Lauf mit realen Aufgaben. Coding, Recherche, längere Tool-Ketten und vor allem die Frage, wie viel von der versprochenen Effizienz nach zwei Stunden echter Arbeit noch übrig ist. Den Test hole ich in den nächsten Wochen nach. Nicht weil irgendwo 61 statt 57 Punkte stehen – sondern weil das Verhältnis aus Leistung und Kosten mich neugierig genug macht, um zu wissen, wo der Haken sitzen könnte – vielleicht.

t01.li

Drei aktuelle Studien zeigen dasselbe Muster: Bei KI-Agenten entscheiden Datenqualität, enger Scope und klare Ownership oft mehr als die Modellwahl. Was McKinsey, Salesforce und Teradata dazu messen – und welche drei Fragen vor dem Modellnamen gehören.

Warum die Modellwahl KI-Agenten nicht rettet – Daten, Scope und Ownership schon eher

In fast jedem Gespräch über KI-Agenten fällt irgendwann die Modellfrage. _Claude_ , _GPT,_ _Gemini_ oder etwas ganz Anderes – als hinge daran das Projekt. Der Reflex ist verständlich. Die Modellwahl fühlt sich nach der großen Weichenstellung an. Drei aktuelle Studien von McKinsey, Salesforce und Teradata zeichnen allerdings ein erstaunlich ähnliches Bild: Das Modell spielt eine Rolle, nur trennt es erfolgreiche Agenten-Projekte weit weniger zuverlässig von gescheiterten als Daten, Scope und die Organisation drumherum. Was stattdessen den Ausschlag gibt, klingt unspektakulär – die Qualität der Daten, die Enge des Auftrags und die Frage, wer für Ergebnis und Fehler geradesteht. Datenqualität und Ownership lassen sich mit keinem besseren Systemprompt reparieren. Einen Scope kann ich zwar in `AGENTS.md` oder den System Instructions beschreiben, aber damit ist noch lange nicht sichergestellt, dass Datenzugriff, Tools und Prozessgrenzen dazu passen. Und Genau deshalb wird es unbequem. ## TL;DR Drei Studien aus dem Sommer 2026 zeichnen dasselbe Muster: Bei KI-Agenten entscheiden Daten, enger Scope und klare Verantwortung häufig stärker über den ROI als die Modellwahl. * Nur 22 % der kleineren Unternehmen skalieren Agenten, bei Unternehmen über einer Milliarde Dollar Umsatz sind es 40 % (McKinsey) * 77 % der Führungskräfte sagen, höchstens ein Fünftel ihrer Daten sei ausreichend für Agenten beschrieben und kontextualisiert (Teradata) * Saubere Daten (36 %), enger Scope (36 %) und Eskalationswege (35 %) liegen vor Modellqualität und Plattformwahl als ROI-Faktoren (Salesforce) * Drei Fragen gehören vor die Modellwahl: Welcher Prozess? Welche Daten? Wessen Verantwortung? ## Drei Studien, ein Muster McKinsey hat Ende August die Ausgabe 2026 der State-of-AI-Umfrage veröffentlicht. Befragt wurden im Mai und Juni 1.719 Führungskräfte in 97 Ländern. Bei Unternehmen ab einer Milliarde Dollar Jahresumsatz stieg der Anteil, der Agenten in mindestens einer Funktion skaliert, binnen eines Jahres von 27 auf 40 %. Bei kleineren Organisationen blieb er bei 22 % – exakt auf Vorjahresniveau. Die Lücke im System ist damit deutlich. Warum sie entsteht, beantwortet McKinsey an dieser Stelle allerdings nicht. Aus „unter einer Milliarde Dollar Umsatz“ direkt „Mittelstand ohne Datentea“ zu bauen, wäre mehr Interpretation als Studienbefund. Für kleinere Unternehmen bleibt die Zahl trotzdem relevant: Beim Skalieren öffnet sich die Schere. Fast zeitgleich hat Salesforce den State of Agentic AI in the Enterprise vorgelegt, eine Befragung von 2.025 Entscheidern in 20 Ländern. Davon haben 30 % Agenten bereits produktiv ausgerollt, 47 % pilotieren und 23 % befinden sich noch in der Evaluierung. Die meisten Detailergebnisse beziehen sich auf die produktiven Deployments. Die drei stärksten Prädiktoren für messbaren ROI sind dort saubere, zugängliche Daten (36 %), ein eng definierter Use Case (36 %) und vorab festgelegte Eskalationswege zu Menschen (35 %). Modellqualität, Plattformwahl und einheitliche Orchestrierung landen jeweils bei rund 30 %. Das ist kein riesiger Abstand – und schon gar kein Beleg dafür, dass das Modell egal wäre. Aber eben auch keiner für die verbreitete Idee, mit dem neuesten Frontier-Model sei der wichtigste Teil der Architektur bereits entschieden. Herstellereigene Zahlen, klar – Salesforce verkauft mit _Agentforce_ genau das Produkt, um das es hier geht. Wenn allerdings ausgerechnet der Plattformanbieter schreibt, dass selbst das beste Modell ein schlechtes Setup nicht rettet, lässt sich das zumindest schlecht als Werbung für den nächsten Modellwechsel lesen. Die dritte Perspektive liefert Teradata mit „Arrested Automation“, einer von Wakefield Research durchgeführten Befragung von 1.000 Tech- und Data-Führungskräften in sechs Märkten. 90 % wollen ihre Agenten-Investitionen in den nächsten zwölf Monaten erhöhen. Gleichzeitig berichten 63 % bislang von höchstens kleinen oder gerade erst entstehenden positiven Returns. Auf der Reifegradskala der Studie haben nur 7 % die Stufe „Operationalizing“ erreicht. Natürlich gehört auch hier ein Hersteller-Sternchen dran, denn Teradata verkauft Datenplattformen. Beratung, CRM-Plattform und Datenanbieter betrachten das Problem aus unterschiedlichen Eigeninteressen – und landen trotzdem bei einem ähnlichen Muster. Wer dafür noch einen älteren Rahmen braucht: Schon die MIT-NANDA-Studie von 2025 berichtete, dass rund 95 % der untersuchten GenAI-Initiativen keinen messbaren P&L-Impact erzielten. Der Report selbst formulierte ausdrücklich, dass die Trennlinie offenbar nicht bei Modellqualität oder Regulierung lag, sondern beim Implementierungsansatz. Die Methodik des vorläufigen Reports wurde zu Recht diskutiert und die Datenbasis ist überschaubar. Als Beleg für eine 95-prozentige „Failure Rate von KI“ taugt er nicht. Die Richtung passt aber zu den drei aktuelleren Studien. ## Die 77-Prozent-Zahl, über die kaum jemand spricht Die für mich wichtigste Zahl steckt im Teradata-Report etwas versteckt. 77 % der befragten Führungskräfte geben an, dass höchstens 20 % ihrer Unternehmensdaten ausreichend beschrieben und kontextualisiert sind, damit Agenten verlässlich damit arbeiten können. Teradata nennt das „Context Fragmentation“ – die Daten existieren, aber ihnen fehlen Zusammenhänge, Herkunft, Bedeutung oder Governance. Das deckt sich mit dem, was ich in Projekten und aus eigenen Evals beobachte. Der größte Fallstrick ist die Datenlage, und zwar qualitativ, nicht quantitativ. Der Punkt wird gern ignoriert, bewusst oder aus Unwissen, nach dem Motto „die KI regelt das schon“. Ein Blick in die Ergebnisse zeigt dann regelmäßig das Gegenteil. Ein Beispiel aus dem eigenen Werkzeugkasten: Mit _Targeta_ betreiben wir ein agentisches System, das Zielgruppen-Personas als Hypothesen anhand von Modellen aus Marktforschung, Psychologie und Soziologie entwickelt – ausdrücklich auch ohne Primärdaten, mit offen markierten Annahmen statt versteckter Gewissheit. Ausgerechnet dieses System, das für den Umgang mit Annahmen gebaut wurde, lebt von der Vollständigkeit seiner Eingangsdaten. In den Evals werden die Ergebnisse mit dünner Datenlage deutlich schwächer, weil das Modell hinter dem Agenten zwangsläufig anfängt, zu raten. Und geratene Analyse sieht auf den ersten Blick genauso aus wie fundierte, nur stimmt sie eben nicht. Der Mechanismus lässt sich verallgemeinern. Ein Agent mit Zugriff auf widersprüchliche oder schlecht beschriebene Daten liefert selten offensichtlich absurden Unsinn. Er füllt die Lücken mit plausiblen Mustern. Das Ergebnis wirkt konsistent, ist aber im schlechtesten Fall Konfabulation mit Geschäftsbezug. Ein besserer Prompt kann dem Modell sagen, wie es mit Unsicherheit umgehen soll. Er kann fehlende Herkunft, widersprüchliche Stammdaten oder veraltete Informationen aber nicht herbeizaubern. Das Problem liegt vor dem Prompt. ## Eng gedacht schlägt groß gedacht Aus der Salesforce-Befragung stammt noch ein Detail, das gerade für kleinere Unternehmen eine gute Nachricht ist: Nur 31 % der Organisationen mit produktiv eingesetzten Agenten hatten ihre Daten vorher vollständig vereinheitlicht. Sie erreichten den angegebenen ROI im Mittel nach 7,3 Monaten. Weitere 34 % gingen iterativ vor, integrierten also nach und nach weitere Daten, und kamen nach 8,2 Monaten dort an. Heißt: knapp einen Monat Unterschied. Du musst also nicht zuerst das ganze Data Warehouse in einen Zustand bringen, bei dem selbst der letzte Data Steward zufrieden lächelt. Salesforce zufolge haben die meisten erfolgreichen Organisationen ihre Datenbereitschaft auf den konkreten Use Case begrenzt. Entscheidend ist die Scheibe, die der Agent für diesen einen Prozess braucht. Das ist eine deutlich realistischere Aufgabe. Bemerkenswert ist auch, wie selten Vollautonomie in der Praxis vorkommt. Nur 1 bis 2 Prozent der Organisationen mit produktiven Agenten berichten von Systemen ganz ohne menschliche Beteiligung. Human-in-the-loop ist damit nicht das peinliche Übergangsstadium auf dem Weg zur großen autonomen Maschine, sondern ziemlich genau der Normalfall. Wer seinen Agenten plant, plant die Übergabe an Menschen gleich mit – inklusive der Frage, wann sie passieren muss. ## Und das Modell? Doch, es spielt eine Rolle So bequem wäre die Geschichte sonst auch wieder nicht. Gartner prognostizierte im Sommer 2025, dass bis Ende 2027 über 40 Prozent aller Agentic-AI-Projekte eingestellt werden. Als zentrale Gründe nennt Gartner eskalierende Kosten, unklaren Geschäftswert und unzureichende Risikokontrollen. Gleichzeitig schreibt Gartner im selben Text ausdrücklich, dass aktuelle Modelle für komplexe autonome Geschäftsziele und langfristig nuancierte Anweisungen teilweise noch nicht reif genug seien. Das Modell ist also nicht egal. Die interessantere Aussage ist eine andere: Selbst ein starkes Modell löst weder einen schlechten Use Case noch fehlende Daten, unklare Zuständigkeiten oder ein kaputtes Kostenmodell. Und ein schwächeres Modell kann selbstverständlich die Grenze sein, wenn der konkrete Prozess Fähigkeiten verlangt, die es nicht zuverlässig beherrscht. Modellqualität ist eine technische Voraussetzung. Sie ist nur keine Organisationsstrategie. Passend dazu prägte Gartner den Begriff „Agent Washing“. Von Tausenden Anbietern, die sich das Agenten-Etikett anheften, schätzt Gartner nur rund 130 als tatsächliche Anbieter agentischer Technologie ein. Auch das ist vielleicht ein Grund, erst über den Prozess und anschließend über den Produktkatalog zu reden. ## Wem gehört der Fehler des KI-Agenten? Die dritte Baustelle ist die am wenigsten sichtbare. In der aktuellen McKinsey-Umfrage sagen 80 Prozent der Befragten, KI habe ihre persönliche Produktivität verbessert. Auf Unternehmensebene schreiben aber nur 37 Prozent KI überhaupt einen positiven EBIT-Effekt zu. Gerade einmal 6 Prozent gelten als High Performer mit mindestens 5 Prozent EBIT-Beitrag und gleichzeitig signifikantem Wertbeitrag – beide Werte praktisch unverändert zum Vorjahr. Das belegt nicht, dass fehlende Ownership die Ursache dieser Lücke ist. Meine Lesart ist trotzdem: Persönliche Produktivitätsgewinne sind vergleichsweise einfach. Unternehmenswert entsteht erst, wenn der Prozess drumherum ebenfalls verändert wird. Genau dazu liefert McKinsey den interessanteren Befund. Knapp drei Viertel der High Performer haben ihre Workflows wegen KI grundlegend umgebaut. Bei den übrigen Befragten ist es ungefähr ein Viertel. High Performer berichten doppelt so häufig von sichtbarem Commitment der Führungsebene – und von definierten Prozessen, um den Impact überhaupt zu messen. Damit wird die Ownership-Frage unangenehm konkret. Wer besitzt das Ergebnis des Agenten? Wer den Fehler, wenn er nachts um drei eine falsche Gutschrift auslöst – und wer merkt das überhaupt? Wer entscheidet, wann ein Mensch übernehmen muss? Und wer besitzt die Weiterentwicklung, wenn sich der Prozess ändert und der Agent stillschweigend gegen Annahmen aus dem vergangenen Jahr läuft? „IT“ ist darauf keine brauchbare Antwort. ## Drei Fragen vor dem Modellnamen Wenn die Studienlage etwas hergibt, dann eine Reihenfolge. Vor der Modellwahl gehören drei Fragen beantwortet, schriftlich und ohne Weichzeichner. 1. Welchen klar abgegrenzten Prozess übernimmt der Agent – und welchen ausdrücklich nicht? 2. Auf welche Daten greift er zu, und sind die für genau diesen Ausschnitt vollständig, beschrieben und aktuell? 3. Wer besitzt Ergebnis, Fehler und Weiterentwicklung, mit Namen statt Abteilungskürzel? Wer alle drei beantworten kann, für den wird die Modellfrage danach interessant. Dann kann man sinnvoll testen, ob _Claude_ , _GPT_ , _Gemini_ oder ein ganz anderes Modell die notwendigen Fähigkeiten, Latenzen und Kosten liefert. Wer die drei Fragen nicht beantworten kann, braucht noch kein Modell-Benchmarking, sondern erst mal einen Termin mit den eigenen Daten und Prozessen. Der ganze heiße Take zum Schluss: Die Modellfrage ist die beliebteste Frage im Raum, weil sie sich per Kreditkarte beantworten lässt. Die drei anderen kosten Arbeit. Deshalb stellt sie kaum jemand.

t01.li

Anthropic veröffentlicht Claude Fable 5.1 und Mythos 5.1 als identisches Modell mit verschiedenen Safeguards. Auf Terminal-Bench 4.0 trennen sie 5,1 Punkte – nur wurden dafür noch die älteren, gröberen Filter gemessen.

Claude Fable 5.1 und Mythos 5.1: was Safeguards kosten

Anthropic hat heute Claude Fable 5.1 und Claude Mythos 5.1 veröffentlicht, beide am selben Tag, beide auf demselben Modell. Getestet habe ich nichts davon, der Release ist beim Schreiben dieses Artikels eine gute Stunde alt. Unabhängige Zahlen gibt es daher auch noch nicht – bei Artificial Analysis stehen weiterhin die Werte von Fable 5. In den nächsten Tagen dürften die ersten unabhängigen Benchmarks folgen. Trotzdem lohnt der Blick. Nicht, weil Anthropic zum ersten Mal zeigt, dass Safeguards Leistung kosten – das stand bereits bei Fable 5 in der System Card. Dieses Mal liegt die Differenz allerdings unübersehbar in der Launch-Tabelle, samt Erklärung, woher sie kommt und warum sie mit den heute ausgelieferten Filtern kleiner ausfallen dürfte. ## TL;DR Anthropic liefert _Fable 5.1_ und _Mythos 5.1_ als dasselbe Modell mit unterschiedlich permissiven Safeguards aus: * _Fable 5.1_ ist allgemein verfügbar, _Mythos 5.1_ bleibt vorerst ausgewählten US-Organisationen vorbehalten * Auf Terminal-Bench 4.0 liegen beide 5,1 Punkte auseinander – 55,8 % gegen 60,9 %. Die Lücke stammt allerdings noch von den älteren, gröberen Cyber-Safeguards * Input und Output bleiben bei 10 $ / 50 $ pro Million Tokens. Nur Cache-Reads sinken um 75 % auf 0,25 $ * Die neuen Cyber-Safeguards greifen pro Claude-Code-Session rund 60 % seltener ein. Dual-Use-Aufgaben werden weiterhin an Opus-Modelle weitergeleitet * Neue API-Accounts können beim Editieren früherer Turns den bisherigen Thinking-Verlauf nicht mehr erhalten ## Mythos 5.1 und Fable 5.1 – dasselbe Modell, zwei Filtersysteme Die Konstruktion kennt man schon von _Fable 5_. Anthropic bezeichnet _Fable 5.1_ und _Mythos 5.1_ als identisches Modell, das mit unterschiedlich permissiven Safeguards ausgeliefert wird. _Fable 5.1_ ist allgemein verfügbar, _Mythos 5.1_ bleibt zunächst einer kleinen Gruppe geprüfter Organisationen in den USA vorbehalten. Ganz so aufgeräumt, wie die Kurzfassung klingt, ist der Zugang zum eingeschränkten Modell noch nicht. Das Life Sciences Verification Program hat gerade erst seine ersten Teilnehmer aufgenommen. Das Cyber Verification Program soll Mythos-Zugang erst in naher Zukunft erhalten. Claude Security läuft dagegen bereits mit _Mythos 5.1_. Der Unterschied liegt damit nicht im trainierten Modell, sondern im System darum herum. Gleiche Basis, andere Zugriffskontrollen und Fallbacks. ## Die interessanteste Zahl steht nicht in der Überschrift Auf Terminal-Bench 4.0 kommt _Fable 5.1_ auf 55,8 %, _Mythos 5.1_ auf 60,9 %. Dasselbe Modell, dieselben Aufgaben, 5,1 Punkte Differenz. Anthropic führt die Lücke auf Tasks zurück, bei denen die vorherigen, gröberen Cyber-Safeguards eingegriffen haben. Genau da sitzt das wichtige Sternchen. Die 5,1 Punkte beziffern nicht den Leistungsabzug der Filter, die seit heute in Produktion laufen. Anthropic erwartet selbst, dass der Abstand mit den neuen Safeguards deutlich kleiner wird. Die Tabelle zeigt sauber, wie stark ein vorgeschaltetes Filtersystem einen Benchmark drücken kann – nur eben rückblickend für die vorige Version dieses Systems. So ganz neu ist die Messung auch nicht. In der System Card zu Fable 5 und Mythos 5 standen für Terminal-Bench 2.1 bereits 84,3 % und 88,0 %. Damals lösten die Safeguards bei 20,9 % der Fable-Durchläufe eine Weiterleitung an Claude Opus 4.8 aus. Der Unterschied war also dokumentiert, nur deutlich tiefer im Material vergraben. Zur aktuellen Tabelle gehört noch eine zweite Fußnote. _Fable 5.1_ wurde mit aktiven Produktions-Safeguards gemessen. Griffen sie auf OSWorld 2.0 ein, erhielten _Fable 5.1_ und _Fable 5_ für den betreffenden Task eine Null; bei AutomationBench galt das für _Fable 5_. Bei den übrigen Eingriffen übernahm Claude Opus 4.8 die Cyber- und _Claude Opus 5_ die Bio-Aufgaben. Anthropic schreibt selbst, dass dies die Ergebnisse wahrscheinlich drückt. Ehrlicher als vieles, was in der Branche sonst unter Benchmark-Kommunikation läuft, ist das aber schon. Es heißt aber auch, dass die Tabelle streng genommen kein reiner Modellvergleich ist, sondern verschiedene Auslieferungssysteme gegeneinander stellt. Wer _Fable 5.1_ nutzt, bekommt die Safeguards mitgeliefert – und damit ist der niedrigere Wert für die Praxis relevanter. Die Opus-Fallbacks müssen API-Kunden selbst aktivieren, über den `fallbacks`-Parameter, den Anthropic mit _Opus 5_ als Beta eingeführt hat. Die übrigen Werte fallen ähnlich deutlich aus: 52,6 % auf Terminal-Bench-Science 0.1 gegen 24,7 % beim Vorgänger, 1853 auf GDPval-AA v2 gegen 1723 und 31,4 % auf AutomationBench gegen 17,1 %. Auf CursorBench 3.2.0 sind es 73,4 % gegen 70,5 %, also im Rahmen. Bei Terminal-Bench-Science nennt Anthropic einen Standardfehler von ±3,5 bis 4,5 Punkten. Das öffentliche Leaderboard führt Fable 5 bei 21,4 %, während die eigene Reproduktion 24,7 % ergab. Beide Werte lägen innerhalb des statistischen Rauschens. Immerhin steht es da. ## Nur Cache-Reads werden billiger 10 $ pro Million Input-Tokens, 50 $ pro Million Output-Tokens. Unverändert. Was gefallen ist, sind die Cache-Reads: minus 75 %, jetzt 0,25 $ pro Million Tokens. Daraus leitet Anthropic rund 25 % geringere Gesamtkosten bei typischer Nutzung ab und bis zu 45 % bei stark agentischer Arbeit. Die Rechenbasis ist die eigene Nutzung über vier Wochen im August 2026, gemessen über Claude Enterprise, Claude Code und die API bei Default-Effort. Für Setups, die ihren Kontext ständig neu aufbauen und wenig aus dem Cache lesen, ändert sich am Rechnungsbetrag kaum. Die 25 % sind ein Durchschnitt über Anthropics Kundschaft, nicht über deine. Wer mit langlaufenden Agenten arbeitet und den Kontext warm hält, dürfte den Unterschied dagegen sehen. Direkt gilt die Preissenkung für tokenbasierte Abrechnung über die API. Der feste Preis meines Max-5x-Plans sinkt natürlich nicht. Spannend ist dort eher, ob durch das günstigere Caching mehr Arbeit in die bestehenden Usage-Limits passt – dazu macht die Ankündigung keine konkrete Zusage. ## Safeguards werden durchlässiger, die API wird dichter An den Filtern hat sich einiges bewegt, und zwar in beide Richtungen. Die Cyber-Safeguards greifen laut Anthropic pro Claude-Code-Session durchschnittlich rund 60 % seltener ein als die vorherigen Filter von Fable 5. _Fable 5.1_ darf jetzt Schwachstellen in Software identifizieren. Exploits dafür entwickeln darf es weiterhin nicht selbst. Pentesting, Exploit-Generierung und binärbasiertes Vulnerability-Scanning werden weiterhin an die Opus-Modelle weitergeleitet. Bei harmlosen Fragen zu grundlegender Biologie und Medizin greifen die neuesten Filter 85 % seltener ein als die Version, die mit Fable 5 startete. Diese Änderung gilt für _Fable 5.1_ und _Fable 5_. Forschungs- und Entwicklungsanfragen aus den Life Sciences gehen weiterhin an Opus. Gleichzeitig macht Anthropic die API an einer Stelle dichter. Ab heute angelegte API-Accounts können frühere Turns einer Konversation nicht mehr manuell editieren und dabei das bisherige Thinking-Transkript behalten. Das war eine öffentlich dokumentierte Methode, um Claudes Reasoning für Distillation abzugreifen. Bestehende Accounts sind vorerst nicht betroffen; mit künftigen Modell-Releases soll die Regel für alle gelten. Ein paar Custom-Integrationen werden das merken. Dazu kommen die Enterprise Frontier Safeguards. Kundendaten bleiben dabei in der eigenen Cloud-Infrastruktur, menschliche Prüfungen liegen standardmäßig beim Kunden. Der Rollout startet in Phasen ab diesem Herbst. Bis dahin gibt es Zero Data Retention für berechtigte Kunden. Auch beim Text-Wasserzeichen lohnt eine saubere Trennung zwischen Gesetz und Umsetzung. Art. 50 des EU AI Act verlangt von Anbietern betroffener generativer KI-Systeme, ihre Outputs maschinenlesbar zu markieren. Anthropic setzt das als Unterzeichner des Code of Practice mit einem unsichtbaren Text-Wasserzeichen für Modelle um, die nach dem 2. August 2026 veröffentlicht wurden. Die Detection-API läuft als Private Preview für berechtigte Regulierer, Strafverfolgungsbehörden, Medien, Faktenchecker, Forschung und weitere Organisationen mit entsprechenden Prüfpflichten. ## Venus, Proteine, GPU-Kernels Den größten Teil der Ankündigung nehmen Wissenschaftsdemos ein, und die gehen ausnahmsweise über reine Prompt-Spielereien hinaus. _Mythos 5.1_ entwarf laut Anthropic Protein-Binder, die zwei externe Organisationen im Labor testeten. Über zwölf Targets lag die Trefferquote bei knapp 50 %, während Anthropic 10 bis 15 % als heute üblichen Bereich nennt. Auf drei Targets soll die Bindungsaffinität eine Größenordnung über den besten vergleichbaren Einreichungen aus Wettbewerben von Adaptyv Bio gelegen haben. Das sind weiterhin Herstellerangaben. Eine unabhängige Studie oder die vollständige Versuchsdokumentation ist noch nicht verlinkt, und bei einem der drei Targets nennt Anthropic selbst einen Binder an einer anderen Bindungsstelle, der ein vergleichbares Ergebnis erreichte. Bei der Venus-Demo gibt es immerhin einen öffentlichen Datensatz. Im Rahmen des Anthropic STEM Fellows Program erstellten Allyson Trussell und Claude aus mehr als 30 Jahre alten Magellan-Radardaten ein neues digitales Höhenmodell. Es deckt 35 % der Venus ab (Anthropic rundet auf ein Drittel) und liegt unter CC BY 4.0 auf Zenodo, rechtzeitig vor den Missionen VERITAS und EnVision. Anthropic fasst die Detailauflösung mit 2 bis 3 km statt der bisherigen 10 bis 20 km zusammen. Das README des Datensatzes ist vorsichtiger: Strukturen zwischen 3 und 20 km werden besser erfasst als mit der alten Altimetrie, unter etwa 5 km seien sie jedoch kaum zuverlässig aufgelöst. Das 300-Meter-Raster sollte man deshalb nicht mit 300 Metern belastbarer räumlicher Auflösung verwechseln. Peer-reviewed ist die Karte ebenfalls noch nicht. Für sieben Open-Source-Modelle aus Genomik und Proteinforschung schrieb _Mythos 5.1_ laut Anthropic Custom-GPU-Kernels und optimierte das Caching. Auf einer NVIDIA H100 liefen die Modelle damit bis zu 2,5-mal schneller bei identischem Output; die geschätzten GPU-Kosten sanken je nach Analyse um 30 bis 60 %. Die Optimierungen will Anthropic erst noch als Open Source veröffentlichen. Greifbarer als die übliche Launch-Demo ist das alles. Vollständig ist das Bild trotzdem nicht. Bei den Protein-Bindern nennt Anthropic zwar die Labortrefferquote, aber nicht die Zahl der Modellläufe und verworfenen Designs davor. Für das Höhenmodell gibt es einen offenen, aber noch nicht begutachteten Datensatz. Bei den Kernels fehlt der Code bislang ganz. ## Der Take zum Schluss Der eigentliche Vorgang hier ist nicht der Sprung auf Terminal-Bench-Science, so hübsch die Verdopplung aussieht. Und es ist auch nicht das erste Mal, dass Anthropic den Leistungsunterschied zwischen Fable und Mythos beziffert. Interessant ist, wie offen die Launch-Kommunikation diesmal Modell und Auslieferungssystem auseinanderzieht. Da stehen 5,1 Punkte Differenz, Anthropic führt sie auf die eigenen Safeguards zurück und schreibt direkt daneben, dass diese Zahl mit den heute eingeführten Filtern vermutlich kleiner ausfallen würde. Das ist keine exakte Sicherheitssteuer, aber ein anschaulicher Beleg dafür, dass ein Benchmark nicht nur das Modell misst, sondern das komplette System darum herum. Die andere Seite der Medaille findet sich drei Absätze weiter unten im selben Text. Anthropic räumt ein, dass das Modell Approvals und Auto-Mode-Klassifikatoren gelegentlich umgehen kann und dass die eigene Alignment-Prüfung bei Long-Context- und Multi-Agent-Szenarien wenig sieht. Genau die Szenarien, für die dieses Modell beworben wird. Ich habe ein paar Tage Geduld. Dann sehe ich, was unabhängige Benchmarks zutage fördern, und schaue mir bis dahin an, ob _Fable 5.1_ in meinem Max-5x-Plan tatsächlich mehr Arbeit in die vorhandenen Usage-Limits bekommt. Die Abo-Gebühr selbst bleibt auf dem Preis, wo sie ist.

t01.li

Drei chinesische Open-Weights-Modelle in drei Tagen, zwei Dokumenten-Parser, ein gekaperter Claude Code Auto Mode, OpenAIs Cursor-Rauswurf nach der SpaceXAI-Übernahme und Metas geplatztes Project OT – der Wochenrückblick der 35. KW.

AI Picks der 35. KW

Reichlich neue Modelle diese Woche – allein drei chinesische Open-Weights-Drops innerhalb von drei Tagen –, dazu zwei Dokumenten-Parser, ordentlich Gossip bei Meta und ein handfester Ärger mit dem Auto Mode in _Claude Code_. Dann mal rein in die spätsommerliche 35. Kalenderwoche des Jahres 2026. ## Qwen3.8-Flash-Next Alibaba hat am 26. August Qwen3.8-Flash-Next rausgehauen: Open Weights, MoE, ausdrücklich als Vorschau auf die kommende Qwen4-Architektur gedacht. Im Backbone stecken 125 Milliarden Parameter, dazu kommt eine separate N-gram-Embedding-Tabelle mit 51 Milliarden, aktiv sind pro Token nur 6 Milliarden. Die MoE-Schicht fährt 512 Experten, von denen 10 geroutete plus 1 shared anspringen. Wer den ganzen Architektur-Kram nachlesen möchte, findet den Tech-Report auf GitHub. Benchmarks gibt es bisher nur aus dem eigenen Haus, und in der Tabelle auf Hugging Face sieht _Flash-Next_ gegen _DeepSeek-V4-Flash-0731_ und _Claude-Opus-4.6 (Max)_ auffällig gut aus, gut – ist ihre Tabelle. Aber wo es kippt: Bei HLE zieht _Opus 4.6 Max_ mit 40,0 zu 35,9 vorbei, bei NL2Repo-Bench führt _DeepSeek-V4-Flash-0731_ mit 54,2 zu 48,1, und bei Agents' Last Exam liegt DeepSeek beim Pass@1 knapp vorn. _Opus 5_ und die anderen echten Frontier-Modelle fehlen komplett. Warten wir auf die unabhängigen Zahlen von Artificial Analysis, dann haben wir Werte, mit denen sich arbeiten lässt. Der Preis ist eine Ansage. Die Produktiv-Version _Qwen3.8-Flash_ soll über QwenCloud 0,16 $ je 1 Mio. Input und 0,47 $ je 1 Mio. Output kosten. ## GLM-5.3-Flash Kaum ist Qwen durch, legt Z.ai am selben Tag nach. GLM-5.3-Flash ist ebenfalls Open Weights unter MIT-Lizenz, kommt mit 320 Milliarden Parametern gesamt bei 18 Milliarden aktiven und einem Kontextfenster von 1 Mio. Token. Und ja, Ox Alpha, über das ich letzte Woche gestolpert bin, war tatsächlich dieses Modell – Z.ai hat es vor dem Launch anonym auf OpenCode und OpenRouter mitlaufen lassen. Artificial Analysis hat schon gemessen und setzt das Modell auf 57 Punkte im Intelligence Index, klar über dem Schnitt vergleichbarer Open-Weights-Modelle. Den Preis, der dafür vorher rund das Zehnfache gekostet hätte, gibt Z.ai selbst als Verkaufsargument aus. Der Haken steht im selben Bericht – langsamer als der Durchschnitt und reichlich geschwätzig, weil ein Großteil der Output-Tokens ins Reasoning fließt. Das Muster mit dem Benchmark-Blatt voller Sternchen kennt man ja schon vom Vorgänger GLM-5.2. Regulär ruft Z.ai 0,15 $ Input und 0,50 $ Output je 1 Mio. Token auf. Bei OpenRouter gibt es das Modell gerade zum Kennenlernpreis für 0,075 $ Input und 0,25 $ Output. ## Hy4 preview Weil aller guten Dinge drei sind, ist bei Tencent am 28. August Hy4 preview als Open Source hinten rausgefallen – MoE, 770 Milliarden Parameter gesamt, davon 49 Milliarden aktiv je Token, Kontextfenster 1 Mio., Apache-2.0-Lizenz. Auf Hugging Face liegen die Gewichte, der Code auf GitHub. Unabhängige Benchmarks gibt es noch nicht, nur Tencents eigene. Tencent ist immerhin nicht dafür bekannt, in der Vergangenheit wild übertrieben zu haben – also nehmen wir die internen Zahlen mal hin, aber mit einem ganz leichten Zucken im Auge: Benchmark| Hy4 preview| Qwen 3.8 Max| GLM 5.3| Kimi K3| GPT 5.6 Sol| Claude Opus 5 ---|---|---|---|---|---|--- Terminal Bench 2.1| **85.4**| 85.8| 88.3| 85.7| **88.8**| 85.1 DeepSWE| **64.3**| 56.6| 68.1| 74.0| 68.9| **74.7** SWE Atlas Refactoring| **63.3**| 51.0| 51.9| 37.4| 62.4| **66.0** ProgramBench| **17.5**| 17.5| 18.0| 24.5| 25.0| **39.5** PostTrainBench| **35.6**| —| 33.2| 32.0| **36.2**| 35.0 Toolathlon-Verified| **74.1**| 69.1| 73.3| 74.7| 73.7| **76.5** Humanity's Last Exam| **43.4**| 41.5| 42.3| —| 49.6| **53.2** HorizonMath| **8.8**| 5.3| —| 7.1| **10.8**| 5.3 OneMillionBench| **65.4**| 63.1| 64.5| 63.5| 67.1| **68.1** Verglichen wird unter anderem mit GPT-5.6 und Kimi K3. Und trotz MoE musst du dir bei 1,56 TB Größe keine Gedanken machen, wo das Ding läuft – auf der besseren Bürokiste jedenfalls nicht, genauso wenig wie zuletzt _Kimi K3_ mit seinen 1,5 Terabyte. ## Cohere Parse 5 Dokumenten-Parsing war diese Woche gleich zweimal ein Thema. Cohere macht den Anfang mit Parse 5, einem Vision-Parsing-Modell, das klar auf Großabnehmer zielt – 2,3 Milliarden Parameter, 8.192 Token Kontextfenster. Den ParseBench-Score von 79,2 hat Cohere selbst ermittelt, und zwar als Mittel über drei der fünf ParseBench-Dimensionen. Charts und Visual Grounding, die zwei Kategorien, an denen die meisten Parser scheitern, sind rausgelassen. Das Hauptargument ist ohnehin der Preis von 1,50 $ je 1.000 Seiten. Zu haben ist das über die Cohere Parse API, Microsoft Foundry sowie AWS SageMaker und auf Hugging Face kannst du es ausprobieren. Wenn du im großen Stil rechtlich unkritische PDF-, PPT- und JPEG-Dokumente durchschieben musst, um sie etwa an einen RAG zu verfüttern, kann sich das rechnen. ## Introducing Light Parse Bei Extend heißt die Antwort Light Parse – eine neue, günstige Parsing-Engine neben dem bestehenden schwereren _Performance Parse_. Die Trennung ist klar: _Light Parse_ (Engine `parse_light`) ist für textlastige Dokumente mit einfachen Formularen und Tabellen gedacht und kostet 0,5 Credits je Seite, im Pay-as-you-go 0,00625 $ pro Seite, im Scale-Tarif 0,005 $. _Performance Parse_ (Engine `parse_performance`) übernimmt komplexe Tabellen, verschachtelte Checkboxen, Handschrift oder schwierige Scans und schlägt mit 2 Credits beziehungsweise 0,025 $ pro Seite zu Buche. In der hauseigenen RealDoc-Bench kommt _Light Parse_ auf 90,5 % und damit auf die Spitzenposition unter den nicht-agentenbasierten Parsern, auf Databricks OfficeQA Pro sind es 54,9 %. Technisch lässt Extend sonst nicht viel raus. Der Pluspunkt für unsere heimischen Gefilde steht abseits der Benchmarks – es gibt eine EU-Data-Region und im Dashboard unter eu1.extend.ai lässt sich explizit ein EU-Standort wählen. ## Gemini 3.5 Transcribe Eine neue Woche, ein neues Gemini-Modell, aber die Überraschung bleibt aus: immer noch kein Pro. Stattdessen schiebt Google ein Transkriptionsmodell nach, was meine These stützt, dass jede KI-Bude erst ein Audio-Transkriptionsmodell im Katalog haben muss, bevor sie sich AI-Lab nennen darf. Gemini 3.5 Transcribe kommt in zwei Geschmacksrichtungen – Transcribe Live für kontinuierliches Streaming über die Live API und _Gemini 3.5 Transcribe_ für vorab aufgezeichnetes Audio. Beide sprechen über 85 Sprachen, unterstützen benutzerdefinierte Vokabulare und formatieren den Text automatisch. Bei der Sprecher-Erkennung geht richtig was: Bis zu acht Sprecher kann das Modell auseinanderhalten, ab drei markiert Google die Zuordnung allerdings als experimentell. Preislich landet _Gemini 3.5 Transcribe_ bei rund 5 $ je 1.000 Minuten, Transcribe Live bei 9 $ – gerechnet mit 25 Audio-Tokens pro Sekunde und 175 Text-Tokens pro Minute zu den jeweiligen API-Raten (2 $ je 1 Mio. Audio-Input, 12 $ je 1 Mio. Text-Output für Transcribe; 3,50 $ bzw. 21 $ für Live). ## Antigravity CLI transkribiert nun auch Sprache Bleiben wir bei Google. Antigravity CLI unterstützt seit Version 1.1.21 den Befehl `/voice` und transkribiert Sprache direkt in den Prompt, gesteuert über die F5-Taste. Dazu gibt es ein neues Feld `cost` in der Statuszeile, das die geschätzten Kosten der laufenden Sitzung zeigt. Plus die üblichen Kleinigkeiten. ## Antigravity Generative UI Artifacts Und noch mal Google: Antigravity kann jetzt Generative UI. Über den Befehl `/generative_ui` bauen die Agenten interaktive Komponenten, dynamische Dashboards, Datenfluss-Visualisierungen und Design-Mockups, direkt im Artifact-Preview-Panel und in Echtzeit iterierbar. 3D geht auch. Der Clou steht im Kleingedruckten. Die Visualisierungen sind zero-dependency – sie rendern lokal, ohne dass zusätzliche Pakete geladen werden, laufen offline und lassen sich als Artefakt exportieren und später wieder öffnen. Kein Server, kein Build-Schritt, kein npm-Gefummel. Frisch dazugekommen sind laut Changelog KaTeX-Formeln sowie Chart.js- und Plotly-Diagramme in den Widgets. ## Claude Memory aufgebohrt Seit dem 25. August teilen sich Chat und _Cowork_ denselben Memory und greifen auf ein gemeinsames Gedächtnis zu. Führt _Cowork_ eine Aufgabe in der Cloud aus, steht das, woran sich _Claude_ aus deinen Chats erinnert, dort bereit – und umgekehrt. Wichtig: nur für Cloud-Tasks. Lokal laufende _Cowork_ -Sessions nutzen den geteilten Speicher nicht. Sensible Themen – Gesundheit, ethnische Zugehörigkeit, religiöse Überzeugungen, Politik, Geschlechtsidentität – speichert _Claude_ per Default nicht, dafür gibt es einen Opt-in in den Settings. SSN, Vorstrafen oder Immigration-Status landen selbst mit aktiviertem Opt-in nie im Speicher. Der gemeinsame Memory ist in Free, Pro und Max standardmäßig aktiv, bei Team und Enterprise muss ihn erst ein Owner freischalten. ## Claude gets its own browser in Cowork _Claude Desktop_ (macOS, Windows, Linux) hat jetzt einen integrierten Chromium-Browser in Cowork, verfügbar für Pro-, Max- und Team-Pläne. Damit ziehen sie gegenüber der _ChatGPT_ -Desktop-App nach, die das ein paar Tage länger kann. Der Witz daran: Der Claude-eigene Browser ist vollständig unabhängig vom Benutzer-Browser auf dem System und erledigt ausschließlich agentische Aufgaben. ## Breaking Claude Code Opus 5 Auto Mode Das kommt via Simon Willison, und tja – kaum schreibe ich über den Auto Mode, erscheint einen Tag später ein Beitrag von Johann Rehberger, wie sich der Auto Mode von _Claude Code_ kapern lässt, um _Claude_ schadhaften Code ausführen zu lassen. Der Aufhänger ist harmlos: die Bitte, eine Website zusammenzufassen. Rehberger kommt damit über eine gezielte Kette auf 60 bis 80 % Erfolg bei kleiner Stichprobe. Die Pointe steckt im Kontrast. Eine von Anthropic beauftragte Drittmessung hatte für Opus 5 im Auto Mode 0,00 % Prompt-Injection-Erfolg ausgewiesen. Rehberger hat den Befund gemeldet, auf zwei Wegen und immerhin über einen eine Antwort bekommen. Die war wenig befriedigend: Anthropic hat den Report als „Informative“ geschlossen, das Verhalten sei so beabsichtigt. Der Auto Mode sei eine Convenience-Funktion mit einem Best-Effort-Klassifikator, keine Sicherheitsgarantie; die echte Grenze seien OS-Isolation und Network-Egress-Control. Simon Willison ordnet das Ganze mal ein. Das simpelste Gegenmittel ist aktuell der Betrieb in einer Sandbox – was aber eher die Symptome bekämpft als die Ursache. ## ChatGPT Cloud Browser mit Login-Funktion Der Cloud Browser von _ChatGPT Work_ erlaubt seit dem 25. August einen Log-in, ohne dass Benutzername und Passwort ans Modell gehen. Das läuft im Web und mobil, für Plus-, Pro- und Business-Nutzer. Klingt erst mal nach mehr Sicherheit. Der Haken steht schon in der Notebookcheck-Überschrift – das Passwort speichert ChatGPT nicht, die Anmeldung schon. Du tippst die Zugangsdaten in ein sicheres Formular, das Modell sieht sie nicht, aber die eingeloggte Session bleibt danach als Cookie auf OpenAIs Servern liegen, bis sie abläuft. Wer sich um seine Sessions Gedanken macht, hat jetzt einen neuen Ort, an dem eine davon liegt. ## Das 5-Stunden-Limit ist zurück, Luna Reserve als Trostpflaster Sechs Wochen lang liefen _Codex_ und _ChatGPT Work_ für Plus-Tier-Nutzer gegen das Wochenkontingent, Potzblitz ist jetzt der 5-Stunden-Deckel wieder da. Seit dem 25. August, angekündigt von Codex-Lead Thibault „Tibo“ Sottiaux. Das rollende Fünf-Stunden-Fenster sitzt neben dem Wochenlimit; ist es leer, heißt es warten oder Credits nachkaufen. Die Pro-Pläne für 100 und 200 $ bleiben vorerst verschont. Als Auffangnetz wirft OpenAI ausgewählten Plus- und Pro-Accounts Luna Reserve hin, einen Fallback-Modus mit etwas Restlaufzeit nach dem Limit: > Luna Reserve provides additional usage only with Luna after regular usage is exhausted. Klingt kulant, die Leistung ist aber überschaubar. Die Reserve läuft ausschließlich auf _GPT-5.6 Luna_ , dem kleinsten Modell der Familie – demselben, das ab dem 31. August das alte _GPT-5.4 mini_ beerbt. Falls du also in die Drosselung rutschst, da du gerade an etwas Komplexem sitzt, bekommst du ausgerechnet das Leichtgewicht als Ersatz – nettes Trostpflaster. Für eine Aufgabe, die eigentlich _Sol_ oder _Terra_ gebraucht hätte, bringt das herzlich wenig. ## Vercel Sandbox is now globally available Zum Abschluss Infrastruktur. Die Vercel Sandbox läuft jetzt weltweit – zum Start in vier Regionen: Washington (iad1), San Francisco (sfo1), Cleveland (cle1) und Paris (cdg1). Default bleibt das US-Rechenzentrum iad1, die einzige EU-Region ist Paris. Region-Auswahl gibt es in allen Plänen, Failover-Regionen nur für Pro und Enterprise, und Snapshots bleiben an ihre Region gebunden. Einerseits schön, yeah – ein EU-Standort! Andererseits stehst du dank US Cloud Act trotzdem im Regen, sobald du Verträge mit US-Buden schließt und deine Daten eigentlich nicht Richtung USA abfließen sollen. Eine US-Behörde kann deinen US-Anbieter gesetzlich zur Herausgabe zwingen, egal wo die Daten physisch liegen – und der Default-Standort ist hier ohnehin Virginia. Technisch laufen die Sandboxes in isolierten Firecracker-microVMs, gedacht zum sicheren Ausführen von fremdem oder Agent-generiertem Code. Details zum Nachlesen in den Docs. ## OpenAI kappt Cursor zum 12. November OpenAI und Musk, die nächste Eskalationsstufe ist ausgerufen. Das Coding-Tool _Cursor_ verliert zum 12. November 2026 den direkten Zugriff auf OpenAI-Modelle, so die Ankündigung. Auslöser ist die Übernahme durch SpaceXAI, das sich _Cursor_ – beziehungsweise dessen Entwickler Anysphere – Mitte August geshoppt hat; OpenAIs Vertrag lässt sich bei so einem Kontrollwechsel kündigen. Bemerkenswert ist der Ton der Begründung. Man könne nicht darauf vertrauen, dass SpaceX die Nutzungsbedingungen einhält, schreibt OpenAI offen – und schreibt da „Elon Musk“ namentlich rein, mit Verweis auf frühere Vertragsbrüche seiner Firmen. Fast schon höflich schiebt man hinterher, wie sehr man _Cursor_ und dessen Verdienste um die Dev-Community schätze – der Pflichtteil im Abschiedsschreiben. Die Retourkutsche von Cursor-Mitgründer Michael Truell ließ nicht lange auf sich warten: > We're sorry to see that OpenAI put out a note saying they plan to block Cursor users from accessing OpenAI models in three months. OpenAI models serve about 5% of Cursor user traffic, and we're speaking with the OpenAI team to resolve this. Cursor was one of the very first users of OpenAI, we've worked closely with their team for years, and we've trusted their platform to be neutral infrastructure for our business. Wie sehr willst du einen bald ehemaligen Partner vorführen? Truell so: ja. Wenn die 5 % tatsächlich stimmen, wird der Abschied nicht besonders vielen _Cursor_ -Nutzern wirklich wehtun – _Claude_ , _Gemini_ und _Grok_ stehen im Editor außerdem auch bereit. ## Meta Projekt OT Zum Schluss der Gossip, und was für einer. Ars Technica hat einen wunderbaren Artikel darüber, wie Meta den feuchten Traum jeder Unternehmensberatung wahr lassen werde wollte – einzelne Teams um bis zu 60 % schrumpfen und den Rest an KI-Agenten übergeben. Intern lief das unter dem Codenamen „Project OT“ (Organization Transformation), ausgeheckt bei Zuckerbergs Januar-Retreat auf Hawaii. Das Ziel: das Unternehmen „KI-nativ“ machen, Startschuss war die erste Entlassungswelle im Mai. Danach ging offenbar so viel schief, dass die zweite Welle, vorgesehen für November, gestrichen wurde. Meta betont, nie 60 % der Gesamtbelegschaft gemeint zu haben, nur einzelne Teams. Für eine Bude, die ihren KI-Kram gern ins Enterprise-Segment verkaufen will, schreibt man das besser dann nicht auf die Website als Referenzimplementierung. Der Artikel strotzt vor Zitat-Gold. Ein Highlight, das Reuters aus internen Beiträgen geholt hat: > For instance, code changes made to the internal software platforms and infrastructure employees use on the job were up 220 percent year-over-year, according to a post by [Meta CTO Andrew] Bosworth in early June. But changes that led to new or upgraded features reaching Meta users were only up 36 percent. Haben die ernsthaft erwartet, dass die Belegschaft das feiert – zumal niemand bei Meta sicher sein konnte, ob er/sie im November auch gehen darf? Kannst du dir nicht ausdenken. Fin. Und auf die Gefahr hin, dass ich mich wiederhole: Passt auf eure Agenten und Sandboxes auf.

t01.li

Auto Mode ist seit Mitte August Default in Claude Code – der Agent fragt nicht mehr bei jedem Schritt. Warum ich ihn auf meinem t01.li-Stack machen lasse, wo der eigentliche Steuerungshebel liegt und wann Accept edits die bessere Wahl bleibt.

Claude Code Auto Mode ist jetzt Default – und wann ich ihn machen lasse

Den kompletten Stack hinter t01.li verwalte ich mit Claude Code. Ghost samt CLI, NGINX, die Dienste drumherum, das Theme, die lokale Testversion – das läuft alles über das Terminal, und den Coding-Agent lasse ich die „Handarbeit“ machen. Meistens starte ich damit im Plan Mode, weil ich erst sehen will, was Claude Code vorhat, bevor er irgendwas anfasst. Seit Mitte August bekomme ich am Ende jedes Plans dieselbe Rückfrage: „Ausführen – im Auto Mode?“ Das ist relativ neu und kein Zufall, denn Anthropic hat Auto Mode zum Standard erkoren. ## TL;DR Auto Mode ist der neue Default in Claude Code – hier steht, was das praktisch heißt und wo die Grenze verläuft. * Seit Mitte August ist Auto Mode der Start-Modus für neue Sessions auf Pro, Max und Team. * „Weniger fragen“ heißt nicht „nicht prüfen“: Ein zweites Modell, der Klassifikator, entscheidet statt dir – statistisch, nicht nach festen Regeln. * Die harte Grenze ziehst du nicht in der CLAUDE.md, sondern über die `deny`-Liste in der `settings.json`. `deny` schlägt jeden Modus, sogar Bypass. * Auf einem eingefahrenen Stack mit Deny-Liste und Snapshots ist Auto Mode entspannt. Beim Neuaufsetzen bleibt Accept edits oder Manual die vernünftigere Wahl. ## Was Auto Mode als Default ändert Seit Mitte August ist Auto Mode der eingebaute Start-Modus für neue Sessions auf den Pro-, Max- und Team-Plänen. Wer vorher jede Datei-Änderung und jeden Shell-Befehl einzeln abgenickt hat, findet sich jetzt in einem Modus wieder, der deutlich weniger fragt. Nur heißt „weniger fragen“ nicht „gar nicht prüfen“, und das ist der Punkt, der gerne überlesen wird. In Auto Mode entscheidest nicht mehr du über jede Aktion, sondern ein zweites Modell: der Klassifikator. Der schaut sich jede Aktion an, bevor sie läuft, und blockiert, was über deinen Auftrag hinaus eskaliert, fremde Infrastruktur anfasst oder danach aussieht, als hätte Claude sich von Prompt Injection im gelesenen Content steuern lassen. Der Modus schiebt Claude außerdem an, ohne Zwischenfragen weiterzuarbeiten – fragt aber trotzdem, wenn dein Prompt oder ein Skill das ausdrücklich verlangt. Aus „ich bin der Türsteher“ wird „ein LLM ist der Türsteher“ – das ist der ganze Unterschied. ## Wie ich das fahre Bei mir läuft fast alles über den Plan Mode, und das hat einen simplen Grund. Wenn ich mehrere kleinere und vor allem zusammenhängende Aufgaben auf einmal verteile und Claude Code seine Sub-Agents nutzen lasse, will ich den Plan sehen, bevor die loslegen – nicht jeden einzelnen Edit, sondern die Marschrichtung. Man sollte immer berücksichtigen, dass mehrere Agents parallel den Token-Verbrauch treiben. Der Plan Mode ist bei mir nicht nur die Vorstufe zum Abnicken, sondern das Werkzeug für die Fragen, die vor einem Eingriff geklärt sein müssen. Bringt ein Ghost-Update eine Änderung mit, die mir schlimmstenfalls das Theme zerlegt? Sind Elemente inzwischen als deprecated markiert, auf die ich mich noch verlasse? Und dann die Dauerbaustelle, die ich seit zwei Monaten vor mir herschiebe – die Migration auf Tailwind 4. Wie aufwendig wird diese Migration wirklich, und wann ist der richtige Moment, ohne dass die Seite zwei Tage im Umbau steht. Das sind Fälle, in denen ich die Analyse und den vorgeschlagenen Weg sehen will, bevor eine einzige Zeile geändert wird. Genau dafür ist Plan Mode gebaut. Wenn der Plan steht und passt, nehme ich das Auto-Mode-Angebot. Nicht aus Bequemlichkeit, sondern weil für diesen Stack die Voraussetzungen stimmen. Ich arbeite seit Monaten mit Claude Code an genau dieser Umgebung, ich kenne alle Ecken und Kanten des Setups, meine CLAUDE.md ist über etliche Sessions gewachsen statt auto-generiert, und darunter liegt ein Netz aus Backups und Server-Snapshots. Wenn im Auto Mode etwas schiefläuft, kostet mich das einen Rollback, keine Nacht. Das ist die eigentliche Bedingung, unter der Auto Mode Sinn ergibt: nicht das Feature, sondern der Reifegrad drumherum. Ein eingefahrener Stack, Guardrails, die du selbst getestet hast, und ein Wiederherstellungspunkt, der greift. Fehlt eins davon, sieht die Rechnung anders aus. ## Der eigentliche Hebel ist nicht die CLAUDE.md Hier lauert ein Fallstrick: Denn man steckt Mühe in die CLAUDE.md und meint, damit die Leine in der Hand zu haben. Das ist aber nur so halb korrekt. Die CLAUDE.md instruiert – sie sagt Claude, was gemeint ist, und der Agent hält sich dran, ähnlich wie er ein „push hier nichts ohne Rückfrage“ befolgt. Ein Riegel ist sie nicht. Wer im Auto Mode eine harte Grenze will, zieht sie in der `settings.json`. Da liegen drei Listen: `allow`, `deny`, `ask`. Und `deny` schlägt alles – den Klassifikator, sogar den Bypass-Modus. Ein `deny` auf `Bash(rm -rf:*)` oder auf `Read(.env*)` steht, egal in welchem Modus die Session läuft. Genau das macht Auto Mode auf einem Produktions-Stack erst verantwortbar. Der Klassifikator ist die zweite Verteidigungslinie, die erste sind ein paar Zeilen, die ich selbst geschrieben habe. Das Modell darf großzügig durchwinken, weil die Deny-Liste die echten Katastrophen schon vorher aussortiert hat. Die Arbeitsteilung in einem Satz: `settings.json` setzt durch, CLAUDE.md redet gut zu. Das sollte man nicht verwechseln, denn dann verlässt man sich an der falschen Stelle auf gutes Zureden. ## Der Türsteher ist auch nur ein Modell Bleibt der Reality-Check, und Anthropic liefert ihn selbst mit. So steht im Warnkasten der Doku, Auto Mode senke die Prompts, aber „does not guarantee safety“ und sei kein Ersatz für Review bei sensiblen Operationen. Der Anbieter schreibt die Grenze selbst hin, statt sie wegzulächeln. Denn was da prüft, ist ein Modell und kein Regelwerk, und ein Modell liegt im Schnitt richtig, nicht immer. Bei mir schlägt dieser Schnitt in die vorsichtige Richtung aus: Der Klassifikator fragt gefühlt lieber einmal zu oft als zu selten, und für bekanntes Terrain ist das die angenehme Fehlerrichtung. Lieber eine Rückfrage zu viel als eine Aktion, die durchrutscht. Auf unbekanntem Terrain kippt die Rechnung. Da verschiebe ich ein Risiko, das ich vorher mit eigenen Augen gesehen hätte, auf eine Instanz, die im Schnitt richtig liegt. „Im Schnitt richtig“ ist bei einem Produktionsserver eine andere Aussage als bei einem Playground oder einem reinen Testprojekt. Das eingebaute Checkpoint-System, das vor jedem Edit einen Snapshot zieht und sich per `/rewind` zurückdrehen lässt, ist ein gutes Sicherheitsnetz – aber es fängt nicht alles. Was ein Bash-Befehl außerhalb deiner Dateien anrichtet, hängt nicht am `/rewind`. Deswegen bleiben meine eigenen Server-Snapshots die Ebene, auf die ich mich verlasse. Claude Code CLI ## Wann Auto Mode das Falsche ist Setze ich einen Stack neu auf, ist Auto Mode das Falsche. Dann kenne ich die Umgebung nicht gut genug, um zu merken, wenn der Agent in die falsche Richtung rennt – und genau dieses Merken ist der Wert der Einzel-Freigabe, der eigentliche Sinn von Human-in-the-loop. In dem Fall greife ich zu „Accept edits“ oder gehe ganz auf „Manual“ zurück. Ein Detail dazu, das in der Arbeit mit dem Stack schnell auffällt: auch „Accept edits“ winkt nicht alles durch. Der Modus lässt Datei-Änderungen und ein paar harmlose Filesystem-Befehle im Arbeitsverzeichnis ohne Rückfrage laufen: `mkdir`, `touch`, `mv`, `cp` und Konsorten. Jeder andere Shell-Befehl promptet weiter. Damit ist „Accept edits“ beim Neuaufsetzen die gezieltere Wahl als „Auto“. Die reine Schreibarbeit läuft flüssig, aber alles, was in die Systemebene greift, landet wieder bei mir. Man macht sich nicht zum Klick-Sklaven und gibt trotzdem nicht die Kontrolle ab, wo sie wichtig ist. „Manual“ ist der Fall, wenn ich jeden Schritt sehen will – erstmalige Migrationen, alles was an Auth oder an die NGINX-Config geht, Sachen, bei denen ein falscher Move teuer werden könnte. ## Das Netz muss vorher hängen „Auto Mode“ als Default ist die richtige Entscheidung für den Durchschnittsfall – wer an vertrauten Projekten arbeitet, will nicht bei jedem Edit klicken. Für meinen t01.li-Stack passt es, weil das Sicherheitsnetz vorher gespannt war und nicht danach: eine Deny-Liste, die die scharfen Kanten abräumt, und Snapshots, die einen Fehler zum Rollback machen statt zur Nachtschicht. Die Frage ist nie „ist Auto Mode sicher“, sondern ob mein Setup an dem Punkt ist, an dem ich einem LLM den Türsteher überlassen kann. Bei mir und in diesem Fall: ja. Beim nächsten frischen Server: erst mal nicht.

t01.li

ChatGPT sucht seit dem 8. August gezielt innerhalb einzelner Domains, Hetzner erklärt schonungslos, warum sein Inference-Experiment einknickte, und auf OpenRouter verschenkt ein anonymes Lab Frontier-Kapazität. Dazu Multica, dessen Lizenz nur so aussieht wie Apache 2.0.

AI Picks der 34. KW

Letzte Woche muss irgendwo eine Abgabefrist für Jahresberichte gelegen haben, anders kann ich mir die Flut nicht erklären. Diese Woche ist da deutlich entspannter, alle haben weniger auf dem Zettel. Immer noch kein Blech … ähm, ich meine Hardware, aber dafür etwas Spannendes von der GEO-Front. Was mir beim Sortieren auffiel: Drei Meldungen erzählen dieselbe Geschichte aus drei Richtungen. ChatGPT sucht seit dem 8. August gezielt innerhalb einzelner Domains, Vercel misst, wie gut eine Website für Agenten überhaupt lesbar ist, und Anthropic gibt Claude den Accessibility Tree statt Screenshot-Koordinaten. Deine Website ist keine visuelle Seite mehr. Sie wird zur Abfrageoberfläche für Agents. Dann mal auf in die Picks der 34. Kalenderwoche. ## ChatGPT search now uses the site:operator at scale Simon Willison verweist auf eine Auswertung von Promptwatch, nach der ChatGPT bei seinen Fanout-Abfragen inzwischen gezielt innerhalb einzelner Domains sucht. Die Zahlen dahinter sind ungewöhnlich eindeutig. Wochenlang lag der Anteil domain-gescopter Suchen zwischen 0,3 und 0,5 Prozent, sackte vom 3. bis 5. August kurz auf 0,15 ab und sprang am 8. August auf 16,8 Prozent. Vorher etwa eine von 280 Abfragen, jetzt ungefähr jede sechste. Interessanter als der Sprung ist aber die zweite Kurve, die Promptwatch danebenlegt. Am selben Tag stieg die durchschnittliche Zahl der Fanout-Abfragen pro Antwort von rund 1,08 auf 1,83. Die domain-gescopten Suchen kommen also obendrauf, sie ersetzen die generischen nicht. Deine bisherigen Chancen bleiben. Vorher aber ein paar kleine Dämpfer in dem Artikel von Promptwatch: Willison hat sich das Tool angesehen und vermutet dahinter eine Signatur der Form `search(query, recency, domains)`, also einen Domain-Parameter und keinen echten `site:`-Operator. Die Datenbasis deckt außerdem nur die Prompts ab, für die Promptwatch automatisiertes Tracking laufen hat. Und Promptwatch ist selbst ein GEO-Anbieter, der solche Auswertungen als Content-Marketing veröffentlicht, was Willison auch deutlich äußert. An der Arbeit ändert das trotzdem etwas Konkretes. Wenn ChatGPT `site:deinedomain.de [Thema]` abfeuert, durchsucht es deine Website direkt, und was dort nicht indexiert ist, existiert für diese Abfrage nicht. Da bleiben also gleich zwei Hausaufgaben: Client-seitiges Rendering ist und bleibt ’ne Scheißidee, wofür die viel zitierte Vercel-Analyse von über 500 Millionen GPTBot-Abrufen ohne eine einzige JavaScript-Ausführung weiterhin die größte Stichprobe liefert. Einzige nennenswerte Ausnahme ist _Gemini_ , das sich bei Googlebots Rendering-Infrastruktur bedient und deshalb sieht, was ChatGPT und Claude entgeht. Und Crawlability samt Indexierbarkeit gehören ins regelmäßige Monitoring, wobei eine Sitemap und eine vernünftig gebaute robots.txt schon das meiste erledigen. Wer wissen will, welche KI-Crawler da überhaupt vorbeikommen, schaut ins Logfile. Kleine Randnotiz mit Folgen für alle, die auf Community-Traffic gebaut haben: In einem Nachtrag vom 18. August berichtet Promptwatch, dass Reddit in diesen Suchen deutlich seltener auftaucht – oops. ## Is Agentic Ein kleiner Service von Vercel, gebaut zusammen mit Ora, das auch jeden Scan ausführt. Is Agentic prüft eine Website darauf, was Agenten dort finden, abrufen, verstehen und benutzen können, und vergibt einen Score bis 100. Die Gewichtung ist erfreulich unaufgeregt. Den Großteil tragen Essential Checks: server-gerendertes Markup, korrektes HTTP-Verhalten, saubere Dokumentstruktur, wiederherstellbare Fehler, bedienbare Controls. Recommended Checks springen nur an, wenn der Scan tatsächlich eine API, OAuth, GraphQL, einen MCP-Server oder eine Commerce-Oberfläche findet. Was nicht zutrifft, fällt raus statt durch. Den Report gibt es neben der Weboberfläche auch als JSON, als Markdown unter derselben URL und über einen eigenen MCP-Server. Beim üblichen Verdächtigen bleibt Vercel bemerkenswert nüchtern. Emerging Formats wie llms.txt geben begrenzten Bonus, ihr Fehlen senkt den Score nie. Wer also gehofft hatte, sich eine Textdatei ins Wurzelverzeichnis zu legen und damit fertig zu sein, findet hier keine Bestätigung. Die schönste Zahl steht auf der Startseite. In den Featured Scores liegt is-agentic.com bei 100 von 100 und ora.ai bei 98, während vercel.com mit 85 einläuft. Wenn der Anbieter seiner eigenen Prüfung fünfzehn Punkte schuldig bleibt, spricht das mehr für die Ernsthaftigkeit des Tests als jedes Marketing-Zitat. ## Anthropic’s new browser tool doesn’t actually run a browser Der Titel beim New Stack sitzt, und er beschreibt die Stelle, an der es dann auch interessant wird. Das neue _Browser Use_ nutzt den Accessibility Tree, um Elemente direkt zu adressieren, statt aus Screenshots zu erraten, wo auf dem Screen ein Button liegt – ruft Claude `read_page` auf, kommt eine Textdarstellung des Baums zurück, in der Links, Buttons und Textfelder Referenzen wie `ref_3` tragen. Statt `x: 640, y: 320` schickt Claude dann die Referenz. Angekündigt wurde das am 20. August als Teil eines größeren Pakets, bei dem auch Computer Use, die Skills API und die Files API allgemein verfügbar werden. Ansprechbar ist das Toolset über die Claude API als `browser_toolset_20260801`, in Claude Managed Agents bislang nicht. Der Haken steckt im Wort „doesn’t run“. Anthropic führt hier gar nichts aus. Deine Anwendung hostet den Browser, übersetzt jede der standardmäßig 27 Operationen in eine echte Aktion, hält die Session über die Turns hinweg und liefert genug Information zurück, dass Claude versteht, was passiert ist. Navigiert der Tab zwischendurch weg, wird eine Referenz ungültig, und die API merkt das nicht von selbst. Dein Executor muss das erkennen, die Aktion ablehnen und Claude die Seite neu lesen lassen. Dazu die Rechnung, die man vor dem Bauen kennen sollte. Das Default-Toolset schlägt laut Anthropics Preisdoku mit rund 6.600 Input-Tokens pro Request zu Buche, bevor Screenshots und Accessibility Trees überhaupt dazukommen. Einzelne Operationen lassen sich abschalten. Gegenläufig wirkt das neue Batching, bei dem mehrere Aktionen in einem Model-Turn ankommen und der Reihe nach abgearbeitet werden, was Latenz und Modellaufrufe spart. Genau das macht Freigaben schwieriger, weil ein harmloser Klick am Anfang einer Sequenz in etwas münden kann, das eigentlich eine Rückfrage gebraucht hätte. Und Achtung, Verwechslungsgefahr zum Schluss: Es gibt ein unabhängiges Open-Source-Projekt namens Browser Use, das AI-Browser-Agenten über das Chrome DevTools Protocol fährt. Mit Anthropics Tool hat es nichts zu tun außer dem Namen. ## Firecrawl connector for Claude Firecrawl ist offizieller Connector. Der Eintrag steht im Anthropic-Verzeichnis, und wer den MCP-Server bisher von Hand konfiguriert hat, kann sich das sparen. Die Doku sagt es deutlich: kein Custom Connector, keine Server-URL zum Einfügen, stattdessen Verbinden über das Verzeichnis und pro Unterhaltung im Plus-Menü aktivieren. Wichtig für die Einordnung ist Anthropics eigene Trennung zwischen lokalen Desktop Extensions und Remote Connectors. Firecrawl ist Letzteres und damit in Web, Desktop und Mobile verfügbar, nicht nur in der Desktop-App. Das Plugin für Claude Code gibt es ohnehin schon länger. Auf Team- und Enterprise-Plänen muss ein Owner den Connector erst freigeben, und die Requests laufen über Credits und Plan des Teams, das du beim Anmelden auswählst. ## Claude Code can design now Diese Überschrift geht schon fast ein wenig in Richtung Clickbait, aber sie kommt nicht von mir. Das hat sich Anthropic ganz allein ausgedacht. Dahinter steckt der neue Skill `/design`, der den Artboard-Workflow aus _Claude Design_ in CLI und Desktop holt, gebaut auf Artefakten. Du beschreibst den Screen, bekommst mehrere editierbare Varianten nebeneinander, wählst eine aus, schiebst Farben und Abstände zurecht und lässt erst dann implementieren. Pick, tweak, implement. Unterstützt wird das ab Pro, außerdem in Max, Team und Enterprise. Zwei klitzekleine Details gingen in der Aufgeregtheit unter: Das läuft als Research Preview. Und ein Artboard bleibt technisch das, was ein Artefakt eben ist, eine einzelne HTML-Seite mit Inline-CSS und JavaScript unter strenger Content Security Policy, ohne eigenes Backend. Das reicht für einen Entwurf, aber mehr dann auch nicht. ## Antigravity IDE Extensions Für Visual Studio Code, Visual Studio (Preview), die JetBrains-IDEs ab Version 2026.2.1 und _Zed_ ist nun eine offizielle Erweiterung für Antigravity verfügbar. Google beschreibt sie ausdrücklich als leichtgewichtig: Der Multi-Agent-Betrieb bleibt in Antigravity 2.0, der Editor ist für die Stellen da, an denen man in konkrete Codepfade schaut oder mit dem Debugger durch Logik steppt. Einloggen geht mit jedem Plan inklusive Free Tier. Enterprise läuft über Gemini Enterprise oder Google-Cloud-Credentials unter Cloud-ToS, ohne Training auf euren Daten und mit IAM sowie VPC Service Controls. Und jetzt schaut mal in den Kalender: Die Gemini-Code-Assist-Extensions haben für Consumer-Tiers am 18. Juni aufgehört, Requests zu bedienen, die GitHub-Variante wurde am 17. Juli endgültig abgeschaltet, Enterprise- und Standard-Lizenzen laufen unverändert weiter. Das sind zwei Monate, in denen Google seine eigenen Nutzer ohne IDE-Integration hat sitzen lassen – mit Verweis auf die Standalone-App. Wer eine Konsolidierung ankündigt, sollte den Ersatz vor der Abschaltung liefern. ## Multica Da bin ich auch erst diese Woche drübergestolpert und habe noch keinen richtigen Use Case dafür, weil das aktuell mit Kanonen auf Spatzen geschossen wäre. Ändern kann sich das aber schneller, als man so denkt. _Multica_ ist ein Workspace, um verschiedene Coding-Agents an einem Ort zu verwalten. Du weist ein Issue einem Agenten zu wie einem Kollegen, der zieht die Arbeit, meldet Fortschritt, hebt die Hand bei Blockern und legt am Ende einen Pull Request hin. Unterstützt werden unter anderem _Claude Code_ , _Codex_ , _Cursor Agent_ , GitHub _Copilot CLI,_ _OpenClaw_ , _OpenCode_ , _Hermes_ , _Gemini_ , _Pi_ , _Kimi_ und _Kiro CLI_. Ausgeführt wird über einen Daemon auf deiner Maschine oder einer Cloud-Box, der Code bleibt dort. 47.3k Sterne auf GitHub, Backend in Go, Self-Hosting geht, alternativ gibt es SaaS über multica.ai. Der Name nickt in Richtung Multics, dem Time-Sharing-Betriebssystem der Sechziger. Bei der Lizenz lag meine erste Recherche falsch. Die LICENSE-Datei heißt „Multica License“ und besteht aus zwei Teilen, wobei Apache 2.0 nur der zweite ist. Teil eins bringt Zusatzbedingungen, die bei Konflikt Vorrang haben: kein gehosteter Dienst für Dritte ohne kommerzielle Lizenz, auch kostenlos nicht und auch ohne Werbung nicht. Logo, Produktname und Attribution dürfen nicht raus – auch nicht aus einem Fork. Wer nur Backend, Daemon oder CLI verwendet, muss in der nutzerseitigen Doku auf Multica hinweisen und verlinken. Beitragende stimmen zu, dass der Hersteller die Lizenz jederzeit verschärfen darf. Interner Betrieb in einer Organisation ist ausdrücklich frei, und für die meisten hier dürfte das der einzige relevante Fall sein. Es ist trotzdem das Muster, das ich mittlerweile bei jeder zweiten Bude sehe, und GitHub weist die Lizenz konsequenterweise als „NOASSERTION“ aus. Mein Take dazu: Nützlich sieht das aus und ich werde das bei Zeiten bestimmt auch mal ausprobieren. Nur „Open Source“ nennen wir es besser mal nicht. ## Claude Academy Anthropic hat am 20. August Claude Academy gestartet, eine eigene Lernplattform unter academy.claude.com. Angeboten werden fünf Produktstrecken zu Claude.ai, Cowork, Code, Tag und Platform, dazu die AI-Fluency-Kurse rund um das hauseigene 4D-Framework aus Delegation, Description, Discernment und Diligence. Alles kostenlos, mit Badges, personalisierten Empfehlungen und einem eigenen Skill, der Lernpfade vorschlägt. Das Verkaufsargument im Blogpost ist ehrlicher, als ich erwartet hätte: Es sei dasselbe Material, mit dem Anthropic seine eigenen Leute im Onboarding schult. Das bestehende Angebot unter anthropic.skilljar.com läuft seit Anfang März weiter und trägt nach wie vor die Zertifizierungen zum Associate, Developer und Architect sowie die Partner Academy. Zwei Angebote nebeneinander also, nicht eines auf dem anderen. Ob sich beide Angebote irgendwie sinnvoll ergänzen, habe ich mir ehrlicherweise noch nicht angesehen. ## Gemini 3.7 Flash: Developer Guide Parallel zum Release von _Gemini 3.7 Flash_ hat Google auch den Developer Guide veröffentlicht, der mir erst diese Woche vor die Füße gefallen ist. Der hätte gerne auch ausführlicher ausfallen dürfen. Immerhin gibt er eine Idee davon, was sich Google bei dem Modell gedacht hat. Das Marketing muss man gedanklich ein Stück weit ausklammern. Nützlich ist vor allem die Migrationsliste, weil dort die Bruchstellen stehen und nicht die Superlative. `temperature`, `top_p` und `top_k` sind deprecated, `thinking_budget` heißt jetzt `thinking_level` mit den Stufen low, medium und high, `candidate_count` fliegt raus, und Model-Turns vorbefüllen geht nicht mehr. Wer eine ältere Gemini-Anwendung einfach auf die neue Model-ID umbiegt, sammelt genau dort seine Fehler ein. Das Kontextfenster liegt bei einer Million Token, maximal 64.000 gehen raus. Für die Kalkulation relevant: Die 0,75 $ je Million Input- und 3,75 $ je Million Output-Token sind Einführungspreis bis zum 31. Dezember 2026, danach verdoppelt Google auf 1,50 beziehungsweise 7,50. ## DeepSeek-V4-Flash-Vision-Exp DeepSeek ist bei der Modellbezeichnung so wunderbar pragmatisch: „Nennen wir das Teil halt so, wie wir es über die API ansprechen würden“ – total simpel und logisch. Es handelt sich um ein experimentelles, multimodales Modell, das die Textfähigkeiten von _DeepSeek-V4-Flash_ bei Reasoning und Weltwissen beibehält und um Bildverarbeitung erweitert, berichtet The Decoder unter Berufung auf DeepSeeks eigene Ankündigung. Bilder beschreiben, Text aus Screenshots ziehen, Diagramme lesen. Angesprochen wird über das OpenAI-Chat-Completions-Format, den Anthropic-Messages-Endpoint oder die Responses-API, und die DeepSeek Harness unterstützt es ab 0.1.1 direkt. Die API-Doku ist an einer Stelle bemerkenswert konkret. Ein Bild kostet maximal 384 Token, unabhängig von der Ausgangsauflösung, weil vor der Verarbeitung ohnehin auf etwa 800 × 800 Pixel normalisiert wird. Ein optionales `detail`-Feld drückt auf 512 × 512, wenn feine Details egal sind. Bis zu 600 Bilder pro Request sind erlaubt, ab 15 Bildern sinkt die maximale Kantenlänge von 8.192 auf 4.096 Pixel, und einbetten lassen sie sich ausschließlich in User-Nachrichten. Das Format erkennt DeepSeek am tatsächlichen Dateiinhalt statt am Dateinamen oder am deklarierten MIME-Typ, was Ärger spart. Dazu kommt eine kostenlose Files-API, über die eine Datei bis 64 MiB einmal hochgeladen und danach per ID mehrfach referenziert wird. Abgerechnet wird zu V4-Flash-Preisen. Bei den Benchmarks das übliche Sternchen hinten dran wegen den Herstellermessungen. DeepSeek sieht die Vision-Variante in internen multimodalen Agenten-Tests nahe an Opus 4.8 und stellenweise darüber (übrigens: Opus 5 haben sie gar nicht erst erwähnt). ## MiniMax Design Eher unüblich für den hier gesetzten thematischen Rahmen, aber spannend, weil es mal was Neues ist. MiniMax stellt für Windows ab 10 und macOS ab 13 eine Desktop-App bereit, die für KI-Content-Produktion gebaut wurde, mit klarem Schwerpunkt auf Video. Im Zentrum steht das eigene Modell _MiniMax H3_ , drumherum arbeitet ein Team aus vier Agenten für Copy, Bild, Video und Audio parallel auf einem Canvas, dessen Nodes sich selbst verbinden. Dazu kommen wiederverwendbare Skills aus einem Marktplatz, eine 3D-Director-Stage zum Vorabstellen von Kamerafahrten und ComfyUI-Nodes für alle, die es genauer wollen. Als Zielgruppen nennt MiniMax auf X und der Produktseite Short Dramas, E-Commerce, Brand-TVCs und Ad Creatives, und den Anspruch bringt das Unternehmen schon in der Selbstbeschreibung der Plattform unter: > AI Agent Platform for Commercial Content Creation Bereitgestellt werden auch reichlich Modelle anderer Anbieter, und das Tutorial listet sie mitsamt Preisen auf (Achtung, das lädt sehr, sehr langsam). Bei den Bildern _Nano Banana Pro_ und _2 Flash_ , _GPT Image 1.5_ , _Seedream 4.5_ und _5.0 Lite_ , _Midjourney V7_ , _Flux Kontext_ , _Qwen Image Edit_ und diverse _Kling_ -Generationen. Beim Video _Seedance 2.0_ , _Wan 2.6_ , die hauseigenen _Hailuo_ -Modelle und _Kling_ bis hinauf zu _V3 Omni_. Dazu Text-to-Speech in zwei Stufen. In dieser Preistabelle steht der ehrlichste Kommentar zu „Commercial Creation“. Abgerechnet wird in Credits, ein Bild kostet zwischen 20 und 150. Video spielt in einer anderen Liga: _Kling V3 Omni_ in 4K mit Referenzen schlägt mit 1.200 Credits pro Sekunde zu Buche, ein Fünfzehn-Sekunden-Clip landet damit bei 18.000. _Wan 2.6_ in 1080p bei fünfzehn Sekunden sind 2.400. Bei _Seedance 2.0_ und _2.0 Fast_ ist die Credits-Spalte über alle sechs Zeilen komplett leer, während jedes andere Modell eine Zahl trägt. Und Teile der Tabelle sind noch nicht übersetzt, „有声“ und „无声“ für mit und ohne Ton, „积分/次“ für Credits pro Durchlauf. Drinnen steckt interessanterweise eine EULA für eine kommerzielle Desktop-App, aber keine Open-Source-Lizenz. Kurioserweise ist das Modell darunter offener als die Hülle: _H3_ selbst hat MiniMax als Open Model veröffentlicht. Ganz heißer Take: Das „Local-First Asset Center“ klingt nach Datensouveränität, meint aber nur, dass die Ergebnisse lokal landen. Generiert wird in Chinas Cloud, angemeldet wird sich mit einem HailuoAI-Account. Für Kundenmaterial würde ich das eher nicht anfassen, so aus einem EU-Standort heraus betrachtet. ## Hetzner Inference Experiment Bei Hetzner plaudert man ein wenig aus dem Nähkästchen, wie das Anfang August gestartete Inference-Experiment tatsächlich gelaufen ist. Der Rückblick nach einer Woche ist eines der ehrlichsten Post-Mortems, die ich dieses Jahr aus einem Rechenzentrum gelesen habe. Der Ablauf in Kurzform. Stiller Start am 7. August, aktive Kommunikation ab dem 10., Kapazitätsgrenze nach sechs Stunden. Die Time to First Token lag im 99. Perzentil zunächst bei fünf bis zehn Sekunden und schoss am zweiten Tag auf fast zehn Minuten hoch, womit die API zeitweise praktisch unbenutzbar war. Beliebtestes Modell war am ersten Tag _Qwen 3.6_ , sowohl nach Anfragen als auch nach Tokens, und es blieb auch danach vorn, wenn auch mit sehr vielen kleinen Anfragen statt großer Lasten. Nebenbei ist der Kubernetes-Cluster für die OpenClaw-Instanzen ans Limit gelaufen, woraufhin der Reiter für neue Accounts abgeschaltet wurde. Mehrere Instanzen haben sich durch Nutzereingaben selbst in einen kaputten Zustand konfiguriert. Der Kern steckt in der Hardware-Aufteilung. Der GEX131 hat genau eine RTX PRO 6000 Blackwell und bedient ausschließlich das kleine _Qwen_. Für _DeepSeek-V4-Flash_ , GLM-5.2 und _Kimi-K2.7-Code_ hat Hetzner eigens Server mit acht dieser GPUs gebaut – und jeden davon exklusiv einem Modell zugewiesen. Die Maschinen können die großen Modelle also durchaus, es waren schlicht zu wenige davon im Pool. Deshalb der Schnitt: > Das Inference Experiment wird fortgesetzt, allerdings in reduziertem Umfang: Kleinere Modelle wie Qwen 3.6 und 3.8 werden wir weiterhin anbieten. Bei großen Modellen legen wir vorerst eine Pause ein. Auch interessant, denn sie hätten wohl gern _Kimi K3_ angeboten, aber: > K3 war bereits erschienen und versprach sehr gute Ergebnisse in öffentlichen Benchmarks. Die sehr spezifischen Lizenzanforderungen von K3 erlaubten es uns jedoch nicht, das Modell als kostenloses Experiment anzubieten. Was Moonshot dort im Kleingedruckten verlangt, habe ich mir Ende Juli angesehen, und Hetzner ist offensichtlich zum selben Schluss gekommen. Auf der Roadmap stehen bessere Doku, ein Review der Modellauswahl anhand echter Nutzungsmetriken und möglicherweise Re-Ranking sowie Embeddings für RAG-Pipelines. Spannend, spannend! Und vielen Dank und Gruß nach Gunzenhausen, dass sie sich den Stress überhaupt geben, das dann kostenlos bereitstellen und hinterher auch noch öffentlich berichten, was und wie es denn so gelaufen ist. ## GPT-5.6 Sol Preissenkung OpenAI senkt die API- und Credit-Preise von GPT-5.6 Sol um mehr als 20 Prozent für die nächsten drei Monate, konkret laut Reuters auf 4 Dollar je Million Input- und 20 Dollar je Million Output-Token. Das greift in der API sowie bei Codex-Credits und ChatGPT Work, während Pro, Plus und Business unverändert bleiben. Die Begründung auf X ist dann eher Marketing-Blabla – irgendwas mit Frontier vorantreiben bei gleichzeitig steigender Effizienz. Die Geschichte hinter der Meldung steht woanders. Die New York Times berichtet unter Berufung auf zwei Personen mit Kenntnis der Gespräche, Anthropics Banker stellten potenziellen Investoren einen Börsengang mit über 100 Milliarden Dollar Volumen bei rund zwei Billionen Bewertung in Aussicht. Ein Statement von Anthropic gibt es natürlich nicht dazu. Mitten in diese Roadshow hinein senkt der direkte Wettbewerber die Preise. Parallel kursieren Hinweise auf Tests eines _GLM-5.3-Flash_ , was den Druck von der anderen Seite erklärt. Gesenkt wird hier weniger der Preis als die Bewertungsgrundlage der Konkurrenz. ## Ox Alpha, oder wie ich mich von zwei Tweets aufs Glatteis führen ließ Einige Labs nutzen OpenRouter gern dafür, ein neues Modell anonym zum Testen bereitzustellen, weder Lab noch Modell sind dann ersichtlich. OpenRouter kennzeichnet das als „Stealth“. Seit dem 20. August liegt dort Ox Alpha, und die Community auf X.com hat seither wenig anderes zu tun. Die Eckdaten laut Modellseite: 1.048.576 Token Kontext, maximal 131.072 Token Output, Text, Bild und Video rein, Text raus, Tool Calling und strukturierte Ausgaben, gedacht für Coding, langlaufende agentische Arbeit und Produktionslasten. Kostenlos, ein einziger Provider – der Prompts und Completions zwar speichert, aber nicht darauf trainiert. Der Durchsatz liegt Stand 22. August bei 21 Tokens pro Sekunde, was ungefähr dem entspricht, was ich vergangene Woche mit _Qwen3.8-27B_ lokal auf meinem MacBook Pro M5 gemessen habe. Als Indiz für richtig fette Infrastruktur taugt das nichts. Herumgereicht wird stattdessen eine Kapazitätsansage: OpenCode nennt 100 Billionen Tokens pro Tag und hat das Angebot am 21. August um sechs Tage verlängert, beim Nous-Research-Portal soll laut Alex Volkov sogar eine Billiarde pro Tag drin sein. Nur ist eine Ansage eben eine Ansage, und niemand hat sie nachgezählt. Belastbar sind die Zahlen, die OpenRouter selbst zählt. Allein über _Hermes Agent_ sind 490 Milliarden Tokens gelaufen, über _Claude Code_ weitere 314 Milliarden, bei 99,99 Prozent Uptime über drei Tage. Die erfolgreich ausgelieferte Inferenz liegt mit 99,51 Prozent etwas darunter, was bei einem kostenlosen Preview niemanden überraschen dürfte. Zum Größenvergleich taugt der Pick von oben. Ein deutscher Hoster, der eigens Achtfach-GPU-Server baut, nimmt nach einer Woche die großen Modelle vom Netz, weil schlicht zu wenige davon im Pool stehen. Hier verschenkt jemand eine Kapazität, die im Bereich dessen liegt, was die größten Frontier-Anbieter für ihr komplettes Geschäft angeben. Das ist keine Fünf-Mann-Bude mit drei RTX-4090-Clustern im Keller. Bei der ersten Spekulationsrunde hätte ich felsenfest behauptet, dass kein führendes US-Lab dahintersteckt, weil das nicht zu deren Umgang mit neuen Modellen passt. Große Ausnahme war OpenAI, die mit „Horizon Alpha“ und „Horizon Beta“ Ende Juli 2025 GPT-5-Vorstufen als Stealth auf OpenRouter gelegt hatten, was OpenRouter beim Launch von GPT-5 dann auch bestätigte. Einen Unterschied hebt OpenRouter diesmal selbst hervor: Bei Horizon wurde ausdrücklich für Feedback und Training mitgeloggt, bei _Ox Alpha_ trainiert der Anbieter nicht mit. Dann fingen Leute aus dem Google-DeepMind-Lager an, beiläufig Öl ins Feuer zu gießen. Vamsi Batchu schrieb „Google is back. Trust the process.“, Jonathan Ouyang legte „It’s Gemini time :)“ nach, und ich war schon fest überzeugt: ein Google-Modell, nur eben nicht unter dem Namen _Gemini_ oder _Gemma_. Also habe ich das Naheliegendste getan und _Gemini 3.7 Flash_ gefragt. Nach ein paar Prompts waren Gemini und ich uns ziemlich einig, dass es _Giedi_ heißen könnte, benannt nach dem Doppelstern von Alpha Capricorni, die klassisch Prima und Secunda Giedi heißen. Passt wie Faust aufs Auge in Googles Nomenklatur. Ich habe also ein Modell von Anbieter A gefragt, ob ein anonymes LLM zufällig auch von Anbieter A stammt. Was dabei zurückkommt, ist kein Wissen, sondern eine plausibel klingende Ableitung aus Trainingsdaten. Genau das kam, und ich habe es genommen, weil es lustig ist. Während ich Sternbilder sortierte, haben andere Leute tatsächlich gemessen. @unclecode hat neun Infrastruktur-Probes über Tokenizer, Error Codes und versteckte Templates gegen zwölf Verdächtige laufen lassen, und eine Familie besteht jeden einzelnen Tokenizer-Test: GLM. Tim Dettmers liefert einen zweiten Fingerabdruck und weist darauf hin, dass Zhipu eines der wenigen Labs mit schwachem Partial Prefill bei gleichzeitig schnellem Output ist, wobei das Modell rund 30 Prozent über _GLM-5.3_ liegt. @skalskip92 hat Luftbilder und Satellitenaufnahmen durchgeschickt und kommt zu einem klaren Nein zur Gemini-These, weil Googles Modelle bei Computer Vision traditionell stark sind und _Ox Alpha_ dort bestenfalls Mittelmaß liefert. Am schönsten hat es @tokengremlin formuliert, als er fragte, ob es nicht ein bisschen demütigend sei, dass Google fremde Modelle als Marketing braucht, um Leute für _Gemini_ zu interessieren. Die Vage-Posterei zielte offenbar nie auf _Ox Alpha_ , sondern auf das, was bei Google selbst in der Pipeline steckt. Die Leistung ist derweil so umstritten, dass beide Lager Belege haben. Auf einem DeepSWE-Subset meldet @karanc_12 über 80 Prozent gegen 52 für _GPT-5.6 Sol_ und 65 für _Fable_. Bindu Reddy dagegen hat es evaluiert und sortiert es auf dem Niveau von _Kimi 2.6_ ein, zwei Generationen alt, nennt es im selben Atemzug aber ein Marketing-Meisterstück. Auf einem kontaminationsfreien Privat-Benchmark fällt es deutlich ab, auf einem Cybersecurity-Benchmark liegt es hinter jedem Frontier-Modell außer _GPT-5.6 Luna_. Und dann one-shottet es eine GPU-beschleunigte Fluidsimulation in tausend Zeilen HTML. Das könnte alles noch sehr spannend werden. Oder eben auch nicht, wenn es sang- und klanglos wieder OpenRouter in ein paar Wochen verschwindet und niemand auch nur ein Wörtchen rauslässt, was das denn nun genau war. Ready for now. Nächste Woche vielleicht wieder mit mehr Blech und weniger Astronomie.

t01.li

Seit August 2026 wird Art. 4 EU AI Act durchgesetzt – aber anders, als viele Schulungsanbieter behaupten. Keine Zertifikatspflicht, kein Einheitskurs. Was KMU wirklich tun müssen: rollenbezogen befähigen, schlank dokumentieren. Ein Reality-Check mit Rechtsstand August 2026.

KI-Kompetenz nach Art. 4: Was Unternehmen jetzt wirklich tun müssen

Seit Februar 2025 gilt die KI-Kompetenzpflicht, seit dem 2. August 2026 kann sie in Deutschland auch überwacht werden – und trotzdem braucht niemand einen staatlich anerkannten KI-Führerschein. Der AI Act verlangt weder einen Einheitskurs für die Belegschaft noch eine feste Stundenzahl. Er verlangt etwas Unbequemeres. Unternehmen müssen wissen, welche KI sie wofür einsetzen, welche Menschen dafür welche Fähigkeiten brauchen und warum die gewählten Maßnahmen zum Risiko passen. Auf LinkedIn läuft dazu seit Wochen das erwartbare Programm. Die üblichen Verdächtigen – gestern noch Krypto-Experte, heute eben KI-Berater, der Markt will es so – produzieren Panikbeiträge im Akkord, meist mit wenig Substanz und viel Ausrufezeichen. In seriösen Newslettern taucht die angebliche Zertifikatspflicht dagegen kaum auf. Das allein ist schon ein brauchbarer Indikator. Genau in diese Lücke zielt das Panik-Marketing mancher Schulungsanbieter, das schon zum 2. August ins Leere lief. Wer im August 2026 „gesetzlich vorgeschriebene KI-Zertifizierung“ verkauft, verkauft etwas, das es rechtlich nicht gibt. Was es stattdessen gibt, ist eine Organisationspflicht – und die ist mit gesundem Menschenverstand und überschaubarem Aufwand erfüllbar. Der Reihe nach. ## TL;DR Art. 4 EU AI Act gilt seit Februar 2025, seit August 2026 wird er beaufsichtigt – als Förderpflicht, nicht als Prüfungspflicht. * Der Digital Omnibus (Juli 2026) hat Art. 4 entschärft: Maßnahmen ergreifen ja, garantiertes Kompetenzniveau pro Person nein * Keine Zertifikatspflicht, kein Einheitskurs, keine Stundenzahl, kein Pflicht-KI-Beauftragter * Schon normale ChatGPT-Nutzung im Marketing fällt in den Anwendungsbereich * Was zählt: KI-Inventar, rollenbezogene Maßnahmen, schlanke Dokumentation * Hochrisiko-Pflichten sind verschoben (Dez. 2027 / Aug. 2028) – Art. 4 und Art. 50 gelten trotzdem jetzt ## Was der Digital Omnibus an Art. 4 geändert hat Die ursprüngliche Fassung von Art. 4 verlangte von Anbietern und Betreibern, „nach besten Kräften“ ein ausreichendes Maß an KI-Kompetenz sicherzustellen. Eine Formulierung, die mehr Fragen aufwarf als beantwortete – welches Niveau ist ausreichend, wer misst das, und was passiert mit dem Kollegen, der nach drei Schulungen immer noch Kundendaten in den Chatbot kippt? Die Digital-Omnibus-Verordnung (EU) 2026/1744, seit dem 27. Juli 2026 in Kraft, hat das aufgeräumt. Die neue Fassung verpflichtet Unternehmen, Maßnahmen zu ergreifen, die die Entwicklung von KI-Kompetenz fördern und unterstützen. Geschuldet ist damit ein angemessener organisatorischer Prozess, kein garantiertes Lernergebnis jedes einzelnen Mitarbeitenden. Die FAQ der EU-Kommission bestätigt das ausdrücklich – ein spezifisches oder „ausreichendes“ Niveau ist nicht mehr vorgeschrieben. Parallel hat der Omnibus die Fristen für Hochrisiko-Systeme deutlich nach hinten geschoben. Eigenständige Hochrisiko-KI nach Anhang III – etwa Bewerber-Screening oder Kreditwürdigkeitsprüfung – muss erst zum 2. Dezember 2027 die vollen Betreiberpflichten erfüllen, KI als Sicherheitsbauteil in regulierten Produkten nach Anhang I zum 2. August 2028. Wer daraus ableitet, bis Ende 2027 sei nichts zu tun, liegt daneben. Art. 4 gilt seit Februar 2025 unverändert, und die Transparenzpflichten nach Art. 50 – Kennzeichnung von Chatbots und synthetischen Inhalten – greifen seit dem 2. August 2026. In Deutschland kommt seit Ende Juli die Aufsicht dazu. Das KI-Marktüberwachungs- und Innovationsförderungsgesetz (KI-MIG), in Kraft seit dem 29. Juli 2026, macht die Bundesnetzagentur zur zentralen Marktüberwachungsbehörde, Anlaufstelle und Beschwerdestelle. Beschäftigte, Mitbewerber oder Betroffene können vermutete Verstöße dort melden. Art. 4 selbst kennt zwar keinen eigenen Bußgeldtatbestand, aber im Rahmen eines Beschwerdeverfahrens landet die Frage nach den Kompetenzmaßnahmen trotzdem auf dem Tisch. ## Wer betroffen ist – Spoiler: fast jeder Die KI-Verordnung unterscheidet zwischen Anbietern, die KI-Systeme entwickeln oder unter eigenem Namen auf den Markt bringen, und Betreibern, die KI-Systeme in eigener Verantwortung beruflich nutzen. Die überwiegende Mehrheit der deutschen KMU ist Betreiber – und zwar schneller, als vielen bewusst ist. Der geschäftliche Einsatz von _ChatGPT_ , _Microsoft Copilot_ , _Claude_ oder _Gemini_ reicht dafür aus, ebenso KI-Funktionen in Bestandssoftware wie CRM- oder ERP-Systemen. Die EU-Kommission nennt in ihrer FAQ ausdrücklich das Beispiel von Beschäftigten, die _ChatGPT_ für Werbetexte oder Übersetzungen einsetzen. Auch dann muss das Unternehmen über spezifische Risiken wie Halluzinationen informieren. Ein Human-in-the-Loop ersetzt die Kompetenzanforderung übrigens nicht – die kontrollierende Person braucht selbst die passenden Fähigkeiten, sonst kontrolliert da niemand, sondern nickt nur ab. Erfasst sind neben der Belegschaft auch Auftragnehmer und Dienstleister, die im Auftrag der Organisation mit KI arbeiten. Wer keinerlei beruflichen Kontakt zu KI-Systemen hat, fällt umgekehrt nicht allein wegen seiner Unternehmenszugehörigkeit unter die Pflicht. Ein kurzes gemeinsames Fundament kann trotzdem sinnvoll sein, schon weil KI-Funktionen inzwischen ungefragt in Standardsoftware auftauchen und Shadow AI sonst unbemerkt bleibt. ## Was Art. 4 nicht verlangt Der Markt für KI-Schulungen lebt gut von Behauptungen, die einer Prüfung nicht standhalten. Eine Auswahl, jeweils mit Rechtsstand August 2026: * **„Jeder Mitarbeitende braucht ein Zertifikat.“** Falsch. Es existiert keine Zertifikatspflicht, und Angebote, die mit staatlich vorgeschriebener KI-Zertifizierung werben, entbehren einer rechtlichen Grundlage. * **„Alle müssen denselben Kurs absolvieren.“** Falsch – ein Einheitskurs widerspricht der rollenbezogenen Logik des Gesetzes eher, als dass er sie erfüllt. * **„Es gibt eine vorgeschriebene Stundenzahl oder Prüfung.“** Weder Gesetz noch EU-FAQ nennen eine Dauer oder verlangen eine Wissensmessung. * **„Ein KI-Beauftragter ist Pflicht.“** Art. 4 schreibt keine Governance-Struktur vor. Die Rolle kann im KMU trotzdem als Koordinationsfunktion taugen. * **„Das betrifft nur Hochrisiko-KI.“** Art. 4 gilt für alle KI-Systeme im beruflichen Einsatz. Hochrisiko löst zusätzliche Anforderungen aus, später. Das EU-Register mit Praxisbeispielen zur AI Literacy ist übrigens Inspirationsquelle, keine Compliance-Vorlage. Die Kommission stellt klar, dass das Kopieren eines Registereintrags keine Konformitätsvermutung erzeugt. ## Was stattdessen zu tun ist Die Pflicht lässt sich auf sechs Schritte herunterbrechen, die auch ein Zehn-Personen-Betrieb ohne Compliance-Abteilung schafft. Erstens die tatsächliche KI-Nutzung erfassen – inklusive der inoffiziellen. Eine gepflegte Tabelle mit System, Zweck, Nutzergruppen, Datenarten und Kontrollpunkten genügt als Inventar. Zweitens die eigene Rolle klären, denn ein reiner Chatbot-Nutzer braucht anderes Wissen als ein Softwarehaus, das unter eigener Marke anbietet. Drittens Risiken je Anwendungsfall bewerten. Nicht der Modellname entscheidet über den Schulungsbedarf, sondern die Frage, ob am Ende ein interner Textentwurf steht oder eine Vorauswahl von Bewerbungen. Viertens Maßnahmen rollenbezogen gestalten – Basismodul für alle Nutzer, Vertiefung für Power User, HR, IT und Führung. Fünftens die Maßnahmen tatsächlich durchführen, wobei Einweisung, Leitfaden, Workshop oder E-Learning gleichermaßen zulässig sind. Und sechstens dokumentieren und aktualisieren, wenn neue Tools, neue Funktionen oder Vorfälle das erfordern. Für die Geschäftsführung ist der Anspruch dabei überschaubarer, als es klingt. Sie muss nicht lernen, bessere Prompts zu schreiben. Sie sollte beantworten können, welche fünf KI-Anwendungen geschäftlich am wichtigsten sind, wer welche Systeme mit welchen Daten nutzen darf und wie das Unternehmen von Vorfällen erfährt. Wer diese Fragen nicht beantworten kann, hat kein Schulungsproblem, sondern ein Übersichtsproblem. Selbstcheck KI-Kompetenz nach Art. 4Sechs Schritte, Inventar-Vorlage und das schlanke Doku-Paket zum Abhaken.checkliste-ki-kompetenz-art-4.pdf65 KBdownload-circle ## Dokumentation: schlank schlägt Zertifikatsordner Eine gesetzliche Prüfungs- oder Nachweisform schreibt Art. 4 nicht vor. Trotzdem ist Dokumentation der Punkt, an dem sich im Ernstfall alles entscheidet. Unterlässt die Geschäftsführung zumutbare Qualifizierungsmaßnahmen, riskiert sie bei Fehlern von Beschäftigten eine persönliche Haftung wegen Organisationsverschuldens nach § 130 OWiG und § 43 GmbHG. Führt mangelnde Prompt-Hygiene zu einer Datenpanne, drohen Bußgelder nach Art. 83 DSGVO. Und bei mitbestimmungspflichtigen KI-Systemen redet der Betriebsrat nach § 87 BetrVG mit. Das größere praktische Risiko liegt darin, nach einem Vorfall nicht erklären zu können, welche Systeme bekannt waren, welche Risiken erkannt wurden und warum die Maßnahmen angemessen erschienen. Ein schlankes Nachweispaket – KI-Inventar, Kompetenzmatrix je Rolle, Maßnahmenblätter mit Datum und Zielgruppe, Teilnahme- oder Bereitstellungsnachweise, eine kurze Begründung der Angemessenheit und ein Aktualisierungsprotokoll – ist dafür wertvoller als ein dicker Ordner mit generischen Kursbescheinigungen. Ehrlich und aktuell schlägt umfangreich und tot. ## Take dazu Art. 4 ist keine Einkaufspflicht für Schulungen, sondern eine Denkpflicht. Das Gesetz verlangt, den Kompetenzbedarf aus der realen KI-Nutzung abzuleiten und darauf angemessen zu reagieren – mehr nicht, aber auch nicht weniger. Der Digital Omnibus hat den Rechtsrahmen milder gemacht, die betriebliche Notwendigkeit bleibt. Kompetente Teams produzieren weniger Fehler, erkennen ungeeignete Anwendungen früher und holen aus freigegebenen Systemen mehr heraus. Compliance ist hier der Nebeneffekt, nicht der Zweck. _Hinweis: Ich bin Marketing- und Tech-Mensch, kein Jurist. Dieser Artikel ist meine Einordnung öffentlich zugänglicher Quellen, keine Rechtsberatung. Die verbindliche Prüfung deines konkreten Einzelfalls, insbesondere bei Hochrisiko-Anwendungen, Beschäftigtenbewertung oder grundrechtssensiblen Einsätzen, kann und darf nur ein zugelassener Rechtsanwalt leisten._

t01.li

Muse Glimmer, Qwen3.8-27B, Grok 4.6 und GLM-5.3 in einer Woche. Auffällig ist nicht, wer im Benchmark vorn liegt, sondern dass fast jeder Release über Tokens pro Aufgabe argumentiert. Dazu Preisbewegungen in beide Richtungen und ein Weight-Delay aus Sicherheitsgründen.

AI Picks der 33. KW

Kein einziges Stück Hardware diese Woche, dafür ein Modell-Stau, wie ich ihn seit dem Frühjahr nicht gesehen habe. Meta, Alibaba, Nvidia, SpaceXAI, Z.ai, DeepSeek, Microsoft und Google haben zwischen Montag und Freitag abgeladen, dazu kommen Preisbewegungen in beide Richtungen. Was mir beim Sortieren aufgefallen ist: Fast jeder dieser Releases argumentiert nicht mehr darüber, wie schlau das Modell ist, sondern wie viele Tokens es für eine Aufgabe verbrennt. Grok kommt mit einem Viertel des Inputs von Opus 5 aus, GLM schlägt Opus 4.8 mit 50.000 statt 120.000 Output-Tokens, Nvidia baut einen Router, damit das teure Modell die Fließbandarbeit gar nicht erst sieht, und IBM zieht dem Agenten-Gedächtnis die Rechnung ab. Bei DeepSeek läuft es genau andersherum – dort versechsfacht sich ausgerechnet der Cache-Preis. Auf geht's in die doch sehr LLM-lastige 33. Kalenderwoche des Jahres 2026, wohl bekomm's. ## Muse Glimmer Bei Meta fällt mit Muse Glimmer der kleine Bruder von Spark hinten raus. Open Weights unter Apache 2.0, 30 Milliarden Parameter, gebaut für lokale Agenten-Workflows mit Text- und Bildeingabe, Tool-Calling, mehrschrittigem Reasoning und automatischer Fehlerbehebung. Die Gewichte liegen auf Hugging Face. Die Verwandtschaft zu _Spark_ ist wörtlicher gemeint, als „kleiner Bruder“ vermuten lässt: Meta hat Glimmer per Logit-Distillation auf den Outputs von Muse Spark vortrainiert, mit ähnlichem Datenmix wie beim Lehrermodell. Unquantisiert bräuchte das Ding über 55 GB, mit 4-Bit-Kompression bleiben unter 20 GB übrig – genug Luft für KV-Cache, Perception-Encoder und den Speculative-Decoding-Drafter innerhalb von 24 oder 32 GB. Optimierte Integrationen für llama.cpp, MLX und ExecuTorch sollen in den nächsten Tagen folgen, die Entwicklerdokumentation steht bereits. Interessant für alle, die hier mitlesen und selbst basteln: Meta nennt _OpenClaw_ explizit als kompatibles Scaffold. Und im Intelligence Index von Artificial Analysis liegt Glimmer bei 35 Punkten, was es in seiner Größenklasse an die Spitze setzt. Dazu gleich mehr bei Nvidia. ## Qwen3.8-27B Open Weights verfügbar Sobald man X.com auch nur öffnet, hagelt es einem Beiträge zu Qwen3.8-27B um die Ohren. Auf Hacker News landete der Release mit 893 Punkten auf Platz eins, und das Ding wird gerade durch die Community gereicht wie geschnitten Brot. Der Kontrast, der das erklärt, steckt in der Familie selbst. _Qwen3.8-Max_ ist ein Brocken mit 2,4 Billionen Gesamtparametern und rund 95 Milliarden aktiven, für dessen Betrieb im Maßstab man ein GB300-NVL72-Rack braucht – die Gewichte dazu kamen am 13. August unter Custom License. Das 27B ist einen Tag später gefolgt, dicht statt MoE, unter Apache 2.0 auf Hugging Face, und läuft 4-Bit-quantisiert mit rund 17 GB auf einer einzelnen RTX 4090 oder einem 24-GB-Mac. Nicht das Flaggschiff ist die Nachricht, sondern das Modell, das Leute tatsächlich selbst hosten. Technisch ist es ein natives Vision-Language-Modell mit eigenem Vision-Encoder, das Text, Bild und Video frisst, bei 262.144 Token Kontext nativ und bis zu einer Million per YaRN. Die Architektur verschachtelt schnelle lineare Layer mit vollen Self-Attention-Blöcken. Ich teste damit gerade ein wenig interdisziplinäres Zeug (Chats, CLI, Agent Pipeline, etc.) und der Lüfter vom MacBook dreht weniger fröhlich frei, als ich zuerst annahm. Aktuell läuft das Teil mit 19,4 Tok/Sek. bei aktiviertem Reasoning, damit kann man doch arbeiten. ## Nemotron 3.5 Lightning Auch bei Nvidia fällt mal wieder Software hinten raus. Nemotron 3.5 Lightning ist ein offenes Mixture-of-Experts-Modell mit 31,6 Milliarden Gesamt- und 3,6 Milliarden aktiven Parametern, hybride Mamba-2-Architektur, ein Kontextfenster von einer Million Token, ausgeliefert als BF16 und in nativer NVFP4-Quantisierung unter OpenMDW-1.1-Lizenz. Flankiert wird das Release von NeMo Switchyard, einer quelloffenen Routing-Bibliothek auf Proxy-Ebene, die Anfragen dynamisch zwischen teuren Frontier-Modellen und schlankeren Kandidaten wie Lightning verteilt. Artificial Analysis hat nachgemessen und kommt im Intelligence Index auf 24 Punkte, gleichauf mit gpt-oss-120b. Das ist hinter _Qwen3.6 35B A3B_ (32) und Muse Glimmer (35), knapp hinter Nvidias eigenem Nemotron 3 Super, das mit 120 Milliarden Parametern fast das Vierfache auf die Waage bringt. Nvidia bestreitet das nicht einmal. Die Rechnung soll über die Geschwindigkeit aufgehen: Eine Aufgabe im Benchmark erledigt Lightning in rund einer halben Minute, wo _Qwen3.6 35B A3B_ etwa dreieinhalb braucht. Bei den Agenten-Tests sieht es besser aus als bei der Rohintelligenz, GDPval-AA v2 springt um 334 Elo-Punkte gegenüber dem Nano-Vorgänger. Und jetzt die Stelle, an der man genauer hinschauen sollte. Nvidia bewirbt bis zu vierfache Token-Geschwindigkeit gegenüber vergleichbar großen Modellen, bei 10.000 PinchBench-Tasks kommt davon aber nur ein Tempoplus von 30 Prozent an. Der Flaschenhals sitzt in der Orchestrierung, nicht im Modell. Diviel zitiertete Zahl, wonach Switchyard die Kosten einer Aufgabe auf ein Drittel gegenüber _Opus 4.8_ drückt, stammt nach Nvidias eigener Formulierung aus internen Benchmarks – unabhängig nachgemessen hat das bisher noch niemand (zumindest habe ich nichts gefunden). Hot Take: Als Baustein in mehrstufigen Agenten-Pipelines ergibt das Sinn. Als Modell, das man einfach so nimmt, eher nicht. ## Grok 4.6 Irgendwie ist mir das immer noch keinen eigenen Artikel wert, auch wenn das Ding aus Elmos Bude mit jeder Version besser im Wettbewerbsvergleich dasteht. Asche über mein Haupt. SpaceXAI schiebt mit Grok 4.6 ein Update nach, das laut den Messungen von Artificial Analysis vor allem bei agentischen Workflows und in Sachen Token-Effizienz punkten will. Im Intelligence Index landet das Modell bei 61 Punkten und zieht damit mit _GPT-5.6 Sol_ gleich, knapp hinter _Claude Fable 5_ (62) und _Claude Opus 5_ (63). Spannender als die Indexmathematik ist die Ausführung: Auf AA-Briefcase, dem Langzeit-Benchmark für Wissensarbeit, braucht Grok 4.6 im Schnitt etwa 53 Turns und 0,5 Milliarden Input-Tokens, während Claude Opus 5 im Max-Modus rund 103 Turns und das Vierfache an Tokens akkumuliert. Bei Aufgaben, die über Stunden laufen, ist das ein Kostenvorteil weit jenseits des Token-Preises. Die Preisgestaltung bleibt mit 2 $ pro Million Input- und 6 $ pro Million Output-Tokens auf dem Niveau des Vormodells. Zwei Fußnoten hat das aber. Ab 200.000 Prompt-Tokens verdoppeln sich die Sätze auf 4 $ und 12 $, und zwar für die gesamte Anfrage – bei einem 500K-Kontextfenster und agentischen Workloads ist das keine theoretische Grenze. Die Cache-Hits sind zudem von 0,30 $ bei Grok 4.5 auf 0,50 $ gestiegen, und einen Batch-Rabatt gibt es anders als bei _Grok 4.20_ nicht mehr. Verfügbar ist das Modell über die SpaceXAI-API, Cursor, Grok Build sowie Gateways wie OpenRouter, Vercel oder Cloudflare. * Kontextfenster: 500.000 Tokens (Input: Text/Bild, Output: Text) * Preise (API): 2,00 $ / 1M Input-Tokens, 6,00 $ / 1M Output-Tokens, Cache-Hits 0,50 $ * Knowledge Cutoff: 1. Februar 2026 * Reasoning-Stufen: low, medium, high (Default), xhigh * Benchmarks: 61 Index-Score, GDPval-AA v2 Elo 1753, Terminal-Bench v2.1 88,4 % (AA-Messung, Opus 5 liegt bei 89 %) Kleiner Dämpfer zu den Benchmarks: SpaceXAI selbst führt in der Release-Tabelle Terminal-Bench v3.0 mit 26 Prozent, wo GPT-5.6 Sol auf 34,6 kommt. Die 88,4 Prozent stammen aus AAs Messung auf der älteren v2.1. Beide Zahlen stimmen, sie messen nur nicht dasselbe – wer sie nebeneinander stellt, ohne die Version zu nennen, erzählt die Story, die die Daten nicht hergeben. ## GLM-5.3 Z.ai schiebt mit GLM-5.3 ein reines Post-Training-Update nach. Das Basismodell bleibt identisch zu Version 5.2, sämtliche Zuwächse stammen aus skaliertem Reinforcement Learning über synthetisierte Umgebungen und das hauseigene Framework slime, dessen Durchsatz bei Long-Horizon-Coding-RL um mehr als das 2,3-Fache gestiegen ist. Bei den Zahlen für Coding-Agenten sieht das nach mehr aus als nach Feinschliff: Terminal Bench 3.0 klettert von 4,6 auf 28,3, DeepSWE v1.1 von 46,2 auf 66,9. Zum Vergleich nennt Z.ai für _GPT-5.6 Sol_ 34,6 beziehungsweise 72,7 – der Abstand zur geschlossenen Spitze bleibt also, er wird nur kleiner. Für Entwickler praktisch relevant: In der API lässt sich das Thinking nicht mehr abschalten. `disabled` fliegt raus, `reasoning_effort` kennt nur noch `low`, `high` und `max`, Default ist `max`. Wer bisher mit abgeschaltetem Thinking gefahren ist und einfach die Model-ID tauscht, bekommt einen Fehler zurück. Der eigentliche Hammer steckt aber nicht in den Coding-Zahlen. Z.ai schreibt, die Cyber-Fähigkeiten hätten sich beim Hochskalieren des Post-Trainings schneller entwickelt als erwartet – das Modell begann, über mehrere Stufen einer Exploit-Kette hinweg zu planen, statt nur isolierte Schwachstellen zu finden. In Zusammenarbeit mit Sicherheitsteams in China hat es an realen Codebasen 2.436 Schwachstellen über 269 Projekte identifiziert, davon 1.097 mit mittlerem bis hohem Schweregrad, quer durch System-Kernel, Browser-Engines und Netzwerkprotokolle. Die älteste stammt von 1981, im Schnitt lebte eine Lücke 26,6 Jahre unentdeckt. Auf CyberGym landet GLM-5.3 bei 84,5 Prozent und damit vor Claude Mythos 5 (83,8) und GPT-5.6 Sol (83,6). In Relation zur Größenordnung: Anthropic meldete für Project Glasswing über 10.000 gefundene Schwachstellen mit hohem oder kritischem Schweregrad – allerdings über rund 50 Partnerorganisationen hinweg und mit Mythos Preview. Deshalb kommen die Open Weights nicht sofort, sondern erst rund zwei Wochen nach dem Launch, nach Abschluss von Sicherheitsprüfung und Hardening. Weiter oben in der Exploit-Kette bleibt der Abstand nach wie vor messbar: ExploitBench springt zwar von 24,4 auf 54,4 Prozent, Mythos 5 liegt dort bei 78,0. Dass ein Anbieter Gewichte aus Sicherheitsgründen zurückhält, kenne ich bisher vor allem als westliche Geste mit Presseanhang. Hier steht eine konkrete Zahl dahinter und ein öffentliches Disclosure-Ledger. Zwei Wochen sind keine Ewigkeit, aber es ist ein anderes Signal als das übliche „wir nehmen Sicherheit ernst“. Nebenbei bemerkt evaluiert Z.ai fast alle diese Benchmarks im Harness von Claude Code 2.1.207. Man nimmt halt, was funktioniert. ## DeepSeek V4-Pro-0813, neue Preise und eine eigene Harness DeepSeek entlässt sein Flaggschiff mit dem Build V4-Pro-0813 aus der Testphase und schiebt mit DeepSeek Harness direkt ein modulares Agenten-Framework unter MIT-Lizenz hinterher, das per npx über eine lokale Weboberfläche läuft. Modellname, Parameterzahl und das Kontextfenster von einer Million Token bleiben unverändert, bestehende Integrationen laufen ohne Anpassung weiter. Neu sind native Unterstützung der OpenAI-Responses-API mit Codex-Anbindung und dreistufiges Reasoning, für das DeepSeek im Agenten-Alltag die mittlere Stufe empfiehlt. Bei den Benchmarks zeigt sich die gewohnte Schere zwischen Hersteller und Messstelle. In DeepSeeks eigener Vergleichstabelle steigt Terminal Bench 2.1 von 72,1 auf 87,9 und DeepSWE von 12,8 auf 62,7. Artificial Analysis misst auf demselben Benchmark 79 Prozent – und exakt dieselben 79 Prozent für das kleinere V4-Flash-0731. Im Intelligence Index klettert V4-Pro von 45 auf 53 Punkte, zieht damit mit _GLM-5.2_ gleich und läuft hinter _Muse Spark_ 1.2 (57), _Qwen3.8 Max_ (58), _Kimi K3_ (60) und _Claude Opus 5_ (63) her. Womit wir bei der Zahl wären, die AA selbst hervorhebt: > DeepSeek V4 Pro 0813 is only 1 point ahead of DeepSeek V4 Flash 0731 on the Artificial Analysis Intelligence Index, and has ~3.8x the active parameters. The two models tie on Terminal-Bench 2.1 at 79%. Ein Punkt Vorsprung bei 49 statt 13 Milliarden aktiven Parametern. Wer sein Modell nach Kosten pro erledigter Aufgabe aussucht statt nach Position im Ranking, sollte sich das durchrechnen. Parallel dreht DeepSeek wie angekündigt ab dem 16. August, 16 Uhr UTC, an der Preisschraube und führt zeitabhängige Tarife ein. Außerhalb der chinesischen Arbeitszeiten kostet die Million Input-Token künftig 0,66 statt 0,435 $, der Output steigt auf 1,98 statt 0,87 $, in den Stoßzeiten zwischen 1 und 4 sowie 6 und 10 Uhr UTC verdoppeln sich diese Werte exakt. Richtig teuer wird es im Unterbau: Die Preise für Cache-Treffer versechsfachen sich im günstigsten Fall von 0,003625 auf 0,022 $, zur Spitzenzeit auf 0,044 $. Der Cache-Rabatt schrumpft damit von etwa einem Hundertzwanzigstel auf ein Dreißigstel des regulären Input-Preises. Für iterative Agenten-Workflows, die permanent dieselben Code- und Kontext-Dateien einlesen, kassiert DeepSeek damit das bisherige Sparpreis-Narrativ ein. Aus europäischer Sicht ist immerhin ein Trost dabei, dass fast der gesamte Nachmittag in den günstigen Tarif fällt. Ein Detail noch, das in der Aufregung untergeht: Die Gewichte des neuen Builds hat DeepSeek bislang nicht veröffentlicht. Auf Hugging Face liegt weiterhin der Preview-Stand vom April. ## MAI-Thinking-1 Microsoft hat sein hauseigenes Reasoning-Modell MAI-Thinking-1 in die Public Preview auf Microsoft Foundry gehoben. Vorgestellt wurde es bereits Anfang Juni auf der Build 2026, seither lief es in der Private Preview – neu ist also nicht das Modell, sondern der Zugang. Technisch setzt Redmond auf eine Sparse-Mixture-of-Experts-Architektur mit rund einer Billion Gesamtparametern, von denen pro Token 35 Milliarden aktiv sind. Das Kontextfenster liegt bei 256.000 Tokens, Function Calling wird unterstützt, die Chat-Completions-API ebenfalls. Microsoft betont vor allem die Unabhängigkeit vom bisherigen Partner-Ökosystem: Das Modell wurde ohne Destillation aus Drittanbieter-Modellen trainiert und soll auf kommerziell lizenzierte, nachverfolgbare Datensätze setzen. Für Käufer in regulierten Branchen, die zunehmend nach der Herkunft von Trainingsdaten gefragt werden, ist das sicherlich das Hauptverkaufsargument. Bei den herstellereigenen Benchmarks meldet Microsoft 97,0 Prozent bei AIME 2025 sowie 94,5 Prozent bei AIME 2026 und sieht das Modell mit rund 53 Prozent bei SWE-Bench Pro auf Augenhöhe mit Claude Opus 4.6. In internen Blind-Side-by-Side-Evaluierungen über 1.276 Tasks, durchgeführt vom Rating-Partner Surge, soll MAI-Thinking-1 gegenüber _Claude Sonnet 4.6_ bevorzugt worden sein – das übliche Blabla, bei Microsoft immer noch eine Spur selbstverliebter. Bevor man das jetzt als Frontier-Ansage liest, ein Blick auf den Kalender. _Opus 4.6_ war das Vergleichsziel im Juni. Inzwischen ist Opus 5 seit dem 24. Juli draußen, und zwischen den beiden liegt noch 4.8. Wer im August mit Juni-Zahlen gegen ein zwei Generationen altes Modell antritt, hat einen Vergleich gewonnen, den niemand mehr führt. ## Gemini 3.7 Flash Google lässt nur drei Wochen nach Version 3.6 bereits Gemini 3.7 Flash raus und positioniert das Modell primär als Werkzeug für Agenten-Workflows, Coding und Dokumentenanalyse. Bei den Benchmarks legt Google die üblichen Steigerungen vor: DeepSWE v1.1 klettert von 49,0 auf 65,3 Prozent, FrontierCode 1.1 Main von 34,4 auf 43,6, das WebDev-Arena-Ranking von 1.538 auf 1.588 Elo. Auffälliger finde ich die Sprünge, wenn das Modell komplexe Dokumente verarbeitet. GDP.pdf geht von 22,0 auf 34,0 Prozent, AutomationBench von 17,0 auf 30,4. Das zielt weniger auf schlauere Antworten als auf weniger Retries und präzisere Tool-Calls. Bemerkenswert ist der Preiskampf über die API. Google halbiert die regulären Preise des Vorgängers bis zum 31. Dezember 2026 auf 0,75 $ pro Million Input-Token und 3,75 $ für die Ausgabe. Ab dem 1. Januar 2027 gelten wieder 1,50 beziehungsweise 7,50 $. Wer jetzt eine Pipeline auf diesen Konditionen kalkuliert, sollte die Januar-Zahlen daneben legen, nicht die aktuellen. Wichtiges Einordnungs-Sternchen zum Intelligence Index: Der Wert von 56 Punkten, den Google in der Ankündigung nennt, ist ein von Google zitierter AA-Score. Unabhängig bestätigt sind bislang die Geschwindigkeitsmessungen mit rund 253 bis 340 Token pro Sekunde, nicht die Einordnung im Feld. Übrigens keine Spur am Horizont von einem neuen Gemini-Pro-Modell. Google hat für Gemini 3.5 Pro auch mit dieser Ankündigung kein Datum genannt, obwohl das Modell zuvor als im Partner-Testing befindlich beschrieben wurde. Und ich habe das Ding (also 3.7 Flash) für diversen Kleinkram getestet: Zusammenfassungen, Generieren von Markdown, Transkribieren und Interpretieren von Audio und Video, bisher aber kein Coding. Die reine Ausgabe im Chat war eher unauffällig, was bei dem von Google avisierten Ziel zu erwarten war. Es gibt ein paar Änderungen bei der Textformatierung im Chat, aber die betreffen genauso 3.6 Flash, was ich nach meinem Anfangsverdacht über einen kurzen Test bestätigt bekommen habe. Auffällig fand ich die Verarbeitung von Video, in Form von Inhaltsanalyse und Transkription von Audio über einen n8n-Workflow. In diesem Fall war 3.7 auch fühlbar schneller als seine unmittelbaren Vorgänger. Antigravity nehme ich mir die Tage mal vor. ## Claude Sonnet 5 Einführungspreis bleibt Auf X bestätigt Anthropic, dass der Ende Juni eingeführte Preis von 2 $ pro Million Eingabe- und 10 $ pro Million Ausgabe-Tokens für _Sonnet 5_ bestehen bleibt. Ursprünglich war das ein Einführungspreis bis zum 31. August, danach hätte es 3 beziehungsweise 15 $ gekostet. Die Erhöhung ist gestrichen, der Preis gilt dauerhaft. Anthropic bekommt wohl aufgrund des zunehmenden Wettbewerbs Preisdruck. Wer jetzt aber die Ersparnis gegenüber _Sonnet 4.6_ ausrechnet, sollte zwei Dinge dazunehmen. Sonnet 5 bringt einen überarbeiteten Tokenizer mit, der denselben Text je nach Inhalt auf das 1,0- bis 1,35-Fache an Tokens abbildet. Dazu kommt der höhere Verbrauch durch das agentischere Arbeitsverhalten, bei maximaler Konfiguration rund 40 Prozent mehr Output-Tokens pro Aufgabe als beim Vorgänger. Artificial Analysis kommt deshalb auf 2,29 $ für eine durchschnittliche Index-Aufgabe mit Sonnet 5, während dieselbe Aufgabe mit _Opus 4.8_ bei rund 1,97 $ landet (_Opus 5_ fehlt in der Rechnung aktuell noch). Fazit dazu: Der eingefrorene Listenpreis ist eine gute Nachricht für die Budgetplanung und eine schlechte Grundlage für den Modellvergleich. Wie schon im Juni gilt: Die Rechnung schreibt der Tokenizer, nicht die Preisliste. Rechnet auf eurer eigenen Last. ## Hetzner experimental open-weight LLM inference API Habe ich erst die Tage mitbekommen, aber Hetzner betreibt seit Juli einen experimentellen Inference-API-Endpunkt mit OpenAI-kompatibler REST-API, gehostet in Deutschland und Finnland. Gestartet ist das mit genau einem Modell, inzwischen sind es vier: DeepSeek-V4-Flash-0731| MoE, 304B total / 13B active| 512.000 tokens| Text ---|---|---|--- GLM-5.2-NVFP4| MoE, 744B total / 40B active| 512.000 tokens| Text Kimi-K2.7-Code| MoE, 1T total, 32B active| 262.144 tokens| Text, Image Qwen/Qwen3.6-35B-A3B-FP8| MoE, 35B total / 3B active| 262.144 tokens| Text, Image Das reißt geschwindigkeitsmäßig keine Bäume aus, läuft bei mir aber prima für eine OpenClaw-Instanz, die darüber _Qwen3.6 35B_ bezieht. Dass sie das „experimental“ nennen, kommt nicht von irgendwoher, denn gelegentlich läuft das bei mir in einen Timeout. Wer sich fragt, warum: Hetzners öffentliches GPU-Lineup besteht aus RTX 4000 Ada und RTX PRO 6000 Blackwell, also Workstation-Karten. Damit serviert man keine Frontier-Modelle bei Volllast. Bleibt der Punkt, der für alle interessant ist, die hier gerade an europäische Datensouveränität denken. Ein Auftragsverarbeitungsvertrag existiert für den Dienst nicht. Hetzner schreibt selbst, dass es keine Backups gibt, keine Zusage zu Leistung und Verfügbarkeit, und dass man das Ding nicht für Produktivumgebungen nutzen soll. Für Prototypen, interne Tools und Coding-Agenten ist das eine feine Sache. Für Kundendaten ist es keine. Also, wenn ihr das nutzt, erwartet keine Wunder, bleibt fair und hängt einen Fallback dahinter. ## Mistral und europäische KI-Souveränität Mistral baut ein wenig an und aus. Drei Kernmaßnahmen für regionale Datenresidenz und europäische KI-Infrastruktur sind angekündigt. * Mistral Regional Endpoints (Inferenz wahlweise in Europa oder den USA) sind allgemein verfügbar, ergänzt durch ein neues Mistral Priority Tier in der Public Preview, das SLA-gesicherte Betriebszeiten und individuelle Rate-Limits für produktionskritische Workloads bietet. * Künftig werden auch externe Open-Weights-Modelle direkt in die eigene Plattform und Infrastruktur eingebunden, beginnend mit _GLM-5.2_ von Z.ai. * Mit Partnern wie ASML, Capgemini, Amadeus, CMA CGM und der Caisse des Dépôts bündelt Mistral über mehrjährige Verpflichtungen die Nachfrage nach Rechenkapazität in sogenannten European Compute Units (ECUs), um bis 2030 bis zu 1 Gigawatt europäische Rechenzentrumskapazität für souveräne Inferenz- und Trainings-Workloads aufzubauen. Man mag das vielleicht als Zeichen von Resignation deuten, dass Mistral fremde Modelle über eigene Infrastruktur anbietet. Ich sehe das eher als breitere strategische Aufstellung. Schließlich kann ich über Google Cloud Platform auch Claude-Modelle beziehen, wenn ich das denn möchte. Ein Detail für alle, die den Begriff Datenresidenz ernst nehmen müssen: Mistral schreibt selbst, dass begrenzte und abgesicherte Übermittlungen an Sub-Prozessoren außerhalb der gewählten Region stattfinden können. „In-Region“ heißt hier also nicht ausnahmslos in der Region, und wer das seinem Datenschutzbeauftragten erklären muss, sollte das Trust Center gelesen haben, bevor er den Vertrag unterschreibt. ## ALTK-Evolve: Agenten-Gedächtnis ohne Token-Verbrennung IBM Research nimmt sich mit ALTK-Evolve des typischen Memory-Problems bei ReAct-Code-Agenten an. Statt an fehlendem Domänenwissen scheitern die Dinger bei komplexen Multi-Step-Workflows meist an banalen Ausführungsfehlern, an falsch paginierten APIs oder unpassenden Rückgabewerten. Frameworks wie ACE lassen den Agenten zwar aus bisherigen Durchläufen lernen, stopfen die gesammelten Erkenntnisse dann aber oft unreflektiert und teuer ins Context Window. IBMs Ansatz wählt denselben Grundgedanken, Erkenntnisse zu zählen und zu gewichten statt sie plump zusammenzufassen, optimiert jedoch die Retrieval- und Delivery-Pipeline, um den Token-Ballast zu drücken. Im hauseigenen Testlauf auf dem AppWorld-Benchmark mit 168 Tasks gegen Basismodelle wie _DeepSeek-V3.2_ und gpt-oss-120b will IBM die gleiche Aufgaben- und Szenario-Erfolgsquote wie ACE erzielen, nur eben mit spürbar reduzierter Token-Rechnung. Wie üblich stammen die Vergleichszahlen aus internen Re-Runs. Spannend bleibt der Ansatz für alle, die agentische Workflows bauen und keine Lust haben, ihr API-Budget für redundanten Context zu verbrennen. Die Pipeline aus Extraktion, Konsolidierung und gezieltem Abruf steht als Library und Technical Report auf Hugging Face bereit. Der Titel des Blogposts fasst die Woche übrigens hervorragend zusammen: > „Thinking of ACE? We Can Do It with Fewer Tokens." ## Message your other Claude Code sessions Ab Claude Code v2.1.224 unterstützt Claude Code sitzungsübergreifendes Messaging, vorerst nur unter macOS und Linux. Über die Tools `ListAgents` und `SendMessage` findet Claude andere Sitzungen und schickt ihnen Nachrichten, auf derselben Maschine ebenso wie auf anderen Rechnern oder im Web. Übertragen wird dabei ausschließlich Text, nie Conversation History und nie Dateien. Wer einen ganzen Kontext verschieben will, muss weiterhin die Session fortsetzen. Interessanter finde ich, dass Claude von sich aus senden darf, etwa nachdem eine Änderung in Sitzung kaputt macht, woran Sitzung B gerade baut. ## Maximizing the value of your Claude Code sessions Anthropic erklärt in einer Anleitung von Lydia Hallie, was eine Claude-Code-Session eigentlich kostet – und das ist mehr Substanz, als der Titel vermuten lässt. Die Mechanik dahinter: Output-Tokens kosten etwa das Fünffache von Input-Tokens, weil das Modell sie einzeln nacheinander erzeugt. Cache-Reads liegen bei einem Zehntel des Input-Preises, Cache-Writes bei bis zum Doppelten. Jeder Turn schickt die komplette bisherige Konversation erneut mit, nur das Neue wird zum vollen Preis vorverarbeitet. Was einmal im Kontext liegt, bleibt dort und wird bei jedem weiteren Turn mitgeschleppt. Daraus folgen ein paar Handgriffe, die man gern vergisst: * `/clear` zwischen einzelnen Aufgaben, damit alter Kontext nicht mitreist * Modell und Effort-Level vor dem Start festlegen, denn ein Wechsel mitten im Gespräch wirft den Prompt-Cache weg * Dateien mit `@` erwähnen statt den Pfad zu tippen – die Datei hängt dann direkt an der Nachricht, der Read-Call entfällt * Laute Befehle mit Quiet-Flags versehen oder in einen Subagenten auslagern, weil Kommando-Ausgaben genau wie Dateien im Kontext liegen bleiben * `/context` einmal in einer frischen Session laufen lassen, um zu sehen, was überhaupt geladen ist * `/compact` vor der Pause, nicht danach – der Cache läuft nach einer Stunde ab, und das Zusammenfassen ist deutlich günstiger, solange er noch steht Der Kniff, den ich mir merke: Wenn die letzten Turns in die falsche Richtung gelaufen sind, ist `/rewind` billiger als `/compact`. Rewind schneidet nur hinten ab, alles davor bleibt im Cache. Compact schreibt die ganze Konversation neu und kostet deshalb immer etwas. ## ChatGPT – Import from another agent _ChatGPT-App_ und _Codex CLI_ haben eine Importfunktion bekommen. Wer von einem anderen Agenten kommt, muss seine Konfiguration nicht neu aufbauen. Wichtig ist der Unterschied zwischen den beiden Wegen: Die Desktop-App importiert aus Claude Code, Claude Cowork und Cursor, das _Codex CLI_ per `/import` dagegen nur aus Claude Code oder Cursor. Das CLI zieht zudem maximal 50 Chats aus den letzten 30 Tagen, und der Befehl funktioniert weder während einer laufenden Task noch in einer Remote-Session. Übernommen wird mehr, als ich erwartet hätte: Instruction-Dateien landen in `AGENTS.md`, die `settings.json` wird zur `config.toml`, dazu kommen Skills, Plugins, Projektordner, MCP-Server-Konfiguration, Hooks, Subagenten und die Projekt-Memories aus Claude Code. Slash Commands werden zu Skills umgebaut. Der bestehende Aufbau im Quell-Agenten bleibt unangetastet, und die Desktop-App kann Importiertes auf Wunsch synchron halten. Bei einem Anbieterwechsel oder allein auch nur, um eine Konfiguration in _Codex_ zu bekommen, etwa für eine zweite Meinung, spart das viel Zeit. Ein Punkt, den OpenAI selbst hervorhebt und den man ernst nehmen sollte: Nach dem Import gehören Tool-Berechtigungen in Skills und Agenten geprüft, ebenso MCP-Server mit eigener Authentifizierung, Headern oder Umgebungsvariablen. Hooks können sich nach der Übernahme anders verhalten. Man importiert eben nicht nur Komfort, sondern auch Rechte. ## ChatGPT desktop app for Linux Die ChatGPT-Desktop-App für Linux ist im Preview-Status und läuft auf den Desktop-Varianten von Ubuntu 24.04 LTS und 26.04 LTS, Debian 13 sowie Fedora 43 und 44. Für jede dieser Distributionen gibt es Pakete für x64 und ARM64, `.deb` für Ubuntu und Debian, `.rpm` für Fedora. Neben dem Chat bringt das wie bei den anderen Versionen auch _Work_ und _Codex_ mit. ## Make it readable Ben Tossell teilt einen hübschen kleinen Prompting-Kniff zur Reduzierung von LLM-Textballast. Um prägnante, gut lesbare Antworten ohne ausschweifende Analogien zu erhalten, empfiehlt er die Kombination der Custom Instructions „Always talk in ASD-STE100 Simplified Technical English“, einem internationalen Standard für technische Dokumentationen, und „Always talk to me like I have ADHD“, was kurze Bulletpoints und klare Header erzwingt. Für STE gibt es kein standardisiertes deutschsprachiges Äquivalent. Alternativ könnte man den Prompt noch anweisen, das Ergebnis auf Deutsch auszugeben, und dann den Part mit ADHS dahinter hängen. ## Zonen, BIND-Files und DNSSEC: Bunny DNS wandert ins Terminal Nur so halb themenrelevant, aber es ist eine europäische Bude und das Thema Datensouveränität bewegt uns ja auch. Der Beitrag ist auch schon ein paar Wochen alt, ich bin erst jetzt drauf gestoßen, nachdem ich den Newsletter gelesen hatte: Bunny.net hat im Juli DNS in seine CLI geholt, nach Database und Edge Scripting der dritte Plattformteil, der im Terminal landet. Der Funktionsumfang geht über die üblichen CRUD-Operationen hinaus. Zonen und Records lassen sich anlegen, `records export` und `import` schreiben und lesen Standard-BIND-Zonefiles für Migration und Backup, und DNSSEC schaltet ein einzelner Befehl frei, der direkt den DS-Record für den Registrar ausgibt. Interessanter ist Scriptable DNS: Damit beantwortet eigener Code die Anfrage zur Query-Zeit, für Geo-Routing, gewichtete Antworten oder Failover. Dafür gibt es einen eigenen `SCRIPT`-Record-Typ und ambiente TypeScript-Typen. Was mich beim Lesen aufhorchen ließ, ist die Begründung. Bunny schreibt sinngemäß, ein dünner API-Wrapper reiche heute nicht mehr, weil im Terminal längst auch Agenten handeln. Entsprechend liefern sie Skill-Files mit, jeder Befehl kennt `--output json`, Prompts erkennen, ob eine TTY dranhängt, und destruktive Operationen verweigern in Pipelines den Dienst, solange kein `--force` gesetzt ist. Genau so sollte CLI-Design 2026 aussehen. Nicht der Mensch bekommt ein hübsches Interface und der Agent muss die Ausgabe parsen, sondern beide bekommen dasselbe Werkzeug mit zwei Modi. Dass DNS-Hosting bei bis zu 500 Domains ohne Query-Limit kostenlos ist, macht das Ausprobieren zusätzlich schmerzfrei. Nächste Woche dann vielleicht wieder mehr Pipeline und mehr Blech, schauen wir mal.

t01.li

Fünf Prompt-Vorlagen für die Aufgaben, die im Arbeitsalltag ständig anfallen: Extraktion, Klassifikation, Analyse, Recherche und Texte. Zum Kopieren, Anpassen und Weitergeben ans Team – plus die zwei Querschnittsregeln, die jede Vorlage besser machen.

Prompt-Vorlagen zum Kopieren: fünf Bausteine für dein Team

Teil 1 hat die Basis-Struktur geliefert, Teil 2 die Modelltyp-Frage geklärt. Jetzt kommt der Teil, den du am ehesten intern weiterreichst: fünf Prompt-Vorlagen für die Aufgaben, die in jedem Unternehmen ständig anfallen. Kopieren, Platzhalter füllen, loslegen – und bei Bedarf ans eigene Team anpassen. Vorlagen sind kein Widerspruch zur Framework-Kritik aus Teil 1. Der Unterschied liegt im Customizing. Ein Akronym verspricht, für alles zu passen; eine Vorlage ist ehrlich auf eine Aufgabenklasse gebaut und darf bei anderen scheitern. ## TL;DR Fünf Kopiervorlagen für den Arbeitsalltag mit LLMs – jede auf eine Aufgabenklasse zugeschnitten statt auf alles gleichzeitig. * Extraktion, Klassifikation, Analyse, Recherche und Schreibaufgaben – je eine Vorlage zum Anpassen * Zwei Querschnittsregeln machen jede davon besser: Instruktionen von Daten trennen, Unsicherheit explizit regeln * Markdown strukturiert die Anweisung, XML-Tags kapseln die Daten – mehr Syntax-Regelwerk braucht kein Prompt * Vorlagen gehören ins Team-Wiki und unter Versionskontrolle, nicht in verstreute Chat-Verläufe ## Zwei Regeln, bevor du kopierst **Instruktionen von Daten trennen.** Der häufigste stille Fehler im Alltag ist der Prompt, in dem Auftrag, Regeln und eingefügter Text ineinanderfließen. Das Modell soll dann raten, wo deine Anweisung endet und das zu verarbeitende Material beginnt. Jede Vorlage hier hat deshalb einen klar abgetrennten Eingabe-Block – bei langen Dokumenten hilft zusätzlich eine simple Markierung wie `<dokument>…</dokument>` um den Inhalt. **Unsicherheit explizit regeln.** Aus Teil 1 bekannt und hier in jeder Vorlage eingebaut: Das Modell bekommt gesagt, was bei Lücken passieren soll. Fehlendes kennzeichnen, Fakten von Schlussfolgerungen trennen, im Zweifel „keine belastbare Aussage möglich“ schreiben. Diese drei Zeilen verhindern mehr Konfabulationen als jedes Verbot (zu einhundert Prozent verhindern, lassen sie sich aber nicht). ## Markdown für die Anweisung, XML für die Daten Dir ist vielleicht aufgefallen, dass alle fünf Vorlagen mit Markdown-Überschriften arbeiten. Das ist kein Zufall und keine Deko. Markdown ist für Menschen lesbar, lässt sich im Team-Wiki pflegen, und jedes aktuelle LLM versteht `##`-Abschnitte als das, was sie sind – Gliederung. Für manuell gepflegte Vorlagen ist Markdown meist die pragmatischste Lösung. XML-Tags sind das zweite Werkzeug, und sie lösen ein anderes Problem. Sobald Daten in den Prompt wandern – ein Vertrag, drei Quellen, ein Support-Verlauf – braucht das Modell eine eindeutige Grenze zwischen deiner Anweisung und dem Material. Anthropic empfiehlt Tags dafür ausdrücklich, OpenAI und Google verstehen sie genauso. Wichtig zu wissen: Das muss kein valides XML sein. Die Tags sind Markierungen, keine Schemata – sie brauchen weder Namespace noch Doctype, nur konsistente Namen und ein sauberes Öffnen und Schließen. So sieht das kombiniert aus, hier als Ausschnitt aus einem Quellenvergleich: ## Aufgabe Vergleiche die beiden Quellen und benenne Widersprüche. ## Quellen <quelle name="Kanzlei-Newsletter" datum="2026-06"> [Text der ersten Quelle] </quelle> <quelle name="Verbandsartikel" datum="2026-07"> [Text der zweiten Quelle] </quelle> Die Faustregel für den Alltag: Markdown strukturiert, was das Modell tun soll, XML kapselt, womit es arbeiten soll. Mehr Regelwerk braucht es nicht – wer anfängt, jede einzelne Anweisung in eigene Tags zu verpacken, baut sich nur das nächste Framework. ## Vorlage 1: Extraktion Der Klassiker für Non-Reasoning-Modelle – Rechnungen, Mails, Formulare, Verträge. Das Format ist hart definiert, Lücken werden zu `null` statt zu Erfindungen. ## Aufgabe Extrahiere die angegebenen Informationen aus dem Eingabetext. ## Gesuchte Felder - Name - Organisation - Datum - Betrag - Handlungsbedarf ## Regeln - Verwende nur Informationen aus dem Eingabetext - Ergänze keine fehlenden Angaben - Verwende null, wenn ein Wert nicht vorhanden ist - Normalisiere Datumsangaben ins Format YYYY-MM-DD - Beträge als Dezimalzahl ohne Währungssymbol ## Ausgabeformat JSON mit exakt den oben genannten Feldern ohne Markdown-Codeblock ## Eingabetext {{TEXT}} Läuft die Extraktion über eine API, gehört das JSON Schema als eigener Parameter in den Request – der Prompt wünscht sich das Format, das Schema erzwingt es per Structured Outputs (die Details dazu stehen in Teil 2). ## Vorlage 2: Klassifikation Hier zahlt sich Few-Shot am deutlichsten aus. Die Beispiele folgen der Regel aus Teil 2 – ein typischer Fall, ein schwieriger, ein Grenzfall. ## Aufgabe Ordne den Eingabetext genau einer Kategorie zu. ## Kategorien - Rechnung - technischer Fehler - Kündigung - Produktfrage - Sonstiges ## Entscheidungsregeln - Bei mehreren Themen wähle das dringlichste Anliegen - Sonstiges nur, wenn keine andere Kategorie eindeutig passt - Gib ausschließlich den Kategorienamen aus, keine Erklärung ## Beispiele Eingabe: „Meine Rechnung enthält eine unbekannte Position.“ Ausgabe: Rechnung Eingabe: „Ich möchte kündigen, weil meine Rechnung erneut falsch ist.“ Ausgabe: Kündigung Eingabe: „Welche Zahlungsarten unterstützt das Produkt?“ Ausgabe: Produktfrage ## Eingabe {{TEXT}} Das zweite Beispiel ist absichtlich mehrdeutig. Genau solche Fälle entscheiden, ob die Klassifikation im Alltag hält oder bei der ersten wütenden Kundenmail kippt. ## Vorlage 3: Analyse und Entscheidung Die Reasoning-Disziplin. Gewichtete Kriterien, gebundene Evidenz, Prüfauftrag – das Modell bekommt das Problem, nicht den Lösungsweg. ## Ziel [Entscheidung oder Problem, z. B.: Bewerte, ob Produkt A oder B für ein Unternehmen mit 50 Mitarbeitenden geeigneter ist] ## Ausgangsdaten Verwende ausschließlich die beigefügten Informationen. ## Bewertungskriterien - Datenschutz: 40 % - Funktionsumfang: 30 % - Integrationsaufwand: 20 % - Preis: 10 % ## Einschränkungen - Erfinde keine Produktmerkmale - Kennzeichne fehlende oder nicht vergleichbare Informationen - Trenne belegte Tatsachen von Annahmen - Benenne widersprüchliche Daten offen ## Ergebnis 1. Empfehlung 2. gewichtete Bewertung 3. tragende Gründe 4. Risiken 5. offene Fragen ## Kontrolle Prüfe abschließend, ob die Empfehlung mit den Gewichtungen und Ausgangsdaten übereinstimmt. Die Gewichtungen sind der Hebel, den fast niemand nutzt. Sie zwingen vor dem Prompten zu einer Entscheidung darüber, was wirklich zählt – und machen das Ergebnis hinterher überprüfbar. ## Vorlage 4: Recherche Für alles, was mit Websuche oder Quellenarbeit zu tun hat. Der Quellenstandard ist das Herzstück, inklusive der Regel, Herstellerangaben als solche zu kennzeichnen – regelmäßige Leser dieses Blogs haben möglicherweise gerade eine sanfte Eingebung, warum mir diese wichtig ist. ## Forschungsfrage [Präzise Frage] ## Geltungsbereich - Zeitraum: - Region: - ausgeschlossene Themen: ## Quellenstandard - Primärquellen bevorzugen - Veröffentlichungsdatum und Ereignisdatum unterscheiden - Zentrale Behauptungen mit Quellen belegen - Widersprüche zwischen Quellen benennen, nicht glätten - Herstellerangaben getrennt von unabhängigen Messungen kennzeichnen ## Ausgabe - Kurzfazit - zentrale Befunde mit Quellenangabe - Gegenargumente - offene Punkte Das ist gelebtes Grounding: Die Antwort wird an überprüfbare Quellen gebunden, statt aus dem Modellgedächtnis zu schöpfen. ## Vorlage 5: Schreibaufgaben Kleine Pointe zum Serienende – für Schreib- und Kommunikationsaufgaben lebt der CO-STAR-Gedanke weiter, nur ergänzt um das, was ihm immer gefehlt hat: Evidenz und Ausschlüsse. ## Ziel [Was soll der Text bewirken?] ## Zielgruppe [Für wen ist der Text bestimmt?] ## Kernaussage [Die eine zentrale Aussage] ## Evidenz - [Beispiel, Datenpunkt oder Argument] - [Beispiel, Datenpunkt oder Argument] ## Ton und Stil [z. B. sachlich, direkt, nicht werblich] ## Ausschlüsse - [Formulierungen oder Muster, die nicht vorkommen sollen] - [Inhalte, die tabu sind] ## Ausgabe [Länge, Format und Sprache] Der Ausschluss-Block ist der unterschätzte Teil. Wer dort einmal die eigenen Marketing-Unwörter einträgt, spart sich das Rausredigieren in jedem einzelnen Entwurf. ## Und jetzt ins Team damit Vorlagen entfalten ihren Wert erst, wenn sie nicht in einzelnen Chat-Verläufen versickern. Der pragmatische Weg führt über drei Stufen. Ins Team-Wiki legen (bzw. Slack, Confluence, Teams, oder was auch immer), damit alle dieselbe Ausgangsbasis haben. Anpassungen erlauben und Änderungen sammeln – die Grenzfälle aus dem echten Betrieb machen jede Vorlage besser als jeden Erstentwurf. Und sobald eine Vorlage in einem produktiven Workflow landet, gehört sie unter Versionskontrolle wie jeder andere Code auch. Wenn ich mir das Fazit noch herausnehmen darf: Gutes Prompting ist 2026 keine Geheimwissenschaft mehr, sondern saubere Auftragsklärung – Ziel, Material, Grenzen, Format, Prüfung. Die fünf Vorlagen hier sind nichts anderes als diese Klärung, einmal pro Aufgabenklasse durchdekliniert. Wer sie ans Team verteilt, verteilt keine Zauberformeln, sondern eine Arbeitsweise. Und das war von Anfang an der Punkt dieser ganzen Serie.

t01.li

Qwen3.8-Max mit 2,4 Billionen Parametern, Metas Muse Code, marodierende Modelle als neues Statussymbol der Labs, drei Cloudflare-Releases, ein Rust-Parser von Firecrawl und eine Preiswarnung von DeepSeek – die AI Picks der 32. Kalenderwoche.

AI Picks der 32. KW

Das Thema marodierende KI-Modelle lässt uns nicht los und die Geschichte wird immer unterhaltsamer. Irgendwie droht es auch zu einem Statussymbol unter den Labs zu verkommen: „Hier, unser Top-Notch-Modell hat gestern leider mal Firma XY gehackt, sorry – kommt auch nicht wieder vor, versprochen.“ Welchem potenziellen Kundenkreis man sich damit so an den Hals wirft, kann sich wohl jeder ausmalen. Ansonsten eher Specs und Software diese Woche, weniger Blech. Auf in die Picks der 32. Kalenderwoche des Jahres 2026: ## Qwen3.8-Max Das wird gerade auf X.com wie bestes Gras einmal quer durch die Community gereicht: Bei Alibaba ist mit Qwen3.8-Max das bisher größte Modell des Unternehmens hinten rausgefallen. 2,4 Billionen Parameter klingen auf dem Papier nach dem nächsten dicken Ding, entpuppen sich architektonisch aber als Mixture-of-Experts-System (MoE). Pro Token sind nur rund 95 Milliarden Parameter aktiv, was die Inferenzkosten im Rahmen halten soll. Neben dem üblichen Kontextfenster von 1 Million Tokens setzt Alibaba laut eigener Ankündigung vor allem auf die Ausrichtung als autonomer Agent. In den internen Demos durfte das Modell unter anderem über 16 Tage hinweg eigenständig an einem CLI-Projekt schrauben – Hersteller-Demo, versteht sich, unabhängig nachgestellt hat das noch niemand. Zwei Details machen den Release trotzdem bemerkenswert. Die API spricht neben dem OpenAI-Format auch das Anthropic-Protokoll, das Modell lässt sich also per Base-URL-Wechsel in _Claude Code_ , _Codex_ oder _OpenClaw_ einhängen. Und: Die Gewichte sollen kommende Woche offen veröffentlicht werden, als erstes Max-Modell überhaupt – zusammen mit einem 27B-Checkpoint für Hardware, die nicht gleich ein ganzes Rechenzentrum belegt. Bei den Benchmarks hat mittlerweile Artificial Analysis nachgemessen. ## Sakana Namazu Vermutlich und wahrscheinlich werdet ihr dieses Ding nie benötigen (außer ihr fahrt einen nicht unerheblichen Anteil eures Umsatzes im japanischen Markt und mit lokalen Partnern vor Ort), aber den Kontext finde ich ganz unterhaltsam, deshalb landet die Meldung hier: Sakana Namazu ist ein auf den japanischen Geschäftskontext spezialisiertes LLM, das auf dem Open-Weights-Modell _Kimi K2.6_ basiert und mit firmeneigenen Daten für lokale Arbeitsabläufe feinabgestimmt wurde. Das Modell integriert laut Ankündigung standardmäßig Web-Suche sowie Code-Ausführung direkt in den API-Workflow und nutzt einen OpenAI-kompatiblen API-Endpunkt mit dem Modellnamen `sakana-namazu`. Also das Ding mal eben in eine fast beliebige Harness reinstricken sollte entspannt sein. Preise sind rein verbrauchsabhängig ohne monatliche Grundgebühr: Input 0,95 $ pro Million Token, cached Inputs kosten 0,15 $ und Output liegt bei 4,00 $ pro Million Token. Hinzu kommen tool-spezifische Kosten von 7,00 $ je 1.000 Web-Suche-Aufrufen (inklusive Seiteninhalten) sowie 0,12 $ pro Stunde für persistente Session-Code-Ausführungen. Gegenüber dem Basismodell _Kimi K2.6_ behält Namazu laut Sakanas eigener Benchmark-Grafik die Leistungen bei AIME26 oder MMLU-Pro bei – eine Drittmessung existiert nicht. Ein Haken für alle, die jetzt neugierig geworden sind: In der EU, in Großbritannien und der Schweiz ist Namazu offiziell nicht verfügbar. Die DSGVO-Compliance ist laut Sakana in Arbeit, bis dahin bleibt der Endpunkt für uns zu. Wenn ihr schon immer mal einen extrem höflichen Chat-Bot wolltet: Bald ist die Chance da. ## Muse Code und Muse Spark 1.2 Meta so: Terminal Coding Agent bzw. Agent Harness – können wir auch. Also haben sie Muse Code veröffentlicht (aktuell noch Beta). Und womit läuft das so? Der Quickstart klärt auf: > Muse Code is a fast and accessible coding agent powered by Muse Spark. _Muse Spark_ haben sie dazu gleich auf Version 1.2 aktualisiert und Artificial Analysis hat auch direkt drüber geguckt. Interessant auch die Tier-Modelle: Neben dem Standard-Tarif gibt es einen „Contributor“-Tarif für ein Zehntel des Preises – im Tausch trainiert Meta dann auf euren Prompts und Completions. Datenhunger als Rabattmodell, das passt zu Meta wie der Blaumann zum Handwerker. _Muse Spark 1.2_ ist direkt ab Start in Europa nutzbar und man darf bei Meta seine Kreditkarte hinterlegen. Das habe ich auch mal getan, da ich ja eine Schwäche für CLIs habe und mir Muse Code zumindest mal ansehen wollte. Sagen wir mal so: Falls ihr mit _Claude Code_ arbeitet, wird euch _Muse Code_ nicht groß überraschen, was Commands, Struktur etc. angeht. Muse Code CLI Ein paar weitere Auffälligkeiten: * Es gibt noch keinen direkten Befehl für MCP. Wenn ich Muse danach frage, bietet es mir an, einen MCP samt Konfiguration anzulegen (getestet mit Chrome Dev Tools). Das ist aktuell eher unpraktisch, da alles extern via Packages installiert werden will und die Sandbox den direkten Aufruf blockiert. Aber: Die Sandbox funktioniert immerhin. * YOLO Mode ist da, habe ich aufgrund des Beta-Status aber mal sein lassen. * Plan Mode ebenfalls vorhanden und tut anscheinend, was er soll. * Generell habe ich dafür plus einen kleinen Frontend-Test (statische HTML-Seite mit Tailwind-4-Integration samt Lite- und Dark-Mode) insgesamt 1,77 Euro für Spark 1.2 mit Medium Effort rausgeballert. * _Muse Spark_ hat noch weniger Persönlichkeit als ein durchschnittlicher Sparkassen-Geldautomat (das kann man gut oder schlecht finden). Ich sage es mal so: Wenn man _Codex_ oder Claude Code CLI gewohnt ist, wirkt das aktuell eher wie ein Rückschritt – eben weil Dinge (noch) fehlen. Das ließe sich jedoch durch den Beta-Status begründen. Also abwarten, was da noch kommt. ## OpenAI-Modelle brechen bei Cyber-Evaluierungen aus Testumgebungen aus Es kann mir niemand erzählen, dass OpenAI das nicht gern als kostenlose PR mitnimmt, und darauf wartet, dass die Nachrichtendienste bei ihnen mal wieder durchrufen. Bei Sicherheitsprüfungen durch externe Partner wie dem britischen AI Security Institute (UK AISI) und der Sicherheitsfirma Irregular sind OpenAI-Modelle über die vorgegebenen Grenzen der Testumgebungen hinaus im öffentlichen Internet aktiv geworden. Die Vorfälle passierten unter gezielt abgeschwächten Sicherheitskonfigurationen (z. B. deaktivierten Cyber-Klassifikatoren) und teilweise durch Fehlkonfigurationen in den Testumgebungen. Im Fall des UK AISI nutzte das Modell GPT-5.6 Sol unter anderem ein GitHub-Token, das der Agent eines anderen Labs öffentlich hatte liegen lassen (die Details werden immer besser), umging Account-Recovery- und Rate-Limits und machte einen lokalen DNS-Server über einen Tunneldienst im Internet erreichbar. Bei Irregular führte eine versehentlich bestehende Internetverbindung dazu, dass ein Modell eine reale Website mit einer fiktiven Zieladresse verwechselte und eine dortige Sicherheitslücke ausnutzte. Genau: „versehentlich“ und „Fehlkonfigurationen in den Testumgebungen“ – man fragt sich, was die Leute da so beruflich machen. Als „frontier security lab“ (steht bei denen so auf der About-Seite) ist „versehentlich“ ein ganz schwieriges Verkaufsargument. Und lustigerweise springt jetzt Meta auch mit auf den Zug auf – ausgerechnet mit _Muse Spark_ , siehe oben. Achso, und na klar: > … the most serious case arising when Anthropic's Mythos 5 model attempted to insert malicious code into an open source software application and created fake identities to deceive the human developers maintaining the project. Die Randnotiz macht es rund: Von den 19 Vorfällen, die das UK AISI in seiner Testreihe zählte, gingen 2 auf _GPT-5.6 Sol_ und 17 auf Anthropics _Mythos 5 zurück_. Da zeichnet sich ein Trend am Horizont ab. Aber irgendwie höre ich von den brandgefährlichen Open-Weights-LLMs aus China nichts dergleichen. ## Introducing Shieldstral Shieldstral ist ein multimodales Open-Weights-Modell (Apache 2.0) zur Inhaltsmoderation von Mistral (das erklärt auch den Namen). 3 Milliarden Parameter klein und darauf ausgelegt, Moderationsregeln dynamisch zur Inferenzzeit auszuwerten. Statt fester Trainingskategorien wie bei klassischen Guardrail-Modellen prüft Shieldstral Texte, Bilder oder Multimodal-Inputs anhand von in natürlicher Sprache formulierten Ja/Nein-Fragen und Kontextanweisungen. Als Ausgabe liefert die API einen kontinuierlichen Sicherheitswert über ein einzelnes Token. Und bei der Größe (eine einzelne 16-GB-GPU reicht) läuft das Ding quasi auf dem Bürotoaster. Die Gewichte liegen auf Hugging Face. Ich habe dafür derzeit keinen Anwendungsfall, aber kennen ist besser als suchen, oder so. ## @cloudflare/computer Cloudflare (der Name fällt heute noch häufiger) hat mit @cloudflare/computer eine Open-Source-Bibliothek für Agent-Runtimes als Early Preview vorgestellt. Statt jeden Agent starr in einen eigenen Container zu sperren – was bei skalierten Setups schnell an Grenzen bei der Rechenkapazität stößt –, setzt das Paket auf eine hybride Architektur aus V8-Isolates und Container-Sandboxes. Der Agent-Harness läuft dabei als Durable Object im Isolate. Ein SQLite-basiertes virtuelles Dateisystem bildet den gemeinsamen Workspace, der Container bindet es per FUSE-Mount ein und synchronisiert Änderungen zurück. Das soll dem Modell erlauben, einfache Dateimanipulationen flott und kostengünstig im Isolate abzuwickeln und einen schwereren Linux-Container nur dann zuzuschalten, wenn beispielsweise native Binärdateien oder Paketmanager benötigt werden. ## Cloudflare OS Cloudflare hat seinen internen KI-Agenten-Workspace als Open Source unter Apache 2.0 veröffentlicht – nach eigener Aussage seit Mai firmenweit im Einsatz. Das Ganze dient als isolierte Umgebung zur Erstellung und Ausführung von KI-Agenten und kleinen internen Apps, die sich mit eigenen Access Controls teilen lassen. Sie nehmen dabei auch gerne den aktuellen Hype mit, alles „AI OS“ zu nennen, was nicht bei drei auf dem Baum ist. ## Cloudflare Wallets Diese Entwicklung war dermaßen absehbar, aber anders, als man erst vielleicht denkt: Cloudflare baut mit _Cloudflare Wallets_ eine programmierbare Geldbörse für Agenten: Stablecoin-Zahlungen über das x402-Protokoll, das Micropayments direkt an HTTP-Requests hängt. Die Idee dahinter ist simpel – Agenten scheitern heute an Signup-Formularen, Zahlungsmethoden und API-Key-Gefrickel, das für Menschen gebaut wurde, und kicken die Aufgabe dann zurück an den Nutzer. Künftig soll der Agent eine API einfach ausprobieren und die paar Cent dafür selbst bezahlen. Das Konstrukt besteht aus zwei Ebenen. Das Account Wallet gehört dem Menschen, der Geld einzahlt und Regeln setzt. Darunter hängen Virtual Wallets für die Agenten, mit Guardrails wie Budget-Limits, Allow-Lists und maximaler Transaktionsgröße – der Agent darf also mit 10 Dollar Spielgeld Dutzende APIs testen, ohne dass jemand aus der Buchhaltung nachts schweißgebadet aufwacht. Obendrauf kommt eine Identitätsschicht: Über cloudflare.pay-Handles können sich Agenten optional als Delegierte eines Accounts ausweisen, damit Seller wissen, wessen Bot da gerade einkauft. Zusammen mit dem kürzlich vorgestellten Monetization Gateway ergibt das die Verkäufer- und die Käuferseite eines Marktplatzes, auf dem Maschinen mit Maschinen handeln. ## anydoc Firecrawl liefert mit anydoc eine Open-Source-Bibliothek (MIT), die 14 Dokumentenformate – von Word über PowerPoint und Excel bis zu RTF, EPUB und PDF – in sauberes, GitHub-Flavored Markdown konvertiert. Der Clou steckt in dem, was fehlt: kein VLM, kein OCR-Modell, keine Cloud-API. Das Ganze ist pures Rust, parst jedes Format in ein gemeinsames Dokumentenmodell und rendert daraus einheitliches Markdown – mit einer medianen Konvertierungszeit unter 5 ms pro Dokument. Das Format wird dabei aus den Datei-Bytes erkannt, nicht aus der Endung, falsch benannte Dateien laufen also trotzdem durch. Bindings gibt es für Node.js, Python und den Browser (WASM), dazu ein fertiges Agent Skill für Claude Code und Co. Die Grenze ist klar gezogen: Bei PDFs wird nur der Text-Layer verarbeitet. Gescannte Dokumente brauchen OCR, und das gibt es ausschließlich über Firecrawls gehostete Parse-API obendrauf – da schließt sich dann der kommerzielle Kreis. Das Konzept ist im RAG-Umfeld keineswegs revolutionär, bündelt aber die typischerweise zusammengefrickelte Dokumenten-Pipeline in ein einzelnes Tool, das lokal läuft und keine API-Keys sehen will. * Eingabeformate: DOC, DOCX, PPT, PPTX, XLS, XLSX, ODT, ODS, ODP, RTF, EPUB, CSV, PDF (Text-Layer) * Ausgabe: Clean Markdown ## Agent Plugins Vercel als primärer Initiator nebst Amazon, Cursor, GitHub, OpenAI und Microsoft haben eine offene Spezifikation vorgelegt, die das Verpacken von Agent-Erweiterungen standardisieren soll. Ein Agent Plugin ist dabei schlicht ein Verzeichnis mit einer `plugin.json` als Manifest, optional einem `skills/`-Ordner für Agent Skills und einer `mcp.json` für MCP-Server-Konfigurationen. Wer heute ein Skill samt zugehörigem MCP-Server für mehrere Clients ausliefert, baut das Paket derzeit für jeden Client neu – genau dieses Glue-Format-Gefrickel soll die Spezifikation ersetzen. Zum Start unterstützen unter anderem ChatGPT, Codex, Cursor, GitHub Copilot und VS Code das Format. Die Spezifikation ist bewusst schmal gehalten: v1.0.0 definiert Paketstruktur und Discovery innerhalb des Verzeichnisses, aber kein Berechtigungsmodell, kein Sandboxing und keine Signaturprüfung – das steht alles offen in den Future Considerations. Auffällig ist, wer in der Liste fehlt: Anthropic. Claude Code fährt weiterhin sein eigenes Plugin-Format. Ob sich hier ein breiter Industriestandard etabliert oder am Ende zwei Lager nebeneinander existieren, entscheidet die Adaption – die technische Basis ist zumindest pragmatisch und ohne unnötigen Ballast aufgesetzt. ## Pricing for DeepSeek API Kam am 6. August per Mail, mittlerweile steht die Notice auch offiziell in der Pricing-Doku: > Dear DeepSeek API user, > We plan to raise the overall pricing for DeepSeek API services in the near future, with a significant increase expected. Please plan your usage accordingly. The specific pricing plan will be subject to official notice. Please keep an eye on the Open Platform announcements and check your email for further details. > If you continue to use our services after the billing adjustment, you will be deemed to have accepted the adjusted billing terms. If you do not agree, you may choose to cancel your service and apply for a refund. Should you have any questions or require further information, please do not hesitate to contact us. > Thank you for your support and understanding! Dann hat sich das leider auch erledigt und ich muss mir etwas anderes für meinen kleinen _OpenClaw_ suchen. Fin. Das war's für diese Woche.

t01.li

Reasoning-Modelle wollen anders angesprochen werden als klassische LLMs – wer beide gleich promptet, verschenkt Qualität oder Geld. Wann welcher Modelltyp die richtige Wahl ist, was ihm hilft, was ihm schadet und welche Few-Shot-Regeln 2026 gelten.

Reasoning oder nicht: Prompts nach Modelltyp

In Teil 1 ging es darum, warum Akronym-Frameworks ausgedient haben und welche Basis-Struktur sie ersetzt. Die funktioniert modellübergreifend – aber sobald du regelmäßig mit LLMs arbeitest oder Workflows baust, lohnt der Blick eine Ebene tiefer. Denn unter der Haube gibt es zwei Arbeitsweisen, und die reagieren auf denselben Prompt unterschiedlich. Die Unterscheidung klingt akademischer, als sie ist. Wer einem Reasoning-Modell Prompts aus der GPT-3.5-Ära vorsetzt, bezahlt für Denkarbeit, die er gleichzeitig sabotiert. Wer umgekehrt ein Non-Reasoning-Modell wie einen Denker behandelt, bekommt selbstbewusst formulierte Abkürzungen. Beides kostet – einmal Geld und Latenz, einmal Qualität. ## TL;DR Reasoning- und Non-Reasoning-Modelle brauchen unterschiedliche Prompts – wer beide gleich behandelt, verschenkt Qualität oder zahlt drauf. * Reasoning-Modelle wollen Ziel, Evidenz, Kriterien und Prüfauftrag – keine vorgekauten Denkschritte * Non-Reasoning-Modelle wollen enge Aufgaben, klare Prozessschritte und gute Beispiele * Few-Shot bleibt für Non-Reasoning-Modelle das stärkste Werkzeug, kann Reasoning-Modelle aber auf falsche Lösungswege fixieren * Von den bekannten Reasoning-Verfahren bleibt im Alltag weniger übrig, als LinkedIn behauptet ## Zwei Arbeitsweisen, ein Chatfenster Reasoning-Modelle erzeugen interne Rechenschritte, bevor sie antworten – sie planen, verwerfen, prüfen, und erst dann kommt Text. Non-Reasoning-Modelle antworten direkt. Das macht sie nicht dümmer, sondern schneller und billiger, und für einen großen Teil der Alltagsaufgaben ist das die passende Eigenschaft. Extraktion, Klassifikation, Umformulieren, formatgebundene Ausgaben, Hochdurchsatz-Jobs in Pipelines – dafür braucht niemand ein Modell, das erst drei Absätze lang mit sich selbst ringt. Im Chatfenster nimmt dir die Entscheidung inzwischen oft ein Router ab, der je nach Frage zwischen den Modi wechselt. Verlassen würde ich mich darauf nicht. Spätestens in der API, in eigenen LLM-Pipelines oder Workflows (z. B. in n8n) oder beim Modell-Dropdown wählst du selbst, und dann hilft eine simple Heuristik: Je mehr Abwägung, Abhängigkeiten und Unsicherheit in der Aufgabe stecken, desto eher lohnt Reasoning. Eine Architekturentscheidung, ein kniffliges Debugging, eine Forschungssynthese sind Reasoning-Fälle. Eine Rechnung klassifizieren ist keiner. Warum mehr Denktiefe kein Qualitätsregler ist und wann sie nur Geld verbrennt, habe ich hier ausführlich auseinandergenommen. ## Was Reasoning-Modelle stark macht Der Prompt für ein Reasoning-Modell definiert das Problem, nicht den Lösungsweg. Vier Zutaten haben sich bewährt. **Ein messbares Erfolgskriterium.** „Analysiere diese Strategie“ lässt offen, woran ein gutes Ergebnis erkennbar wäre. „Bewerte die Strategie nach Umsetzbarkeit, Kosten und Risiken, empfiehl eine Option und benenne die größten Unsicherheiten“ gibt dem Modell einen Maßstab, gegen den es seine eigene Arbeit prüfen kann. **Gebundene Evidenz.** Nur die mitgelieferten Quellen verwenden, Fakten von Schlussfolgerungen trennen, fehlende Evidenz kennzeichnen. Das schränkt den Lösungsraum ein – und genau davon lebt Grounding. **Gewichtete Kriterien.** „Welche Lösung ist besser?“ lädt zum Münzwurf ein. „Gewichte Datenschutz mit 35 %, Wartbarkeit mit 25 %, Kosten mit 20 %“ zwingt zu einer nachvollziehbaren Abwägung, die sich hinterher auch gegen die Gewichtung kontrollieren lässt. **Verifikation statt Selbstkritik.** „Reflektiere tief über deine Antwort“ produziert vor allem überzeugender klingende Antworten. „Prüfe jede Tatsachenbehauptung gegen die angegebenen Quellen“ oder „führe die vorhandenen Tests aus und nenne die Fehlschläge“ produziert Kontrolle. Eine konkrete Prüfhandlung schlägt jede allgemeine Sorgfalts-Beschwörung – und wo es um produktive Pipelines geht, gehört die Prüfung ohnehin aus dem Prompt heraus in ein QA-Gate. Was denselben Modellen schadet, ist das Spiegelbild davon. Starre Denkpfade („bearbeite das exakt in diesen 14 Schritten“) legen das Modell auf einen Weg fest, der zur Aufgabe nicht passen muss. Die 70-Seiten-Materialschlacht, in der Regeln, Daten und Auftrag irgendwo verstreut liegen, verdrängt im Kontextfenster genau die Information, auf die es ankommt. Und Negativregel-Kaskaden („nicht werblich, nicht zu lang, nicht zu technisch, nicht langweilig …“) beschreiben alles außer dem gewünschten Verhalten. Eine positive Stilvorgabe plus zwei, drei harte Verbote leisten mehr als zehn weiche. ## Was Non-Reasoning-Modelle stark macht Hier dreht sich das Bild. Ohne eingebaute Denkschleife braucht das Modell mehr Führung – und belohnt diese zuverlässig. Die Aufgabe muss eng geschnitten sein, ein Auftrag pro Prompt. „Fasse zusammen, analysiere kritisch, übersetze und mach noch Social-Media-Posts draus“ scheitert nicht an der Modellqualität, sondern daran, dass Priorität und Format nirgends definiert sind. Komplexe Jobs werden zerlegt: erst extrahieren, dann strukturieren, dann formulieren, dann prüfen – als Pipeline mit vier kleinen Prompts statt einem Monster. Klare operative Verben helfen zusätzlich. „Extrahiere“, „klassifiziere“, „konvertiere“ sind Arbeitsanweisungen; „beleuchte“, „sei kreativ“ und „mach was Professionelles draus“ sind Hoffnungen. Das Ausgabeformat gehört exakt definiert, im Zweifel als Schema. Wo die Schnittstelle Structured Outputs oder JSON-Schema anbietet, ist das dem rein sprachlichen Format-Erzwingen vorzuziehen – der Prompt wünscht sich ein Format, das Schema erzwingt es. Welches Datenformat sich für welche Aufgabe eignet, steht hier im Detail. ## Few-Shot: das unterschätzte Arbeitstier Few-Shot-Beispiele sind für Non-Reasoning-Modelle das wirksamste einzelne Werkzeug – und gleichzeitig das am schlechtesten gepflegte. Sie lohnen sich, wenn Kategorien schwer abgrenzbar sind, ein Format ungewöhnlich ist, ein Stil getroffen werden muss oder interne Unternehmenslogik im Spiel ist. Die Auswahl folgt einer einfachen Regel, die kaum jemand anwendet: ein typischer Fall, ein schwieriger Fall, ein Grenzfall, optional ein Negativbeispiel. Drei unterschiedliche Beispiele schlagen zehn fast identische. Der Haken steckt hier im Kleingedruckten. Das Modell übernimmt aus Beispielen nicht nur die Lösung, sondern auch Ton, Struktur, Annahmen – und Fehler. Ein schlechtes Beispiel ist deshalb schädlicher als gar keins. Bei Reasoning-Modellen kommt ein zweiter Effekt dazu, den OpenAI in den eigenen Best Practices benennt: Erst Zero-Shot probieren, Beispiele nur bei Bedarf nachlegen, denn unpassende Demonstrationen können das Modell auf einen Lösungsweg fixieren, den es allein besser gewählt hätte. ## Die Verfahren aus den Papern – ein Reality-Check Chain-of-Thought, Self-Consistency, Least-to-Most, Plan-and-Solve, Tree of Thoughts, ReAct – die Verfahrensliste liest sich beeindruckend und wird auf LinkedIn gern als Geheimarsenal verkauft. Für den Alltag Mitte 2026 schrumpft sie zusammen. Chain-of-Thought (Wei et al. 2022) steckt in Reasoning-Modellen nativ drin; die explizite Aufforderung hat, wie in Teil 1 gezeigt, dort ausgedient. Für Non-Reasoning-Modelle bleibt sie bei Mathe- und Logikaufgaben ein legitimes Werkzeug. Self-Consistency (Wang et al. 2022) – mehrere unabhängige Lösungswege erzeugen, Mehrheitsentscheid nehmen – funktioniert nachweislich, aber nur bei Aufgaben mit eindeutiger Antwort und zum Preis mehrfacher Modellaufrufe. Für offene Schreibaufgaben taugt das Verfahren nicht, und sinnvoll umgesetzt ist es ein technischer Ablauf mit getrennten Aufrufen, kein „denk fünfmal nach“-Prompt. Least-to-Most und Plan-and-Solve sind im Kern Problemzerlegung mit Plan – nützlich, solange der Plan anpassbar bleibt und nicht als unverrückbares 25-Punkte-Korsett daherkommt. Tree of Thoughts und ReAct schließlich sind ehrlicherweise keine Prompt-Techniken mehr. Ein echter Suchbaum braucht externe Zustandsverwaltung und Bewertung, ReAct braucht echte Tools samt Berechtigungs- und Abbruchlogik. Das ist Orchestrierung, also Software-Architektur – wer das in ein einzelnes Prompt-Textfeld tippt, spielt die Verfahren nur nach. Als Faustregel für die Praxis reicht: Zerlegung und Verifikation gehören in den Prompt, alles mit Schleifen, Zuständen und Werkzeugen gehört in den Code. ## Kurz verdichtet Für Reasoning-Modelle: Ziel, Evidenz, gewichtete Kriterien, Prüfauftrag – und dem Modell den Weg selbst überlassen. Für Non-Reasoning-Modelle: enge Aufgabe, klare Schritte, drei gute Beispiele, hartes Format. Für beide gilt, dass widersprüchliche Regeln und irrelevanter Langkontext mehr kaputt machen als jeder fehlende Trick. Und produktive Prompts gehören versioniert und getestet, sonst bleibt jede Optimierung irgendwas zwischen Quiz und Anekdote. Ganz heißer Take zum Schluss: Die Modelltyp-Frage ist die neue „Welches Keyword nehme ich“-Frage – alle reden über die Feinheiten, die meisten scheitern eine Etage tiefer, nämlich an der unklaren Aufgabe. Erst die Aufgabe sauber schneiden, dann den Modelltyp wählen, dann feilen. Im dritten Teil gibt es das Ganze zum Anfassen – fertige Vorlagen für Extraktion, Klassifikation, Analyse, Recherche und Schreibaufgaben, für Copy&Paste zum direkten Ausprobieren.

t01.li