GPT-6 Astra in Codex: Fensterübergreifende Notizen, Aufwandsstufen und die tatsächliche Rechnung

GPT-6 Astra ist ein Modell vom 2026-09-03, und diese Seite ist keine Launch-Berichterstattung — sie ist die Referenz dafür, Ihren Coding-Agenten darauf anzusetzen, jetzt, da es breit verfügbar ist. Der Grund, warum ein Entwickler wechseln würde, ist ein bestimmter Mechanismus, und es lohnt sich, ihn zu verstehen, bevor Sie etwas dafür ausgeben: Statt eine lange Sitzung jedes Mal, wenn das Fenster voll wird, zu einer einzigen verlustbehafteten Zusammenfassung zu komprimieren, behält Co​dex mit GPT-6 Astra Notizen über Kontextfenster hinweg und lässt frühere Kontextfenster durchsuchbar, sodass eine Anforderung, die Sie vor vierzig Zügen genannt haben, und die Testausgabe, die vor zehn Zügen fehlgeschlagen ist, beide weiterhin abrufbar sind, statt durch eine Zusammenfassung verloren zu gehen. Ope​nAI nennt die Funktion experimentell, aktiviert sie mit einer Zeile in Ihrer Co​dex config.toml und sagt, dass sie zum Standard für Astra wird. Alles unten — die genaue Konfiguration, die Effort-Stufen, die gemessenen Ergebnisse und eine durchgerechnete Sitzungsrechnung, die die Zeile für gecachte Eingabe nennt — wurde am 2026-09-16 von Ope​nAIs eigenen Seiten gelesen, und jede Drittanbieter-Zahl ist als solche gekennzeichnet.

Diese Woche sind zwei Dinge passiert, die die Rechnung bei der Übernahme verändern. Am 2026-09-12 veröffentlichte der Codex-Lead von OpenAI eine Postmortem-Analyse, die bestätigte, dass das Kontextmanagement-Experiment selbst einen Bug hatte – es verursachte vorzeitige Abbrüche und Antworten auf veraltete Nachrichten und wurde für die rund 4.000–5.000 Nutzer, die es nutzten, deaktiviert – und OpenAI setzte um Mitternacht vom 09-12 auf den 09-13 das Nutzungskontingent für Codex- und Astra-Nutzer vollständig zurück. In derselben Woche wurden Enterprise-Workspaces, bei denen Astra zum Start standardmäßig deaktiviert war, unter ihrer eigenen Rate Card administrierbar. Die ehrliche Einschätzung ist also: Der Mechanismus ist es wert, übernommen zu werden, der Build bewegt sich noch unter Ihren Füßen, und Sie sollten ihn eher in einem Branch ausprobieren als auf eine Deadline hin.

Was ist in Codex mit GPT-6 Astra tatsächlich neu?

Bitten Sie einen beliebigen Coding-Agenten, sechs Stunden lang zu arbeiten, und Sie stoßen an dieselbe Wand. Das Kontextfenster füllt sich, das Harness fasst das Transkript zu einem einzigen dichten Block zusammen, um Platz zu schaffen, und die Zusammenfassung ist verlustbehaftet – und zwar genau auf die Art, die weh tut: der Grund, warum ein früherer Fix fehlschlug, die exakte Gestalt eines fehlschlagenden Tests, eine Einschränkung, die der Nutzer im dritten Turn nebenbei erwähnt hat. Abgerufene Details, nicht zusammengefasste Details, sind das, was Sie eigentlich wollten.

Astras Codex-Integration verändert die Gestalt davon. Die Codex-Dokumentation von OpenAI sagt es unmissverständlich: „Astra führt Notizen über Kontextfenster hinweg und kann frühere Nachrichten und Tool-Ergebnisse aus derselben Aufgabe durchsuchen.“ Notizen sind dauerhaft und beschreibbar; die dahinterliegende Historie bleibt lesbar, sodass ein früheres Kontextfenster weiterhin nach den ursprünglichen Belegen durchsucht werden kann, selbst nachdem die Notiz darüber geschrieben wurde. Anforderungen und Testergebnisse aus früheren Nachrichten und Tool-Ausgaben bleiben auffindbar.

