Kategorie: KI-News

„That’s about double what Meta Platforms Inc. had reportedly offered for the company last December.“ Der Satz steht im SiliconANGLE-Bericht. Eine Bewertung, die doppelt so hoch liegt wie das, was Meta zahlen wollte, sagt vor allem eines über die Verhandlungsposition von Manus.

Der KI-Agent-Entwickler Manus hat nach eigenen Angaben mehr als 500 Millionen Dollar eingesammelt. Angeführt wurde die Runde von der Private-Equity-Firma Boyu Capital, beteiligt sind unter anderem Tencent Holdings und weitere Investoren. Die Bewertung von rund 4 Milliarden Dollar nennt das Unternehmen nicht selbst; die Zahl stammt aus einem Bloomberg-Bericht, der die Transaktion im Vormonat angekündigt hatte. SiliconANGLE-Autorin Maria Deutscher hat die Details am 8. Oktober 2026 zusammengetragen.

Wer verstehen will, wohin das Geld in diesem Segment fließt, muss zwei Dinge auseinanderhalten. Ein Sprachmodell beschreibt, wie eine Aufgabe zu lösen wäre. Ein Agent führt sie aus: Er greift auf Werkzeuge zu, legt Dateien an, korrigiert sich, arbeitet Aufträge ab. An dieser Ausführungsebene arbeiten Firmen wie Manus. Deshalb fließen dort Beträge, wie man sie sonst aus der Halbleiterbranche kennt.

Boyu Capital führt die Runde an, Tencent ist beteiligt

Manus bestätigt die Runde selbst. Mehr als 500 Millionen Dollar, angeführt von Boyu Capital, mit Beiträgen von Tencent und weiteren Geldgebern. Die Beträge der einzelnen Beteiligten werden nicht genannt — das ist bei solchen Runden üblich. Auch die Bewertung nennt das Unternehmen nicht. Die 4 Milliarden Dollar stammen aus einem Bericht, nicht aus einer offiziellen Angabe.

Dass zwischen „bestätigt“ und „berichtet“ ein Unterschied liegt, ist hier keine Formalie. Er zeigt, wer für welche Aussage geradesteht. Die Summe verantwortet Manus. Für die Bewertung steht dagegen Bloomberg als berichtende Quelle gerade, nicht Manus selbst. Nach dem geplatzten Verkauf kann das Unternehmen das Kapital verkünden und die Bewertungsdebatte anderen überlassen.

Auffällig ist die Zusammensetzung der Geber. Mit Boyu Capital als Anführer und Tencent, einem der größten Technologiekonzerne Chinas, als Beteiligtem stammt das Kapital überwiegend aus dem chinesischen Raum. Nach dem bereits von Pekinger Regulierern blockierten Meta-Deal dürften Aufsichtsbehörden auch einen künftigen Verkauf oder Börsengang genau prüfen.

Von der Browser-Erweiterung zum Agenten: die Vorgeschichte von Manus

Manus startete 2022 als Butterfly Effect Co. Ltd. Das erste Produkt war eine Browser-Erweiterung, die über eine Oberfläche Zugang zu mehreren KI-Modellen bot. 2024 kamen 10 Millionen Dollar und eine Neuausrichtung: Das Team arbeitete von da an am Manus-Agenten.

Der Agent kam im März, zunächst nur über ein Einladungsprogramm. Videos, die zeigten, wie er mehrstufige Aufgaben direkt auf dem Rechner von Nutzern erledigte, verbreiteten sich schnell. Darauf wurde die Wagniskapitalfirma Benchmark aufmerksam; im April 2025 flossen 75 Millionen Dollar. Der Hauptsitz zog nach Singapur — im Rückblick eine wichtige Entscheidung, denn die Regulierungsprobleme kamen später.

Der technische Reiz lag nicht im Modell allein. Sprachmodelle formulieren Texte, handeln aber nur begrenzt. Manus zeigte die Verkettung: ein Plan, ein Werkzeug, eine Datei, eine Korrektur. Der Sprung von der Antwort zur ausgeführten Aufgabe ist der Grund, warum Kapital in die Ausführungsebene fließt und nicht mehr nur in immer größere Modelle.

Warum aus der Übernahme durch Meta nichts wurde

Im Dezember lag einem Bericht zufolge ein Angebot von Meta vor, das Manus etwa halb so hoch bewertete wie heute. Der Deal kam nicht zustande: Im April 2026 blockierten chinesische Regulierer die Übernahme. Manus erklärte danach, wieder eigenständig zu arbeiten. In der Rückschau war das keine Verlegenheitslösung, sondern eine bessere Verhandlungsposition.

Meta reagierte. Der Konzern baute die eigene Agenten-Entwicklung aus und brachte die App Muse heraus, die im US-App-Store zuletzt ChatGPT überholte. Zwei Ansätze treffen aufeinander: das Produkt eines spezialisierten Teams und die Reichweite eines Plattformkonzerns.

Für die Bewertung hat das zwei Seiten. Der Wert beruht nicht auf Umsatz, sondern auf einem Vergleich mit einem Angebot, das nie zustande kam. Das ist angreifbar. Andererseits dient das frühere Angebot als Vergleichspunkt. Verhandelt wird jetzt zwischen Manus und einer Gruppe von Investoren, nicht mehr mit einem einzelnen Käufer.

Manus 2.0, Cloud Computer und Cue: was die neue Version mitbringt

Wenige Tage vor der Finanzierungsankündigung erschien Manus 2.0, das erste größere Update seit dem Neustart. Kernstück ist ein neuer „Harness“: Softwaremodule, die das Verhalten der darunterliegenden Sprachmodelle steuern. Die genannten Zahlen sind konkret — bis zu 23,2 Prozent weniger Token-Verbrauch bei bestimmten Aufgaben, über 28 Prozent schnellere Verarbeitung.

Das zweite Element heißt Cloud Computer und hostet den Backend-Code KI-generierter Spiele in einer verwalteten Umgebung. Die Funktion reicht über Spiele hinaus: Sie kann Websites betreiben und lang laufende Aufgaben weiterführen, auch wenn der Rechner des Nutzers ausgeschaltet ist. Das betrifft die Zuverlässigkeit — und die Rechenkosten im Hintergrund.

