Kategorie: KI-News

„Today we released by far the largest update in the history of OpenClaw“, schreibt das OpenClaw-Team zum Start von Version 2.0. Das Release berührt praktisch jeden Bereich der Open-Source-Plattform – von der Installation über die Browser-App bis hin zu den Multiplayer-Funktionen.

933 Contributors haben mitgearbeitet, 569 davon zum ersten Mal. Zusammen brachten sie über 16.000 Pull Requests ein. Das Team spricht von der größten Aktualisierung in der Projektgeschichte. Wer OpenClaw nutzt, bekommt keine einzelnen Features, sondern eine überarbeitete Plattform.

OpenClaw 2.0 in Zahlen

Über 16.000 Pull Requests in einem Update sind ungewöhnlich. Die bisherige Release-Historie zeigt warum: Vor dieser Version erschienen in 230 Tagen 106 Releases – im Schnitt alle zwei Tage. Dann pausierte das Projekt fast sieben Wochen. Für ein so schnelles Team ist das lang.

Die Pause war kein Stillstand. Die Entwicklung beschleunigte sich sogar. Mehr Mitwirkende, mehr Aufgaben – die bisherige technische Basis stieß an ihre Grenzen. Deshalb überarbeitete das Team nicht nur die Plattform, sondern auch den Prozess, mit dem sie entsteht. Das Release enthält jetzt ungefähr die Hälfte aller jemals gemergten Pull Requests.

Große Updates bringen oft Fehler mit sich. Das Team testete deshalb gründlich, bevor es lieferte. Neue Nutzer und bestehende Claw-Installationen sollten ohne Brüche auf die neue Version wechseln können.

Warum die Pause vor dem Release lang war

Die lange Entwicklungszeit hat einen einfachen Grund: OpenClaw wuchs schneller, als die Infrastruktur verkraftete. Die hohe Arbeitsgeschwindigkeit überforderte die Grundlagen von OpenClaw und den internen Ablauf. Zwei Baustellen waren gleichzeitig offen.

Ein Release mit so vielen Änderungen muss auch Bestandsschutz bieten. Wer ein Claw-System betreibt, soll seine Konfigurationen und Workflows behalten. Das klingt selbstverständlich, ist bei einem Projekt dieser Größe aber schwer umzusetzen.

Die zusätzliche Zeit steckte das Team in die Migration für Bestandsnutzer. Neulinge sollten leichter einsteigen können. Hier setzt die nächste Änderung an.

Installation und Browser-App

OpenClaw hat die Installation vereinfacht. Das System erkennt, was bereits auf dem Rechner vorhanden ist, statt Nutzer mit langen Konfigurationslisten zu überfordern. Wer ChatGPT oder Claude nutzt, kann bestehende Abos oder API-Schlüssel direkt einbinden. Auch lokale Modelle werden erkannt.

Die Einrichtung ist kürzer: Viele Konfigurationsschritte fallen weg oder wandern aus dem Erstsetup. Du kannst direkt nach der Installation ein Gespräch führen. Weitere Einstellungen erledigst du im Chat mit deinem Claw.

Die Browser-App wurde komplett neu aufgebaut. Statt einer bloßen Web-Oberfläche gibt es jetzt einen Arbeitsbereich: Einstellungen nachholen, laufende Projekte zurückholen, dem Claw live zuschauen. Die meisten Menschen begegnen OpenClaw zuerst hier. Deshalb musste der Einstieg einfacher werden.

Der Effekt: Du erzielst schneller ein erstes Ergebnis. Ein Werkzeug, das du nicht verstehst, nutzt du nicht.

Vom einfachen Workflow zur Multiplayer-Umgebung

OpenClaw bleibt einfach, solange es möglich ist. Beispiel: Dein Claw überwacht dein E-Mail-Postfach auf Nachrichten von der Schule deiner Kinder und schickt dir eine Telegram-Nachricht, wenn Hausaufgaben anstehen oder ein Elterntag. Ein Postfach, ein paar Regeln, ein Zielort – mehr braucht es nicht.

Die Aufgabe kann wachsen, ohne dass die Bedienung komplizierter wird. Angenommen, dein Bruder schreibt dir eine iMessage und fragt, welches iPad ihr für euren Vater gekauft habt. Du kannst in den Mails suchen – oder deinem Claw sagen, dass dein Bruder geschrieben hat, und ihn bitten, die Antwort zu finden und zurückzuschicken. Der Claw erledigt das.

Das Team hat diesen Weg selbst erlebt. Beim Entwickeln von OpenClaw 2.0 setzten die Mitarbeiter ihre Claws für immer mehr Aufgaben ein. Irgendwann wollten sie Aufgaben teilen, gemeinsam bearbeiten oder übergeben. Das war bisher nicht möglich: Ein anderes Teammitglied ließ sich nicht einbinden, ohne dass der Claw sein Wissen verlor.

Shared Cloud Sessions schließen diese Lücke. OpenClaw wird damit zur Multiplayer-Umgebung. Das Team nutzt die Funktion inzwischen, um OpenClaw selbst zu entwickeln. Du kannst eine Person live in eine laufende Sitzung holen oder die Arbeit samt Kontext übergeben. Zusammenarbeit ist nicht an einen Rechner gebunden.

Das verändert die Vorstellung davon, was ein KI-Agent sein kann: nicht nur ein Werkzeug, das für dich arbeitet, sondern eine gemeinsame Arbeitsumgebung, in der Mensch und Maschine zusammenarbeiten – und auch mehrere Menschen.

OpenClaw 2.0 im Alltag

Dein OpenClaw startet mit einem einzigen nützlichen Workflow. Er kann so weit wachsen, wie du willst. Du verbindest ihn mit mehr Bereichen deines Lebens oder teilst ihn mit Familie und Team. Die Kontrolle darüber bleibt laut Ankündigung bei dir, nicht bei einem Anbieter.

