Kategorie: Erklärer

„Text is text, so when you copy text, what are the possible avenues for having watermarks? If you use basic ASCII in its most primitive form with uniform spacing, which is industry standard, there is literally no possible way to have a watermark.“ – Daniel Miessler schreibt das in einem neuen Essay. Auf der reinen Byte-Ebene hat er recht. Die eigentliche Antwort liegt woanders.

Anthropic hat am 11. August 2026 angekündigt, alle Texte von Claude mit einem unsichtbaren Wasserzeichen zu versehen. Bei Bildern und anderen Dateien geschieht das über den C2PA-Standard, eine signierte Metadaten-Provenienz, die am Dateianhang klebt. Bei einfachem Text nennt das Unternehmen ein „imperceptible watermark“, das auch dann erhalten bleibt, wenn man den Text kopiert und anderswo einfügt. Die Ankündigung verrät nicht, wie diese Textversion funktioniert. Es gibt weder einen veröffentlichten Algorithmus noch einen Detektor. Was wir im Folgenden erklären, ist eine Rekonstruktion – basierend auf den wenigen öffentlichen Aussagen und auf dem, was man über typische Wassereichenverfahren weiß.

Die Ankündigung von Anthropic: Was genau passiert?

Die Datei-Version ist simpel. Ein C2PA-Manifest ist eine Signatur, die an die Datei angehängt wird. Sobald jemand ein Bild abfotografiert oder in ein anderes Format konvertiert, ist sie weg. Die Textversion ist anders. Miessler hat zuerst bezweifelt, dass sie überhaupt existieren kann. Sein Einwand zielt auf die kleinste gemeinsame Basis: Wenn Text nur aus 7-Bit-ASCII und einfachen Leerzeichen besteht, gibt es keine versteckten Bits, keine unsichtbaren Zeichen, keinen Platz für irgendetwas Zusätzliches. Zwei Personen, die denselben Satz tippen, erzeugen identische Dateien – Byte für Byte. Wir haben das selbst überprüft: Mit einem Skript, das die Code Points von Claudes Ausgabe liest, finden sich keine Zero-Width-Zeichen, keine ungewöhnlichen Abstände, nichts. Die Ausgabe ist normales, druckbares ASCII.

Der Einwand übersieht eine Ebene. Das Wasserzeichen muss nicht in den Bytes der Datei stecken. Es kann auch in der Wahl der Wörter liegen, die das Modell beim Schreiben trifft. Jeder Satz, den ein Sprachmodell erzeugt, ist eine Kette von Entscheidungen. An jedem Schritt gibt es mehrere plausible Wörter, das Modell entscheidet sich für eines. In diesen Entscheidungen kann ein Signal versteckt werden – unsichtbar für das Auge, aber messbar für jemanden mit dem richtigen Schlüssel.

Die vier Ebenen, auf denen ein Wasserzeichen sitzen kann

Diese Entscheidungen lassen sich in vier Schichten einteilen, die von der Oberfläche bis zur Bedeutung reichen. Die obersten beiden Schichten hat Miessler im Blick: die Codierung und die Formatierung. Dort kann man Bits in Zero-Width-Zeichen verstecken oder Buchstaben aus anderen Alphabeten verwenden, die optisch identisch zu den lateinischen sind. Auch die Zeilenumbruchpositionen bieten einen versteckten Kanal. Aber all das verschwindet, sobald der Text in reines ASCII zurückgezwungen wird. Deshalb nutzen Wassereichenverfahren diese Ebenen nicht.

Die dritte Ebene ist die Wortwahl. Hier liegt der Schlüssel zu dem, was Anthropic vermutlich einsetzt. Man gibt dem Modell einen geheimen Schlüssel. Bei jedem Schritt neigt das Modell leicht zu bestimmten Wörtern, die dieser Schlüssel bevorzugt. Für einen normalen Leser sieht der Text gewöhnlich aus. Wer den Schlüssel kennt, kann die leichten statistischen Abweichungen messen und nachweisen, dass der Text von Claude stammt. Weil das Signal in den Wörtern selbst liegt, überlebt es das Kopieren und Einfügen. Und weil jede Bearbeitung Wörter ersetzt, wird das Signal mit jeder Änderung schwächer.

Es gibt zwei publizierte Methoden, wie diese dritte Ebene funktioniert: die Green-List-Methode von Kirchenbauer und das Tournament-Sampling, das Google in Gemini verwendet. Beide sind in der Fachliteratur beschrieben und dienen als Grundlage für viele Wassereichen-Systeme. Was Anthropic genau nutzt, ist nicht bestätigt. Es könnte auch tiefer gehen, in die vierte Ebene, wo das Signal in der Bedeutung des Textes lebt und selbst eine leichte Umschreibung übersteht. Oder es könnte ein völlig neues Verfahren sein. Ohne einen offiziellen Detektor kann niemand von außen sicher sein.

Wie die Green-List- und Tournament-Sampling-Methode funktioniert

Die Green-List-Methode ist ein Beispiel für die Wortwahl-Ebene. Man legt eine Liste von „grünen“ Wörtern fest, die bei jedem Schritt bevorzugt werden. Das Modell hat für jeden möglichen nächsten Token eine Wahrscheinlichkeitsverteilung. Normalerweise wählt es das wahrscheinlichste Wort. Mit dem Wasserzeichen wird eine Zufallsentscheidung getroffen, aber das Modell wird so beeinflusst, dass es häufiger Wörter von der grünen Liste wählt. Das gelingt, indem man die Wahrscheinlichkeiten leicht anhebt, aber nicht so stark, dass die Textqualität leidet. Ein Detektor, der den Schlüssel kennt, kann die Ausgabe statistisch analysieren: Ist der Anteil grüner Wörter höher als bei einem normalen Text, ist das Wasserzeichen vorhanden.

Tournament-Sampling geht einen Schritt weiter. Statt einer festen Liste werden bei jeder Token-Auswahl mehrere Kandidaten per Turnier gegeneinander antreten gelassen. Der Schlüssel bestimmt, welcher Kandidat gewinnt. Das macht es für Angreifer schwerer, das Muster zu erkennen, weil die Auswahl auf mehreren Parametern basiert. Beide Verfahren sind so konzipiert, dass sie die Textqualität kaum beeinflussen. Der Preis dafür ist die Robustheit: Je stärker das Signal, desto mehr leidet die Qualität. Deshalb ist die Stärke in der Praxis oft ein Kompromiss.