OpenAI stellt ausdrücklich klar, dass dies keine fertige Arbeit ist. Die Konfigurationsreferenz beschreibt das Flag als „Experimentelle Kontextverwaltung aktivieren (standardmäßig deaktiviert)“ und sagt über die Funktion, dass sie „Notizen und durchsuchbare Historie verwendet, um angesammelte Details zu bewahren“. Die Dokumentation gibt außerdem an, dass sie „zum Start nicht mit Business, Enterprise oder Anmeldung per API-Schlüssel verfügbar ist“. Auch das ist kein unendlicher Kontext – das Modell denkt weiterhin innerhalb eines endlichen Fensters, und jedes Zurücklesen einer früheren Notiz verbraucht das Eingabebudget des jeweiligen Turns. Laut der Modelldokumentation von OpenAI umfasst das Fenster 1.050.000 Token bei maximal 922.000 Eingabe-Token; der Notizmechanismus setzt darauf auf, ersetzt es aber nicht.

Die Konfiguration, genau so, wie Ope​nAI sie dokumentiert

Die Einstellung ist ein Kind der Tabelle [features] in deiner Codex config.toml – die Datei liegt in ~/.codex/, sofern du CODEX_HOME nicht überschrieben hast. Der dokumentierte Schlüsselpfad ist features.context_management.experimental_mode, ein Boolean, und der Wert ist true:

[features.context_management]
experimental_mode = true

Wenn Sie in der Datei bereits eine [features]-Tabelle haben, fügen Sie den zugehörigen Schlüssel darin ein, anstatt die Tabelle zweimal zu deklarieren:

[features]
context_management.experimental_mode = true

Verwende die eine oder die andere Form. Community-Berichte zu dem Flag berichten, dass das Deklarieren des gepunkteten Pfads an der Wurzel und das anschließende Öffnen einer [features]-Tabelle weiter unten in derselben Datei beim Parsen als erneut deklarierte Tabelle fehlschlagen kann, was eine TOML-Regel und keine OpenAI-Regel ist — aber es trifft Leute, also wähle eine Form und bleib dabei. Starte nach der Bearbeitung eine neue Aufgabe: Die Einstellung wird nicht nachträglich auf eine bereits laufende Sitzung angewendet.

Die Modellhälfte derselben Datei ist unbemerkenswert, und OpenAIs Referenz dokumentiert diese Schlüssel direkt – model ist „Zu verwendendes Modell“, model_provider ist standardmäßig openai:

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

Ein warnender Hinweis zum Lesen von Dokumentationsversionen. Die Co​dex-Konfigurationsreferenz listet model_reasoning_effort mit den akzeptierten Werten minimal, low, medium, high und xhigh auf und merkt an, dass xhigh modellabhängig ist – während die API-Modellseite von Ope​nAI für gpt-6-astra reasoning.effort als low, medium, high, xhigh und max dokumentiert. Der Client-Slider und die API beschreiben nicht dieselbe Menge. Setzen Sie effort daher explizit und bestätigen Sie, was Ihr Client akzeptiert hat, statt es anzunehmen.

Das Modell auswählen – und die Zugriffsregel, die viele auf dem falschen Fuß erwischt

Die Modelldokumentation von OpenAI für Codex gibt die CLI-Form direkt an: codex -m gpt-6-astra. In einer interaktiven Sitzung wechselt /model das Modell und passt den Reasoning-Aufwand an; bei einem One-Shot-Lauf funktioniert codex exec -m gpt-6-astra "Review the current changes" genauso. In der Desktop-App und der IDE-Erweiterung befindet sich die Modellsteuerung unter dem Composer.

Die Zugriffsregel ist der Punkt, an dem viele Leute Fehler machen, und es lohnt sich, sie zweimal zu lesen, weil die beiden Funktionen unterschiedliche Voraussetzungen haben:

• Das Modell — verfügbar über ChatGPT Work, Codex und die API sowie auch auf Microsoft Azure und AWS Bedrock. Auf der Startseite von OpenAI heißt es, Astra werde „heute für eine begrenzte Zahl von Organisationen ausgerollt und in den kommenden Tagen für alle ChatGPT Plus-, Pro-, Business- und Enterprise-Nutzer verfügbar sein".

• Die experimentelle Kontextverwaltung – enger gefasst. Die Dokumentation von Ope​nAI gibt an, dass sie „eine ChatGPT-Anmeldung bei Plus, Pro oder Pro Lite erfordert“ und dass sie „zum Start nicht mit Business-, Enterprise- oder API-Schlüssel-Anmeldung verfügbar ist“.