OpenClaw steht unter einer Open-Source-Lizenz; das Team beschreibt das Projekt als eines, das den Menschen gehört, die es nutzen und weiterentwickeln. Du kannst es nicht nur verwenden, sondern mitgestalten. Gefällt dir etwas nicht, änderst du es oder weist das Projekt darauf hin.

Du entscheidest, welche Modelle und Dienste du einbindest – nicht eine Firma oder ein KI-Anbieter. OpenClaw 2.0 liefert den Rahmen: eine Installation, die schneller zum Ziel führt, eine Browser-App, die sich gut bedienen lässt, und Multiplayer-Funktionen für gemeinsames Arbeiten.

OpenClaw 2.0 ist ein umfangreiches Update. Die Plattform startet einfach und lässt sich beliebig ausbauen. Ob du allein arbeitest oder im Team – die Werkzeuge sind da. Was du daraus machst, liegt bei dir.

Quelle: openclaw.ai

584 Commits von 270 Beitragenden, 76 davon zum ersten Mal dabei. vLLM 0.28.0 ist kein Wartungs-Release. Das Projekt gleicht einer Werkstatt, in der an vielen Stellen gleichzeitig geschraubt wird – an Motor, Getriebe, Fahrwerk und Armaturenbrett. Genau das zeigt der Blick in die Release Notes.

Kimi K3: Optimierungen über den ganzen Stack

Ein Schwerpunkt liegt auf Kimi-K3, einem Modell, das ähnlich wie DeepSeek auf Mixture-of-Experts-Architekturen setzt. Solche Modelle verteilen die Rechenlast auf viele spezialisierte Experten. Das macht sie leistungsfähig, aber auch schwer beherrschbar. Die Optimierungen in vLLM 0.28.0 betreffen alle Schichten. Neu ist Decode Context Parallel (DCP), eine Technik, die das Dekodieren – also das Generieren neuer Tokens – parallel über mehrere Kontexte hinweg aufteilt. Dazu kommen zusammengeführte FlashKDA-Kernel für Dekodierung und Prefill. Prefill bezeichnet das Befüllen des Kontextfensters vor der eigentlichen Generierung. SiTU-Aktivierungen werden für MegaMoE unterstützt. GEMM-RS erweitert die Sequence Parallelism um eine effizientere Matrizenmultiplikation.

Laut Release Notes ergeben diese Arbeiten einen 1,5- bis 3-fachen Speedup auf Kernel-Ebene. Ein adaptives Budget für spekulative Tokens senkt die Time-to-First-Token (TTFT) im DSpark-Modus um rund 60 Prozent. TTFT ist die Zeit, bis das Modell das erste Zeichen einer Antwort liefert. Je kürzer, desto flüssiger wirkt die Anwendung. Optional lässt sich der Shared-Experte sharden. Das macht etwa 17 GiB GPU-Speicher pro Grafikprozessor frei. Außerdem läuft Kimi-K3 jetzt auf AMD-Hardware mit dem neuen Model Runner V2. Die Codebasis löst sich damit zunehmend vom CUDA-only-Image.

DeepSeek V4: Sparse MLA wird produktionstauglich

DeepSeek V4 nutzt Multi-Head Latent Attention (MLA), ein Verfahren, das den Aufmerksamkeitsmechanismus deutlich komprimiert. Die sparse Variante davon funktioniert in dieser Version durchgängig für reguläres Dekodieren, MTP (Multi-Token Prediction) und spekulative Dekodierung mit DSpark. MTP bedeutet, dass das Modell pro Schritt mehrere Tokens vorhersagt und anschließend verifiziert. Das erhöht den Durchsatz.

Hinzu kommen AMD-Quark-Unterstützung für NVFP4 – ein 4-Bit-Format mit spezieller Skalierung – sowie neue Reasoning-Effort-Prompts. Damit lässt sich steuern, wie viel ein Modell „nachdenkt“. Auf der Kernel-Seite wurden die Top-k-Metadaten weiter optimiert und die CUDA-Graph-Regionen für Eager-Mode enger gezogen. Das sind die Bereiche, in denen das Modell ohne Graph-Capture direkt ausgeführt wird. Auch AMD profitiert: DeepSeek V4 läuft jetzt auf den Grafik-Generationen gfx11 und gfx950, jeweils mit angepassten Optimierungen für die dort verfügbaren Sparse-MLA-Pfade.

Model Runner V2: Disaggregation wird ausgebaut

Der Model Runner V2 ist das neue Ausführungs-Backend von vLLM. Er orchestriert die einzelnen Komponenten eines Inferenz-Systems. In 0.28.0 unterstützt er E/P/D-Disaggregation, also die strikte Trennung von Encode-, Prefill- und Decode-Phase. Während des Prefills wird der Kontext einmal vorbereitet. Das eigentliche Generieren übernimmt der Decode-Schritt. Beide Phasen haben unterschiedliche Anforderungen an Rechenzeit und Speicher. Eine Trennung ist daher oft effizienter.

Neu sind außerdem Weight Offloading – das Auslagern von Modellgewichten auf langsamere Speicher, wenn sie gerade nicht gebraucht werden – sowie Multi-Layer-MTP-KV-Cache, Encoder-CUDA-Graphen und Decoder-Token-wise Pooling. Transformerbasierte Pooling-Modelle werden ebenfalls unterstützt. Dazu kommen Aufmerksamkeits-freie Modelle und das Konzept eines thinking_token_budget. Damit lässt sich der Denkaufwand eines Reasoning-Modells explizit begrenzen.

Spekulative Dekodierung: mehrere Wege zum schnelleren Token

Spekulative Dekodierung ist ein Verfahren, bei dem ein kleines, schnelles Entwurfsmodell mehrere Tokens vorschlägt. Das große Modell verifiziert sie anschließend in einem Schwung. vLLM 0.28.0 baut diese Idee konsequent aus. DFlash2 bringt eine lokale Faltung (Convolution) mit, die das Entwurfsmodell zusätzlich verfeinert, sowie einen Candidate Selector, der unter mehreren Vorschlägen auswählt. DSpark erhält eine Confidence-Scheduling-Stufe für die Verifikation. Das asynchrone Scheduling für Draft Models ist nun automatisch aktiviert.