Um diese Technik zu verstehen, hilft eine Analogie: Eine Fluggesellschaft druckt jeden Passagier mit einem geheimen Code auf das Ticket. Der Code ist in die Sitzplatzwahl eingewoben. Jeder Sitzplatz hat eine Nummer, aber die Kombination aus Reihe und Fensterplatz ergibt ein Muster, das nur der Fluggesellschaft etwas sagt. Ein Passagier merkt nichts, aber das Unternehmen kann bei jedem Ticket nachweisen, dass es das Muster erzeugt hat. So funktionieren die Wortwahl-Wasserzeichen.

Wie man das Wasserzeichen entfernt: Zwei Wege

Die Ebenen zeigen auch, wie man das Wasserzeichen loswird. Es gibt zwei grundlegende Methoden, die an entgegengesetzten Enden des Stapels arbeiten. Die erste ist die „santialisierte Neuerzeugung“: Man nimmt den Text und führt ihn durch einen deterministischen Pass, der ausschließlich reines ASCII und normalisierte Leerzeichen ausgibt. Alles, was in der Codierung oder Formatierung versteckt war, ist damit verschwunden. Miessler beschreibt es als „Complete sanitized regeneration of the text using a separate method that produces the canonicalized ASCII-only pure text format with validation“. Das funktioniert, weil das Format danach keinen Platz mehr für versteckte Daten bietet.

Die zweite Methode ist die Umschreibung. Sie greift auf der Wortwahl-Ebene an. Jedes ausgetauschte Wort entfernt ein Stück des statistischen Signals. Eine gründliche Paraphrase verwässert das Signal so weit, dass ein Detektor nichts mehr findet. Wer beide Methoden kombiniert, deckt den gesamten Stapel ab. Allerdings hat die Umschreibung eine wichtige Einschränkung: Wenn ein anderes KI-Modell die Umschreibung übernimmt, tauscht es nur das Wasserzeichen von Claude gegen das des anderen Modells – es entfernt es nicht wirklich. Eine Umschreibung, die nichts hinterlässt, muss von einem Menschen kommen, der den Text wirklich neu denkt. Und genau dieser Fall war von Anfang an unsichtbar für solche Detektionssysteme.

Was der Nachweis wirklich bedeutet – und was nicht

Anthropic ist vorsichtig mit einer Behauptung, die man leicht überlesen kann. Ein erkanntes Wasserzeichen beweist, dass der Text irgendwann von Claude verarbeitet wurde. Es beweist nicht, dass Claude der Autor ist. Wenn du deinen eigenen Absatz einfügst und Claude bittest, die Grammatik zu korrigieren, kann das Ergebnis mit dem Wasserzeichen zurückkommen. Und wenn kein Wasserzeichen vorhanden ist, heißt das auch nicht viel: Kurze Passagen, bearbeitete Texte und Ausgaben älterer Modelle kommen alle ohne Markierung zurück.

Das Wasserzeichen unterstützt also nur die Aussage, dass eine Maschine an den Wörtern beteiligt war. Es kann weder sagen, wer letztlich geschrieben hat, noch wie viel der Arbeit tatsächlich maschinell war. Und selbst diese schwache Aussage hängt von einem Detektor ab, den bisher niemand außerhalb von Anthropic gesehen hat. Wir bewegen uns also im Bereich der Spekulation.

Wenn du wissen willst, ob ein Text von Claude stammt, wirst du es momentan nicht zuverlässig feststellen können. Du kannst dich nur auf Wahrscheinlichkeiten stützen. Und wenn du selbst KI-Texte erstellst und ein Wasserzeichen vermeiden willst, hilft nur eine ehrliche Umschreibung. Das ist arbeitsintensiv, aber es ist die einzige Methode, die wirklich funktioniert. Jede neue Technik erzeugt neue Gegenmittel. Solange Menschen selbst denken und schreiben, kann kein Algorithmus sie vollständig ersetzen oder überwachen.

Quelle: danielmiessler.com

Die gängige Annahme lautet: Autoregressive Video-Weltmodelle scheitern an langen Sequenzen, weil ihr Speicher voll läuft oder Informationen verloren gehen. Das ICML-2026-Papier „Addressable Memory for Video World Models“ zeigt jedoch, dass das eigentliche Problem ganz woanders liegt: Die Modelle vergessen nicht, weil sie zu wenig speichern, sondern weil sie gespeicherte Informationen schlicht nicht mehr abrufen können. Die Forschung von Xindi Wu und Kollegen bei NVIDIA, Princeton und der University of Toronto identifiziert die Ursache in der Positionskodierung und liefert mit WorldTrace einen trainingsfreien Fix.

Stell dir ein volles Bücherregal vor: Alle Bände sind da, aber wenn die Regal-Beschriftung ihre Bedeutung verliert, findest du nichts mehr. Genau so verhält es sich mit den Key-Value-Caches in Video-Weltmodellen. Die Autoren nennen das Problem „Addressability“ – die Erinnerung existiert, aber die Aufmerksamkeitsmechanismen können sie nicht mehr erreichen, sobald die Generierung den Trainingshorizont überschreitet.

Die Wurzel des Übels: Temporale RoPE-Offsets außerhalb der Trainingsverteilung

Um zu verstehen, warum das passiert, müssen wir kurz auf die technische Grundlage schauen. Moderne Video-Weltmodelle verwenden häufig RoPE (Rotary Position Embedding), um die Position jedes Frames in einer Sequenz zu kodieren. Diese Positionskodierung wird während des Trainings auf eine bestimmte Länge beschränkt – sagen wir auf L Frames. Sobald das Modell im Inferenzbetrieb mehr als L Frames generiert, bekommen die neuen Frames RoPE-Offsets zugewiesen, die außerhalb des trainierten Wertebereichs liegen.

Die Konsequenz daraus ist subtil, aber fatal: Die Aufmerksamkeitsmechanismen des Modells haben während des Trainings nie gelernt, mit solchen Offset-Werten umzugehen. Selbst wenn die visuellen Informationen aus früheren Frames noch im Cache liegen, interpretiert das Modell die Phasen der Positionskodierung als fremdartig. Die Aufmerksamkeit kann diese Speicher nicht mehr adressieren – wie eine Bibliothek, in der die Bücher zwar vorhanden sind, aber die Katalogkarten nur bis zu einem bestimmten Regal reichen.

Hinzu kommt ein zweites Problem, das die Autoren als „Content Fidelity“ bezeichnen. Wenn man Schlüssel (Keys) aus verschiedenen Zeitpositionen mittelt, um eine kompakte Zusammenfassung zu erzeugen, führen die unterschiedlichen RoPE-Phasen zu Interferenzen. Die Phasensignale kippen sich gegenseitig aus – eine Art destruktive Interferenz, die das inhaltliche Signal zerstört, bevor es überhaupt verwendet werden kann. Das ist vergleichbar mit zwei Schallwellen, die sich gegenseitig aufheben, obwohl jede für sich klar hörbar wäre.