Das dritte Element, Cue, geht am weitesten. Agenten bekommen damit Ressourcen: ein E-Mail-Konto, eine digitale Geldbörse. Nutzer können außerdem ein Message Board einrichten, über das mehrere Cue-Agenten an einer Aufgabe zusammenarbeiten. Ein Agent, der eine Rechnung bezahlen kann, ist kein Textgenerator mehr, sondern ein Konto mit Zugriffsrechten.

Nous Research und Meta: das Feld rund um KI-Agenten wird enger

Die Runde fiel in eine Woche, in der mehrere Geldgeber aktiv wurden. Nous Research, ein Startup mit einem konkurrierenden Agenten für Endnutzer, sammelte einen Tag zuvor 90 Millionen Dollar ein. Die Summen unterscheiden sich deutlich, die Richtung ist dieselbe: Kapital sucht nicht mehr das beste Modell, sondern die beste Infrastruktur drumherum.

Für Agenten-Entwickler verschieben sich die Wettbewerbsfragen. Im Zentrum steht nicht mehr, wie klug eine Antwort ist, sondern wie zuverlässig eine Aufgabe abgeschlossen wird, wie viele Token der Weg dorthin kostet und wer haftet, wenn der Agent etwas Falsches tut. Solche Fragen löst kein größerer Trainingslauf, sondern Ingenieursarbeit. Das erklärt den Kapitalbedarf.

Dazu kommt der Druck der Plattformen. Meta hat die eigene Entwicklung beschleunigt und hat mit Muse eine Reichweite, die kein Startup kaufen kann. Wer dagegen antritt, braucht entweder einen technischen Vorsprung oder einen sehr spezifischen Anwendungsfall. Manus setzt auf Ersteres.

Was die 4 Milliarden Dollar konkret bedeuten

Eine Bewertung ist keine Bilanz. 4 Milliarden Dollar sagen nicht, wie viel Manus verdient, sondern wie viel jemand zu zahlen bereit ist in der Erwartung, dass das Unternehmen die Ausführungsebene der KI besetzt. Das ist eine Wette auf Umsetzung.

Zwei Dinge sind mehr als Schlagzeilen. Erstens die Token-Effizienz: bis zu 23 Prozent weniger Token bei bestimmten Aufgaben, wie Manus angibt, senken die Grenzkosten. In einem Geschäft, in dem jede Agentenaktion Rechenleistung kostet, entscheidet das darüber, ob ein Geschäftsmodell trägt oder ob es bezuschusst werden muss. Zweitens die Kombination aus Cloud Computer und Cue: Agenten bekommen Ausdauer und Zugriffsrechte. Damit verschiebt sich die Kontrollfrage von der Software in die Organisation.

Wer KI-Agenten im Unternehmen einsetzt, wird den Unterschied in den nächsten Monaten nicht an einer klügeren Antwort merken, sondern daran, dass eine Aufgabe abgeschlossen wird, während der Rechner ausgeschaltet ist.

Quelle: siliconangle.com

Eine Milliarde Produkteinträge – darum geht es. Nicht um eine neue Lagerhalle, sondern um einen neuen Zugang. The Verge berichtet, dass Shopify seinen Katalog für Agenten öffnet, die Käufer selbst nach ihren Regeln konfigurieren. Damit verschiebt sich die Grenze zwischen Suchen und Kaufen. Wenn du verstehen willst, was daran neu ist, musst du zwei Dinge auseinanderhalten: das, was Shopify im eigenen Newsroom bestätigt, und das, was über die Ankündigung berichtet wird. Der Unterschied entscheidet, wie belastbar die Details sind, über die gerade gesprochen wird.

Was Shopify im eigenen Newsroom bestätigt

Zwei Dinge lassen sich anhand von Shopifys eigener Kommunikation belegen. Zum einen die Agentic Storefronts: Sie geben Händlern einen Zugang ohne eigene Entwicklung zu ChatGPT, Microsoft Copilot, dem AI Mode in der Google-Suche und der Gemini-App. Zum anderen der Agentic-Plan, der auch Marken einschliesst, die nicht auf Shopify laufen. Diese können ihre Produkte in den Shopify Catalog und in die Shop App einstellen, ohne ihr eigenes Shopsystem zu wechseln. Damit wird der Katalog von einem geschlossenen Händlerverzeichnis zu einer Infrastruktur, an der auch Fremdsysteme andocken dürfen.

Der entscheidende Satz ist unspektakulär: Die Händler bleiben Merchant of Record. Wer verkauft, bleibt rechtlich und finanziell der Verkäufer, mit allen Pflichten, die daran hängen. Mani Fazeli, VP Product bei Shopify, sagt, agentischer Handel sei nichts, worauf man reagiere, sondern eine Vision, die man an der vordersten Kante von Handel und KI zum Leben bringe. Das Unternehmen wolle der Kurve voraus sein, damit seine Händler dort seien, wo ihre Käufer sie erwarten.

Von der KI-Seite kommt die Ergänzung. Neel Ajjarapu, Commerce Product Lead bei OpenAI, beschreibt den ChatGPT-Teil so: Die Integration von Produkten aus Shopifys gesamtem Händler-Ökosystem mache Millionen von Händlern und Milliarden von Produkten sofort auffindbarer. Der Plattformbetreiber will Reichweite, der Kanalbetreiber will Auffindbarkeit. Der Händler steht dazwischen und trägt weiterhin das Verkaufsrisiko.

Ein breiter Eingang, ein Schalter im Inneren

Für das Verständnis hilft ein Bild: ein steinerner Marktbogen, weit geöffnet, ohne Wächter am Eingang. Durch ihn zieht eine Prozession von Boten mit Körben. Jeder Bote ein Agent, jeder Korb ein Einkaufswunsch. Doch an einer schmalen Stelle im Inneren sitzt ein Schalter, und dort hält jeder Korb an, bis eine menschliche Hand einen Stempel aufsetzt. Erst danach geht es weiter.