Die zweite Zeile ist die, die es zu verinnerlichen gilt. Du kannst gpt-6-astra mit einem API-Schlüssel aufrufen, und du kannst dafür mit einem Business-Plan bezahlen – aber die fensterübergreifende Notizen-Funktion wird es dort nicht geben. Wenn der Notizmechanismus der Grund für deinen Wechsel ist, brauchst du eine Plus-, Pro- oder Pro-Lite-ChatGPT-Anmeldung im Co​dex-Client, keinen API-Schlüssel. Ope​nAI formuliert es als Verfügbarkeit, die von „dem Rollout, deiner Anmeldemethode und deinem Client“ abhängt, was die höfliche Version desselben Sachverhalts ist.

Zwei weitere Vorbehalte, gekennzeichnet als berichtet und nicht als vom Anbieter dokumentiert. Die Berichterstattung zum Rollout besagt, dass Co​dex CLI Version 0.153.0 oder höher für Astra erforderlich ist; diese Mindestversion konnten wir auf Ope​nAIs eigenen Seiten nicht bestätigen. Und die Co​dex-Dokumentation beschreibt Presets für die Modellauswahl – Astra Light, Astra Medium, Astra Extra High –, die berechtigten Pro-, Business- ($100) und Enterprise-Konten zusammen mit dem Reasoning-Slider angeboten werden. Dabei handelt es sich um Positionen in der Auswahlliste, nicht um separate Produkte: Ope​nAI dokumentiert eine Modell-ID, gpt-6-astra, mit einem Satz Spezifikationen und einem Preis und veröffentlicht keine separate Spezifikation oder Preisangabe für eine „Astra Pro“- oder „Astra Medium“-Konfiguration. Jede für eine benannte Astra-Stufe angeführte Zahl ist als unbestätigt zu behandeln.

Wenn Sie das Modell ausprobieren möchten, bevor Sie sich mit einem Produktionspfad darauf festlegen, ist es der günstige Weg, es über einen einzigen Endpunkt neben Ihrem aktuellen Modell laufen zu lassen, um es herauszufinden – GPT-6 Astra ist im OrcaRouter-Katalog, sodass ein Vergleichslauf Sie lediglich einen Modell-String statt eines zweiten Vertrags und eines zweiten SDK kostet.

Reasoning-Aufwand: Fünf Stufen und was jede kostet

Die API-Dokumentation von OpenAI für gpt-6-astra listet fünf Effort-Level auf – low, medium, high, xhigh und max – und die Codex-Anleitung ist unverblümt, was ihre Verwendung angeht: „Verwenden Sie den niedrigsten Reasoning-Aufwand, der das benötigte Ergebnis liefert“, und beginnen Sie mit dem Standardwert, erhöhen Sie ihn, wenn eine Aufgabe tiefergehende Planung erfordert.

Der Grund, warum es teuer ist, diesen Rat ausgerechnet bei diesem Modell zu ignorieren, liegt darin, wo Reasoning-Tokens auf der Rechnung landen. Reasoning-Tokens sind Output-Tokens, und Output kostet bei Astra 50,00 $ pro Million – zehnmal so viel wie der Input-Tarif und fünfzigmal so viel wie der Tarif für gecachten Input. Die Abwägung ist also nicht abstrakt:

• Für jeweils zusätzliche 1.000 Reasoning-Tokens pro Turn fallen zum Ausgabetarif 0,05 $ an.

• Über eine Sitzung mit 150 Turns hinweg kostet das Vorhalten von 1.000 zusätzlichen Reasoning-Tokens pro Turn etwa 7,50 $; 5.000 zusätzliche kosten etwa 37,50 $.

• In der unten durchgerechneten Sitzung ist die Ausgabe mit 0,200 $ pro Turn gegenüber 0,090 $ an Cache-Lesevorgängen bereits der größte Einzelposten — das Reasoning-Wachstum ist die Größe, die die Gesamtsumme am schnellsten bewegt.

Was OpenAI nichtveröffentlicht, ist eine Tabelle pro Effort-Stufe: Es gibt keine Herstellerangabe dazu, wie viele Reasoning-Tokens xhigh oder max bei einer Coding-Aufgabe im Verhältnis zu medium ausgeben, und keinen Hersteller-Benchmark, der nach Effort-Stufe aufgeschlüsselt ist. Wer Ihnen ein präzises Verhältnis wie „max kostet 2x" nennt, zitiert seine eigene Messung, nicht die von OpenAI. Die ehrliche Methode ist, eine repräsentative Aufgabe auf zwei Effort-Stufen auszuführen und den Usage-Block in der Antwort zu lesen – diese Zahl, multipliziert mit 50 $ pro Million, ist Ihr tatsächlicher Effort-Aufschlag.

