KI Picks der 42. KW

Das Thema Decision Model ist derzeit nicht totzukriegen, und gefühlt wachsen da täglich neue nach. Es reizt mich ja, also werfe ich zumindest die interessanten Kandidaten auf die Liste, auch einen von Microsoft – weil es ihn eben gibt, weil er einen ganz guten Eindruck macht und weil er auch über OpenRouter zu bekommen ist.

Ansonsten so: Multi-Agent Self-Supervision durch das gleiche Modell, SpaceXAI wirft X Premium, Grok und Cursor in ein Abo zusammen, Gemini 4 Argon rutscht in Antigravity von den dicken Tarifen auch ins Pro-Abo, die Open Weights von Ling-3.1-flash sind nun verfügbar, Meta kann auch noch Open Weights (wenn auch etwas anders, als vielleicht erst vermutet), und dazu kommen noch weitere schöne Dinge. Auf geht’s in eine wieder mal modelllastige 42. Kalenderwoche im Jahre 2026.

Decision 3.0

Die Meldung zu Decision 2.0 ist gerade mal eine Woche alt, und zack: Decision 3.0. Zwischen den beiden Releases lagen genau acht Tage, vom 3. bis zum 11. Oktober. Wie die Leute hinter dem vLLM Semantic Router ihre Versionierung halten, ist ihre Sache, aber man kann es auch ein wenig übertreiben.

Und was hat sich außer der Versionsnummer so geändert?

Inhaltlich rechtfertigt der Sprung die neue Hauptversion durchaus. Decision 2.0 war im Kern eine Text- und JSON-Familie für typisierte Entscheidungen. Decision 3.0 macht daraus ein multimodales Decision Model, bei dem Text, JSON, mehrere Bilder und mehrere Videos gemeinsam als State dienen können. Die drei Entscheidungstypen bleiben unverändert: Choice, Yes/No und Score, jeweils mit Wahrscheinlichkeiten und ohne generierten Freitext. Neues gibt es beim Kontextfenster. Der D3-Decision-Layer setzt kein eigenes max_length, die theoretische Obergrenze liegt damit bei den 262.144 Tokens der zugrunde liegenden Qwen-Modelle. Öffentlich getestet hat das Team nur bis 32.000 Tokens, eine Zusage für die volle Länge ist das damit nicht.

Die Benchmarks in den Model Cards stammen vom öffentlichen Jev Decision Index, gemessen hat das Team selbst. Im unabhängigen Decision Index von Artificial Analysis (dazu gleich mehr bei d1-ultra) taucht Decision 3.0 noch nicht auf.

Microsoft-Decision-1

Aber natürlich: Kaum werden Decision Models interessant, steht ein paar Wochen nach Jev auch Microsoft vor der Tür. Microsoft-Decision-1 ist am 9. Oktober erschienen und soll Routing, Klassifikation, Priorisierung, Verifikation oder Gates in Agent-Workflows übernehmen. Das Modell bekommt feste Antwortoptionen und liefert dafür Wahrscheinlichkeiten zurück, Text generiert es keinen – man kennt das mittlerweile. Unter der Haube steckt zunächst kein neues Microsoft-Basismodell. Microsoft hat für diesen Zweck ein Qwen3.5-9B post-trainiert und will es demnächst auch auf MAI- und OpenAI-Modelle umziehen. Das Kontextfenster liegt laut OpenRouter bei 32.768 Tokens, und rein darf nur Text. Der Preis beträgt 0,042 $ pro Million Input-Tokens, Output ist kostenlos (exakt der Jev-Preis). Zu haben ist das Modell über Microsoft Foundry, OpenRouter und Vercels AI Gateway.

Microsoft meldet erwartungsgemäß Bestwerte aus eigenen Evals, genauer bei Genauigkeit und Tempo. Bei der Kalibrierung reicht es auch laut Microsoft nur für Platz drei, 1,5 Punkte hinter Jev. Die relevante Fußnote steht gleich oben im Beitrag: dieser wurde nach der Veröffentlichung aktualisiert, um Jev in den Accuracy- und Calibration-Vergleich aufzunehmen. In der Urfassung vom 9. Oktober stand Jev nur mit seiner Latenz in der Grafik, und Microsoft lag bei der Kalibrierung dort noch auf Platz zwei. Der naheliegendste Konkurrent hat es also erst in Version zwei des Blogposts in alle Charts geschafft, prompt rutscht Microsoft einen Platz nach hinten. Läuft.