WorldTrace: Ein zweistufiger Cache mit festen, in-verteilten Slot-Positionen

Die Lösung, die das NVIDIA-Team mit WorldTrace vorschlägt, ist bemerkenswert einfach und elegant. Statt die Positionen der Zusammenfassungs-Slots dynamisch an die aktuelle Generierungslänge zu koppeln, weist WorldTrace jedem Slot eine feste, relative Position zum aktuellen Frame zu – unabhängig davon, wie weit die Sequenz bereits fortgeschritten ist. Das bedeutet konkret: Ein Slot, der zwei Zusammenfassungs-Einheiten hinter dem aktuellen Frame liegt, bekommt immer denselben virtuellen RoPE-Offset, egal ob das Modell gerade das 10. oder das 1000. Frame generiert.

Diese „Slot-Rank-Position“ bleibt damit immer innerhalb des trainierten RoPE-Bereichs. Jedes Zusammenfassungs-Element ist zu jedem Zeitpunkt adressierbar, weil seine Positionskodierung nie außerhalb der Verteilung gerät. Der Cache selbst ist zweigeteilt: ein verbatim Fenster der letzten Frames plus eine Reihe von Zusammenfassungs-Slots, die verdichtete Informationen über weiter zurückliegende Zeitpunkte enthalten. Die Zusammenfassungen verwenden weniger Speicher als die vollen Frames, aber genau genug, um kohärente Videoübergänge zu ermöglichen.

Die Autoren betonen, dass WorldTrace vollständig trainingsfrei funktioniert. Es ist ein Drop-in-Add-on für bestehende autoregressive Video-Weltmodelle. Man muss das Modell nicht neu trainieren, keine Gewichte anpassen – man ersetzt nur die Art, wie der Cache verwaltet und adressiert wird. Das hat praktische Relevanz, denn ein Nachtraining von Video-Weltmodellen auf längere Sequenzen ist teuer und oft mit anderen Stabilitätsproblemen verbunden.

Zwei Schreibstrategien: WorldTrace-Field und WorldTrace-Landmark

WorldTrace stellt zwei komplementäre Mechanismen bereit, die unterschiedliche Ziele verfolgen. WorldTrace-Field konzentriert sich auf zeitliche Kohärenz – also darauf, dass die Generierung über lange Strecken stabil bleibt ohne zu driften. Dafür werden die Schlüssel der zu komprimierenden Frames zunächst in eine gemeinsame, kanonische Phase überführt, gemittelt und dann zurück auf die Slot-Position rotiert. Diese Prozedur vermeidet die Phasenauslöschung, die bei naivem Mitteln in RoPE-rotierem Raum auftritt. Dadurch bleiben die mittleren Aufmerksamkeitslogits erhalten, was die Stabilität der Generierung deutlich verbessert.

WorldTrace-Landmark zielt dagegen auf episodisches Erinnern: Das Modell soll in der Lage sein, früher besuchte Szenen wiederzuerkennen und zurückzukehren – ähnlich wie du dich in einer Stadt daran erinnerst, wo du vor einer Stunde geparkt hast. Landmark erkennt Szenen-Einstiegsframes anhand des kanonischen Schlüsselsignals, speichert sie unverändert in die Zusammenfassungs-Slots und friert sie dort ein. Das Einfrieren verhindert ein langsames Driften, das durch wiederholte Rotationsoperationen in bfloat16-Präzision entstehen würde – ein Detail, das zeigt, wie sorgfältig die Autoren praktische Implementierungsfallen berücksichtigen.

Die beiden Strategien sind nicht austauschbar. WorldTrace-Field ist kein Erinnerungsmechanismus, sondern ein Kompressions- und Stabilisierungswerkzeug. WorldTrace-Landmark dagegen opfert bewusst etwas Kompressionsdichte zugunsten von Detailtreue, um Szenen über lange Distanzen wiedererkennbar zu halten. Die Aufteilung macht Sinn: Für kohärente Übergänge braucht es eine glatte, kontinuierliche Repräsentation; für episodische Erinnerung braucht es genaue, diskrete Spuren.

LoopMem: Die erste Benchmark für episodische Erinnerung in Video-Weltmodellen

Um die Effektivität von WorldTrace-Landmark zu testen, haben die Autoren eine eigene Benchmark namens LoopMem entwickelt. Die Idee ist simpel: Ein Weltmodell soll eine Umgebung durchlaufen, verschiedene Wege mit unterschiedlichen Topologien, Kantenlängen, Kamerawinkeln und Revisit-Mustern, und dann zu einer früher besuchten Szene zurückkehren. Die Qualität der Regenerierung wird mit Position-Aligned CLIP (PAC) gemessen – ein Metrik, die überprüft, ob das Modell tatsächlich die richtige Szene aus dem Gedächtnis rekonstruiert, nicht nur eine ähnliche Ansicht.

Die Ergebnisse über alle LoopMem-Szenarien hinweg sind überzeugend: WorldTrace-Landmark verbessert den Recall konsistent gegenüber dem Standard-Sliding-Window-Ansatz. Auf dem langen ABA-Pfad steigt der PAC-Score von 0,627 auf 0,825. Beim Standard-ABA von 0,723 auf 0,864. Selbst beim komplexen ABABA-Muster mit mehreren Revisits verbessert sich der Wert von 0,892 auf 0,941. Der einzige Fall mit kleinem Gewinn ist der schwerversetzte Kamera-Pan (0,559 auf 0,577) – was die Autoren offen als Limitierung benennen.

Besonders interessant ist, dass der größte Nutzen bei den längsten Pfaden auftritt – genau dort, wo herkömmliche Methoden am meisten versagen. Das bestätigt die Diagnose: Das Problem ist nicht der Speicherplatz, sondern die Adressierbarkeit. Sobald die Adressierung funktioniert, können auch extrem lange Sequenzen stabil erinnert werden. Der kleine Gewinn beim Pan zeigt allerdings, dass räumliche Transformationen wie große Kameradrehungen eine zusätzliche Herausforderung darstellen, die WorldTrace noch nicht vollständig löst.

Langzeit-Kohärenz mit WorldTrace-Field: Ergebnisse über den Trainingshorizont hinaus

