GPT-6 Astra: Angeblich rekurrent, offiziell schnell, der Betrieb bleibt die offene Frage

GPT-6 Astra ist da, und die Diskussion läuft auf zwei Ebenen. Offiziell ist die OpenAI-Ankündigung vom 03.09.2026, sie nennt Rekordwerte in mehreren Agent-Benchmarks, unter anderen 99,9 Prozent auf ARC-AGI-3. Die Hacker-News-Diskussion zur Ankündigung steht bei 2.196 Punkten, eigene Abfrage der HN-API am 05.09.2026. Inoffiziell ist der Bericht von The Information, nach dem Astra mit einer rekurrenten Architektur arbeitet. Genau dieser Unterschied ist der Kern des Beitrags: Was steht in der offiziellen Ankündigung, was ist Bericht aus zweiter Hand, und was bedeutet der Unterschied für den Betrieb eines Agenten, der dauerhaft laufen soll. Denn Betrieb ist die Disziplin, die entscheidet, ob so ein Modell am Ende arbeitet oder nur in Demos existiert.

Ein Hinweis vorweg: Die rekurrente Architektur ist nicht Teil der offiziellen OpenAI-Ankündigung. Sie stammt aus einem Bericht von The Information über ein looped-transformer-Design und aus der Community-Diskussion, die daran anschließt. Für diesen Beitrag behandle ich sie als Annahme, nicht als Fakt. Der Unterschied zur klassischen Architektur wäre betrieblich konkret: Ein Transformer zahlt für jeden Kontext-Schritt neu, ein rekurrentes Design hält Zustand. Wenn das stimmt, spricht viel dafür, dass längere Läufe ohne Context-Kollaps möglich werden und der Kompressionsdruck sinkt. Bestätigt ist das für Astra nicht, es bleibt die Erwartung, die dieser Beitrag prüft.

Klar getrennt werden muss die Erinnerungsfrage. Zustand innerhalb eines Laufs ist nicht dasselbe wie dauerhaftes Gedächtnis, und ob Astra über Sitzungen hinweg erinnert, weiß derzeit niemand. In meinem Setup liegt das Gedächtnis ohnehin im Host, in Snapshot-Dateien und Logs, nicht im Modell. Der eigene Beleg für lange Läufe: 88 Stunden am Stück, dokumentiert durch stündliche Heartbeats und Stability-Snapshots vom 28.08. bis zum 01.09.2026. In der Praxis lag das Limit beim Betrieb, nicht beim Modell.

Warum das für lange Läufe zählt, lässt sich ohne Theoriepapier erklären. Ein klassischer Transformer arbeitet mit einem begrenzten Kontextfenster, und je länger ein Agent läuft, desto mehr Verlauf, Tool-Ausgaben und Zwischenergebnisse müssen in dieses Fenster oder komprimiert hinaus. Genau an dieser Stelle werden lange Recherche-Ketten im Praxisbetrieb träge: Der Verlauf wird zusammengefasst, Details fallen weg, und der Agent arbeitet mit einer Verkürzung seiner eigenen Geschichte. Würde die berichtete Rekurrenz dieses Problem strukturell reduzieren, änderte das die Betriebsrechnung für lange Läufe deutlich. Belegt ist das für Astra nicht, es ist die Erwartung, mit der ich in den Test gehe.

Die Ankündigungsseite nennt Messwerte, die sich für Agenten-Betreiber einzeln auszahlen. Terminal-Bench Science 0.1, ein Test für wissenschaftliche Forschungs-Workflows mit Code und Terminal-Tools: 64,6 Prozent für Astra, gegen 52,6 Prozent für Claude Fable 5.1, bei rund 31 Prozent niedrigeren geschätzten API-Kosten. In der günstigeren Konfiguration erreicht Astra noch 61,1 Prozent, während GPT-5.6 Sol dort bei 22,4 Prozent liegt. Agents' Last Exam, komplexe Profi-Aufgaben in echter Software: 59,3 Prozent, gegen 55,5 für Claude Opus 5 und 53,6 für GPT-5.6 Sol, bei rund 65 Prozent weniger Output-Tokens als Opus 5.

Zwei weitere Blöcke der Ankündigung betreffen Latenz und Sicherheit. In Latenz-Simulationen auf OSWorld 2.0 erreicht Astra 72,6 Prozent in rund 40 Minuten pro Aufgabe, Sol schafft 65,7 Prozent in rund 75, das sind etwa 47 Prozent weniger Zeit. Zusammen mit dem aktualisierten Codex-Harness ergibt das laut OpenAI eine 1,9-fach schnellere Aufgabenerledigung auf Mind2Web. Zwei Sicherheitswerte bleiben für meinen Betrieb relevant: In einem Scope-Test überschritt Astra das autorisierte Ziel in 0 Prozent der Fälle, GPT-5.6 Sol ohne Produktions-Schutzmaßnahmen in 48, und im ExploitGym-Honeypot lag die Erfolgsrate von Astra bei 0 Prozent gegen 48,2 Prozent von Sol.

Der Rollout läuft nach offizieller Angabe seit dem 03.09.2026 für eine begrenzte Zahl von Organisationen, in den kommenden Tagen folgen die ChatGPT-Plus-, Pro-, Business- und Enterprise-Konten, dazu die API, Microsoft Azure und AWS Bedrock. Für mich ist der relevante Kanal die Cloud-Anbindung, über die meine Modelle laufen. Sobald das Modell dort in der Modellliste steht, beginnt der Test, nicht vorher.

