GPT-6 Astra in Codex: Cross-Window Notes, Effort Levels, and the Real Bill

GPT-6 Astra is a 2026-09-03 model, and this page is not launch coverage — it is the reference for pointing your coding agent at it now that it is broadly available. The reason a developer would switch is one specific mechanic, and it is worth understanding before you spend anything on it: instead of compacting a long session into a single lossy summary every time the window fills, Co​dex with GPT-6 Astra keeps notes across context windows and leaves earlier context windows searchable, so a requirement you stated forty turns ago and the test output that failed ten turns ago are both still retrievable rather than summarised away. Ope​nAI calls the feature experimental, enables it with a line in your Co​dex config.toml, and says it will become the default for Astra. Everything below — the exact config, the effort levels, the measured results, and a worked session bill that names the cached-input line — was read from Ope​nAI's own pages on 2026-09-16, and every third-party figure is labelled as such.

Two things happened this week that change the arithmetic on adopting it. On 2026-09-12 Ope​nAI's Co​dex lead published a postmortem confirming that the context-management experiment itself had a bug — it caused premature stops and replies to stale messages, and was disabled for the roughly 4,000–5,000 users on it — and Ope​nAI issued a full usage reset for Co​dex and Astra users at midnight on 09-12 into 09-13. The same week, enterprise workspaces that had Astra off by default at launch became administrable under their own rate card. So the honest position is: the mechanism is worth adopting, the build is still moving under you, and you should try it on a branch rather than a deadline.

What is actually new in Co​dex with GPT-6 Astra

Ask any coding agent to work for six hours and you hit the same wall. The context window fills, the harness summarises the transcript into one dense block to make room, and the summary is lossy in exactly the way that hurts — the reason an earlier fix failed, the exact shape of a failing test, a constraint the user mentioned in passing on turn three. Retrieved detail, not summarised detail, is the thing you actually wanted.

Astra's Co​dex integration changes the shape of that. Ope​nAI's Co​dex documentation states it plainly: "Astra keeps notes across context windows and can search earlier messages and tool results from the same task." Notes are durable and writable; the history behind them stays readable, so an earlier window can still be searched for the original evidence even after the note about it was written. Requirements and test results from earlier messages and tool output remain findable.

Ope​nAI is explicit that this is not finished work. Its configuration reference describes the flag as "Enable experimental context management (off by default)" and says the feature "uses notes and searchable history to preserve accumulated details". The documentation also states it "isn't available with Business, Enterprise, or API-key sign-in at launch". This is not infinite context, either — the model still reasons inside a finite window, and every read-back of an earlier note consumes that turn's input budget. The window is 1,050,000 tokens with a maximum of 922,000 input tokens, per Ope​nAI's model documentation; the notes mechanism sits on top of that, it does not replace it.

The config, exactly as Ope​nAI documents it

The setting is a child of the [features] table in your Co​dex config.toml — the file lives in ~/.codex/ unless you have overridden CODEX_HOME. The documented key path is features.context_management.experimental_mode, a boolean, and the value is true:

[features.context_management]
experimental_mode = true

If you already have a [features] table in the file, add the relative key inside it instead of declaring the table twice:

[features]
context_management.experimental_mode = true

Use one form or the other. Community write-ups of the flag report that declaring the dotted path at the root and then opening a [features] table later in the same file can fail to parse as a redeclared table, which is a TOML rule rather than an Ope​nAI one — but it bites people, so pick a form and stay with it. After editing, start a new task: the setting does not retro-fit itself onto a session already running.

The model half of the same file is unremarkable, and Ope​nAI's reference documents these keys directly — model is "Model to use", model_provider defaults to openai:

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

One caution on reading documentation versions. The Co​dex configuration reference lists model_reasoning_effort as accepting minimal, low, medium, high and xhigh, noting xhigh is model-dependent — while Ope​nAI's API model page for gpt-6-astra documents reasoning.effort as low, medium, high, xhigh and max. The client slider and the API do not describe the same set, so set effort explicitly and confirm what your client accepted rather than assuming.