Für die zeitliche Kohärenz liefert die Arbeit ebenfalls klare Zahlen. WorldTrace-Field, bei dem der Inhaltsoperator fix bleibt (kanonisches Mitteln) und nur die Positionszuordnung variiert, verbessert die temporale SSIM gegenüber Block-Rel um +5,9% bei 8-facher Horizontverlängerung und +2,8% bei 16-facher. Bei 24-facher Horizontlänge (N=48) steigt die Verbesserung gegenüber dem Sliding-Window auf +15,5% TempSSIM, gleichzeitig sinkt der lokale Szenen-Drift. Das Modell bleibt also nicht nur stabil, sondern weicht auch inhaltlich weniger von der generierten Welt ab.

Die Autoren zeigen in ihren Kohärenz-Rollout-Videos, dass Sliding-Window-Ansätze bei 24× Horizont komplett in sich zusammenfallen – erkennbar an roten Rändern, die auf Divergenz hinweisen. WorldTrace-Field dagegen hält die Struktur der Szene weitgehend aufrecht. Das ist bemerkenswert, weil es ohne jedes zusätzliche Training erreicht wird. Das Modell wurde auf eine bestimmte Kontextlänge trainiert, und trotzdem generiert es kohärente Inhalte über das 24-fache dieser Länge hinaus – allein durch bessere Adressierung des Speichers.

Ein weiteres wichtiges Detail: Positionsformeln, die von der aktuellen Generierungslänge abhängen (etwa lineare Skalierung mit der Rollout-Größe), degradieren nicht monoton – sie brechen in sich zusammen, sobald die Skalierung zu groß wird. Die festen Slot-Rank-Positionen von WorldTrace haben diesen Nachteil nicht. Sie sind inhärent robust, weil sie von der Rollout-Länge unabhängig sind. Das macht die Methode zu einer Art „Skalengesetz“ für Speicheradressierung: Solange die Slot-Positionen in der Trainingsverteilung bleiben, bleibt auch der Zugriff stabil.

Eine neue Perspektive auf Video-Weltmodelle

Die Forschungsergebnisse sind ein starkes Argument, die Diagnose umzudrehen: Bisher wurde angenommen, dass Video-Weltmodelle bei langen Sequenzen „vergessen“, weil ihre Caches zu klein sind oder weil die Generierung unweigerlich driftet. WorldTrace zeigt, dass das Kernproblem viel grundlegender ist – eine Frage der Positionskodierung und der daraus resultierenden Adressierbarkeit. Das ist eine gute Nachricht, denn Positionskodierungen lassen sich außerhalb des Trainingsprozesses beeinflussen.

Für praktische Anwendungen bedeutet das: Du kannst bestehende Video-Weltmodelle mit einem überschaubaren Eingriff für deutlich längere, kohärentere Sequenzen nutzen – ohne teures Nachtraining. WorldTrace ist ein trainingsfreies Framework, das sich als Erweiterung in vorhandene AR-Video-Weltmodelle integrieren lässt. Ob für interaktive Umgebungen, Simulationen oder langfristige Szenenplanung – die Methode erweitert den nutzbaren Horizont von Videogenerierung erheblich.

Die Einschränkungen sind ehrlich benannt: Die Verbesserung bei Kameratransformationen wie weiten Pans bleibt begrenzt. Und WorldTrace-Field zielt auf Kohärenz, nicht auf fotografische Erinnerungstreue. Aber als Konzept zeigt die Arbeit, dass „mehr Speicher“ nicht die Antwort ist, sondern „besserer Zugriff“. In einer Zeit, in der Modelle immer größere Kontexte verarbeiten, ist das eine wichtige Erinnerung: Die Technik, die Informationen speichert, ist oft weniger entscheidend als die Technik, die den Zugriff darauf ermöglicht.

Quelle: research.nvidia.com

Die meisten halten GitHub Copilot für eine simple Anfrage an ein Sprachmodell: Tippen, Enter, fertig. Wer den Netzwerkverkehr der VS-Code-Erweiterung beobachtet, findet ein komplexes System aus Authentifizierung, Modell-Routing und Kontext-Sammlung. Rafael, ein Entwickler, hat das analysiert und zeigt, wie Copilot wirklich arbeitet.

Rafael ist Ingenieur und betreibt den Newsletter „Lighthouse“ über KI-Systeme. Er interessiert sich für Electron-basierte Desktop-Apps – ein Framework, das Webtechnologien wie HTML, CSS und JavaScript mit Node.js bündelt und in Chromium rendert. Viele KI-Tools wie Cursor, Notion oder ChatGPT Desktop setzen darauf. Rafael wollte wissen, was diese Apps nach außen senden. Der Auslöser war ein praktisches Problem: Sein Copilot-Kontingent war Monat für Monat schneller aufgebraucht, als ihm lieb war. Das brachte ihn dazu, VS Code und Copilot genauer zu analysieren.

Warum Electron-Apps eine Fundgrube für Reverse Engineering sind

Electron hat einen schlechten Ruf, was Ressourcenverbrauch angeht, aber für Reverse Engineering ist es nützlich. Da die App-Grundstruktur aus Chromium und Node.js besteht, kannst du den Netzwerkverkehr fast beliebig abgreifen. Es gibt zwei Hauptwege, über die eine Electron-App HTTP-Anfragen schickt: über die Netzwerkfunktionen des Browsers (Chromium-API) oder über Node.js-Module wie http oder fetch. Für die Analyse ist wichtig, welcher Weg genutzt wird, weil sich beide unterschiedlich abfangen lassen.

VS Code hat eine zusätzliche Besonderheit: eine Prozessarchitektur mit dediziertem Extension Host. Erweiterungen – inklusive Copilot – laufen in einem eigenen Prozess, getrennt von der Oberfläche. Ein Absturz einer Erweiterung reißt dann nicht die ganze IDE mit. Das macht die Analyse aber kniffliger, denn der Extension Host kann eigene Netzwerkverbindungen aufbauen.

Rafael nutzte diese Architektur, um Copilot zu untersuchen. Sein Plan: Ein Proxy-Server zwischen App und Internet schaltet sämtliche HTTP- und WebSocket-Verbindungen mit. Dafür verwendet er mitmproxy, ein Open-Source-Tool, das als Man-in-the-Middle arbeitet. Der Proxy fängt Anfragen ab, leitet sie an den Zielserver weiter und reicht Antworten zurück. Bei HTTPS erzeugt er ein eigenes Zertifikat, dem der Client vertrauen muss. Dadurch entstehen zwei TLS-Verbindungen – eine zwischen App und Proxy, eine zwischen Proxy und Server – und der Proxy liest den Datenverkehr im Klartext.