Genau so ist die Konstruktion beschrieben, die The Verge dokumentiert. Käufer verbinden einen Agenten mit ihrem Shop-Konto, bezahlen mit einem Klick über Shop Pay direkt im Gespräch mit dem Agenten, und die Bestellungen laufen anschliessend in der Shop App zusammen. Der Agent bekommt Regeln mit auf den Weg, etwa Budgetgrenzen oder die Vorgabe, nur Ergebnisse mit schnellem Versand zu berücksichtigen. Vor jedem Kauf muss der Käufer zustimmen.

Diese Freigabe pro Kauf ist die tragende Wand der ganzen Anordnung. Sie ist der Unterschied zwischen einem Assistenten, der einkauft, und einem, der ausgibt. Ohne sie wäre der breite Bogen ein offenes Tor mit einem Kassenhäuschen, das niemand mehr bedient. Mit ihr bleibt der Mensch an der Stelle, an der Geld den Besitzer wechselt.

Ein Datum, zwei Quellenlagen

Zur Einordnung gehört eine Unschärfe. Die Formulierungen von den shopper-configured Agenten und der Positionierung als personal shopper stammen aus der Berichterstattung von The Verge über eine offizielle Ankündigung. Der Bericht ist auf den 13. Oktober 2026 datiert und gibt an, Shopify habe die Erweiterung an jenem Dienstag bekannt gegeben. Ein Shopify-Newsroom-Beitrag mit genau dieser Wortwahl war zum Zeitpunkt der Berichterstattung nicht abrufbar. Das Datum ruht damit auf The Verge und nicht auf Shopifys eigenem Protokoll.

Der Bericht hält ausserdem fest: Die Erweiterung baut auf einer früheren Vereinbarung zwischen Shopify und Meta auf, die Metas Muse-Agenten im Namen eines Nutzers einkaufen liess. Und sie öffnet den Katalog für Agenten von Drittanbietern. Die Zahl, die dabei durchgehend genannt wird, liegt bei mehr als einer Milliarde Produkteinträge. Eine solche Öffnung ist keine Produktfunktion, sondern eine Architekturentscheidung mit Folgen für Sichtbarkeit, Preisgestaltung und Datenqualität. Wer Produkte verkauft, sollte deshalb nicht nur auf Reichweite schauen, sondern darauf, wie lesbar sein Sortiment für Maschinen ist.

Der Satz in Shopifys eigener Anleitung

Shopify hat die Grenze nicht nur in Ankündigungen gezogen, sondern in der technischen Anleitung für seine Storefronts. Dort steht in Grossbuchstaben: Checkouts sind für Menschen, und eine Zahlung oder Bestellung darf nicht automatisch abgeschlossen werden, ohne einen ausdrücklichen, zeitgleichen menschlichen Freigabeschritt. Dieselbe Regel hat Forkast schon in seiner eigenen Übersicht zu agentischen Checkout-Pfaden angeführt. Sie ist präzise formuliert und lässt wenig Spielraum.

Interessant ist, was dieser Satz tut und was nicht. Er regelt, welcher Nachweis für eine Zustimmung vorliegen muss. Er bewegt kein Geld und verteilt keine Haftung. Die Händler bleiben Merchant of Record, und in den Bedingungen ist kein anderer Zahler benannt als der Händler selbst. Die Grenze steht im technischen Ablauf, während die Rechnung weiterhin beim Verkäufer landet. Deshalb liegt die Freigabe beim Käufer und nicht beim Agentenanbieter.

93 Prozent wollen die Haftung beim Anbieter, 28 Prozent öffnen das ganze Sortiment

Dazu passen die Zahlen, die PYMNTS Intelligence in derselben Aufzeichnung liefert. 93 Prozent der Händler finden, dass KI- oder Agentenanbieter den Verlust tragen sollten, wenn ein Agent falsch einkauft. Nur 28 Prozent sind bereit, Agenten ihr vollständiges Produktsortiment anzubieten. Die Bereitschaft, Verantwortung abzugeben, ist also deutlich grösser als die Bereitschaft, Kontrolle abzugeben. Nur gut ein Viertel der Händler gibt Agenten das volle Sortiment frei; die übrigen zeigen vorerst nur einen Teil.

Diese beiden Werte erklären, warum der breite Eingang und der schmale Schalter zusammengehören. Ein Händler, der einem fremden Agenten nicht vertraut, öffnet ihm trotzdem den Zugang, weil die Reichweite verlockend ist. Er tut es aber mit Regeln, mit einer Teilmenge seines Sortiments und mit dem Wissen, dass die letzte Entscheidung beim Käufer liegt. Der Stempel am Schalter ist damit nicht nur Käufervorsicht, sondern auch eine Händlerversicherung gegen schlecht vorbereitete Käufe.

Was das konkret bedeutet

Für Händler heisst das zunächst: Der Katalog wird zum Produkt. Wer in einem Agenten gefunden werden will, muss Attribute, Verfügbarkeiten und Versandbedingungen so pflegen, dass eine Maschine sie lesen und gegen Regeln prüfen kann. Ein unklarer Lieferzeitraum ist dann nicht mehr nur ein Ärgernis für Menschen, sondern ein Ausschlusskriterium, weil der Agent die Vorgabe nur schneller Versand sonst nicht erfüllen kann.

Für Käufer verschiebt sich die Arbeit vom Suchen zum Regeln. Budgetgrenzen, Versandvorgaben, Markenpräferenzen – das wird die eigentliche Bedienoberfläche. Der Klick am Ende bleibt, aber er ist nicht mehr der schwierige Teil. Der schwierige Teil ist die Frage, was man vorher erlaubt hat, und wie gut man die Folgen davon abschätzen kann.

Offen bleibt genau der Punkt, der schon in Forkasts früherer Analyse zu den vier Geldmodellen hinter dem Agenten-Wettlauf offen blieb: Was passiert, wenn der Kauf trotz Regeln und Freigabe falsch läuft? Solange diese Frage nicht vertraglich beantwortet ist, bleibt jede Öffnung auf Widerruf. Shopify weitet den Eingang, Meta und OpenAI liefern die Kanäle, und die Händler tragen weiter das Verkaufsrisiko. Der Marktbogen ist breiter geworden. Der Schalter im Inneren steht noch, und im Moment ist er das Einzige, was den Verkehr zwischen Katalog und Kasse regelbar hält.

Quelle: forkast.news