Ein unabhängiger kleiner Reranking-Test (NFCorpus, 200 Fragen) sieht Microsoft-Decision-1 denn auch nicht schlecht, aber keineswegs als Durchmarsch. Je nach Setup liegt es ungefähr gleichauf mit OpenAIs Decisions API mit GPT-6 Luna und beim Reranking mit Fusion leicht hinter Jev. Bei Artificial Analysis landet es mit 53,8 Punkten hinter beiden Jev-Versionen.

Jev 1.14: jetzt mit Bildern

Am 14. Oktober ist bei TypeSafe Jev 1.14 hinten rausgefallen. Kleinere Verbesserungen über mehrere Bereiche, den größten Sprung erwartet TypeSafe bei mehrsprachigen Aufgaben (erwartet, wohlgemerkt). Dazu gibt es drei experimentelle Funktionen: Jev verarbeitet Bilder als Input, lokalisiert mit dem neuen box-Typ Objekte darin als Bounding Box und kann deutlich längeren Context nutzen. Kleine Überraschung am Rande, Bilder und Long Context laufen auch schon mit 1.13, das Modell war laut TypeSafe „multimodal all along“. Wirklich an 1.14 gebunden ist nur box. Freigeschaltet wird das Ganze über zwei Danger-Zone-Header, einen für Bilder und box, einen für den langen Context (262.000 statt 64.000 Tokens pro Request).

Den Namen serviert TypeSafe mit reichlich Emojis, dahinter steckt trotzdem eine brauchbare Produktentscheidung. Denn TypeSafe sagt selbst deutlich, dass diese Funktionen nicht für Production gedacht sind:

we think there is still way too much jaggedness for us to vouch for these for production use cases!

Multimodalität sei weniger zuverlässig als reiner Text, und auch längerer Context verschlechtere die Zuverlässigkeit. Besonders interessant finde ich box. Damit geht Jev erstmals über reine probabilistische Entscheidungen à la „ja/nein“ oder „Option A/B/C“ hinaus und liefert eine strukturierte Position innerhalb eines Bildes zurück, vier Kanten plus Confidence. Eine Antwort „nicht gefunden“ kennt box nicht, dafür soll man zusätzlich eine Ja/Nein-Frage stellen. Das öffnet neue Workflows, am eigentlichen Konzept ändert es nichts. Jev bleibt ein Werkzeug für kleine, typisierte Entscheidungen in Software, und Modelle, die einem einen Aufsatz schreiben, gibt es ja genug.

TypeSafe veröffentlicht dazu auch neue interne Messungen und das Unternehmen weist immerhin selbst darauf hin, dass sich die Eval-Methode noch verändert und zugunsten des eigenen Modells verzerrt sein kann („This is likely biased towards our models.“). Fair enough. Artificial Analysis sieht 1.14 mit 57,1 Punkten sogar minimal unter 1.13 (57,5), dafür flotter. Für mich zeigt Jev 1.14 deshalb vor allem, wohin TypeSafe mit seinen System-One-Modellen will: mehr Input-Typen und mehr mögliche Entscheidungen, ohne aus Jev heimlich doch noch ein LLM für alles zu machen. Der Preis bleibt bei 0,042 $ pro Million Input-Tokens, jev-latest soll in rund einer Woche auf 1.14 umspringen.

Liquid AI d1-ultra

Inzwischen wird es bei den Decision Models richtig voll. Liquid AI hat am 15. Oktober mit d1-ultra die leistungsfähigere Variante seiner d1-Familie nachgelegt. Das Prinzip bleibt gleich. Text und Bilder rein, eine oder mehrere vorgegebene Fragen dazu, und das Modell liefert in einem Forward Pass Wahrscheinlichkeiten für noul (so heißt Ja/Nein im System-One-Format von TypeSafe), choice oder score. Keine generierten Antworten, keine Output-Tokens. Liquid verlangt 0,042 $ pro Million Input-Tokens, womit sich bei TypeSafe, Microsoft und Liquid offenbar ein Einheitspreis eingependelt hat.

Multimodal waren schon die kleinen d1-Modelle, mit d1-ultra kommt das in die größere Klasse (siehe auch den Pick zu Jev 1.14). Damit lässt sich etwa entscheiden, wohin ein Support-Ticket gehört, genauso aber, ob ein Bauteil auf einem Foto einen Defekt hat oder eine Schadensmeldung zum Bild des Kunden passt. Gebaut hat Liquid d1-ultra auf Basis eines größeren Open-Weight-Modells (welches, verrät Liquid nicht) und es stark angepasst. Die Gewichte von d1-ultra selbst gibt es trotzdem nicht. Es gibt das Modell über die Liquid API und, anders als im Blog noch angekündigt, schon jetzt auch bei OpenRouter und im Vercel AI Gateway, jeweils mit 32.768 Tokens Kontext.