Die Messergebnisse, jeweils mit eigener Quelle

Coding- und Terminal-Arbeiten, alle vom Anbieter OpenAI gemeldet, sofern nicht anders gekennzeichnet. Terminal-Bench 4.0: GPT-6 Astra bei 57,9 % gegenüber 37,3 % für GPT-5.6 Sol und 55,8 % für Claude Fable 5.1 — wobei OpenAI schätzt, dass die API-Kosten pro Aufgabe im Vergleich zu GPT-5.6 Sol um etwa 9 % und im Vergleich zu Claude Fable 5.1 um 63 % niedriger liegen. Datacurves DeepSWE v1.1 setzt Astra mit 74,1 % in Datacurves eigenem Benchmark an, ein Wert, den Datacurve als neuen Rekord bezeichnet und den einige Berichte auf 74 % runden. Im breiteren agentischen Set meldet OpenAI OSWorld 2.0 mit 72,6 % bei etwa 40 Minuten pro Aufgabe — rund 47 % weniger Zeit pro Aufgabe als GPT-5.6 Sol — daneben FrontierMath Tier 4 mit 98 %, ARC-AGI-3 mit 99,9 % und ExploitBench mit 100 %, die alle von OpenAI als gesättigte oder praktisch gesättigte Stufen beschrieben werden. Das sind die Zahlen des Anbieters; wir haben sie nicht reproduziert, und eine unabhängige Prüfung der ARC-AGI-3-Zahl durch ARC Prize ergab, dass sie in einer speziellen Provider-Adapter-Umgebung gemessen wurde und unter Standardbedingungen niedriger ausfällt.

Die Kennzahl, die keine Anbieterkennzahl ist, ist diejenige, um die sich ein Code-Review-Workflow am meisten kümmern sollte. CodeRabbit hat am 4. September 2026 seine eigene Bewertung von Astra veröffentlicht, und das Ergebnis ist enger als die Schlagzeile. Bei dateiübergreifenden Pull Requests – den schwierigen Reviews, bei denen eine Änderung mit ihren Folgen an anderen Stellen der Codebasis verknüpft werden muss – fand Astra etwa 20 % mehr Bugs als GPT-5.6 Sol, mit einer Abdeckung handlungsrelevanter Bugs von 57,1 % gegenüber 47,6 %. Bei den Gesamtreviews verflüchtigt sich der Gewinn weitgehend: 61,3 % gegenüber 59,0 %, rund 4 % mehr. CodeRabbit bezeichnet beide als „frühe, richtungsweisende Ergebnisse“, die keine Rangfolge belegen, und merkt an, dass seine Methode die Ursache der Verbesserung nicht isoliert. Die Launch-Seite von Ope​nAI bezeichnet dieselbe Arbeit als „mehr als doppelt so hoch bei dateiübergreifenden Pull Requests“; CodeRabbits eigene Darstellung nennt die 20 % und die oben genannten Abdeckungsprozentsätze. Lesen Sie die Prozentzahlen, nicht die Zusammenfassung.

Diese Asymmetrie ist die mit Abstand nützlichste Zahl auf dieser Seite, um zu entscheiden, wie das Modell eingesetzt werden sollte, und sie weist in dieselbe Richtung wie der Preis: Der Gewinn konzentriert sich auf dateiübergreifendes Reasoning, also ist es genau dort, wo man das Modell einsetzt.

Was die Computernutzung in Co​dex für deinen Workflow ändert

OpenAI sagt, dass das aktualisierte Codex-Harness GPT-6 Astra bei der Aufgabenabwicklung auf Mind2Web 1,9-mal schneller macht als die aktuelle GPT-5.6-Sol-Erfahrung. Mind2Web ist Web-Aufgaben-Automatisierung, das heißt: Agentenarbeit, die einen Browser oder eine GUI berühren muss, wird wesentlich schneller abgeschlossen, und dasselbe aktualisierte Harness ist das, was Sie ausführen, wenn Sie Codex überhaupt steuern. Die begleitende Zahl ist das oben stehende OSWorld-2.0-Ergebnis – 72,6 % bei ungefähr 40 Minuten pro Aufgabe, etwa 47 % weniger Zeit pro Aufgabe als Sol.