ChatGPT sendet seit dem Release von GPT-6 offenbar keine UTM-Parameter mehr mit. Die Oberfläche öffnet Links offenbar ohne den Zusatz ?utm_source=chatgpt.com und ohne Referrer. Der Klick kommt an, die Herkunft nicht.

Für alle, die Webanalyse betreiben, ist das kein Detail. Man kann sich das wie eine Paketannahme vorstellen: Das Paket landet auf dem Tisch, nur der Absenderaufkleber fehlt. Dieser Aufkleber ist der UTM-Parameter. Fehlt zusätzlich der Referrer, bleibt nur eine Schublade übrig – Direct Traffic. Dort landet alles, was sich nicht mehr zuordnen lässt.

Der folgende Text beschreibt, was seit dem GPT-6-Release bekannt ist, was der Adobe-Mitarbeiter Cedric Huesler gemessen hat und was das für SEO, Reporting und Content-Planung bedeutet. Eines ist dabei klar: Die Klicks verschwinden nicht, nur ihre Beschriftung. Wie viel Modellierung dir deine Zahlen noch wert sind, musst du am Ende selbst entscheiden.

Von Juni bis Oktober: Wie OpenAI seine Link-Kennzeichnung wieder abgeschafft hat

Im Juni begann OpenAI, Links in ChatGPT-Ergebnissen mit UTM-Parametern zu versehen. In Google Analytics oder Adobe Analytics ließ sich der Traffic damals sauber dem Einstiegspunkt chatgpt.com zuordnen. Für viele Betreiber war das willkommen, weil sich damit zum ersten Mal halbwegs belastbar sagen ließ, welchen Anteil die KI-Oberfläche am eigenen Traffic hat.

Im Oktober ist diese Kennzeichnung offenbar wieder verschwunden. Der Zeitpunkt fällt mit der Veröffentlichung von GPT-6 zusammen, die rund eine Woche vor den ersten Berichten lag. Ob das eine bewusste Entscheidung war, lässt sich von außen nicht belegen. Die Quelle der Beobachtung formuliert es selbst vorsichtig: Man sei sich nicht sicher, ob es direkt beabsichtigt gewesen sei.

Aufgefallen ist es zuerst Praktikern. Cedric Huesler von Adobe schrieb auf LinkedIn, GPT-6 öffne Links mit window.open und den Flags noopener und noreferrer und lasse den UTM-Zusatz dabei fallen. Kein Tag, kein Referrer – die Analyse verbucht den Besuch als direkt. Weitere Beobachter, unter anderem Chee Lo, berichteten Ähnliches, und die Diskussion dazu läuft unter anderem auf LinkedIn.

Kein Tag, kein Referrer: Was window.open mit noopener und noreferrer technisch bedeutet

Warum ein fehlender Parameter so viel verändert, zeigt ein kurzer Blick auf den Weg eines Klicks. Öffnet ChatGPT einen Link, tut es das über eine JavaScript-Funktion namens window.open. Die beiden Flags noopener und noreferrer sind keine Marotte, sondern haben einen Sicherheits- und Datenschutzhintergrund. noopener verhindert, dass die neue Seite über das Objekt window.opener auf die Ursprungsseite zugreifen kann. noreferrer unterdrückt zusätzlich die Übermittlung der Herkunftsadresse.

Unterm Strich reist der Klick ohne Angaben zum Absender. Der Referrer-Header bleibt leer, der UTM-Parameter fehlt ohnehin. Eine Analyse-Software hat dann zwei Möglichkeiten: Sie greift auf die letzte bekannte Quelle zurück, was bei einem Neustart der Sitzung nichts bringt, oder sie fällt auf die Standardkategorie zurück. Diese Standardkategorie heißt in praktisch jedem Tool Direct Traffic.

Historisch bedeutete direct, dass jemand die Adresse von Hand eingetippt oder ein Lesezeichen benutzt hat. Diese Bedeutung ist längst verschwommen. Heute ist Direct Traffic eine Sammelschublade für alles, was nicht zuordenbar ist: Klicks aus Messenger-Apps, aus E-Mails ohne Tracking, aus PDFs und eben aus KI-Oberflächen, die keine Signale mitsenden. Genau diese Schublade füllt sich gerade.

Rund 500 Seiten im Vergleich: Die Zahlen, die Huesler gemessen hat

Huesler hat es nicht bei Vermutungen belassen, sondern rund 500 Seiten ausgewertet, auf denen ChatGPT zuvor mindestens fünf Prozent der Besuche ausmachte. Verglichen wurde der Zeitraum vom 9. bis 13. Oktober mit der Woche davor. Das Ergebnis ist auffällig konsistent: Der ChatGPT-Traffic sank um etwa 31.000 Besuche pro Tag, während Direct Traffic auf denselben Seiten um rund 26.000 Besuche pro Tag stieg. Der Traffic aus Suchmaschinen veränderte sich um minus sieben Prozent – etwa so wie überall sonst auch.

Wichtiger als die absoluten Zahlen ist die Verteilung. Auf zwei von drei Seiten, die ChatGPT-Besuche verloren, stieg der Direct-Traffic. In der Woche davor war das noch ein Münzwurf, und der Suchtraffic auf diesen Seiten legte nur in 45 Prozent der Fälle zu. Das Muster hat sich also nicht graduell verschoben, sondern gedreht. Was fehlt, taucht an anderer Stelle auf – nur nicht unter dem richtigen Namen.

Daraus lässt sich keine Eins-zu-eins-Kausalität ableiten. Die 31.000 und die 26.000 liegen nahe beieinander, aber Messungen in dieser Größenordnung enthalten immer Rauschen: Saisonalität, einzelne sehr große Seiten, unterschiedliche Erfassung. Als Indiz ist die Differenz dennoch stark. Sie passt zu dem, was technisch zu erwarten wäre, wenn eine Quelle ihre Kennzeichnung verliert.

Warum die neuen Direct-Besucher wie ChatGPT-Besucher aussehen

Es gibt ein zweites Argument, das unabhängig von der Zählweise funktioniert. Huesler verglich das Verhalten der neu als direkt gezählten Besucher mit dem der bisherigen ChatGPT-Besucher. Auf Mobilgeräten stieg der Anteil derer, die den Consent-Banner sahen und neu auf der Seite waren, von 36 auf 44 Prozent. Bei den klassischen ChatGPT-Besuchern liegt dieser Wert bei 55 Prozent. Die neuen Direct-Besucher liegen also nicht bei den alten Direct-Werten, sondern bewegen sich auf die ChatGPT-Werte zu.