Wichtig für die Preisliste im Hinterkopf: Jede Frage wird als eigener Prompt inklusive State und aller Bilder berechnet. Ein Bild mit 1.024 × 1.024 Pixeln kostet 1.536 Tokens, bei drei Fragen fallen damit mindestens 4.608 Bild-Tokens an, dazu dreimal State und Fragetext. Bei 0,042 $ pro Million fällt das erst bei großem Volumen ins Gewicht, aber genau da wollen solche Modelle ja hin. Bei Jev wird ein Bild im State übrigens nur einmal für alle Fragen gelesen.

Mit dem Artificial Analysis Decision Index gibt es seit dem 13. Oktober auch einen unabhängigen Benchmark speziell für diese Modellklasse. Er prüft zu gleichen Teilen Klassifikation (WildGuardTest), Tool-Calling (When2Call), Wissen und Halluzinationen (AA-Omniscience) sowie Reasoning (Fragen aus Humanity’s Last Exam). Der aktuelle Stand für die Modelle aus diesen und den letzten Picks:

• d1-ultra: 65,2
• Jev 1.13: 57,5 und Jev 1.14: 57,1
• Microsoft-Decision-1: 53,8
• Clef: 48,6
• GPT-6 Luna (Decisions API): 48,5

Liquids Sieg ist deutlich, bloß der Claim „outperforms Jev 1.14 across all tasks“ hält nicht ganz. Bei Reasoning und Wissensgenauigkeit liegt Jev vorn, der Vorsprung von d1-ultra kommt vor allem vom ehrlichen „Ich weiß es nicht“ (Non-Hallucination-Rate 84,5 gegenüber 37,2) und vom Tool-Calling. Zur Einordnung der ganzen Klasse hilft ein Blick auf die LLMs im selben Index. Claude Haiku 5.5 auf Max kommt auf 68,4. Decision Models gewinnen bei Preis und Tempo, bei Wissen und Reasoning liegen ordentliche LLMs weiter vorn – das kommt so von Artificial Analysis selbst.

Ling-3.1-flash Open Weights

InclusionAI aus dem Umfeld der Ant Group hat die Gewichte von Ling-3.1-flash am 14. Oktober unter MIT-Lizenz veröffentlicht. Per API war das Modell schon seit Anfang Oktober zu haben, etwa über OpenRouter. Technisch ist das Ding kein Leichtgewicht: rund 560 Milliarden Parameter, davon etwa 25 Milliarden pro Token aktiv, als Hybrid-Linear-MoE mit KDA (Kimi Delta Attention) und Gated MLA im Verhältnis 7:1. Das Modell beherrscht Hybrid Reasoning und Tool Calling und ist vor allem auf lange Agent-Workflows getrimmt, neben Coding nennt Ant auch Büro-, Finanz- und Healthcare-Aufgaben. Das Context Window reicht laut Ant bis 1 Million Tokens, über den eigenen API-Service sind derzeit allerdings nur 256K verfügbar. Auch die Konfiguration auf Hugging Face steht ab Werk auf 262.144 Tokens, und wie man auf die volle Million kommt, dokumentiert Ant nicht.

Die FP8-Weights liegen inzwischen auf Hugging Face, knapp 574 GB fett, empfohlen wird ein SGLang-Setup auf 8 × H200. „Open“ heißt bei 560B also eher Rechenzentrum als bessere Bürokiste. Wer es lieber gehostet mag, zahlt bei OpenRouter derzeit 0,075 $ / 0,225 $ pro Million Input-/Output-Tokens (75 % Aktionsrabatt auf 0,30 $ / 0,90 $). Artificial Analysis misst 41 Punkte im Intelligence Index, aber das Modell ist sehr „mitteilungsbedürftig“. Die 41 merken wir uns kurz für Meta.

Nemotron 3.5 Super VL und Nemotron 3.5 Bolt 74B-A9B

Am 15. Oktober hat NVIDIA gleich zwei Modelle der Familie rausgehauen (nach Nemotron 3.5 Lightning im August): Nemotron 3.5 Super VL und Nemotron 3.5 Bolt 74B-A9B. Super VL ist ein multimodales 120B-MoE mit 12B aktiven Parametern, kombiniert Mamba-2, Transformer und einen C-RADIO-Vision-Encoder und verarbeitet Text, Bilder sowie Video (bis zwei Minuten) bei bis zu 1 Million Tokens Kontext. Tool Calling, Reasoning und Structured Outputs sind direkt vorgesehen. Die Gewichte gibt es in BF16 und quantisiertem NVFP4, Lizenz ist die permissive OpenMDW 1.1 der Linux Foundation.