Für Entwickler besteht die praktische Konsequenz darin, dass sich verschiebt, was sich überhaupt zu delegieren lohnt. Workflows, die bisher zu langsam waren, um sie durchgängig zu automatisieren – eine Staging-Konsole ohne API bedienen, einen Bug über eine UI reproduzieren, ein mehrstufiges Formular durchlaufen, um eine Fixture zu erzeugen – rücken in den Bereich, in dem ein Agentenlauf günstiger ist als Handarbeit. Zugleich steigt der Wert der Enterprise-Kontrollen, die OpenAI zusammen damit ausgeliefert hat: ChatGPT Work und Codex ergänzen Bestätigungsrichtlinien, also eine Genehmigung vor folgenreichen Aktionen, sowie eine automatisierte Prüfung unsicherer oder nicht autorisierter Tool-Aufrufe. Wenn man einen Agenten durch eine echte Oberfläche klicken lässt, ist diese Prüfschicht das, was zwischen einem schlechten Lauf und einem schlechten Nachmittag steht – und sie ist der Grund, warum der standardmäßig deaktivierte Enterprise-Zugang, den ein Administrator gemäß der geltenden Preisliste freischaltet, eine Governance-Funktion und kein Hindernis ist.

Den Workflow bepreisen, nicht das Token

Hier ist der Preis, mit Namen und Datum. Von der Preisseite von OpenAI, abgerufen am 2026-09-16, kostet gpt-6-astra standard 10,00 $ pro Million Eingabe-Token, 1,00 $ pro Million zwischengespeicherter Eingabe-Token, 12,50 $ pro Million Cache-Schreibvorgänge und 50,00 $ pro Million Ausgabe-Token. Batch und Flex werden zu den halben Sätzen abgerechnet; der Fast-Modus verdoppelt sie. Die Zeile für zwischengespeicherte Eingaben ist diejenige, die über Ihre Rechnung in einer agentischen Schleife entscheidet, denn ein Coding-Agent sendet bei jedem einzelnen Turn einen großen, größtenteils unveränderten Kontext erneut, und zwischengespeicherte Eingaben kosten ein Zehntel frischer Eingaben.

Zwei Schwellenwerte sind vor der Berechnung entscheidend. In der Modelldokumentation von OpenAI heißt es, dass Prompts mit mehr als 272.000 Eingabe-Tokens mit dem 2-fachen Eingabe- und Cache-Tarif sowie dem 1,5-fachen Ausgabe-Tarif berechnet werden für die gesamte Anfrage – nicht nur für den überschüssigen Teil –, und auf der Preisseite steht die Zeile für langen Kontext mit 20,00 $ Eingabe, 2,00 $ gecachte Eingabe und 75,00 $ Ausgabe. Und jedes Reasoning-Token wird zum Ausgabe-Tarif abgerechnet, wie oben beschrieben.

Nehmen wir ein realistisches nächtliches Refactoring: 150 Modell-Turns, durchschnittlich 100.000 Input-Tokens pro Turn, wovon 90.000 über Cache-Reads und 10.000 frisch anfallen, sowie 4.000 Output-Tokens pro Turn einschließlich Reasoning. Unter der 272K-Schwelle, zu Standardtarifen:

• Zwischengespeicherte Eingabe — 90.000 Tokens × 1,00 $ pro Million = 0,090 $ pro Turn

• Neuer Input — 10.000 Tokens × 10,00 $ pro Million = 0,100 $ pro Turn

• Ausgabe — 4.000 Tokens × 50,00 $ pro Million = 0,200 $ pro Runde

• Gesamt — 0,390 $ pro Zug, 150 Züge kosten für die Sitzung also etwa 58,50 $.

Bringen Sie nun dieselbe Sitzung über die Schwelle. Bei 300.000 Eingabe-Token pro Turn – 270.000 zwischengespeichert, 30.000 frisch – wird die gesamte Anfrage neu bepreist, sodass sich der zwischengespeicherte Input auf $2,00 verdoppelt, der frische Input auf $20,00 verdoppelt und der Output auf $75,00 steigt:

• Zwischengespeicherte Eingabe — 270.000 × 2,00 $ pro Million = 0,540 $ pro Turn