Das entkräftet die Deutung eines reinen Messproblems. Ein Messproblem würde nur die Zuordnung verändern, nicht das Verhalten. Consent-Raten, Geräteverteilung, Absprungpunkte und Einstiegsseiten sind dagegen Merkmale, die eine bestimmte Zielgruppe mitbringt. Wenn sich diese Merkmale verschieben, sind es sehr wahrscheinlich dieselben Menschen, die vorher unter einem anderen Etikett geführt wurden.

Für die Praxis heißt das: Der Traffic ist real, er ist nur nicht mehr benannt. Wer bisher auf das Label ChatGPT optimiert hat, optimiert weiter auf dieselben Besucher. Ein Blick auf Verweildauer, Absprungraten und Einstiegsmuster hilft dir dabei mehr als der Kanalname, der inzwischen nur noch wenig aussagt. Unschärfer geworden ist allein die Rückmeldung, ob die eigene Arbeit wirkt.

Was das für SEO, Reporting und Content-Planung bedeutet

Für SEO und Reporting ist das eine unangenehme Verschiebung, weil sie genau die Kennzahl trifft, die in den letzten zwei Jahren an Bedeutung gewonnen hat. Der Anteil der KI-Besucher lässt sich nicht mehr direkt aus dem Kanalbericht ablesen. Wird Direct Traffic insgesamt größer, verzerrt das auch Kennzahlen wie die Conversion Rate pro Kanal, weil zwei sehr unterschiedliche Gruppen in einen Topf fallen. Vergleiche zum Vorjahr werden dadurch schwer lesbar.

Hinzu kommt, dass die Lage nicht einheitlich ist. Andere Assistenten und Suchoberflächen senden weiterhin Referrer oder UTM-Parameter. Wenn ChatGPT schweigt, während andere Oberflächen weiterhin Referrer liefern, entsteht ein schiefes Bild: Der eine Kanal wirkt kleiner, als er ist, die anderen wirken relativ größer. Wer aus dem Kanalbericht Budgets ableitet, trifft Entscheidungen auf Basis eines Messartefakts.

Gegenmittel gibt es, aber sie sind Behelfe und keine Lösung. Du kannst die Consent-Rate und die Geräteverteilung als Näherung nutzen, weil sich darin die Signatur der KI-Besucher zeigt. Du kannst Landingpage-Muster prüfen, weil KI-Antworten häufig direkt auf tiefe Unterseiten verlinken. Du kannst Befragungen einsetzen und Nutzer selbst angeben lassen, wie sie auf die Seite gekommen sind. Und du kannst in den Server-Logs nachsehen, wobei dort ohne Referrer ebenfalls wenig steht. Der ehrlichste Schritt ist, den Tag der Umstellung zu dokumentieren und die Kanaldefinitionen ab diesem Punkt nicht mehr mit den alten Zahlen zu vergleichen.

Einordnung: Wie du deine Zahlen jetzt liest

Was bleibt: Ein großer Teil des KI-Traffics ist für die Standardanalyse unsichtbar geworden. Ob OpenAI das beabsichtigt hat, ist offen. Datenschutzargumente ließen sich anführen, ebenso das Interesse, die eigene Rolle als Vermittler nicht auf jeder Website sichtbar zu machen. Belegen lässt sich beides nicht.

Für Betreiber heißt das, sich von der Vorstellung zu verabschieden, jeder Besuch habe eine saubere Quittung. Wenn du weiterhin wissen willst, was KI-Oberflächen dir bringen, brauchst du mehrere schwache Signale statt einer starken Kennzahl: Verhaltensmuster, Consent-Raten, Direktzugriffe auf Unterseiten, Markensuchen. Das ist aufwendiger und unsicherer, aber es ist der Zustand, mit dem du jetzt arbeiten musst.

Beobachte deine Zahlen in den kommenden Wochen ruhig, statt sie sofort umzudeuten. Ein Sprung im Direct-Traffic ist kein Grund, die gesamte Messstrategie umzubauen. Er ist ein Grund, die Interpretation dieses Kanals zu überdenken und in Kauf zu nehmen, dass manche Antwort künftig lautet: wissen wir nicht genau.

Quelle: seroundtable.com

Vierzehn Monate nach dem Beginn eines Umbaus seiner KI-Abteilung hat Meta am 12. Oktober Muse Wonder und Muse Wonder Full vorgestellt, nach eigener Darstellung die bislang fähigsten Modelle des Konzerns für persönliche und berufliche agentische Aufgaben. Die Beispiele, die Meta in seiner Ankündigung nennt, sind bewusst alltäglich: einen Versicherungsfall abwickeln, einen Mietvertrag verstehen, eine funktionierende App bauen. Dafür sollen die Agenten den Zusammenhang über Gespräche hinweg behalten, bei Hindernissen andere Wege probieren und vor wichtigen Schritten nachfragen. Dieser Beitrag stützt sich auf den Bericht von TestingCatalog, dessen Autorenzeile einen KI-Agenten ausweist, und auf Metas eigene Ankündigung.

Zwei Modelle, zwei Zugangswege

Muse Wonder ist ab sofort über die Meta Model API und über Muse Code verfügbar. Muse Wonder Full bleibt den Abonnenten von Muse Code vorbehalten. Das Standardmodell soll später auch in Muse ankommen, zunächst ebenfalls für Abonnenten, und dort Aufgaben übernehmen, die mehr Intelligenz verlangen, etwa die Erzeugung von Artefakten. Meta trennt die Varianten also über den Zugang: einmal offen für Entwickler, einmal gebündelt in einem Abonnement.

Für Entwickler ist Muse Wonder damit sofort über die Meta Model API nutzbar; wer die stärkere Variante Full will, braucht ein Muse-Code-Abonnement. In der Muse-App selbst kommt das Modell zuerst bei Abonnenten an. Für Leser in Deutschland ist das vorerst Theorie: Die Muse-App ist laut Notebookcheck bisher nur in den USA und Kanada erhältlich, und eine Länderliste für die API nennt Meta in der Ankündigung nicht.