Für macOS beschreibt Rafael die Installation mit Homebrew und das Einrichten in VS Code. Du setzt in den Benutzereinstellungen den HTTP-Proxy auf localhost:8080, deaktivierst striktes SSL und erzwingst Proxy-Unterstützung für Erweiterungen. Nach einem Neustart erscheint im mitmweb-Interface ein Strom von Requests, die du filtern kannst – etwa mit marketplace, um nur den Traffic zur Marketplace-API zu sehen. Ein Stolperstein: Der Extension-Host-Prozess wird manchmal nicht korrekt aktualisiert. Die Lösung: Über die Befehlspalette „Developer: Restart Extension Host“ ausführen und prüfen, ob die Prozess-IDs mit dem aktuellen Zeitstempel übereinstimmen.

Mit mitmproxy dem Copilot in die Karten schauen

Nachdem die Infrastruktur stand, analysierte Rafael die Requests. Bereits beim Start sendet VS Code eine Reihe von Anfragen an GitHub und Copilot – noch bevor du eine Eingabe machst. Diese Bootstrap-Phase lässt sich in Kategorien unterteilen: Authentifizierung & Session, Konfiguration & Richtlinien, Registry für MCP, Repository- und Session-Kontext, Modell-Erkennung sowie zuletzt geöffnete Repositories. Die Verteilung zeigt: Der Großteil des Netzwerkverkehrs betrifft GitHub oder Copilot, nicht den Marketplace.

Die erste Aktion von Copilot ist die OAuth-Authentifizierung. Der Client holt ein OAuth-Token, tauscht es gegen ein kurzlebiges Token und prüft die Berechtigung. Das ist ein klassischer OAuth-Ablauf. Es beginnt mit einem Redirect zu GitHub, dann folgt der Token-Austausch, am Ende steht eine validierte Session. Dieser Prozess läuft bei jedem Neustart von VS Code durch – selbst wenn du eingeloggt bist. Das erklärt die vielen Requests beim Start.

Danach folgt die Modell-Erkennung. Copilot fragt zuerst eine Liste der verfügbaren Modelle über den Endpunkt /models ab. Kurz darauf geht eine zweite Anfrage an /agents/swe/models, speziell für Agents mit Software-Engineering-Fähigkeiten. Hier erfährt Copilot, welche Modelle für dich und deinen Plan freigeschaltet sind. Das beeinflusst, welche Modelle später ausgewählt werden.

Zusätzlich lädt die Erweiterung Konfigurations- und Richtlinieninformationen, vermutlich um Enterprise-Policies oder Datenschutzeinstellungen durchzusetzen. Auch eine Registry für MCP (Model Context Protocol) wird abgerufen. MCP ist ein Standard, über den KI-Anwendungen auf externe Tools und Datenquellen zugreifen. In der Registry sind die verfügbaren Tools und Ressourcen verzeichnet. Rafael erwähnt außerdem, dass die zuletzt geöffneten Repositories mitgeschickt werden – vermutlich um den Arbeitskontext vorzuladen, damit die KI schneller auf relevante Dateien zugreifen kann.

Was VS Code beim Start bereits an GitHub schickt

Die Menge an Daten, die beim Start übertragen wird, ist beachtlich. Rafael hat die prozentuale Verteilung der Requests während der Bootstrap-Phase in einem Diagramm festgehalten. Es zeigt: Nicht der Marketplace dominiert, sondern GitHub-spezifische Endpunkte. Copilot ist also tief in die Grundfunktionen von VS Code integriert – selbst wenn du es nicht aktiv nutzt, läuft ein ständiger Austausch mit den GitHub-Servern.

Für Nutzer mit sensiblen Projekten ist das relevant. Beim Start werden automatisch Kontext wie Repositories, Session-Informationen und Modell-Verfügbarkeit übertragen. GitHub erhält ein detailliertes Bild deiner Arbeitsumgebung, unabhängig davon, ob du eine KI-Empfehlung anforderst. Rafael merkt an, dass diese Requests nicht dokumentiert sind, aber durch Netzwerkanalyse sichtbar werden. So wird Transparenz geschaffen.

Er testete außerdem, ob das Bearbeiten einer .env-Datei mit geheimen Schlüsseln automatisch einen HTTP-Request auslöst. Das passierte nicht. Die bloße Änderung sendet keinen Inhalt nach außen. Das bedeutet nicht, dass der Inhalt nicht in den Kontext aufgenommen wird, wenn du Copilot darauf ansprichst. Es zeigt nur, dass kein Hintergrund-Versand ohne deine Aktion erfolgt. Für alle, die sorgen, ihre Schlüssel könnten unbemerkt hochgeladen werden, ist das beruhigend.

Ein weiterer Befund ist die Intent-Klassifikation. Nachdem du eine Nachricht im Auto-Modus sendest, geht eine Anfrage an den Endpunkt /models/session/intent. Diese Anfrage bewertet dein Prompt und ordnet ihn einer Kategorie zu – etwa code-gen, debugging, reasoning oder tool-use. Erst danach wird das passende Modell ausgewählt und die Generierung gestartet. Diese Klassifikation ist nicht immer dokumentiert, aber sie spart Kosten, weil teure Modelle gezielt eingesetzt werden. Rafael beobachtete das live, obwohl es bereits in der Copilot-Dokumentation erwähnt wird.

Wie Copilot das passende Modell für deine Anfrage wählt

Die Intent-Klassifikation ist der erste Schritt in einer mehrstufigen Pipeline. Nachdem die Absicht erkannt ist, wählt ein Modell aus der zuvor abgerufenen Liste. Das erklärt, warum Copilot mit verschiedenen Modellen arbeitet – je nach Aufgabe nutzt es kleinere, schnellere Modelle oder mächtigere, langsamere. Der Wechsel passiert automatisch und ist für dich unsichtbar, es sei denn, du schaust genau hin.

Rafael untersuchte auch die Inline-Vervollständigung (Ghost Text). Während des Schreibens sendet die Erweiterung ständig Kontext an den Server – in der Regel den aktuellen Inhalt der geöffneten Datei. Das war zu erwarten. Überraschend war, wie viel zusätzlicher Kontext mitgeschickt wird: häufig der gesamte Inhalt des aktuellen Tabs sowie relevante Ausschnitte aus anderen geöffneten Dateien. Diese Informationen werden als Teil des Prompt-Kontexts zusammengebaut und an das Modell übertragen.

„Speicher“ bei Copilot ist also kein dauerhafter Verlauf. Es ist ein flüchtiger Kontext-Puffer, der für jede Anfrage neu aufgebaut wird. Was hineingelangt, hängt von deiner Aktion ab – welche Datei du bearbeitest, welche Symbole du referenzierst, welche Änderungen vorliegen. Copilot baut sich ein situatives Bild, das weit über die Prompt-Zeile hinausgeht. Dieses Vorgehen ist nötig für qualitativ hochwertige Vorhersagen, aber es bedeutet auch, dass ein großer Teil deines Codes die lokale Umgebung verlässt.