• Neue Eingabe — 30.000 × 20,00 $ pro Million = 0,600 $ pro Turn

• Ausgabe — 4.000 × 75,00 $ pro Million = 0,300 $ pro Runde

• Gesamt — 1,44 $ pro Zug, oder etwa 216,00 $ für 150 Züge

Gleiche Aufgabenstruktur, rund 3,7-mal so hohe Rechnung, und der gesamte Unterschied besteht darin, auf welcher Seite von 272.000 Tokens dein Transkript liegt. Das ist das Argument für den Notizmechanismus in einem Satz: Wenn dauerhafte Notizen und durchsuchbare Historie es dir ermöglichen, einen Arbeitskontext schlanker zu halten, anstatt das gesamte Transkript mitzuschleppen, dann rechnet sich das Feature über Eingabe-Tokens, noch bevor es überhaupt der Qualität hilft. Es ist auch das Argument dafür, zu verhindern, dass ein unbeaufsichtigter Lauf ein Transkript ohne Obergrenze anwachsen lässt.

Zum Vergleich: Dieselbe 150-Turn-Sitzung beim selben Token-Profil auf den günstigeren Tarifstufen kostet mit GPT-5.6 Terra zu den veröffentlichten Preisen von $2,00 für Eingabe / $0,20 für Cache / $12,00 für Ausgabe etwa $12,90, und GPT-5.6 Luna kommt bei $0,20 / $0,02 / $1,20 auf rund $1,29. Das ist reine Arithmetik auf Basis der von Ope​nAI veröffentlichten Preise, keine Behauptung, dass sie dieselbe Aufgabe abschließen würden — und genau darum geht es in den nächsten beiden Abschnitten.

Wenn Sie all das über verschiedene Anbieter hinweg vergleichen, lohnt es sich zu wissen, dass OrcaRouter den Listenpreis des Anbieters mit 0 % Aufschlag weitergibt, sodass eine Preisänderung eines Anbieters noch am selben Tag am gerouteten Endpoint live ist und nicht erst bei der nächsten Rechnung.

Die Fehlermodi, die bei der Konstruktion berücksichtigt werden müssen

Astra ist ein Long-Horizon-Modell mit einem Long-Context-Design, und beide Hälften dieser Beschreibung sind genau da, wo die Probleme liegen. Das sind Community-Erkenntnisse und Anbieter-Postmortems, nicht unsere Messungen.

• Das Kontextmanagement-Experiment hatte diese Woche einen Bug. OpenAIs Postmortem vom 2026-09-12 bestätigt, dass das Opt-in-Experiment „vorzeitige Abbrüche und Antworten auf veraltete Nachrichten verursachte“, wovon rund 4.000–5.000 Nutzer betroffen waren, und es wurde deaktiviert. Dasselbe Postmortem nennt zwei weitere Ursachen für die Qualitätsbeschwerden in der Startwoche: für frühere Modelle geschriebene Skills, die fälschlicherweise ausgelöst wurden und Astra daran hinderten, ihre eigene Arbeit zu überprüfen, sowie fehlkonfigurierte Serving-Engines, die einen Tail des Traffics beeinträchtigten. Ein Nutzungsreset folgte um Mitternacht vom 09-12. auf den 09-13.

• Übermäßiges Nachdenken und Test-Wildwuchs. Ein viel geteilter r/codex-Thread beschreibt, wie Astra auf eine kleine Feature-Anfrage reagiert, indem es zuerst Ebenen der Verifikation, Smoke-Tests und Hash-Prüfungen aufbaut, sie in mehreren Reihenfolgen ausführt und die Nutzungsanzeige als nahezu erschöpft meldet, lange bevor es das Feature überhaupt gab. Bei den Berichten handelt es sich um Einzelschilderungen statt um kontrollierte Messungen, und ähnliche Beschwerden kursierten im Vormonat über andere Frontier-Modelle — behandle es also als ein reales Muster, gegen das du den Umfang abgrenzen kannst, nicht als eine Rate, auf die du verlässlich planen kannst.