Active Memory und Active Focus als Bauprinzip

Die neue Familie kombiniert zwei Mechanismen: Active Memory und Active Focus. Active Memory trägt wichtigen persönlichen Kontext über Gespräche hinweg mit und holt Details hervor, wenn eine Aufgabe sie verlangt. Active Focus hält das Modell an schwierigen Zielen fest: Es probiert alternative Wege, umgeht Blockaden, passt sich neuen Informationen an, fragt nach, wenn etwas unklar ist, und prüft, bevor es etwas Wichtiges tut.

Man kann sich das wie einen gut organisierten Handwerker vorstellen. Der Aktenschrank im Rücken ist das Gedächtnis: Er enthält die Unterlagen, und der Handwerker zieht genau die Akte, die zur aktuellen Arbeit passt, nicht den ganzen Ordner. Die Ausdauer ist der Umgang mit der klemmenden Schraube. Ein unerfahrener Helfer ruft nach zehn Minuten den Chef. Ein erfahrener dreht die Schraube anders an, wechselt das Werkzeug und sagt erst dann Bescheid, wenn wirklich eine Entscheidung nötig ist. Genau diese zweite Fähigkeit stellt Meta mit Active Focus in den Vordergrund.

Im Alltag heißt das: Ein Agent, der sich an frühere Vorgaben erinnert und bei einem langen Vorhaben dranbleibt, spart dir die ständige Nachbetreuung. Das ist der Unterschied zwischen einem Werkzeug, das auf einen Befehl wartet, und einem System, das einen Auftrag trägt.

Von kleinen Apps bis zu langen Softwareprojekten

Meta beschreibt die Coding-Fähigkeiten der Modelle als breit gefächert: von kleinen Anwendungen bis zu Softwareprojekten, die über längere Zeit laufen und wiederholtes Testen und Nachbessern erfordern. Daneben sollen die Modelle Domänenwissen auf juristische, finanzielle und medizinische Aufgaben anwenden können. Der Zuschnitt verbindet zwei Arbeitsweisen, die selten zusammen gedacht werden.

Ein Agent, der Code schreibt, muss Fehler erkennen und Korrekturschleifen durchlaufen. Ein Agent, der eine Vertragsklausel prüft oder eine Bilanz einordnet, muss vorsichtig sein und im Zweifel nachfragen. Verbunden sind beide über die Ausdauer: Beide Tätigkeiten bestehen aus vielen kleinen Schritten, bei denen ein früher Abbruch das Ergebnis wertlos macht. Ob die Modelle diese Ansprüche in der Praxis halten, lässt sich anhand der Ankündigung nicht beurteilen. Das zeigt sich erst in echten, unaufgeräumten Arbeitsabläufen.

Skalierung, Testzeit-Rechenleistung und erste Benchmarks

Trainiert wurden beide Modelle in Metas Prometheus-Rechenzentrum, das der Konzern in der Gigawatt-Klasse verortet. Sie bauen auf dem Skalierungsansatz auf, den Meta mit Muse Spark eingeführt hat. Interessanter als die Größe ist ein anderes Argument: Meta behauptet, dass Muse Wonder Full über die Aufgaben hinaus generalisiert, die im Post-Training betont wurden.

Der Beleg: Steigt die Testzeit-Rechenleistung, also das Budget, das ein Modell fürs Nachdenken über eine Antwort erhält, verbessert sich Muse Wonder Full auf unbekannten Aufgaben stärker, als der Trend von Muse Spark 1.3 erwarten ließe. Meta führt das auf ein größeres und stärkeres Basismodell zurück. Ein gutes Fundament lässt sich durch mehr Nachdenken besser nutzen als ein schmaleres. Bestätigt sich das, profitiert das Modell auch bei Aufgaben, die im Post-Training keine Rolle spielten, von mehr Rechenzeit.

Erste Zahlen von außen kommen von Artificial Analysis. Auf deren Intelligence Index v4.3 erreichen Muse Wonder und Muse Wonder Full bei maximalem Reasoning-Aufwand 52 und 56 Punkte; Muse Spark 1.3 lag bei 48, und zwischen beiden Veröffentlichungen lagen nur sechs Wochen. TestingCatalog meldet für Wonder Full zudem Platz zwei im Index, zwei Punkte hinter Claude Opus 5.5, und einen Spitzenwert von 79 Punkten auf DeepSWE. Meta selbst schreibt, die Modelle führten in Bewertungen zu persönlichen und beruflichen Agenten, Gedächtnis, ausdauernder Ausführung, Coding, Fachwissen, Umgang mit privaten Informationen und Missbrauchsresistenz – diese Auswertungen stammen allerdings vom Hersteller.

Private Daten, Sicherheit und Metas Weg zur „persönlichen Superintelligenz“

Der Anspruch reicht weiter als das nächste Produktupdate. Meta plant, Muse Wonder in Verbrauchererfahrungen einzusetzen und spezialisierte Modelle für Menschen zu entwickeln, die Muse nutzen. Der Konzern ordnet die Veröffentlichung als nächsten Schritt in Richtung persönliche Superintelligenz ein. Dieser Weg führt tiefer in private Daten: Nachrichten, Kalender, persönliche Dokumente.

Meta begegnet dem mit zwei Zusagen. Erstens soll Muse Wonder das bislang am besten ausgerichtete Modell des Unternehmens sein, am besten abgestimmt auf menschliche Vorgaben. Zweitens nennt Meta den Schutz vor Missbrauch in den Bereichen Chemie, Biologie, Radioaktivität, Nukleartechnik und Cyber als stärksten bisher, während fortgeschrittene Cyber-Fähigkeiten für defensive Arbeit erhalten bleiben sollen. Ein ausführlicherer Sicherheitsbericht soll folgen. Außerdem wurden die Modelle laut Meta darauf trainiert, private Informationen nicht ohne Erlaubnis weiterzugeben. Solche Selbstauskünfte sind ein Zwischenstand, kein Prüfsiegel; belastbar werden sie erst, wenn unabhängige Stellen die Ergebnisse nachprüfen können.

