How to Switch to GPT-6 Astra Without Losing Your Context (2026)

The spec, first, from OpenAI's own model page. Astra offers a "1,050,000 context window" and "128,000 max output tokens," with an "Apr 30, 2026 knowledge cutoff." OpenAI describes it as "our most capable model, built for the hardest end-to-end work" and recommends it for "complex reasoning, coding, computer use, research, and document creation." Reasoning is tunable: reasoning.effort supports "low, medium, high, xhigh, and max."

Availability is staged, so plan for a mixed period. Per the model page: "GPT‑6 Astra is rolling out today for enterprises in our Trusted Access Program, with access through API and our Plus, Pro, Business and Enterprise plans coming in the coming days." The API rate-limit table also lists the Free tier as "Not supported."

That matters for a practical reason people underestimate: for a while you will be running Astra in some places and something else in others. Any context that lives inside one model's conversation history does not exist in the other.

Instruction files transfer completely, because they were never model-specific. This is the good news and it is worth being precise about why. Codex's documentation states that "Codex reads AGENTS.md files before doing any work," and the discovery chain it builds — global file, then project files from the root down — has nothing to do with which model answers. Same for CLAUDE.md in Claude Code, .cursor/rules in Cursor, AGENTS.md in Amp and Warp.

So if your conventions are in files, switching models costs you nothing. If they are in conversations, switching models costs you all of them.

Conversation history does not transfer, on any surface. A new model is a new conversation. On the API this is obvious — you build the message array yourself, and nothing carries unless you carry it. In a chat surface it is less obvious, because the interface looks continuous while the thing answering has changed.

The knowledge cutoff is the part no window size compensates for. April 30, 2026. Four months of your own decisions sit after it. This is the clearest possible illustration of a distinction we keep returning to: why long context isn't memory. Capacity is how much the model can hold at once. Memory is whether anything is there when it starts.

Computer use changes what "context" even refers to. Astra supports computer use, and the model page lists Apply patch, Skills, MCP, and Tool search as supported. When an agent operates applications on your behalf, the relevant context is not only your codebase — it is which systems it is allowed to touch, what your internal names for them are, and which of last month's workarounds are still needed. None of that is derivable from a repository, and none of it is in a model trained through April.

Snapshots pin behavior, not knowledge. The docs note that "Snapshots let you lock in a specific version of the model so that performance and behavior remain consistent." Useful for reproducibility. It does not give the pinned version any more information about your project.

Step 1: Write down the four months the model does not have

This is the highest-value hour in the whole switch, and almost nobody spends it.

Open your team's recent history — pull requests merged since May, decision records, the Slack threads you keep linking to — and write down what changed. Not everything. Only what an agent would get wrong if it did not know.

Concretely, that tends to be five categories. Dependency and framework moves: what you migrated to and, crucially, what you migrated away from, since a model trained earlier will confidently suggest the old thing. Deprecations: services, endpoints, and internal libraries that still exist in the codebase but must not be extended. Conventions settled after April: the naming decision, the error-handling pattern, the review rule. Ownership changes: which team owns which surface now. Constraints with reasons: "the API is versioned in the path because two mobile clients pin an old build" is worth ten lines of style guidance, because without the reason an agent will helpfully remove it.

Then put it somewhere durable. If your instructions already live in AGENTS.md or CLAUDE.md, this goes there — the files are model-independent, so this work survives the next switch too, which is the argument in turning project docs into AI memory.

Step 2: Decide what happens during the mixed period, then verify one conversation

While the rollout is staged, you will have both models in play. Two decisions make that survivable.

First, keep your instruction layer in one place rather than per model. It is tempting to write an Astra-tuned instruction file while leaving the old one for older surfaces. That is two files diverging from day one, and it is the mechanism behind why agents ignore your instruction files — not that they cannot read them, but that they read one of several disagreeing copies.

Second, tune reasoning effort deliberately rather than leaving it at whatever the surface defaults to. reasoning.effort takes low through max, and higher effort on a task where the model lacks your context does not produce a better answer. It produces a more thoroughly reasoned wrong one. Give it the context first.

Then verify, once. Start a fresh Astra conversation and ask it something whose correct answer depends only on a post-April decision — a question where the pre-cutoff answer is confidently wrong. Read what comes back. If it gives you the old answer, your instruction layer is not reaching it, and you have found that out in two minutes instead of in a pull request.

While you are there, check what a million tokens actually costs you in practice. A very large window invites pasting everything, and a conversation stuffed with a whole repository is not the same as a conversation with the ten facts that matter. The relationship between what you load and what you get back is the subject of keeping less in agent memory.

Everything above is real work, and the uncomfortable part is that you did it for GPT-5.6 too, and you will do it again for whatever ships in December. Every model switch turns into a context migration because the context is stored in the wrong place — inside conversations, or inside files you maintain per tool.

The alternative is to keep the durable half outside both. Facts about your project do not change when the model does. If they live in a layer your agents read, a model switch becomes what it should be: a model switch. You point a different model at the same knowledge and it starts informed.

That also fixes the knowledge-cutoff problem permanently rather than once. April 30, 2026 stops being a cliff you paper over with a long paste, because the four months after it are written down somewhere the model can reach. MemoryLake sets up in three steps.

Step 1: Create an API key

Sign in and generate an API key from your dashboard. It is not tied to a model, a snapshot, or a plan tier, which is the property that matters while access to a new model is staged across surfaces.

Step 2: Upload your first memories

Start with the list from Step 1 above: what you moved to and away from, what is deprecated, the conventions settled since April, ownership, and the constraints that have reasons attached.

Add the things a computer-use agent needs and cannot infer — which internal systems it should touch, what your team calls them, which manual step still exists because a vendor has not fixed something.

Step 3: Connect your AI & agents

Point Astra at the store, and point whatever you are still running elsewhere at the same one. During a staged rollout that is the difference between one source of truth and two drifting ones, which is the case made in switching between AI models without losing context.

The first change is that the cutoff date stops mattering. Every model has one, every one of them is in the past, and the gap is filled by writing your own recent history down rather than by hoping the next release moves the line far enough.

The second is that a big window becomes a capability instead of an obligation. You can hold a million tokens; you should not have to spend them re-establishing who you are. Load the task, not the orientation.

The third is that the next switch is cheap. This is the fourth or fifth time in a year that a frontier release has made teams consider moving, and the teams that keep paying full price are the ones whose context lives in conversations.

• Read both numbers. 1,050,000 tokens of capacity, and an April 30, 2026 knowledge cutoff. The second one is the one that changes your work.
• Write down the post-cutoff months. Moves, deprecations, conventions, ownership, and constraints-with-reasons.
• Keep one instruction layer, not one per model. Instruction files were never model-specific; do not make them so.
• Expect a mixed period. Rollout is staged through Trusted Access, API, and the paid plans, and the API Free tier is listed as not supported.
• Set reasoning.effort on purpose. Low through max is a real range, and effort does not substitute for context.
• Verify with a post-April question. One prompt whose pre-cutoff answer is wrong tells you whether your context is reaching the model.
• Pin snapshots for reproducibility, not for knowledge. A pinned version behaves consistently; it does not know more.
• Give computer use its own context. Which systems, what they are called internally, which workarounds still apply.

The interesting thing about Astra is not that it can hold a million tokens. It is that a model this capable still starts every conversation not knowing what your team decided in May.

Switching well means separating the two problems. Capability comes from the model, and it is genuinely better. Knowledge comes from you, and the only way to stop paying for it on every switch is to keep it somewhere the model can read rather than somewhere a conversation happens to have been.