Artificial Analysis misst 26 Punkte, doppelt so viel wie beim Vorgänger Nemotron 3 Super, mit rund 60 % weniger Output-Tokens pro Task und praktisch ohne Verlust in NVFP4. NVIDIAs Effizienz-Story stammt damit nicht komplett aus der eigenen Presseabteilung, auch wenn AA das Modell im Klassenvergleich trotzdem „somewhat verbose“ nennt. Das oft zitierte „leading open model“ braucht ebenfalls sein Sternchen. Die Formulierung stammt von AA und bezog sich auf die US-Open-Weight-Kategorie, und selbst dort hielt der Titel nur ein paar Stunden, bis Meta am Abend nachlegte (siehe nächster Pick). In der Gewichtsklasse 40 bis 150 Milliarden Parameter liegt Super VL bei AA dagegen weltweit vorn.

Interessanter finde ich eigentlich Bolt: NVIDIA komprimiert Super VL auf 74B Gesamt- und 9B aktive Parameter, 256K Kontext und eine native 2-Bit-Quantisierung (genauer eine Mischung, die Experts liegen in 2 Bit, der Rest in NVFP4 und 8 Bit), sodass die Gewichte rund 24 GB wiegen. Es bleibt multimodal und unterstützt Tool Use sowie abschaltbares Thinking. NVIDIA liefert neben Safetensors gleich ein offizielles GGUF mit, Unsloth hat nachgezogen. Belegt sind llama.cpp, Ollama, Unsloth und vLLM, für LM Studio habe ich noch keinen Bolt-Eintrag gefunden. Damit wird aus dem üblichen „offene Weights, viel Spaß mit deinem Rechenzentrum“ tatsächlich ein Modell, das lokal auf stärkerer Consumer-Hardware richtig interessant wird.

Mit universeller Hardware-Kompatibilität hat die 24-GB-Angabe wenig zu tun, sie beschreibt die Dateigröße. NVIDIAs Rezepte verlangen für den Betrieb 28 beziehungsweise 32 GB, das heißt eine Grafikkarte ab 32 GB oder 64 GB Unified Memory, eine RTX 4090 mit 24 GB sieht NVIDIA gar nicht vor. Der validierte Pfad ist, wenig überraschend, NVIDIA-lastig (Blackwell, Linux, RTX und DGX Spark). Bei AA landet Bolt mit 21 Punkten nur zwei hinter dem rund siebenmal größeren Nemotron 3 Ultra.

Muse Spark Open

War der 15. Oktober irgendwie abgesprochen? Auch Meta hat an diesem Tag mit Muse Spark Open erstmals die Gewichte eines großen Modells aus der Muse-Spark-Reihe veröffentlicht. Ganz so, wie Zuckerberg es im August angekündigt hatte, ist es allerdings nicht gekommen. Versprochen waren die Gewichte von Muse Spark 1.2, gekommen ist ein eigenes „Open“-Modell auf diesem Niveau, mit zusätzlichem Safety-Training und eigener Lizenz. Das MoE kommt auf 816 Milliarden Parameter, davon 42 Milliarden aktiv, bietet 1 Million Tokens Kontext und ist nativ multimodal, mit Text, Bild, Video und sogar Audio als Input. Die Gewichte liegen unter anderem auf Hugging Face, mit manueller Freigabe nach Angabe von Klarnamen, Geburtsdatum und Firma. Für Self-Hosting unterstützt Meta SGLang, vLLM, TensorRT-LLM, Transformers, llama.cpp, Unsloth und ausdrücklich Apple MLX. Dazu kommen gehostete Varianten bei Baseten, Fireworks, Groq, Modal, Nebius, OpenRouter und Together AI, zum Start für 1,25 $ / 4,25 $ pro Million Input-/Output-Tokens.

Meta verkauft Muse Spark Open als Frontier-Modell für den „Desktop“ – wobei Desktop hier zwei Mac Studios mit M5 Ultra und zusammen 1 TB Unified Memory bedeutet, verbunden per RDMA über Thunderbolt 5. Alternativ gehen laut Meta-Doku vier Mac Studios mit je 256 GB, und das ist sogar die schnellste Variante. In BF16 brauchen allein die Weights rund 1,65 TB, und selbst die NVFP4-Version ist mit etwa 530 GB größer als ein voll ausgebauter Mac Studio. Den 512-GB-Mac-Studio gibt es laut MacRumors noch gar nicht zu kaufen, er soll erst Ende Oktober 2026 verfügbar sein (die 256-GB-Variante kostet schon über 10.000 $). „Lokal ausführbar“ stimmt also, nur braucht das Bild vom Modell, das gemütlich auf dem Mac unter dem Schreibtisch läuft, mindestens einen zweiten Mac daneben und ausreichend Dampf unterm Blech.