Die Netzwerk-Traffic-Analyse deckte zudem auf: Verbindungen führen nicht nur zu GitHub, sondern auch zu Azure-basierten Endpunkten, wo die eigentliche Inferenz stattfindet. Die Trennung zwischen Authentifizierung (GitHub) und Inferenz (Azure) ist ein bekanntes Muster. Gut zu wissen: Die API-Schlüssel gehen nicht an Dritte. Der OAuth-Token wird ausschließlich für die GitHub-Authentifizierung verwendet, die Inferenz-Endpunkte nutzen kurzfristige, gesonderte Tokens.

Kontext und Speicher: Was mit deiner Anfrage mitreist

Copilot ist also mehr als ein simpler „Prompt in, Antwort raus“-Dienst. Die Architektur kombiniert Identitätsmanagement, Modell-Routing und Kontext-Konstruktion. Für dich als Nutzer bedeutet das: Je präziser du dein Arbeitsumfeld pflegst – relevante Dateien geöffnet lässt, klare Namen verwendest, die Projektstruktur sauber hältst – desto bessere Vorschläge bekommst du, weil der Kontext auf soliden Informationen basiert.

Für Entwickler, die ähnliche KI-Funktionen einbauen möchten, liefert die Analyse eine Vorlage. Sie zeigt, wie man mit einem Proxy, ein paar Einstellungen und etwas Geduld die Netzwerkkommunikation einer Electron-App nachvollzieht. Das ist nicht nur für Reverse Engineering nützlich, sondern auch für das Debugging eigener Anwendungen. Wer versteht, welche Daten die App sendet, kann Leistung optimieren, Datenschutzrisiken erkennen und Serverlast reduzieren.

Copilot ist keine simple HTTP-API, die einen Prompt an ein LLM schickt. Es ist ein komplexes System mit mehreren Verarbeitungsstufen. Die Netzwerk-Traffic-Analyse von Rafael zeigt, wie tief es in VS Code integriert ist. Wer die Requests selbst beobachtet, versteht die Integration besser. Die Analyse ist einfach durchzuführen – und die Erkenntnisse sind oft erstaunlich.

Quelle: lighthousenewsletter.com

Ein verschlüsseltes Denkblock-Fragment einer KI wird in eine schwächere Modell-Sitzung eingespielt. Statt des erwarteten kryptischen Rauschens erscheint der komplette versteckte Reasoning-Verlauf als Klartext. Das ist keine Magie, sondern eine Sicherheitslücke, die Forscher öffentlich gemacht haben.

Große Sprachmodelle wie ChatGPT, Claude oder Gemini zeigen ihre internen Denkschritte nicht mehr offen. Sie liefern verschlüsselte Blöcke, die angeblich nur das Modell selbst lesen kann. Doch diese Verschlüsselung ist löchrig wie ein Schweizer Käse.

Wie die Forscher die Verschlüsselung umgehen

Die Gruppe um Alexander Panfilov hat einen Angriff entwickelt, der auf den ersten Blick einfach wirkt. Sie nehmen den verschlüsselten Reasoning-Block, den ein teures Modell erzeugt hat, und spielen ihn in eine schwächere, aber ähnliche Modellvariante desselben Anbieters ein. Dazu verwenden sie einen Jailbreak-Prompt, der das schwächere Modell dazu bringt, den Inhalt des Blocks zu transkribieren.

Das funktioniert, weil diese Blöcke portabel sind – sie lassen sich außerhalb ihres ursprünglichen Kontexts wiederverwenden. Das Angriffsziel ist nicht das starke Modell selbst, sondern sein kleiner Bruder, der leichter zu manipulieren ist. Und genau dort werden die Gedanken des großen Bruders ausgeplaudert.

Die Forscher demonstrieren das anhand von 120 Codeforces-Aufgaben. Sie verglichen die versteckten Denk-Token-Zahlen mit den dekodierten Token-Längen. Die Übereinstimmung ist fast perfekt – die Punkte liegen auf der Diagonalen bis an die Grenze des Generierungslimits von 12.000 Token.

Warum die Blöcke überhaupt existieren

Warum schickt ein KI-Anbieter überhaupt einen verschlüsselten Block an den Client? Der Grund ist ein Schutz vor Modell-Destillation, also dem Versuch, die Fähigkeiten eines teuren Modells durch Abfragen zu kopieren. Die Idee: Wenn der Client die Gedanken nicht lesen kann, kann er sie auch nicht weiterverarbeiten.

Diese Logik hat einen Haken: Der Block muss zurück zum Server geschickt werden, wenn das Gespräch weitergeht. Die Anbieter vertrauen darauf, dass niemand den Block manipuliert. Genau das nutzen die Forscher aus. Sie spielen den Block nicht an das ursprüngliche Modell zurück, sondern an ein schwächeres Geschwistermodell, das weniger Sicherheitsvorkehrungen hat.

Das Ergebnis ist ein klassischer Replay-Angriff – nur eben auf die KI selbst. Die Verschlüsselung schützt vor direkter Manipulation, nicht vor der Verwendung eines ungeschützten Lese-Ziels.

Vom Denken zur Datenpanne: Secrets in den Traces

Die Forscher gingen noch einen Schritt weiter. Sie sammelten 6.708 öffentlich verfügbare Agent-Trajektorien von GitHub und Hugging Face – also tatsächliche KI-Ausführungen, die echte Aufgaben lösen. In diesen Traces fanden sie 351 verschiedene geleakte Objekte: 204 technische Identifikatoren, 126 persönliche Daten und 23 Zugangsdaten.

Wenn eine KI mit einem Tool interagiert, speichert sie oft sensible Informationen in ihrem Reasoning. Und wenn dieses Reasoning verschlüsselt, aber wiederverwendbar ist, wird es zum Sicherheitsrisiko. Ein Angreifer könnte einen API-Key aus einem öffentlichen Trace extrahieren, ohne das ursprüngliche Modell zu attackieren.

Die Angriffsfläche ist real. Viele Unternehmen setzen Agenten ein, die auf Code-Repos, Datenbanken oder Ticketsysteme zugreifen. Wenn diese Agenten ihren Denkprozess protokollieren, wird das zur Goldgrube für Angreifer – sofern sie die Verschlüsselung wie oben beschrieben umgehen.

Was die gelösten Aufgaben über die Methode verraten