Wer ein produktives System betreibt und bisher klassische autoregressive Generierung nutzte, kann die Tokens pro Sekunde oft verdoppeln, ohne die Modellqualität zu beeinträchtigen. Voraussetzung: Das Draft-Modell passt zur Aufgabe.

Tiered KV Cache Offloading: vom RAM zur SSD

Ein zweiter Schwerpunkt betrifft den KV-Cache. Das ist der Zwischenspeicher, in dem vLLM die Aufmerksamkeits-Zustände vergangener Tokens ablegt. In großen Deployments passt dieser Cache selten komplett in den GPU-Speicher. Die Lösung heißt Offloading: selten benötigte Teile wandern auf die CPU oder – neu in 0.28.0 – auf die Festplatte. Dafür gibt es jetzt Disk-Offloading für den SimpleCPUOffloadConnector, einen Hook für Out-of-Tree-Implementierungen und ein kanonisches CPU-Layout, das unabhängig vom Parallelismus funktioniert.

Ergänzend gibt es Metriken, mit denen sich das Tiering im Betrieb beobachten lässt. Außerdem lassen sich Ergebnisse aus dem Secondary-Tier teilweise laden, wenn nur ein Teil des Kontexts benötigt wird. Praktisch heißt das: Auch lange Konversationen mit hunderttausenden Tokens lassen sich wirtschaftlich bedienen, wenn man SSD-Speicher in Kauf nimmt.

Rust-Frontend, gRPC und neue Defaults

Im API- und Frontend-Bereich gibt es vor allem das Rust-Frontend. Es bringt einen eigenständigen Renderer mit, erlaubt multimodale Bildinferenz über gRPC und unterstützt explizites Routing für Data-Parallel-Ränge. Auch der Lebenszyklus für Reinforcement-Learning-Workflows lässt sich steuern. Die Protobuf-Schemas werden über Buf publiziert, was die Integration in andere Sprachen erleichtert.

Bei den Defaults gibt es drei spürbare Änderungen: max_num_batched_tokens steigt von 8192 auf 16384, also die maximale Anzahl Tokens, die pro Batch verarbeitet werden. Prefix Caching ist nun für Mamba-Modelle standardmäßig aktiv. Der Blackwell-CUDA-Graph-Capture-Bereich wächst auf 1024 Tokens. Wer bestehende Setups betreibt, sollte diese Änderungen berücksichtigen, da sie Speicherverbrauch und Verhalten bei kleinen Batches beeinflussen können.

Breaking Changes, neue Modelle und Lieferung

Mit 0.28.0 wandert bitsandbytes in ein Out-of-Tree-Plugin. Transformers wird auf 5.15.0 aktualisiert. Das veraltete calculate_kv_scales verschwindet, override_attention_dtype wird entfernt. Wer diese Pfade nutzt, muss vor dem Upgrade migrieren. Auf der Modellseite kommen unter anderem Muse Glimmer, Ling 3.0 Flash (mit BF16, MTP und Parser), Dots3 NOTE mit nativer multimodaler Unterstützung sowie Interns2mobius dazu. Qwen3.8 läuft jetzt auf AMD ROCm. Für Qwen3.5 GDN gibt es einen zusammengeführten CUDA-Post-Conv-MTP-Dekodierungskernel.

Geliefert wird vLLM 0.28.0 als Python-Wheel über PyPI und uv, mit eigenem ROCm-Index, sowie als Docker-Image für CUDA 12.9, CUDA 13.0 (Standard), ROCm, CPU und XPU. Hinzu kommen Tarballs und wheels für x86_64, arm64 und macOS.

Was das in der Praxis bedeutet

Für Betreiber großer Serving-Infrastrukturen ist 0.28.0 vor allem wegen der E/P/D-Disaggregation im Model Runner V2 interessant. Prefill- und Decode-Ressourcen lassen sich damit sauberer trennen und skalieren. Für Forschende zählt die breite Unterstützung von Kimi-K3 und DeepSeek V4, einschließlich AMD-ROCm und Intel XPU. Für Entwickler, die eigene Tools oder UIs bauen, wird das Rust-Frontend mit gRPC multimodal zunehmend attraktiv. Wer auf Stabilität setzt, sollte die Breaking Changes prüfen, bevor er upgradet.

Quelle: github.com

Ein lokal erzeugter Chatverlauf eines nicht-OpenAI-Providers wird nachträglich in eine Memory-Sitzung geladen und an einen OpenAI-Endpunkt übertragen. Das passiert nicht im Rahmen von Analytics oder Telemetrie, sondern als gewöhnlicher Modell-Inferenz-Request.

Dieser Vorgang ist als Codex Memory Exfiltration bekannt geworden. Der Sicherheitsforscher, der den Vorfall untersuchte, hat die Übertragung mit der offiziellen Windows-Binärdatei 0.150.0-alpha.12.2 in einer kontrollierten Umgebung nachvollzogen. Für dich heißt das: Wer Codex mit Memories nutzt, muss damit rechnen, dass Inhalte aus lokalen Provider-Sitzungen an OpenAI fließen – auch wenn alle Telemetrie- und Analyse-Features deaktiviert sind. Es ist ein Datenabfluss, der sich unterhalb des üblichen Datenschutz-Radars bewegt.

Der kontrollierte Beweis: Ein lokaler Chat landet bei OpenAI