Selecting the model — and the access rule that catches people out

Ope​nAI's Co​dex model documentation gives the CLI form directly: codex -m gpt-6-astra. In an interactive session, /model switches the model and adjusts reasoning effort; on a one-shot run, codex exec -m gpt-6-astra "Review the current changes" works the same way. In the desktop app and the IDE extension, the model control sits beneath the composer.

The access rule is where people go wrong, and it is worth reading twice because the two features have different gates:

• The model — available across ChatGPT Work, Co​dex and the API, and also served on Microsoft Azure and AWS Bedrock. Ope​nAI's launch page says Astra was "rolling out today to a limited set of organizations and over the coming days will become available to all ChatGPT Plus, Pro, Business, and Enterprise users".

• The experimental context management — narrower. Ope​nAI's documentation states it "Requires ChatGPT sign-in on Plus, Pro, or Pro Lite" and that it "isn't available with Business, Enterprise, or API-key sign-in at launch".

That second line is the one to internalise. You can call gpt-6-astra on an API key, and you can pay for it on a Business plan — but the cross-window notes feature will not be there. If the notes mechanism is the reason you are switching, you need a Plus, Pro or Pro Lite ChatGPT sign-in in the Co​dex client, not an API key. Ope​nAI frames it as availability depending on "the rollout, your sign-in method, and your client", which is the polite version of the same thing.

Two further caveats, labelled as reported rather than vendor-documented. Coverage of the rollout states that Co​dex CLI version 0.153.0 or later is required for Astra; we could not confirm that version floor on Ope​nAI's own pages. And the Co​dex documentation describes model-picker presets — Astra Light, Astra Medium, Astra Extra High, offered to eligible Pro, Business ($100) and Enterprise accounts alongside the reasoning slider. Those are picker positions, not separate products: Ope​nAI documents one model id, gpt-6-astra, with one set of specs and one price, and publishes no separate specification or rate for any "Astra Pro" or "Astra Medium" configuration. Treat any figure quoted for a named Astra tier as unverified.

If you want to try the model before committing a production path to it, routing it through one endpoint alongside your current model is the cheap way to find out — GPT-6 Astra is in the OrcaRouter catalog, so a comparison run costs you a model string rather than a second contract and a second SDK.

Reasoning effort: five levels, and what each one costs

Ope​nAI's API documentation for gpt-6-astra lists five effort levels — low, medium, high, xhigh and max — and the Co​dex guidance is blunt about how to use them: "Use the lowest reasoning effort that produces the result you need," and start at the default, raising it when a task needs deeper planning.

The reason that advice is expensive to ignore on this model specifically is where reasoning tokens land on the bill. Reasoning tokens are output tokens, and output on Astra is $50.00 per million — ten times the input rate and fifty times the cached-input rate. So the trade is not abstract:

• Each additional 1,000 reasoning tokens per turn costs $0.05 at the output rate.

• Across a 150-turn session, holding 1,000 extra reasoning tokens per turn costs about $7.50; holding 5,000 extra costs about $37.50.

• In the worked session below, output is already the largest single line at $0.200 per turn against $0.090 of cache reads — reasoning growth is the term that moves the total fastest.

What Ope​nAI does not publish is a per-effort table: there is no vendor figure for how many reasoning tokens xhigh or max emits on a coding task relative to medium, and no vendor benchmark broken out by effort. Anyone quoting you a precise "max costs 2x" ratio is quoting their own measurement, not Ope​nAI's. The honest method is to run one representative task at two effort levels and read the usage block in the response — that number, multiplied by $50 per million, is your real effort premium.

The measured results, each with its own source