Wo wir gerade bei nicht ganz unerheblichen Einschränkungen sind: Mit Open Source hat das trotz offener Gewichte wenig zu tun. Die Muse Model License erlaubt zwar kommerzielle Nutzung, verlangt aber den „Built with Muse Spark Open“-Hinweis in jeder Oberfläche, auch bei Distillaten, dazu kommen eine Usage Policy und die Umsatzklausel für API-Anbieter. Technisch ist der Release trotzdem relevant. Nach der bislang geschlossenen Spark-Serie und dem kleinen Muse Glimmer im August gibt Meta Entwicklern erstmals seit Llama 4 wieder ein großes eigenes Modell zum Herunterladen, Quantisieren und Self-Hosten.

Bevor man das jetzt aber als Frontier-Modell liest, muss man das etwas einschränken: Artificial Analysis misst 39 Punkte, das reicht für Platz eins unter den US-Open-Weight-Modellen. Metas eigenes geschlossenes Muse Wonder liegt allerdings 13 Punkte darüber. Und das chinesische Ling-3.1-flash von weiter oben zieht mit 41 Punkten an Meta vorbei. So viel zum US-Sternchen.

Bonsai 2 2B, 4B, 9B

Das LLM für die Bürokiste (dedizierte GPU wäre trotzdem gut): PrismML erweitert Bonsai 2 um drei kleinere Varianten mit 2, 4 und 9 Milliarden Parametern (mit Bonsai 27B war PrismML schon im Juli in den Picks). Basis ist jeweils Qwen3.5, die Sprachgewichte werden ternär als {-1, 0, +1} abgelegt. Dadurch schrumpft das reine Language Model im kleinsten GGUF-Packing auf 0,43 GB beim 2B, 0,95 GB beim 4B und 2,00 GB beim 9B. Kleiner Haken dabei: Dieses Format (PTQ1_0) läuft nur mit PrismMLs eigenem llama.cpp-Fork, Standard-llama.cpp lädt erst die Q2_0-Fassung mit 0,55 / 1,21 / 2,56 GB. Alle drei behalten 262.144 Tokens Kontext, Vision-Input, Thinking und Tool-Calling. Die Modelle liegen auf Hugging Face unter Apache 2.0, als GGUF für llama.cpp und als MLX-Paket für Apple Silicon (das braucht mlx-vlm ab 0.7.8).

*Format PTQ1_0, nur mit PrismMLs llama.cpp-Fork

Die „mehr als 9× kleiner“-Schlagzeile braucht ein klitzekleines Sternchen: PrismML vergleicht dabei die gepackten ternären Sprachgewichte im kleinsten Format mit dem jeweiligen 16-Bit-Modell, und im eigenen Whitepaper stehen dann auch „nur“ 8,8 bis 9,0×. Für Vision kommt ein separater Tower dazu, und einzelne empfindliche Tensoren bleiben höherpräzise. Beim 9B sind das beispielsweise weitere 0,62 GB für den empfohlenen Q8-Vision-Tower. Ein paar Punkte kostet die Diät auch. Der 9B behält bei Coding und Instruction Following praktisch alles, bei Knowledge und Reasoning rund 93 % (herstellereigene Werte). Mit „Agentic AI auf jedem Gerät“ kann ich wenig anfangen. Spannend finde ich, dass hier 2 bis 9 Milliarden Parameter mit langem Kontext und multimodalem Input in Größenordnungen landen, bei denen lokales Deployment nicht mehr nach Homelab-Spleen klingt.

MASS – Multi-Agent Self-Supervision

Sakana AI und Forschende der UC Berkeley (darunter Databricks-Mitgründer Matei Zaharia) stellen mit MASS – Multi-Agent Self-Supervision – einen Ansatz für Recursive Self-Improvement vor, samt Paper und Code. Die Idee: Dasselbe Modell übernimmt drei Jobs. Es löst die Aufgabe, optimiert den Multi-Agent-Workflow und bewertet anschließend die Ergebnisse im paarweisen Vergleich. Im Inner Loop bleiben die Gewichte unangetastet, optimiert wird die Organisation der Agenten mit Rollen, Instructions, Output Contracts und der Reihenfolge der Aufrufe. Die besten Workflows laufen anschließend mehrfach (18-mal pro Aufgabe), das Modell rankt die Ergebnisse selbst, und die Gewinner werden zu Trainingsdaten. Im Outer Loop landet diese Erfahrung per LoRA wieder im Modell. Dann beginnt das Spiel von vorn, im Experiment waren es zwei Runden.