Der Forscher nutzte eine isolierte Codex-Installation mit aktivierten Memories, aber deaktiviertem Analytics und allen OpenTelemetry-Exporten auf none. Als Quelle diente ein synthetischer Rollout mit eindeutigen Markern – sogenannten Canaries –, der mit dem Provider-Label synthetic_source gespeichert war. Nachdem ein OpenAI-gestützter Codex-Prozess die Memory-Erzeugung anstieß, sendete die Software eine 38.095 Byte große WebSocket-Nachricht an den Endpunkt chatgpt.com/backend-api/codex/responses.

Die Nachricht trug die Kennung request_kind = memory und bestand aus drei Top-Level-Elementen: einem Developer-Item für zusätzliche Tools, einer Memory-Instruktion und einer User-Nachricht, die den serialisierten Quell-Chat enthielt. In diesem User-Wrapper fanden sich 3.092 Byte des ursprünglichen Verlaufs. Die fünf übertragenen Quell-Elemente stimmten strukturell exakt mit dem gespeicherten Rollout überein: die Umgebungsdaten, die normale User-Nachricht, ein Tool-Call samt Argumenten, die Tool-Ausgabe mit Fehlertext und Pfaden sowie eine synthetische Assistant-Antwort.

OpenAI quittierte den Vorgang mit response.created und response.completed. Das antwortende Modell gpt-5.6-luna erzeugte eine 3.405 Zeichen lange Memory-Notiz, die die eindeutigen Canaries mehrfach reproduzierte. Damit war nicht nur ein Verbindungsversuch belegt, sondern eine echte Verarbeitung der übertragenen Inhalte. Die Antwort zeigt: Der Datenabfluss ist ein faktischer, kein bloß theoretischer Vorgang.

Warum die Provider-Grenze fällt: Drei Schritte im Quellcode

Der gemeldete Vorfall ist keine Panne einer einzelnen Version. Der Forscher verweist auf den getaggten Quellcode von Codex, der drei Stationen des Memory-Prozesses dokumentiert. In der ersten Stufe wählt der Memory-Job einen geeigneten früheren Rollout aus. Dabei prüft er Kriterien wie Memory-Modus, Alter, Idle-Zustand, Quelltyp und Claim-Status – aber nicht den Provider, unter dem der Rollout entstanden ist. Der entsprechende Aufruf übergibt für model_providers den Wert None.

In der zweiten Stufe erzeugt der Worker den Provider aus der aktuell aktiven Sitzung. Die Memory-Runtime liest config.model_provider und nutzt diesen Client für den späteren Request. In der dritten Stufe lädt Phase 1 den ausgewählten Rollout, filtert die zu behaltenden Elemente, packt sie in eine neue User-Nachricht und sendet sie über den Memory-Client. So entsteht die Kette: Ein lokaler Provider-Rollout wird durch eine spätere OpenAI-Sitzung ausgewählt und über deren Provider versendet.

Das ist die eigentliche ChatGPT Codex Sicherheitslücke. Die Auswahl der Quelle und der Ziel-Provider sind entkoppelt. Es gibt keine Bedingung, die einen unter einem lokalen Provider erzeugten Chat vor einer Übertragung an OpenAI schützt. Die einzige Hürde sind andere Ausschlusskriterien, die den spezifischen Rollout möglicherweise nicht für die Memory-Erzeugung freigeben. Genau darin steckt das providerübergreifende Datenleck: Die Erinnerung kennt keine Herkunftsbindung.

Welche Inhalte betroffen sind: Vom Chat bis zum Tool-Fehler

Die Filterlogik, die vor dem Senden angewendet wird, ist kein Geheimnis, aber sie ist überraschend weit gefasst. Übertragen werden können vollständige User- und Assistant-Nachrichten, Agent-Nachrichten, lokale Shell-Aufrufe, Funktionsaufrufe samt Ausgaben, Tool-Suchen, Web-Suchen, benutzerdefinierte Tool-Ausgaben und konvertierte Inter-Agent-Kommunikation. Ausgeschlossen sind Entwickler-Nachrichten, Reasoning-Aufzeichnungen, Kompaktierungen, einige generierte Medien oder Tool-Deklarationen und Buchhaltungsdatensätze.

Bei längeren Verläufen wird der Inhalt mittig gekürzt: auf 70 Prozent des effektiven Modellkontexts, mit einer Ausweichgrenze von 150.000 Token. Anfang und Ende bleiben erhalten. Für einen normalen kurzen Thread bedeutet das: Praktisch die gesamte Konversation, inklusive Tool-Aktivität, Umgebungspfaden und Fehlermeldungen, kann als Quellmaterial verwendet werden. Es geht also nicht um einzelne Zeilen, sondern um umfangreiche Verlaufsbestandteile.

Die vor dem Versand angewendete Schwärzung ist kein Datenschutz-Werkzeug. Der Filter erkennt klassische Muster wie sk- Schlüssel, AWS-Kennungen, lange Bearer-Tokens und Werte mit Namen wie api_key, token oder password. In einem Test entfernte er genau solche Muster. Er ließ jedoch untypische Schlüssel, cookie-ähnliche Werte, E-Mail-Adressen, Telefonnummern, private Header, vertrauliche Prosa, Windows-Pfade und die eigentlichen Inhalt-Canaries unangetastet. Wer hofft, dass eine Redaktion vor dem Transfer vertrauliche Details entfernt, wird enttäuscht.

Analytics aus, Telemetrie aus: Warum der Kanal trotzdem offen ist

Eine wichtige Eigenschaft dieses Vorfalls: Die Einstellungen, die man normalerweise für Datenschutz zuständig macht, greifen hier nicht. In der Testumgebung waren [analytics] enabled = false gesetzt und alle OpenTelemetry-Exporter auf none. Der Request wanderte trotzdem an OpenAI. Die Ursache ist die getrennte Verwaltung der Systeme. Analytics und Telemetrie sind separate Pfade; die Memory-Erzeugung ist ein eigener, funktional notwendiger Modell-Inferenz-Request.