Coding and terminal work, all vendor-reported by Ope​nAI unless marked otherwise. Terminal-Bench 4.0: GPT-6 Astra at 57.9%, against 37.3% for GPT-5.6 Sol and 55.8% for Claude Fable 5.1 — with Ope​nAI estimating approximately 9% lower API cost per task against GPT-5.6 Sol and 63% lower against Claude Fable 5.1. Datacurve's DeepSWE v1.1 puts Astra at 74.1% on Datacurve's own benchmark, a figure Datacurve describes as a new record and which some coverage rounds to 74%. On the wider agentic set, Ope​nAI reports OSWorld 2.0 at 72.6% at roughly 40 minutes per task — about 47% less time per task than GPT-5.6 Sol — alongside FrontierMath Tier 4 at 98%, ARC-AGI-3 at 99.9% and ExploitBench at 100%, all described by Ope​nAI as saturated or effectively saturated tiers. Those are the vendor's numbers; we have not reproduced them, and independent scrutiny of the ARC-AGI-3 figure by ARC Prize found it measured under a special provider-adapter environment and falling in standard conditions.

The piece that is not a vendor number is the one a code-review workflow should care about most. CodeRabbit published its own evaluation of Astra on 2026-09-04, and the result is narrower than the headline. On cross-file pull requests — the hard reviews that require connecting a change to consequences elsewhere in the codebase — Astra caught about 20% more bugs than GPT-5.6 Sol, with actionable bug coverage of 57.1% against 47.6%. On overall reviews the gain largely evaporates: 61.3% against 59.0%, roughly 4% more. CodeRabbit characterises both as "early, directional results" that do not establish a ranking, and notes its method does not isolate the cause of the improvement. Ope​nAI's launch page characterises the same work as "more than double on cross-file pull requests"; CodeRabbit's own write-up gives the 20% and the coverage percentages above. Read the percentages, not the summary.

That asymmetry is the single most useful number on this page for deciding how to deploy the model, and it points the same direction as the price: the gain is concentrated in cross-file reasoning, so that is where you spend the model.

What computer use in Co​dex changes for your workflow

Ope​nAI says the updated Co​dex harness makes GPT-6 Astra 1.9x faster at task completion on Mind2Web than the current GPT-5.6 Sol experience. Mind2Web is web-task automation, so read that as: agent work that has to touch a browser or a GUI finishes materially faster, and the same updated harness is what you are running when you drive Co​dex at all. The companion figure is the OSWorld 2.0 result above — 72.6% at roughly 40 minutes per task, about 47% less time per task than Sol.

For a developer the practical consequence is a change in what is worth delegating. Workflows that were previously too slow to automate end-to-end — driving a staging console with no API, reproducing a bug through a UI, walking a multi-step form to generate a fixture — come inside the range where an agent run is cheaper than doing it by hand. It also raises the value of the enterprise-side controls Ope​nAI shipped alongside: ChatGPT Work and Co​dex add confirmation policies, meaning approval before consequential actions, and automated review of unsafe or unauthorised tool calls. If you are letting an agent click through a real interface, that review layer is the thing standing between a bad run and a bad afternoon — and it is the reason enterprise access being off by default, with an administrator enabling it under the applicable rate card, is a governance feature rather than an obstacle.

Pricing the workflow, not the token

Here is the price, named and dated. From Ope​nAI's pricing page, read 2026-09-16, gpt-6-astra standard is $10.00 per million input tokens, $1.00 per million cached input tokens, $12.50 per million cache writes and $50.00 per million output tokens. Batch and Flex run at half those rates; Fast mode doubles them. That cached-input line is the one that decides your bill in an agentic loop, because a coding agent re-sends a large, mostly-unchanged context every single turn, and cached input costs one tenth of fresh input.

Two thresholds matter before the arithmetic. Ope​nAI's model documentation states that prompts above 272,000 input tokens are priced at 2x input and cache rates and 1.5x output for the full request — not just the excess — and the pricing page carries the long-context row at $20.00 input, $2.00 cached input and $75.00 output. And every reasoning token bills at the output rate, as covered above.