• Läufe, die nicht terminieren. Armin Ronacher, der Schöpfer von Flask, beschrieb, wie er Astra 35 Stunden lang in einem unbeaufsichtigten Lauf laufen ließ, an dessen Ende es etwa 75.000 Nettozeilen über 79 Commits, rund 1.400 Agent-zu-Agent-Nachrichten und etwa 1.200 US-Dollar an API-Gebühren produziert hatte — etwa 15,50 US-Dollar pro Commit —, wobei seiner Einschätzung nach nichts von Wert geliefert wurde. Die Berichte über die Token-Anzahl variieren, daher sollte man diese Zahl als grobe Richtgröße betrachten. Er bezeichnete die fehlende Abbruchbedingung als ebenso sehr ein Harness-Problem wie ein Modellproblem, was die praktisch umsetzbare Lesart ist: Definieren Sie den Abschluss, bevor Sie beginnen.

• Auch der umgekehrte Fehlerfall existiert. Community-Berichte beschreiben, dass Astra vor einer abgeschlossenen Aufgabe stoppt und auf eine Aufforderung zur Fortsetzung wartet – dieselbe Ursache, nur von der anderen Seite betrachtet: eine unzureichend definierte Vorstellung davon, was „fertig“ bedeutet. „Fertig“ explizit zu definieren, ist die wertvollste einzelne Zeile in deinem Aufgaben-Prompt.

• Lange Sitzungen können unrettbar werden. Offene Codex-Issues berichten von einem Catch-22: Das Kontextfenster füllt sich, die automatische Kompaktierung wird ausgelöst, die Kompaktierungsaufgabe selbst läuft aus dem Kontext, und der Thread kann nicht wiederhergestellt werden — und separat davon, dass die nativen Notizen- und Verlaufsrouten auf Pro mit Astra in manchen Konfigurationen 404 zurückgeben, während ein Fensterwechsel den Aufgabenstatus verwerfen kann. Beides sind offene Berichte und keine Herstelleraussagen, aber sie sprechen dafür, Läufe in Git mit Checkpoints zu versehen, statt darauf zu vertrauen, dass die Sitzung überlebt.

• Veraltete Notizen sind eine Designeigenschaft, kein Fehler. Nichts garantiert, dass eine Notiz den aktuellen Zustand einer Datei widerspiegelt, die sie beschreibt, und die Suche ist ein wörtlicher Teilstring-Abgleich statt semantisch. Speichere den Quellpfad zusammen mit der Notiz, verifiziere bei Änderungen erneut, und behandle die Notizen eines unbeaufsichtigten Laufs als zu prüfende Belege statt als verlässliche Wahrheit.

• Nutzungsobergrenzen sind der aktuelle Beschwerdepunkt. Berichte aus der Woche vom 14.09.2026 nennen Obergrenzen, die bis zu viermal strenger sind als in der Startwoche, sowie eine ungeklärte Beschwerde, dass xhigh-Aufwand weniger des Kontingents verbraucht als medium – was, falls es zutrifft, bedeutet, dass Aufwand und Kontingent nicht im Gleichschritt laufen. OpenAI hat für Astra keine zahlenmäßigen Obergrenzen je Plan veröffentlicht.

Wann ein günstigeres Modell die richtige Wahl ist

Die oben gemessenen Ergebnisse treffen die Routing-Entscheidung für Sie. Astras Vorteil konzentriert sich auf Arbeit, die sich über Dateien oder über Stunden erstreckt: dateiübergreifende Reviews, langfristige agentische Aufgaben, Computer-Use-Flows. Bei gewöhnlichen Einzeldatei-Bearbeitungen, mechanischen Refactorings, Test-Scaffolding und Formatierung rechtfertigt das ~4 % Gesamt-Review-Delta gegenüber GPT-5.6 Sol nicht den ungefähr 2,5-fachen aktuellen Preis pro Token — und CodeRabbits eigene Schlussfolgerung weist in dieselbe Richtung und empfiehlt intelligentes Task-Routing statt eines vollständigen Ersatzes. Reservieren Sie das teure Modell für die Aufgaben, bei denen sein Vorsprung sichtbar wird, und routen Sie den Rest nach unten.

Konkret eine funktionierende Aufteilung: GPT-6 Astra für dateiübergreifende Änderungen, unbekannte Codebasen, mehrstündige Agent-Läufe und alles, was mit einem Browser zu tun hat; GPT-5.6 Terra für abgegrenzte Änderungen, Boilerplate und Testgenerierung; GPT-5.6 Luna für Klassifizierung, Extraktion und mechanische Massendurchläufe. Mit der obigen Sitzungsrechnung ist der Unterschied zwischen dem Ausführen von allem auf Astra und dem Ausführen eines Drittels davon auf Astra der Unterschied zwischen ungefähr 58,50 $ und ungefähr 28 $ für dieselben 150 Turns.