Der einzige aktuelle Schalter, der diesen Kanal zuverlässig unterbricht, ist das Deaktivieren der Memories selbst: [features] memories = false. Es gibt keine Option, die Memories aktiv lässt und zugleich die Provider-Übergrenzung verbietet. Der Forscher betont, dass Nutzer nicht darauf kommen müssen, dass das Abschalten von Analytics und Telemetrie einen separaten Hintergrund-Request übrig lässt, der fremde Provider-Inhalte überträgt. Das ist eine Dokumentations- und Designschwäche – und aus Nutzersicht eine versteckte Datenübertragung. Wer das nicht riskieren will, muss die Memory-Funktion komplett abschalten.

So lässt sich der Vorfall kontrolliert nachstellen

Für die Reproduktion ist kein echter privater Chat nötig. Der Forscher beschreibt eine minimale Testumgebung: eine isolierte Codex-Home mit aktivierten Memories, deaktiviertem Analytics und deaktivierten OpenTelemetry-Exporten. Dazu kommt ein berechtigter früherer Rollout, dessen Provider-Label nicht OpenAI ist und dessen Nachrichten eindeutige synthetische Canaries enthalten. Dieser Rollout muss die Memory-Bedingungen erfüllen. Danach triggert eine OpenAI-gestützte Codex-Sitzung die Memory-Verarbeitung.

Ein lokaler TLS-Inspektionsproxy fängt den ausgehenden WebSocket-Request ab. Entscheidend sind die Felder request_kind = memory und die eingebetteten Elemente des Quell-Rollouts. Bestätigt wird der Vorgang, wenn die Server-Antwort die einzigartigen Canaries reproduziert. Der Forscher hat genau das getan und damit die Übertragung eindeutig belegt. Diese Vorgehensweise zeigt zugleich, wie sich der Abfluss sicher und ohne echte Nutzerdaten demonstrieren lässt.

Erwartetes Verhalten wäre aus seiner Sicht: Ein Rollout aus einem lokalen oder Drittanbieter-Provider darf nicht ohne ausdrückliche, zielbezogene Zustimmung an einen anderen Provider gesendet werden. Die Memory-Erzeugung sollte entweder den Provider der Quelle verwenden oder den Rollout überspringen, wenn dieser Provider nicht verfügbar ist. Falls die Funktion gewollt ist, müsste sie als Opt-in ausgeführt werden und vor dem Senden das Ziel sowie die betroffenen Inhaltsklassen nennen. Außerdem fordert er eine Quittung in der Benutzeroberfläche, die zeigt, welche Aufgabe verarbeitet wurde, welcher Anbieter sie empfangen hat und wann das geschah.

Einordnung: Daten, die niemals hätten fließen dürfen

Der Bericht endet mit einer klaren Bewertung: Es handele sich um Datenexfiltration im üblichen Sinne – private Daten wurden ohne informierte Autorisierung aus der gewählten Provider-Grenze an einen entfernten Empfänger übertragen. Ob das Ergebnis eines Bugs oder einer bewussten Entscheidung ist, ändere nichts an der Grenzüberschreitung. Der Forscher verbindet den Vorfall zudem mit einer OpenAI-Kontowarnung wegen „Cyber Abuse“, die in keinem Zusammenhang mit den an OpenAI gerichteten Chats gestanden habe. Die entsprechenden Inhalte seien nur in einem bewusst an einen lokalen Provider gerichteten Verlauf vorhanden gewesen.

Daraus leitet er ab, dass OpenAI möglicherweise Konten auf Basis von Inhalten bewertet hat, die es rechtlich nicht hätte erhalten dürfen. Er zieht einen drastischen Vergleich: Das sei, als öffne jemand ohne Erlaubnis die Schlafzimmertür, missbillige das Gesehene und bestrafe die Person dafür. Die Metapher ist bewusst überspitzt, macht aber pointiert klar, worum es geht: eine nicht autorisierte Informationsübertragung mit potenziellen Folgen für das Nutzerkonto.

Solange keine offizielle Antwort vorliegt, bleibt die Lage angespannt. Der Forscher fordert OpenAI auf, alle zugehörigen Dokumente, Logs und Moderationsaktionen aufzubewahren, den Umfang der Übertragung offenzulegen, betroffene Nutzer zu informieren und negative Kontoentscheidungen zu überprüfen. Ein stilles Reparieren der Provider-Auswahl wäre unzureichend. Für Nutzer von Codex mit Memories bedeutet das: Es ist an der Zeit, die eigene Konfiguration zu überdenken, bis die Hersteller klare Antworten liefern. Bis dahin ist das Abschalten der Memory-Funktion die einzige wirksame Kontrolle – und ein deutlicher Hinweis, dass die Trennung der Provider-Grenzen noch nicht zu den selbstverständlichen Sicherheitsmerkmalen gehört.

Quelle: github.com

Viele halten die Parameterzahl für den entscheidenden Maßstab bei Sprachmodellen. Dabei übersehen sie, was Tencents Hy4 Preview wirklich ausmacht: die Kontrolle über den Denkprozess und ein riesiges Kontextfenster.

Große KI-Labore veröffentlichen Modelle mit immer mehr Parametern und längeren Kontexten. Tencent folgt dem mit Hy4 Preview – aber mit einer Besonderheit. Das Ende August 2026 vorgestellte Modell bietet eine einfache Steuerung für das Reasoning. Genau das macht Hy4 für Entwickler und Tech-Entscheider interessant, nicht die bloße Zahlenspielerei.

Der Größenwandel: Hy4 im Vergleich zu Hy3

Der Vorgänger Hy3 kam im Juli 2026 auf 295 Milliarden Gesamtparameter, davon 21 Milliarden aktive pro Inferenz. Hy4 Preview hat 770 Milliarden Gesamtparameter, 49 Milliarden davon aktiv. Das ist eine Steigerung um den Faktor 2,6 beziehungsweise 2,3.