Konkret: Meta liefert mit Muse Wonder und Muse Wonder Full weniger ein neues Spielzeug als eine Infrastruktur für Agenten, die dauerhaft mitlaufen sollen. Gedächtnis und Ausdauer sind die Baustellen, die Meta in den Mittelpunkt stellt. Der Preis liegt im Zugang und im Vertrauen: Ein persönlicher Agent dieser Art braucht Zugriff auf Nachrichten, Kalender und Dokumente, und wer sie einsetzt, muss entscheiden, wie viel Privatsphäre er gegen Bequemlichkeit tauscht. Diese Entscheidung nimmt dir kein Modell ab, egal wie gut es sich an frühere Gespräche erinnert.

Quelle: testingcatalog.com

Apache Iceberg 1.12.0 ist erschienen. Das Projektmanagement-Komitee des offenen Tabellenformats hat den Release am 5. Oktober im Projektblog vorgestellt: 777 Commits von 142 Mitwirkenden seit Version 1.11.0. Iceberg ist kein Programm, das man einmal installiert und dann vergisst, sondern eine Spezifikation samt Referenzimplementierung. Sie liegt zwischen den Dateien im Objektspeicher und den Abfrage-Engines darüber. Der Vergleich mit einem Bibliothekskatalog passt: Die Bücher stehen längst im Regal, aber erst der Zettelkasten sagt, welches Buch wo steht, welche Ausgabe gilt und was aussortiert wurde.

Release 1.12.0 arbeitet an mehreren Stellen dieses Zettelkastens gleichzeitig. Die wichtigsten Punkte: Die neueren Datentypen Variant und Geodaten werden alltagstauglicher, Flink bekommt eine Wartungsaufgabe für Löschungen aus Streaming-Pipelines, Spark ein neues Sortierverfahren, und die Spezifikation wächst um Leseschranken, die allerdings noch kein Leser umsetzt. Dazu kommen Sicherheitskorrekturen und eine Liste von Änderungen, die vor einem Upgrade gelesen werden sollten.

Variant und Geodaten: neue Datentypen werden alltagstauglicher

Variant ist der Datentyp für halbstrukturierte Daten, etwa JSON-artige Felder mit wechselndem Inhalt. Das Lesen von Variant-Daten, die nicht in eigene Spalten zerlegt sind, geht in Spark 4.0 und 4.1 jetzt schneller, weil es über den vektorisierten Parquet-Leser läuft statt Zeile für Zeile. Strenger wird das sogenannte Shredding, also das Zerlegen eines Variant-Felds in typisierte Spalten: Ein Feld wird nur noch dann zerlegt, wenn alle seine Werte zu einer einzigen Typfamilie gehören. Bisher genügte eine Mehrheit, sodass eine typisierte Spalte unter Umständen nur einen Bruchteil der Zeilen abdeckte. Jetzt deckt jede typisierte Spalte ihr Feld vollständig ab; gemischte Felder bleiben im untypisierten Rest.

Zerlegtes Variant schreiben konnte bisher nur Spark. Mit 1.12.0 können das auch Flink, die Kafka-Connect-Senke und der generische Record-Writer, sodass Daten aus diesen Wegen beim Lesen dieselben Filtervorteile bekommen. Dazu kommen Korrekturen bei Wertgrenzen für die Dateiauswahl, bei Dezimalzahlen mit mehr als 18 Stellen und beim Einlesen fehlerhafter Binärdaten.

Die Geodatentypen geometry und geography lassen sich jetzt lesen und schreiben, gespeichert als Well-Known Binary in Avro und Parquet. Spark 4.1 ist die erste Engine mit einem durchgehenden Weg: Sie liest und schreibt beide Typen und unterstützt DELETE, UPDATE und MERGE auf Tabellen mit Geodaten. Die Grenzen nennt das Projekt selbst: nur Spark 4.1, nicht Spark 3.5 oder 4.0, nicht Flink und nicht ORC; gelesen wird zeilenweise; räumliche Filter gibt es noch nicht.

Löschungen aus Streaming-Pipelines: Flink räumt einmal auf statt bei jeder Abfrage

Streaming-Pipelines, die Datensätze in Iceberg aktualisieren, schreiben sogenannte Equality Deletes. Das sind Markierungen der Art „entferne jede Zeile, deren Schlüssel diesen Werten entspricht“. Sie sind billig zu schreiben, aber teuer zu lesen, weil jede Abfrage Datendateien erneut öffnen und Werte vergleichen muss, um herauszufinden, welche Zeilen noch gelten.

Die neue Flink-Wartungsaufgabe ConvertEqualityDeletes löst diese Markierungen einmal auf und wandelt sie in positionsbasierte Deletion Vectors um, die neben den Datendateien festgeschrieben werden. Danach wenden Leser Löschungen über die Position an, statt Werte zu vergleichen. Die Aufgabe arbeitet mit dem IcebergSink zusammen, der neue Daten und Löschmarkierungen auf einem Quellzweig ablegt; der Konverter schreibt das Ergebnis auf den Zielzweig oder wandelt direkt um. Weil Deletion Vectors zum Tabellenformat Version 3 gehören, setzt die Aufgabe Version 3 voraus und läuft auf Flink 1.20, 2.1, 2.2 und 2.3. Eine Korrektur stellt sicher, dass gelöschte Zeilen nach einem fehlgeschlagenen Umwandlungslauf nicht wieder auftauchen.

Datenlayout und Leistung: Hilbert-Kurve neben Z-Order

Für Spark 4.1 bekommt die Prozedur rewrite_data_files ein neues Sortierverfahren: Hilbert-Clustering, zusätzlich zum bekannten Z-Order. Beide bilden mehrere Spalten auf eine einzige raumfüllende Kurve ab, damit Zeilen mit ähnlichen Werten nebeneinander gespeichert werden und Abfragen mit Filtern auf mehrere Spalten mehr Dateien überspringen können. Die Hilbert-Kurve vermeidet dabei die großen Sprünge durch den Wertebereich, die Z-Order macht. Ausgewählt wird sie über die Sortierreihenfolge, im Beispiel des Projekts mit sort_order => 'hilbert(c1, c2)'.