Das ist beileibe aufregender als das übliche „wir lassen fünf Agenten miteinander reden“. Ausgangspunkt ist Qwen3.6-27B im qwen-code-Harness, und MASS versucht explizit, gute Koordination aus den Multi-Agent-Traces in die Gewichte zu destillieren. Nach zwei Runden delegiert das Modell auch ohne vorgegebenen Workflow, in 87 von 110 Läufen statt in einem einzigen. Sakana beobachtet außerdem, dass optimierte Workflows mit der Zeit weniger Information in hübschen Rollenbeschreibungen und mehr in Contracts und Übergaben zwischen den Agenten tragen. Ganz von allein kam das nicht, wie Sakana selbst einräumt, denn der System-Prompt des Optimierers schubst genau in diese Richtung. Es passt trotzdem gut zu dem, was bei produktiven Agent-Systemen ohnehin zählt (siehe auch Loop Engineering): Wer liefert wem was – und wann?

Eine Einschränkung wird gleich mitgeliefert: Das Experiment umfasst nur zwölf synthetische Research-Aufgaben aus Finance, Robotics und Pharmacy, neun davon fürs Training. Auf ähnlich gelagerten Research-Evals verbessert sich das Modell, die Hauptmetrik ist dabei Score pro Output-Token und misst eher Effizienz. Bei Software-Engineering wird es auf SWE-bench Verified und Terminal-Bench 2.0 sogar minimal schlechter. Der offensichtlichste Haken steckt im Konzept selbst. Wenn dasselbe Modell erzeugt, optimiert und bewertet, können sich gemeinsame Blind Spots gleich mitoptimieren, und Sakana benennt das selbst:

shared blind spots may be an Achilles’ heel of recursive self-improvement.

Meinen ersten Verdacht, dass LLM-as-a-Judge durch das gleiche Modell eher kontraproduktiv ist, stützen die Daten allerdings nicht. Die Übereinstimmung des Selbst-Bewerters mit externen Judges (GPT-5.5 und Claude Opus 4.8) steigt über die Zyklen von 73 auf 93 %, und laut Paper ist eher der Optimierer der Engpass als der Bewerter. Ich lasse das so stehen. MASS ist ein interessantes Forschungsstück über lernende Agent-Workflows. Ob sich Modelle demnächst zuverlässig selbst aus dem Sumpf ziehen, belegt es noch nicht.

Claude Code Desktop App frisch renoviert für parallele Sessions

Anthropic hat der Claude Code Desktop-App am 14. Oktober ein Update für paralleles Arbeiten spendiert. Sessions lassen sich schneller starten, zuletzt genutzte Ordner liegen direkt bereit, und wiederkehrende Setups aus mehreren Ordnern, einem SSH-Host oder der Cloud lassen sich als Environment speichern, auf Wunsch mit einem Worktree pro Ordner. Interessant wird es beim Aufteilen größerer Aufgaben. Wer Claude bittet, Aufgaben parallel abzuarbeiten, bekommt pro Aufgabe eine eigene verschachtelte Session, die ihr Ergebnis anschließend an die Hauptsession meldet. Von sich aus schlägt Claude Folgeaufgaben vor, die sich per Klick als eigene Session starten lassen. Sidebar, Live-To-do-Liste und Recap-Karten sollen sichtbar machen, wer gerade arbeitet und wo Claude auf den Nutzer wartet. Die Dokumentation beschreibt die Basis mit parallelen Sessions, optionalen Git-Worktrees, Cloud- und SSH-Sessions sowie Side Chats. Die Neuerungen dieser Woche stehen bislang nur im Ankündigungs-Thread.

In erster Linie ist das eine bessere Bedienoberfläche für Dinge, die darunter zum guten Teil schon existierten. Parallele Sessions, Worktrees und Side Chats sind keine Erfindung dieser Woche, Anthropic hatte die Desktop-App bereits im April auf mehrere gleichzeitige Agenten ausgerichtet. Neu ist vor allem, dass der ganze Kram stärker zusammengezogen wird und Claude die Aufteilung in weitere Sessions sichtbarer übernimmt. Fürs Terminal gab es am selben Tag übrigens Idle Compaction. Lange Sessions, die herumliegen, komprimiert Claude Code jetzt kurz bevor der Prompt-Cache nach rund einer Stunde abläuft.

Und genau dieses Aufräumen finde ich an dem Update deutlich faszinierender als jedes „autonome Agenten“-Marketing-Gedöns. Wenn fünf Sessions gleichzeitig werkeln, ist ein sechster Agent schnell gestartet. Schwieriger wird es, im Blick zu behalten, welcher gerade was tut, worauf er wartet und welche Änderungen am Ende wo landen. Agentic Coding bekommt langsam dasselbe Problem wie klassische Projektarbeit (siehe auch den Koordinator in den neuen Claude-Projekten). Überraschend eigentlich nur, dass wir dafür wieder bei einer GUI landen und das Terminal mal Pause hat.