Die Zahlen folgen dem Prinzip der Mixture-of-Experts-Architektur. Statt bei jedem Token das gesamte Netzwerk zu durchlaufen, werden nur spezialisierte Untermodelle aktiviert. Das macht den Betrieb effizienter, erhöht aber die Modellgröße. Die Gewichte von Hy4 belegen auf Hugging Face rund 1,56 Terabyte. Zum Vergleich: Hy3 benötigte 598 Gigabyte. Wer das Modell lokal betreiben will, braucht leistungsfähige GPUs und ein verlässliches Storage-Konzept.

Der Blogpost, der das Modell vorstellt, wertet die Zahlen als Beleg, dass Tencent den Weg zu sehr großen Open-Weight-Modellen weitergeht. Die Gewichte sind öffentlich, das Modell ist auf Text beschränkt – Vision ist in dieser Preview nicht enthalten. Das schränkt den Einsatzbereich ein, fokussiert die Rechenleistung aber auf Textaufgaben.

1M Token Kontextfenster: Mehr als nur eine Zahl

Das Kontextfenster von Hy4 umfasst eine Million Token. Das ist grob die anderthalbfache Textmenge von Tolstois „Krieg und Frieden“ – in einem einzigen Durchgang. Praktisch heißt das: Du kannst dem Modell ganze Codebasen, umfangreiche Verträge oder Doku-Sammlungen vorlegen, ohne sie vorab zu zerkleinern.

Ein so langer Kontext hat seinen Preis. Je mehr Token das Modell verarbeiten muss, desto höher die Rechenlast und desto größer die Gefahr, dass es wichtigen Kontext übersieht. Tencent begegnet dem mit einer Architektur, die trotz der 1M-Token-Größe nur 49 Milliarden aktive Parameter nutzt. So bleibt die Latenz für interaktive Anwendungen brauchbar.

Der Vergleich zu Hy3 ist aufschlussreich: Dessen Kontextfenster umfasste 256.000 Token. Die Vervierfachung ist kein kosmetisches Update. Sie ermöglicht Aufgaben, die bisher speziellen Lösungen vorbehalten waren – etwa eine juristische Recherche über hunderte Urteile oder der Abgleich mehrerer Romanmanuskripte. Für Hy4 ist das Alltag.

Reasoning an oder aus: Die chat_template-Datei als Signatur

Wer Modelle auf Hugging Face untersucht, stößt oft auf Details, die in Marketingmaterialien fehlen. Der Autor des Originalartikels hat sich die Datei chat_template.jinja von Hy4 angesehen. Diese Datei legt fest, wie die Kommunikation zwischen Benutzer und Modell formatiert wird. Sie zeigt: Es gibt nur zwei gültige Werte für reasoning_effort: high und no_think. Der Standardwert ist high.

Das bedeutet: Du entscheidest, ob das Modell vor der Antwort eine interne Denkschleife durchläuft. Setzt du no_think, antwortet es direkt. Das hilft bei einfachen Formatierungen oder kurzen Faktenfragen. Im Modus high denkt das Modell ausführlich nach, prüft Optionen und gibt eine durchdachte Antwort – auf Kosten der Latenz.

Damit unterscheidet sich Hy4 von anderen Reasoning-Modellen, die oft drei oder mehr Abstufungen anbieten. Tencent setzt auf eine einfache Dichotomie. Das ist kein Nachteil: Eine Zweifach-Option ist leichter zu verstehen und zu konfigurieren. Eine fehlerhafte Angabe im Chat-Template wirft eine Exception – das Modell ist streng bei der Eingabe. Unerfahrene Benutzer könnten sich daran stoßen, für automatische Aufrufe ist es aber genau richtig, weil es stille Fehler vermeidet.

Ein Praxistest: SVG-Prompt und die Spuren des Denkens

Wie sieht das Reasoning im Modus high aus? Der Autor des Blogposts hat einen Prompt verwendet, der in der KI-Community für Tests beliebt ist: „Generate an SVG of a pelican riding a bicycle“. SVG steht für Scalable Vector Graphics, ein Grafikformat, das sich per Text beschreiben lässt. Das Modell sollte also keine Bilddatei ausgeben, sondern den Code für eine Zeichnung eines Pelikans auf einem Fahrrad.

Das Ergebnis ist eine präzise, farblich detaillierte Bildbeschreibung im Flat-Cartoon-Stil. Interessant wird es beim Reasoning-Trace, den das Modell während der Verarbeitung erzeugt. Der Autor zitiert daraus:

„Vielleicht einen Helm hinzufügen? Könnte das Radfahrthema verbessern, aber den Kopf verdecken. Vielleicht eine kleine Radkappe oder Helm? Der Nutzer hat nicht darum gebeten; roter Helm hinzufügbar? Könnte niedlich sein. Aber Pelikan mit großem Schnabel; ein Helm könnte verdecken. Besser vielleicht nicht. Vielleicht eine Sonnenbrille? nein. Vielleicht Wasser? nein.“

Die Gedankenschleife zeigt, wie das Modell im Modus high Ergänzungen durchspielt, verwirft und sich auf das Wesentliche konzentriert. Auffällig ist die verknappte Sprache im Reasoning-Trace. Der Autor merkt an, dass das Modell offenbar bewusst auf vollständige Grammatik verzichtet, weil perfekt formulierte Gedanken unnötig Token verbrauchen würden. Das Modell spart beim Denken Klartext ein, um schneller zur Lösung zu kommen.

Für dich als Anwender heißt das: Du bekommst nicht nur das Endergebnis, sondern kannst bei einem Open-Weight-Modell auch den Denkprozess nachvollziehen. Das unterscheidet Hy4 von reinen API-Modellen, die solche Traces nicht offenlegen. Der Trace ist sicherlich nicht vollständig und zeigt nur einen Ausschnitt der internen Verarbeitung.

Warum Open-Weight-Modelle wie Hy4 die Landschaft verändern