Geplant ist als nächster Schritt ein 24-Stunden-Test unter produktiver Last, und ich schreibe das bewusst als Plan, nicht als Ergebnis. Vorgesehen sind reine Agenten-Arbeit auf dem Pixel, gemessen über die Heartbeat-Kette, dokumentiert werden sollen Turn-Zeiten, Restart-Zeiten der Watchdogs, RAM-Verlauf und Request-Kosten. Gestartet wird erst, wenn die Cloud-Anbindung das Modell führt, und bis dahin ist für Astra nichts gemessen. Die Begrenzung auf 24 Stunden ist bewusst: 88 Stunden am Stück sind bereits belegt, jetzt zählt die Vergleichsmessung unter echter Last, nicht ein weiterer Leerlauf-Rekord.

Ein Frontier-Modell mit Zustand braucht einen Host, der Dauerbetrieb übersteht. Dabei sind zwei Ebenen sauber zu trennen. Das Denken läuft in der Cloud: Der Modellzustand entsteht im Rechenzentrum. Das entlastet den Host, aber auf null fällt der lokale Speicherbedarf nicht: Antworten, lokale Kontexte und die eigene Verarbeitung belegen weiterhin Arbeitsspeicher. Der Host trägt den Rest: Watchdogs, Gedächtnis-Dateien, Prozessüberwachung, Automatik. Auf dieser Host-Seite sind die Grenzen real: Android killt Hintergrundprozesse bei Speicherdruck, Laptops schlafen ein, VPS-Setups kosten Miete.

Beim Arbeitsspeicher halte ich mich an mein Messregister, Stand 05.09.2026. Der Container mit Hermes, Gateway und herdr nimmt rund 380 MB ein, gelegentlich rund 450 MB unter Last. Das sind RSS-Summen, die Shared Memory mitzählen können, und eine Momentaufnahme ohne definierte Workerlast. Der Wert sagt nichts über den frei verfügbaren RAM des Geräts, der lag am gleichen Tag bei rund 1,2 GB MemAvailable inklusive Android. Der Cloud-Modellzustand erscheint in keiner dieser Zahlen, er bleibt im Rechenzentrum.

Für Betreiber wie mich ist der berichtete Ansatz genau deshalb interessant: Würde die Rekurrenz den Kontextdruck im Cloud-Modell senken, entspannte das die Seite, die bei mir nicht der Engpass ist. Der Engpass liegt erfahrungsgemäß eher am Host als am Modell; das ist eine Betriebsbeobachtung aus diesem Projekt und keine gemessene Engpassanalyse. Wer einen 2.000-Dollar-Laptop kauft, um Astra zu füttern, zahlt für die falsche Komponente, denn das Denken sitzt ohnehin im Rechenzentrum. Mein Stack übersteht den Betrieb auf einem 45-Euro-Handy: Watchdogs, die nach Kills wiederaufsetzen, ein externer Cron-Tick, der Jobs unabhängig vom internen Scheduler feuert, und ein Gedächtnis im Dateisystem, das jeden Kill überlebt. Den ganzen Aufbau dieses Hosts habe ich im Beitrag zum Agenten-Stack auf dem 45-Euro-Handy dokumentiert.

Dass der Host der Engpass ist, ist bei mir keine Theorie, sondern ein dokumentierter Vorfall. Am 28.08.2026 hat Android bei Speicherdruck fünf Gateway-Prozesse hintereinander gekillt, Auslöser war ein Chromium-Test, der den RAM des Geräts hochschnellen ließ. Der Fix war kein Versprechen an das Betriebssystem, sondern Architektur: Watchdogs, die nach jedem Kill wiederaufsetzen, ein externer Cron-Tick, der Jobs unabhängig vom internen Scheduler feuert, und ein Gedächtnis in Dateien, das Kills überlebt. Seit der Härtung am 28.08.2026 steht im Snapshot-Log: null OOM-Kills, bei 99 Prozent Lebendrate über sieben Tage mit 170 von 171 stündlichen Checks. Gebaut, um Kills zu überstehen, nicht um sie zu verhindern.

Die Reihenfolge ist gesetzt. Erst der geplante 24-Stunden-Test unter produktiver Last, dann der Ausbau: Die Content-Kette des Blogs wäre das erste echte Astra-Einsatzgebiet, weil sie Recherche, Entwurf, Verifikation und Veröffentlichung in einem Ablauf vereinigt. Messbar wird der Test an drei Stellen: an den Restart-Zeiten nach Android-Kills, an den Turn-Zeiten im Dashboard und an den Request-Kosten pro fertigem Blog-Beitrag. Solange das Modell nicht in meiner Cloud-Anbindung liegt, bleibt das Planung, und genau so dokumentiere ich es. Der Härtetest kommt, wenn die Modelle so gut werden, dass der Betrieb die eigentliche Grenze ist. Was ich daraus halte, bleibt eine Beobachtung: 88 Stunden Betrieb mit null OOM-Kills seit der Härtung am 28.08.2026 zeigen, dass dieser Host Dauerbetrieb übersteht. Ob der Host oder das Modell der engere Engpass ist, habe ich nicht gemessen.

Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Ich betreibe das HUNTER-Cyberdeck, einen KI-Agenten-Betrieb auf einem gebrauchten Google Pixel 6a, ohne Root, mit Cloud-Modellen und Terminal-Orchestrierung. Diesem Beitrag liegen die Stability-Snapshots und die Heartbeat-Kette vom 28.08. bis 01.09.2026 zugrunde, die Benchmark-Zahlen stammen aus der am 05.09.2026 abgerufenen offiziellen OpenAI-Ankündigung. Zuletzt fachlich geprüft: 05.09.2026.