Take a realistic overnight refactor: 150 model turns, an average of 100,000 input tokens per turn of which 90,000 is a cache read and 10,000 is fresh, and 4,000 output tokens per turn including reasoning. Under the 272K threshold, at standard rates:

• Cached input — 90,000 tokens × $1.00 per million = $0.090 per turn

• Fresh input — 10,000 tokens × $10.00 per million = $0.100 per turn

• Output — 4,000 tokens × $50.00 per million = $0.200 per turn

• Total — $0.390 per turn, so 150 turns is about $58.50 for the session

Now move the same session over the threshold. At 300,000 input tokens per turn — 270,000 cached, 30,000 fresh — the whole request reprices, so cached input doubles to $2.00, fresh input doubles to $20.00 and output goes to $75.00:

• Cached input — 270,000 × $2.00 per million = $0.540 per turn

• Fresh input — 30,000 × $20.00 per million = $0.600 per turn

• Output — 4,000 × $75.00 per million = $0.300 per turn

• Total — $1.44 per turn, or about $216.00 for 150 turns

Same task shape, roughly 3.7x the bill, and the entire difference is which side of 272,000 tokens your transcript sits on. That is the argument for the notes mechanism in one line: if durable notes and searchable history let you keep a working context leaner instead of dragging the whole transcript forward, the feature pays for itself in input tokens before it ever helps with quality. It is also the argument for not letting an unattended run grow a transcript without a ceiling.

For scale, the same 150-turn session at the same token profile on the cheaper tiers: GPT-5.6 Terra at its published $2.00 input / $0.20 cached / $12.00 output comes to about $12.90, and GPT-5.6 Luna at $0.20 / $0.02 / $1.20 comes to roughly $1.29. Those are arithmetic on Ope​nAI's published rates, not a claim that they would finish the same task — which is the whole point of the next two sections.

If you are comparing all of this across providers, it is worth knowing that OrcaRouter passes provider list price through at 0% markup, so a vendor price change is live on the routed endpoint the same day rather than at the next invoice.

The failure modes to design around

Astra is a long-horizon model on a long-context design, and both halves of that description are where the problems live. These are community findings and vendor postmortems, not our measurements.

• The context-management experiment had a bug this week. Ope​nAI's 2026-09-12 postmortem confirms the opt-in experiment "caused early stops and replies to stale messages", affecting roughly 4,000–5,000 users, and it was disabled. The same postmortem names two other causes of the launch-week quality complaints: skills written for earlier models misfiring and preventing Astra from checking its own work, and misconfigured serving engines degrading a tail of traffic. A usage reset followed at midnight 09-12 into 09-13.

• Overthinking and test sprawl. A widely-shared r/codex thread describes Astra responding to a small feature request by first building layers of verification, smoke tests and hash checks, running them in several orders, and reporting the usage meter near exhaustion well before the feature existed. The reports are individual accounts rather than controlled measurements, and similar complaints circulated about other frontier models the month before — so treat it as a real pattern to scope against, not a rate you can plan on.

• Runs that do not terminate. Armin Ronacher, the creator of Flask, described leaving Astra on an unsupervised run for 35 hours, at the end of which it had produced roughly 75,000 net lines across 79 commits, about 1,400 agent-to-agent messages and around $1,200 in API fees — about $15.50 per commit — with, in his assessment, nothing of value delivered. Reports of the token count vary, so treat that figure loosely. He framed the missing stop condition as much a harness problem as a model one, which is the actionable reading: define completion before you start.

• The opposite failure also exists. Community reports describe Astra stopping short of a finished task and waiting for a prompt to continue, which is the same root cause seen from the other side — an underspecified notion of done. Explicitly defining "done" is the single highest-value line in your task prompt.

• Long sessions can become unrecoverable. Open Co​dex issues report a catch-22 where the context window fills, automatic compaction triggers, the compaction task itself runs out of context, and the thread cannot be recovered — and separately, that the native notes and history routes return 404 on Pro with Astra in some configurations, while swapping windows can discard task state. Both are open reports rather than vendor statements, but they argue for keeping runs checkpointed in git rather than trusting the session to survive.