Die offenen Gewichte machen den Unterschied. Mit Hy4 Preview kannst du das Modell nicht nur über eine API nutzen, sondern auch selbst hosten, auf eigene Daten anpassen oder in bestehende Systeme integrieren. Das ist für Unternehmen interessant, die datenschutzkritische Prozesse nicht an externe Anbieter geben wollen.

Die Herausforderungen sind nicht zu unterschätzen. 1,56 Terabyte Gewichte müssen erst geladen sein. Selbst mit einer schnellen Internetverbindung dauert das Stunden. Für Feintuning-Varianten sind die Anforderungen an Speicher und Rechenleistung noch höher. Trotzdem zeigt der Schritt von Tencent: Auch ein chinesisches Unternehmen will am Open-Source-Ökosystem teilhaben.

Hy4 liefert einen Beleg dafür, dass Parameterzahl und Kontextfenster nicht automatisch für bessere Leistung stehen. Entscheidend ist die Kombination aus Architektur, Reasoning-Steuerung und praktischer Verfügbarkeit. Wer das Modell testet, merkt: Die 770B-Parameter sind nicht nur Marketing. In komplexen Szenarien liefert es solide Ergebnisse – wenn das Reasoning eingeschaltet ist.

Tencents Hy4 Preview ist ein beachtlicher Fortschritt, keine Revolution. Die Open-Weight-Community erhält ein weiteres Werkzeug für lange Texte und anspruchsvolle Reasoning-Aufgaben. Die eigentliche Arbeit beginnt für die meisten Entwickler erst nach dem Download: Sie müssen die 1,56 Terabyte Daten und das 1M-Token-Kontextfenster in sinnvolle Produkte übersetzen. Das nimmt ihnen kein Modell ab.

Quelle: simonwillison.net

„We cannot be confident that SpaceX will use our technology within our terms of service“ – mit diesem Satz hat OpenAI am 29. August 2026 eine Entscheidung begründet, die in der KI-Branche für Aufsehen sorgt. Der Satz spricht nicht von einem technischen Problem, sondern von einem Vertrauensverlust. OpenAI will den Vertrag mit Cursor beenden, jenem Coding-Startup, das Mitte August 2026 von Elon Musks SpaceX für 60 Milliarden Dollar übernommen wurde. Geplant ist eine Abschaltung der OpenAI-Modelle in Cursor zum 12. November 2026. Wer Cursor als KI-gestützten Programmier-Assistenten nutzt, sollte die Entwicklung im Auge behalten.

Eine lange Partnerschaft zerbricht

Cursor war nicht irgendein Kunde. Das Unternehmen gehörte zu den ersten Nutzern von OpenAI-Modellen und hat jahrelang eng mit dem KI-Pionier zusammengearbeitet. Cursor-CEO Michael Truell beschrieb die Beziehung kurz darauf auf X selbst als eng: Man habe OpenAIs Plattform als neutrale Infrastruktur für das eigene Geschäft betrachtet. Mit der Übernahme durch SpaceX ist diese Neutralität Geschichte. OpenAI sieht sich offenbar nicht mehr in der Lage, sicherzustellen, dass die Modelle unter den eigenen Nutzungsbedingungen verwendet werden. Deshalb kündigt OpenAI nicht nur den bestehenden Vertrag, sondern will auch künftig keine neuen Modelle mehr an Cursor liefern.

Das ist eine Zäsur, zumal Cursor zu den erfolgreichsten KI-Coding-Tools gehört. Der Hype um „Vibe Coding“ – also das Programmieren mit KI-Unterstützung auf hohem Abstraktionsniveau – hat den Markt in den vergangenen Jahren stark wachsen lassen. Genau in diesem Markt will OpenAI künftig selbst eine größere Rolle spielen, denn das Unternehmen plant eigenen Angaben zufolge im nächsten Jahr an die Börse zu gehen. Da passt es ins Bild, dass OpenAI einen wichtigen Vertriebskanal nicht einem erbitterten Gegner überlassen will. Man kann sich das wie einen Zulieferer vorstellen, der entdeckt, dass sein bester Kunde plötzlich vom Konkurrenten gekauft wurde. Dann fragt man sich, ob die eigene Technologie am Ende gegen einen verwendet wird.

Der Streit zwischen Altman und Musk lässt sich nicht entkoppeln

Die Entscheidung von OpenAI ist ohne die persönliche Fehde zwischen Sam Altman und Elon Musk kaum zu verstehen. Musk hat OpenAI 2015 mitgegründet und die Forschungslabors als Non-Profit-Organisation mitfinanziert. 2018 verließ er den Vorstand, nachdem es unter anderem um die strategische Ausrichtung und die Abwerbung von Talenten zu Konflikten gekommen war. Seither ist er einer der schärfsten Kritiker des Unternehmens. Er hat OpenAI, Altman und Greg Brockman 2024 verklagt und ihnen vorgeworfen, eine „offene Non-Profit-Organisation gestohlen“ zu haben. Das Gericht wies die Klage zwar ab, doch Musk hat bereits angekündigt, in Berufung zu gehen.

Der Konflikt ist keine juristische Randnotiz, sondern begleitet beide Unternehmen seit Jahren. SpaceX hat im Februar 2026 X und xAI übernommen, bevor das Raumfahrtunternehmen im Juni selbst an die Börse ging. Damit bündelt Musk mehrere Tech-Bausteine unter einem Dach. Genau das könnte OpenAI zu der Einschätzung gebracht haben, dass SpaceX nicht vertrauenswürdig ist. In der offiziellen Mitteilung heißt es, man habe aufgrund „Erfahrungen mit den Firmen von Elon Musk, die Verträge verletzen“ keine ausreichende Sicherheit. Musk reagierte auf X mit gewohnter Schärfe: Er bezeichnete Altman und Brockman als „zutiefst unzuverlässig“ und wiederholte den Vorwurf, sie hätten eine Open-Source-Non-Profit-Organisation gestohlen. Hier geht es nicht um sachliche Vertragsdetails, sondern um jahrelange persönliche Animositäten.