Diese Aufteilung richtig hinzubekommen, ist genau das, wofür eine Routing-Schicht da ist. OrcaRouter stellt 200+ Modelle hinter einer einzigen API, sodass die obige Aufteilung eine Konfigurationsänderung ist statt drei Integrationen — und automatisches Failover bedeutet, dass ein experimentelles Feature, das gerade eine schlechte Woche hat, wie es bei diesem der Fall war, deinen Lauf beeinträchtigt, statt ihn zu beenden. Für ein Modell, dessen Kontextmechanismus selbst Ope​nAI noch als experimentell einstuft und kurzzeitig deaktiviert hat, ist ein konfigurierter zweiter Pfad keine Paranoia; es ist das richtige Maß an Vorsicht.

Was von hier aus zu beobachten ist

Vier Dinge würden diese Seite verändern, und alle vier sind offen. Ob das Kontextmanagement-Experiment wieder eingeschaltet wird und in welcher Form – OpenAI sagt, es werde zum Standard für Astra, was bedeutet, dass die Konfigurationszeile oben irgendwann nicht mehr etwas ist, das man selbst festlegt. Ob die 404-Meldungen zu Notizen und Verlauf bei Pro geschlossen werden, denn das ist der Unterschied zwischen einem Mechanismus, der wie dokumentiert funktioniert, und einem, der auf manchen Routen funktioniert. Ob OpenAI irgendwelche Token- oder Kostendaten pro Effort veröffentlicht, also die Zahl, die heute bei jeder Effort-Entscheidung fehlt. Und ob die Nutzungslimits, die während der Launch-Woche verschärft wurden, gelockert werden, sobald die Nachfrage absorbiert ist, die am 2026-09-10 neue $200-Pro-Abonnements pausiert hat.

Bis dahin ist das Playbook kurz. Fixiere das Modell mit codex -m gpt-6-astra, aktiviere das Experiment nur, wenn du im Client eine Plus-, Pro- oder Pro-Lite-Anmeldung hast, lege den Effort explizit fest, statt einem Slider-Label zu vertrauen, halte deinen Arbeitskontext unter 272.000 Tokens, denn dort verdoppelt sich die Rechnung, definiere „fertig“, bevor du weggehst, und leite die einfache Arbeit an eine günstigere Stelle weiter. Das Modell ist vom 2026-09-03 und es wird nicht verschwinden; das Tooling darum herum ist das, was sich noch setzt.

Die Fragen, die aufkommen

Lohnt es sich, die fensterübergreifende Notizfunktion für Aufgaben normaler Größe zu aktivieren?Im Allgemeinen nein. Sie existiert, um Verluste über Kontextfenstergrenzen hinweg zu beheben. Bei einer Aufgabe, die in ein einziges Fenster passt, fügt sie also bewegliche Teile hinzu – darunter einen experimentellen Codepfad, der am 12.09.2026 wegen eines Fehlers deaktiviert wurde –, ohne irgendeinen Schmerz zu lindern. Schalten Sie sie für langfristig angelegte Arbeit ein und lassen Sie sie bei einer klar abgegrenzten Änderung aus.

Kann das 1.050.000-Token-Fenster in meinem Setup das Retrieval ersetzen? Aus Kostengründen nicht. Das erneute Lesen eines großen Kontexts wird bei jeder Runde berechnet, und oberhalb von 272.000 Eingabe-Tokens ändert sich der Preis für die gesamte Anfrage auf 20,00 $ für die Eingabe und 75,00 $ für die Ausgabe. Ein Retrieval-Schritt, der den Arbeitskontext kleiner hält, ist in der Regel das günstigere Design, weshalb der Notizmechanismus interessant ist: Er ist Retrieval, das direkt in das Harness eingebaut ist.

Was passiert mit den Notizen, wenn eine Aufgabe endet? OpenAIs Dokumentation beschränkt den Mechanismus auf dieselbe Aufgabe, und Community-Beiträge beschreiben die Notizen als zu dieser Aufgabe gehörend gespeichert, statt automatisch weitergetragen zu werden. Gehen Sie nicht davon aus, dass eine neue Aufgabe die Notizen der vorherigen erbt; alles, was erhalten bleiben muss, gehört in Ihr Repository, nicht in den Speicher des Agenten.