Ein bemerkenswertes Detail der Studie ist die Vielfalt der extrahierten Inhalte. In den Denk-Traces tauchen nicht nur allgemeine Textantworten auf, sondern konkrete algorithmische Lösungen – etwa für Max-Flow-Probleme mit Zeitexpansion oder BFS-basierte Infektionsausbreitung. Du kennst das vielleicht von Plattformen wie Codeforces: Dort entwickelt man unter Zeitdruck einen Algorithmus.

Die Forscher zeigen, dass die entschlüsselten Gedanken exakt den Lösungsweg enthalten – inklusive der Überlegungen zu Zeitfenstern, Pfad-Suche und Optimierung. Nimm die Aufgabe, eine Infektionszeit für Laborzellen zu berechnen: Ein Max-Flow-Modell mit Zeitexpansion ist die Standardmethode. In den gestohlenen Gedanken findest du die exakte BFS-Logik, die der KI durch den Kopf ging, bevor sie die Antwort formulierte.

Auch kombinatorische Probleme sind darunter, etwa die Zählung von Strings mit minimalen Ziffernhäufigkeiten. Die KI denkt über Multinomial-Koeffizienten nach, baut Polymere aus Fakultäten und minimiert letztlich die Zahl. Das ist nicht nur für Wettbewerbsprogrammierer interessant – es zeigt, dass die verschlüsselten Blöcke vollständige Lösungswege enthalten, nicht nur vage Notizen.

Die Sicherheitslücke ist prinzipiell

Was bedeutet das für die Branche? Die Forscher haben bewiesen, dass die Verschlüsselung von Reasoning-Traces keinen Schutz vor Extraktion bietet, solange ein schwächeres Modell derselben Modellfamilie existiert. Solange Anbieter wie OpenAI, Anthropic oder Google mehrere Modellgrößen anbieten, bleibt dieser Angriffsvektor offen.

Die naheliegende Gegenmaßnahme wäre, die Blöcke modell- oder sitzungsgebunden zu machen – also eine Signatur einzuführen, die den Empfänger festlegt. Doch das ist leichter gesagt als getan, schließlich müssen die Blöcke auch bei Kontextverlust noch funktionieren. Eine andere Lösung wäre, die Blöcke gar nicht erst an den Client zu senden, sondern nur auf dem Server zu halten – aber das kollidiert mit der Architektur vieler Produkte.

Für dich als Entwickler oder KI-Nutzer heißt das: Sei vorsichtig, welche Daten du durch einen KI-Agenten schickst. Wenn er mit sensiblen Systemen interagiert, nimm an, dass sein Reasoning abrufbar ist – auch wenn die API eine Verschlüsselung verspricht. Der Schutz durch Verschlüsselung ist nur so gut wie das schwächste Modell im selben Ökosystem.

Die Studie ist ein Weckruf. Sie zeigt, dass Sicherheit nicht durch obskure Kryptographie erreicht wird, sondern durch durchdachte Architektur und die Einschränkung von Wiederverwendbarkeit. Bis dahin gilt: Die Gedanken der stärksten KI sind offen für alle, die den Replay-Trick beherrschen.

Quelle: stolen-thoughts.com

Ein Datenbankadministrator starrt auf sein Monitoring-Dashboard. Die Kurve für Transaktionen pro Sekunde fällt abrupt von rund 7.200 auf 160 ab – ohne dass ein Deployment, ein Schema-Change oder ein Hardware-Problem vorliegt. Er prüft die Replikationsverzögerung, die CPU-Last, die I/O-Werte – alles normal. Erst nach einer Stunde normalisiert sich der Wert wieder. Was ist passiert? Ein einzelner Prozess hat eine Subtransaktion eröffnet, die mehr als 64 verschachtelte Blöcke mit EXCEPTION-Handling durchlief. Genau daran krankt PostgreSQL – und es kann noch schlimmer kommen.

Subtransaktionen sind in PostgreSQL ein mächtiges Werkzeug: Sie erlauben es, innerhalb einer größeren Transaktion Rücksprungpunkte zu setzen. Ein Anwendungsentwickler nutzt sie über SAVEPOINT-Anweisungen, und PL/pgSQL verwendet sie automatisch für jeden Block mit einer EXCEPTION-Klausel. Sinnvoll? Ja. Aber wenn eine einzelne Transaktion zu viele Subtransaktionen aufstapelt, verändert sich das Verhalten des gesamten Datenbanksystems. Zudem kann eine neue Read Replica dauerhaft blockiert werden, obwohl sie die WAL-Daten weiterhin repliziert.

Wie Subtransaktionen entstehen und was sie bewirken

Eine Subtransaktion ist eine Transaktion innerhalb einer Transaktion. Du startest sie implizit mit SAVEPOINT oder in PL/pgSQL, sobald ein Block eine EXCEPTION-Klausel enthält. Jede Subtransaktion erhält eine eigene Transaktions-ID (XID). Das System muss diese IDs verwalten, um atomares Verhalten zu garantieren. Dazu hält jeder Backend-Prozess eine Liste der aktiv zugewiesenen Subtransaktions-IDs im Arbeitsspeicher – den sogenannten Subtransaktions-Cache.

Dieser Cache hat eine feste Größe: PGPROC_MAX_CACHED_SUBXIDS, in der Regel 64. Wenn du also mehr als 64 Subtransaktionen in einer einzigen Top-Level-Transaktion anlegst – explizit oder über Schleifen mit EXCEPTION-Blöcken –, platzt der Cache. PostgreSQL markiert den Cache als überlaufen. Ab diesem Moment kann keine Snapshot-Berechnung mehr alle aktiven Subtransaktions-IDs vollständig erfassen. Das bleibt nicht lokal – die Auswirkung greift auf alle Backends und sogar auf Read Replicas über.

WAL-Replikation und die Rolle der RUNNING_XACTS-Einträge

Um zu verstehen, warum ein Subtransaktions-Overflow eine Replica blockieren kann, musst du kurz die Replikationsarchitektur von PostgreSQL kennen. Die primäre Instanz schreibt alle Änderungen sequenziell in das Write-Ahead Log (WAL). Dieses Log dient als Grundlage für Crash-Recovery, wird aber auch an Replikas gestreamt. Eine Read Replica empfängt den WAL-Stream, dekodiert die Records und wendet sie auf ihre eigene Datenbasis an. Das ist der physikalische Teil der Synchronisation.