Cursor-CEO Truell zeigt sich gelassen – aber die Unsicherheit bleibt

Michael Truell, CEO von Cursor, hat auf die Ankündigung verhältnismäßig ruhig reagiert. Er betonte, dass OpenAI-Modelle nur etwa fünf Prozent des gesamten Cursor-Traffics ausmachen. Das klingt nach einer Entwarnung, ist aber im Kontext zu sehen. Fünf Prozent sind für ein Unternehmen in dieser Größenordnung kein existenzielles Problem, aber sie sind nicht nichts. Truell sagte, man spreche mit dem OpenAI-Team, um die Lage zu lösen. Zugleich machte er klar, dass Cursor jahrelang eng mit OpenAI zusammengearbeitet habe und man die Plattform als neutrale Infrastruktur betrachtet habe. Diese Neutralität ist offenbar dahin.

Für Nutzer bedeutet das zunächst: Cursor lässt sich weiterhin verwenden, aber möglicherweise nicht mehr mit den gewohnten OpenAI-Modellen. Der geplante Stichtag ist der 12. November 2026. Bis dahin will OpenAI den Zugang schrittweise herunterfahren. Die Frage ist, welche Alternativen Cursor anbieten kann. Dass Truell ausgerechnet die fünf Prozent betont, dürfte auch ein Signal an andere Modellanbieter sein: Cursor ist nicht von einem einzigen Anbieter abhängig. Das mag langfristig klug sein, kurzfristig steht aber eine wichtige Umstellung ins Haus.

Anthropic als Gegenspieler? Der Präzedenzfall Windsurf

OpenAI ist nicht der erste Anbieter, der einem Coding-Tool den Zugang zu seinen Modellen entzieht. Im Juni 2025 hat Anthropic den Zugriff auf seine Claude-Modelle für das KI-Coding-Tool Windsurf blockiert. Anthropic begründete das damals mit Nutzungsbedingungen und strategischen Erwägungen. Jetzt zeigt sich, wie komplex die Verflechtungen in dieser Branche sind: Anthropic arbeitet ausgerechnet mit SpaceX zusammen und mietet Rechenkapazität von Musks Unternehmen. Anthropic-Mitbegründer Tom Brown schrieb auf X, Cursor sei seit Sonnet 3.5 ein vertrauenswürdiger Partner, man werde die Rechenkapazität für Claude-Modelle in Cursor weiter erhöhen und freue sich auf die Zusammenarbeit mit SpaceX.

Das ist eine bemerkenswerte Konstellation. Der Rivale von OpenAI springt ausgerechnet in die Lücke, die OpenAI selbst reißt. Der Präzedenzfall Windsurf zeigt aber auch, dass dieser Schritt nicht ohne Risiko ist. Einige Tech-Führungskräfte kritisierten Brown öffentlich und erinnerten an die damalige Blockade. Replit-CEO Amjad Masad verwies auf die Geschichte mit Windsurf, und Docker-Manager Mat Velloso kommentierte trocken: „Das wäre eine gute Gelegenheit gewesen, den Mund zu halten.“ Anbieter beobachten sich gegenseitig und ernten für jeden strategischen Zug sofort Kritik. Für Entwickler heißt das: sich nicht an ein einziges Ökosystem ketten, sonst steht man plötzlich vor einer leeren Wand.

Was das für die Zukunft der KI-Coding-Tools bedeutet

Die Entscheidung von OpenAI ist ein weiteres Zeichen dafür, dass sich der Markt für KI-Coding-Tools neu ordnet. Die Übernahme von Cursor durch SpaceX hat nicht nur den Besitzer gewechselt, sondern auch die Zerwürfnisse der Tech-Oberklasse in die Produktlandschaft gebracht. OpenAI will offenbar verhindern, dass seine Modelle in einem Unternehmen landen, das von einem erbitterten Feind kontrolliert wird. Aus Unternehmenssicht ist das nachvollziehbar, aber es zeigt auch, wie fragil solche Partnerschaften sind. Man sollte nicht nur auf die Funktionen eines Tools schauen, sondern auch auf die Unternehmensstrukturen dahinter. Wenn der Eigentümer wechselt, kann sich die Verfügbarkeit von Modellen über Nacht ändern.

Gleichzeitig bleibt abzuwarten, ob Cursor die fünf Prozent OpenAI-Traffic problemlos kompensieren kann. Anthropic hat bereits Unterstützung zugesagt. Andere Anbieter könnten ebenfalls einspringen. Die eigentliche Frage ist, ob OpenAI mit dieser Entscheidung nicht auch eigene Marktanteile riskiert. Entwickler schätzen Cursor nicht wegen eines einzelnen Modells, sondern wegen der integrierten Arbeitsweise mit verschiedenen KI-Modellen. Wenn OpenAI sich als unzuverlässiger Partner erweist, könnte das Vertrauen in andere OpenAI-Produkte leiden. Andererseits hat OpenAI mit ChatGPT ein breites Standbein, das von der Cursor-Entscheidung kaum berührt wird.

Am Ende bleibt eine geerdete Erkenntnis: Die KI-Branche wird zunehmend von strategischen Rivalitäten bestimmt, und die Auswirkungen spüren wir alle. Eine Partnerschaft wie die zwischen Cursor und OpenAI war nie nur ein Vertragsverhältnis, sondern immer auch ein politisches Bündnis. Wenn sich die politischen Machtverhältnisse verschieben, kann das Produkt darunter leiden. Es ist deshalb klug, als Nutzer auf mehrere Modellanbieter zu setzen und nicht auf ein einzelnes Tool zu vertrauen. Die Ankündigung von OpenAI ist kein Weltuntergang, aber sie ist ein Warnsignal. Und wer in dieser Branche Warnsignale ignoriert, wird früher oder später wachgerüttelt.

Quelle: cnbc.com