Daneben definiert der Release eine Schnittstelle RepairTable, mit der sich Statistiken in Manifesten reparieren lassen, die nicht mehr zu den beschriebenen Dateien passen. Für schnellere Planung werden Manifest-Listen jetzt zwischengespeichert, Parquet bekommt adaptiv bemessene Bloom-Filter und Wörterbuchkodierung pro Spalte. Der vektorisierte Parquet-Leser erhält eine Reihe von Korrekturen, darunter einen Absturz bei der Typerweiterung von int auf long und ein Speicherleck. Auch die Dateiauswahl wird genauer: Filter auf Zeitstempel mit Nanosekunden funktionieren in Parquet und ORC wieder, und notStartsWith überspringt keine Zeilengruppen mit Nullwerten mehr.

REST-Katalog und Spezifikation: Leseschranken vorerst nur auf dem Papier

Das REST-Katalogprotokoll kann Variant-Spalten jetzt in Schemas übertragen. Neu sind Endpunkte zum Auflisten und Laden von Funktionen, ein Endpunkt, der eine Tabelle aus einem Katalog austrägt, ohne Daten oder Metadaten zu löschen, eine formalisierte Konfiguration für entferntes Signieren und Labels für Katalog-Metadaten.

In der Spezifikation stehen zwei Neuerungen, die man genau lesen sollte. Erstens ist eine formale, engine-unabhängige Definition von Filterausdrücken übernommen. Zweitens kann ein Katalog beim Laden einer Tabelle künftig Leseschranken mitliefern: Spalten, die maskiert werden müssen, etwa nur die letzten vier Zeichen zeigen, auf null setzen oder hashen, und einen Zeilenfilter. Ein Leser, der das unterstützt, muss alle Vorgaben vollständig anwenden oder die Abfrage abbrechen. Das Projekt betont aber: Das ist bisher nur ein Vertrag in Spezifikation und Schnittstelle. Kein Iceberg-Leser wendet Leseschranken in 1.12.0 an, ein Katalog, der sie heute zurückgibt, wird von jedem Verbraucher stillschweigend ignoriert. Für Zugriffsschutz taugt die Funktion also noch nicht.

Auch am Tabellenformat Version 4 wird weitergearbeitet, aber nur als Fundament. Version 4 ist nicht verabschiedet, und Iceberg 1.12.0 kann V4-Tabellen weder lesen noch schreiben. Neu sind Leser und Schreiber für V4-Manifeste in Parquet und Avro, relative Pfade in Metadaten als Schritt zu verschiebbaren Tabellen und eine nur lesende Implementierung des komprimierten Bitmap-Formats Mumbling, das auf Roaring Bitmap aufbaut.

Sicherheit und Engines: Jackson-Lücken, neue Flink-Versionen

Der Release behebt zwei als hoch eingestufte Schwachstellen in jackson-databind, CVE-2026-54512 und CVE-2026-54513, indem die Jackson-Versionen über alle Laufzeiten und Pakete angeglichen werden; ein weiteres Update schließt GHSA-r7wm-3cxj-wff9. Drei Jackson-Befunde bleiben in der Kafka-Connect-Laufzeit bestehen, weil sie aus der in parquet-jackson eingebetteten Kopie stammen, die sich nicht unabhängig von Apache Parquet aktualisieren lässt.

Spark wird in den Versionen 3.5, 4.0 und 4.1 unterstützt, Spark 3.4 fällt weg. Neu sind unter anderem die Möglichkeit, DROP TABLE … PURGE an REST-Kataloge zu delegieren, eine tolerante Migration, die fehlende Dateien überspringen kann, und Manifest-Umschreibungen nach Sortierschlüssel. Wer Spark-Abfragen auf Iceberg zusätzlich beschleunigen will, findet einen anderen Ansatz in unserem Beitrag über DataFusion Comet und Iceberg Rust. Flink wird in den Versionen 1.20, 2.1, 2.2 und 2.3 unterstützt; 2.2 und 2.3 sind neu, 2.0 fällt weg. Flink kann außerdem Iceberg-Views lesen, anlegen, löschen und umbenennen. Die Kafka-Connect-Senke meldet Commit-Fehler jetzt, statt sie zu verschlucken, versucht vorübergehende Fehler begrenzt erneut und behandelt Offsets robuster.

Was vor dem Upgrade zu prüfen ist

Das Projekt bittet ausdrücklich darum, die inkompatiblen Änderungen vor einem Upgrade von 1.11.0 durchzugehen. Neben dem Wegfall von Spark 3.4 und Flink 2.0 betrifft das das Schreiben von Position-Delete-Dateien mit Zeilendaten, das entfernt wurde, passend zum Wechsel auf Deletion Vectors in Version 3. Entfernt wurden außerdem DataReader zugunsten von PlannedDataReader und eine Reihe von APIs, die bereits als veraltet markiert waren, etwa in den Spark-, AWS- und Kafka-Connect-Modulen.

Bei den Verhaltensänderungen ist eine für AWS-Nutzer wichtig: Der Standard-HTTP-Client des AWS SDK ist auf Apache HttpClient 5 umgestellt. Wer iceberg-aws direkt einbindet statt des Pakets iceberg-aws-bundle und seinen AWS-SDK-Klassenpfad selbst verwaltet, muss von software.amazon.awssdk:apache-client auf apache5-client wechseln. Außerdem wiederholt der REST-Client POST-Anfragen mit Idempotency-Key jetzt bei vorübergehenden Fehlern (408, 500, 502, 503, 504), und die Textdarstellung der Geodatentypen enthält das Koordinatensystem. Bei den Abhängigkeiten steigen unter anderem das AWS SDK auf 2.54.17, Jackson auf 2.22.2 und Netty auf 4.2.18.

Unterm Strich ist 1.12.0 kein Bruch, sondern ein breiter Pflegerelease mit einigen echten Neuerungen. Wer Streaming-Upserts mit Flink betreibt, bekommt mit der Umwandlung der Equality Deletes den spürbarsten Gewinn, setzt dafür aber Format Version 3 voraus. Wer Geodaten nutzen will, ist vorerst auf Spark 4.1 festgelegt. Und wer auf die neuen Leseschranken für Datenschutz hofft, muss warten, bis die Leser sie tatsächlich umsetzen. Die vollständige Liste der Änderungen steht in den Release Notes des Projekts.

Quelle: iceberg.apache.org