Doch für eine konsistente Sicht auf die Daten muss die Replica zusätzlich wissen, welche Transaktionen auf dem Primary noch aktiv sind. Dafür gibt es spezielle WAL-Records: RUNNING_XACTS. Sie werden vom Primary in regelmäßigen Abständen in den WAL-Stream eingefügt. Sie enthalten eine Momentaufnahme der laufenden Transaktionen, inklusive der IDs der aktiven Top-Level-Transaktionen und ihrer Subtransaktionen. Erst wenn eine Replica einen solchen Record verarbeitet hat, kann sie lesenden Zugriff erlauben – sofern Hot Standby aktiviert ist.

Der Trick: Eine Replica startet aus einem Base-Backup und muss den WAL-Stream ab dem Checkpoint des Backups anwenden. Ohne ein RUNNING_XACTS-Record fehlt ihr der Kontext, welche Transaktionen schon vor dem Checkpoint liefen. Deshalb wird dieses Record gezielt injiziert. Solange die Replica einen sauberen, nicht überlaufenen RUNNING_XACTS-Record verarbeitet, kann sie den Zustand aller Transaktionen nachvollziehen und sicher lesen.

Der Subtransaktions-Cache und sein Overflow

Jeder Backend-Prozess verwaltet seinen eigenen Cache mit den XIDs der aktuell verschachtelten Subtransaktionen. Die vollständige Zuordnung von Subtransaktionen zu ihrer Top-Level-Transaktion liegt in der Systemtabelle pg_subtrans, die auf der Platte liegt und über einen SLRU-Cache abgefragt wird. Solange die Anzahl der Subtransaktionen unter der Cache-Grenze liegt, ist alles schnell. Überschreitet sie die Grenze, wird der Cache als „overflowed“ markiert.

Ein Überlauf hat eine kritische Eigenschaft: Er wirkt global. Wenn irgendein Backend auf dem Primary einen Overflow meldet, wird jede danach erzeugte RUNNING_XACTS-Record ebenfalls als overflowed markiert – selbst wenn andere Transaktionen völlig sauber sind. Das liegt daran, dass das Record nur eine Momentaufnahme aller aktiven Transaktionen liefert. Fehlt einem davon die vollständige Subtransaktions-ID-Liste, ist das gesamte Bild unvollständig. Dadurch wird jeder Snapshot, der auf einer solchen Basis aufbaut, ebenfalls als overflowed behandelt.

Cluster-weite Leistungsprobleme durch einen einzigen Overflow

Was passiert konkret mit der Performance? Wenn eine Query eine Zeile liest, muss sie prüfen, ob die Transaktions-ID der Zeile (xmin oder xmax) in der Menge der abgeschlossenen oder aktiven Transaktionen liegt. Dazu wird der Snapshot herangezogen, der normalerweise alle relevanten IDs in einem kompakten Format enthält. Bei einem overflowed Snapshot fehlen jedoch einige Subtransaktions-IDs. Das System muss dann bei jeder Abfrage der pg_subtrans-Tabelle nachschlagen, um die fehlende Zuordnung zu ermitteln – ein teurer Prozess, der SLRU-Locks benötigt und bei hoher Last sogar Disk-I/O auslöst.

Ein einzelner Overflow kann also dazu führen, dass alle Queries auf dem Cluster langsamer werden, selbst wenn sie gar keine Subtransaktionen nutzen. In Benchmarks wurde ein Einbruch der TPS von über 95 Prozent beobachtet. Der Overhead entsteht durch das ständige Nachschlagen in pg_subtrans und die damit verbundenen Lock-Konflikte. Der Effekt ist nicht nur messbar, sondern erstreckt sich über alle Datenbanken, weil SLRU-Locks global sind. Ein einzelner Savepoint-Stapel kann also die Produktivität des gesamten Clusters zerstören.

Warum neue Read Replicas keine Verbindungen annehmen

Die zweite Gefahr betrifft Read Replicas, die während eines Overflows hinzugefügt werden. Sie beziehen ihr Base-Backup vom Primary und beginnen, den WAL-Stream abzuspielen. Wenn sie dabei auf einen overflowed RUNNING_XACTS-Record stoßen, können sie sich kein konsistentes Bild der laufenden Transaktionen machen. Sie wissen nicht, welche Subtransaktionen unterhalb der Grenze existierten. Aus Sicherheitsgründen versetzt PostgreSQL die Replica in den Status STANDBY_SNAPSHOT_PENDING – sie setzt das WAL-Replay fort, erlaubt aber keine Leseabfragen.

Die Replica bleibt in diesem Zustand, bis einer von drei Fällen eintritt: Sie erhält ein vollständiges, nicht überlaufenes RUNNING_XACTS-Record, sie replayt ein Shutdown-Checkpoint, der garantiert, dass keine Transaktionen aktiv sind, oder sie wartet, bis alle Transaktionen, die zum Zeitpunkt des Overflow-Events aktiv waren, abgeschlossen sind. Das kann Minuten oder Stunden dauern. Für einen Administrator, der gerade eine Read Replica hochgefahren hat, um Last abzufangen, ist das ein fataler Schlag: Die Replica wird nicht lesbar, obwohl sie WAL fleißig anwendet.

Was du tun kannst, um Probleme zu vermeiden

Das erste und einfachste Gegenmittel ist, die Anzahl der Subtransaktionen pro Transaktion zu begrenzen. In PL/pgSQL vermeidest du durch Refactoring, dass Schleifen mit EXCEPTION-Klauseln zu viele Subtransaktionen erzeugen. Vermeide EXCEPTION-Blöcke in Schleifen oder fasse sie in separate Funktionen zusammen. Oft lässt sich Logik ohne verschachtelte SAVEPOINTs umsetzen.

Falls du keine Kontrolle über den Code hast, kannst du überwachen, wie viele Subtransaktionen ein Backend erzeugt. PostgreSQL liefert in den Statistiken des pg_stat_database die Zahl der Subtransaktionen, und pg_stat_statements gibt Hinweise auf problematische Queries. Behalte außerdem die Anzahl der gleichzeitig aktiven Transaktionen im Auge – ein einzelner Prozess kann den ganzen Cluster beeinflussen. Einen Parameter, um den Overflow zu verhindern, gibt es derzeit nicht; du kannst nur durch Code-Richtlinien oder Query-Rewriting gegensteuern.

Für das DBA-Team bedeutet das: Teste deine Anwendungen gezielt auf dieses Muster. Simuliere eine Transaktion mit mehr als 64 Subtransaktionen und beobachte die Wirkung auf dein Cluster. Nur so stellst du sicher, dass ein solcher Ausfall nicht in der Produktion passiert. Es ist ein versteckter Fallstrick – aber mit den beschriebenen Mechanismen kennst du die Risiken und kannst sie vermeiden.

Quelle: planetscale.com