Scion: Versionierung made by Anthropic

Heise berichtet, dass Anthropic sein internes Monorepo von Git auf ein eigenes Source-Control-System namens Scion umgezogen hat, die Details liefert Anthropic im Engineering-Blog gleich selbst. Den Ausschlag gibt Anthropics inzwischen ziemlich absurder Workload. Die Merges pro Tag sind von rund 2.500 im Mai auf über 30.000 im September gestiegen, die Main-History allein ist knapp 100 GB groß, und die CI checkt täglich etwa 25 Millionen Mal Code aus. Naiv per Git geholt wären das über 600 PB Traffic am Tag. Scion dreht deshalb einige Git-Grundannahmen um. Clients gelten als immer online, Historie, Merges, Rebases und Blame liegen serverseitig, Working Copies sind optional, und Dateien werden sparse beziehungsweise bei Bedarf materialisiert. Die Arbeitseinheit sind serverseitige Changesets, die Daten verteilt Scion horizontal über Storage und Caches.

Anthropic meldet dafür einen 200-mal kleineren CPU- und RAM-Bedarf gegenüber der vorherigen Git-Mirror-Infrastruktur, Checkouts in Sekunden statt Minuten, und in der CI wurden 25 % CPU-Kapazität frei. Das sind Anthropics eigene Zahlen aus Anthropics eigener Infrastruktur, unabhängige Messungen gibt es naturgemäß nicht. Zum Ausprobieren taugt Scion auch nicht. Anthropic erachtet eine öffentliche Version für wenig sinnvoll, weil Scion stark von Git abweicht und eigenes Code Review, eigene Code-Suche und eigene CI voraussetzt (bei Heise heißt das schlicht, Anthropic wolle es nicht veröffentlichen). Die Ideen sollen stattdessen zusammen mit GitHub, GitLab und der Open-Source-Community in Git einfließen. Was Scion nicht sein soll, schreibt Anthropic unmissverständlich hin:

Scion is by no means a suitable replacement for git for general use.

So viel zur „Git-Alternative“ aus der Heise-Überschrift.

Wenn Coding-Agenten Code schneller produzieren, als klassische CI-, Review- und Source-Control-Infrastruktur ihn verdauen kann, verschiebt sich der Flaschenhals einfach eine Etage weiter. Anthropic sieht den Engpass inzwischen selbst in der Entwickler-Infrastruktur, die für menschliches Tempo gebaut wurde, und rechnet damit, dass andere in sechs bis zwölf Monaten vor derselben Frage stehen. Für 99,x % der Teams bleibt Git deshalb das passende Werkzeug. Anthropic zeigt trotzdem ganz gut, welche Infrastrukturfragen auftauchen, wenn Agenten im industriellen Maßstab Änderungen rausfeuern, wo sie früher gelegentlich mitgecodet haben. Zed arbeitet mit Delta gerade an einer ähnlichen Baustelle.

The X Subscription: Grok, Cursor und X Premium in einem Abo

Wer schon immer das Supidupi-Rundum-Paket haben wollte, bekommt das jetzt in einem Abo. SpaceXAI hat am 12. Oktober The X Subscription vorgestellt, die Grok, Grok Bot, Cursor und X Premium unter einen Hut bringt, samt Zugang zur Grok-API (deren Nutzung wird separat zu den normalen Tokenpreisen abgerechnet). Grok Bot, Cloud Agents und Automationen, Code-Hosting über Origin und KI-Code-Reviews über Bugbot kosten keinen Aufpreis, die stecken ab der Stufe Premium mit drin.

Ernsthaft zu haben ist das Ganze ab 8 $ im Monat, alle Stufen teilen sich einen wöchentlichen Nutzungspool für Cursor und Grok. Die Staffel laut Preisseite:

• Free: 0 $, mit Tageskontingent
• Plus: 8 $, Cursor nur mit Grok-Modellen, kein Grok Bot
• Premium: 30 $, laut SpaceXAI der Gegenwert von SuperGrok, Cursor Pro und X Premium+
• Super: 100 $
• Ultra: 200 $

Jährlich wird es etwas günstiger, die Preise verstehen sich ohne Steuern. Team-Optionen gibt es ab 30 $ pro Nutzer und Monat, Plus ist für Teams nicht buchbar.