• Stale notes are a design property, not a bug. Nothing guarantees a note reflects the current state of a file it describes, and search is literal substring matching rather than semantic. Store the source path with the note, re-verify on change, and treat an unattended run's notes as evidence to check rather than truth to rely on.

• Usage caps are the live complaint. Reports from the week of 2026-09-14 include caps up to four times tighter than launch week and an unresolved complaint that xhigh effort consumes less of the allowance than medium — which, if it holds, means effort and quota do not move together. Ope​nAI has not published numeric per-plan caps for Astra.

When a cheaper model is the right call

The measured results above make the routing decision for you. Astra's advantage is concentrated in work that spans files or spans hours: cross-file review, long-horizon agentic tasks, computer-use flows. On ordinary single-file edits, mechanical refactors, test scaffolding and formatting, the ~4% overall review delta against GPT-5.6 Sol does not justify roughly 2.5x the current per-token price — and CodeRabbit's own conclusion points the same way, recommending intelligent task routing rather than wholesale replacement. Reserve the expensive model for the tasks where its edge shows up, and route the rest down.

Concretely, a working split: GPT-6 Astra for cross-file changes, unfamiliar codebases, multi-hour agent runs and anything touching a browser; GPT-5.6 Terra for scoped edits, boilerplate and test generation; GPT-5.6 Luna for classification, extraction and high-volume mechanical passes. On the session arithmetic above, the difference between running everything on Astra and running a third of it on Astra is the difference between roughly $58.50 and roughly $28 for the same 150 turns.

Getting that split right is exactly what a routing layer is for. OrcaRouter puts 200+ models behind one API, so the split above is a config change rather than three integrations — and automatic failover means an experimental feature having a bad week, as this one did, degrades your run instead of ending it. For a model whose context mechanism Ope​nAI itself still labels experimental and briefly disabled, having a second path configured is not paranoia; it is the correct amount of caution.

What to watch from here

Four things would change this page, and all four are open. Whether the context-management experiment comes back on and in what form — Ope​nAI says it will become the default for Astra, which means the config line above eventually stops being something you set. Whether the notes and history 404 reports on Pro close, since that is the difference between the mechanism working as documented and working on some routes. Whether Ope​nAI publishes any per-effort token or cost data, which is the missing number in every effort decision today. And whether the usage caps that tightened through the launch week loosen once the demand that paused new $200 Pro subscriptions on 2026-09-10 is absorbed.

Until then, the playbook is short. Pin the model with codex -m gpt-6-astra, turn the experiment on only if you have a Plus, Pro or Pro Lite sign-in in the client, set effort explicitly rather than trusting a slider label, keep your working context under 272,000 tokens because that is where the bill doubles, define done before you walk away, and route the easy work somewhere cheaper. The model is from 2026-09-03 and it is not going anywhere; the tooling around it is what is still settling.

The questions that come up

Is the cross-window notes feature worth enabling for ordinary-sized tasks? Generally no. It exists to solve loss across context-window boundaries, so on a task that fits in one window it adds moving parts — including an experimental code path that was disabled for a bug on 2026-09-12 — without removing any pain. Turn it on for long-horizon work and leave it off for a scoped edit.

Can the 1,050,000-token window replace retrieval in my setup? Not on cost grounds. Reading a large context back on every turn is billed every turn, and above 272,000 input tokens the whole request reprices to $20.00 input and $75.00 output. A retrieval step that keeps the working context smaller is usually the cheaper design, which is why the notes mechanism is interesting: it is retrieval built into the harness.

What happens to the notes when a task ends? Ope​nAI's documentation scopes the mechanism to the same task, and community write-ups describe the notes as stored against that task rather than carried forward automatically. Do not assume a new task inherits the previous one's notes; anything that must survive belongs in your repository, not in the agent's memory.