Wie gut der Gegenwert des 8-Dollar-Deals bei einer halbwegs ambitionierten Nutzung von Cursor ist, kann ich mangels Erfahrungswerten nicht beurteilen. Bei Plus gibt es in Cursor ohnehin nur Grok-Modelle, und die „Latest Grok models“ führt die Preistabelle erst ab Premium. Das aktuelle Grok 4.7 ist im Plus-Tarif trotzdem enthalten (allerdings nur mit Medium-Effort verfügbar). Die Cursor-Preisseite empfiehlt Plus eher „social creators with limited AI usage“.

Apropos, etwas verwirrend: Auf der Website steht unten noch „© 2026 SpaceXAI LLC“, die Seitentitel tragen aber schon „SpaceXSI“, und der X-Account heißt mittlerweile trendgerecht „SpaceX Super Intelligence“.

Gemini 4 Argon in Google Antigravity verfügbar

Google hat Gemini 4 Argon am 13. Oktober in Antigravity und der Gemini API freigeschaltet, sowohl in der Desktop-App als auch in der CLI. Am selben Tag kam das Modell auch in die Gemini-App für AI Pro und Ultra.

Google nennt über 100.000 monatliche Argon-Nutzer bei Alphabet, die mit der internen Antigravity-Version arbeiten, und berichtet über vier Wochen von 35 % mehr agentisch erzeugtem Code bei gleichzeitig 30 % weniger Rollbacks nach dem Einreichen. Das sind Zahlen aus dem eigenen Maschinenraum. Unabhängiger ist Artificial Analysis mit 53 Punkten im Intelligence Index, gleichauf mit GPT-6 Astra und pro Aufgabe zum Einführungspreis rund 40 % günstiger.

Der kleine Haken beim Zugang: In Antigravity bekam man Argon zunächst nur mit Google AI Ultra oder einem passenden Gemini-Enterprise-Abo (den Blogpost hat Google inzwischen still auf „Pro and Ultra“ umgeschrieben). Über die API reicht ein bezahlter Gemini-API-Account mit aktiviertem Billing, der Free Tier ist raus. Seit dem 15. Oktober (US-Zeit) darf man auch mit dem Pro-Abonnement mitspielen, mit einem eigenen wöchentlichen Argon-Kontingent.

Ach so, bei OpenRouter geht es auch ganz ohne Abo, vorerst zum bekannten Einführungspreis von 2 $ / 10 $ pro Million Input-/Output-Tokens. Das ist Googles eigener API-Preis, und der verdoppelt sich ab dem 1. Dezember auf 4 $ / 20 $.

Google serviert Scrapern offenbar Fake-SERPs

Passt nur über Bande zum Thema KI, lustig ist es trotzdem. Google scheint erkannten Scrapern inzwischen Suchergebnisse unterzuschieben, die vollkommen normal aussehen und nur eben nicht stimmen. SEO Südwest greift dazu eine Analyse von Nozzle auf. Nozzle hat 27,5 Millionen seit dem 13. September gesammelte SERPs ausgewertet, und von den 17,8 Millionen bewertbaren galten 8 % nach Nozzles Definition als „poisoned“ (vorher waren es 0,17 %). Gewohnte Treffer verschwinden, Reddit, Facebook, LinkedIn oder Quora rücken nach, und ein Rank-Tracker speichert das Ganze brav als echten Rankingverlust. Ausgerechnet Österreich liegt mit 18,8 % vergifteter SERPs an der Spitze, Deutschland kommt auf 4,3 %.

Das Gemeine daran: Ein geblockter Scraper weiß wenigstens, dass er geblockt wurde. Eine plausibel aussehende Fake-SERP landet dagegen einfach in den Daten. Bei 77,9 % der von Nozzle erkannten Fälle waren die gewohnten Ergebnisse innerhalb von drei Tagen wieder da. Für SEO-Tools ist das unangenehm, und für deren Nutzer ein guter Grund, bei plötzlich abstürzenden Rankings erst einmal in die Search Console zu schauen, bevor jemand hektisch die halbe Website umbaut. Das empfiehlt auch Nozzle.

Nozzle hält das Ganze für Googles Antwort auf KI-Scraper, die Suchergebnisse in großem Stil für KI-Antworten einsammeln, Rank-Tracker wären demnach nur Beifang (da ist er dann doch, der KI-Bezug). Die Interpretation ist schlüssig, eine Stellungnahme von Google gibt es bislang aber nicht. Ende September lief außerdem ein Spam-Update, echte Rankingverluste sind in dem Zeitraum ebenfalls möglich. Wer gerade seine KI-Sichtbarkeit oder klassische Rankings mit Tools misst, sollte deren Datenquelle im Moment besonders kritisch anschauen.

Damit Feierabend für diese Woche – und glaubt keinem Rankingabsturz, den die Search Console nicht bestätigt.