GPT-6 Astra for Business: What Changed and What Did Not

GPT-6 Astra is OpenAI's flagship model, released September 3, 2026, priced at $10 per million input tokens and $50 per million output tokens through the API, with a context window of about a million tokens. It is rolling out in phases, so whether your business has it today depends on your plan. Its headline capability is computer use: operating a browser and desktop software to finish a task, not only answering a question about one.

Two flagship models landed in the same week. Anthropic shipped Claude Fable 5.1 first, OpenAI followed with Astra two days later, and they carry the same list price: $10 in, $50 out, a context window around a million tokens, 128,000 max output on both.

So the race a business buyer has watched for two years, which lab is cheaper at the top, just ended in a tie. That is worth sitting with, because it moves the decision somewhere less convenient.

Why does the price tie matter more than the benchmarks?

For two years, part of every model decision was a price decision. You could hold two spec sheets side by side and one of them cost less per token. At the frontier, that is now gone.

Both labs published benchmark claims with these releases, and both sets are the vendor's own. OpenAI says Astra is state of the art on Agents' Last Exam, AutomationBench, and ScreenSpot Pro, which are computer-workflow evaluations, and on FrontierMath Tier 4, ARC-AGI 3, and TerminalBench-4.0. Read those as claims, not as findings, and notice they cluster on agentic and computer-operating work rather than chat.

We are not going to tell you which lab wins, because we do not think that is the shape of the question. When list prices converge, the decision moves to three things that do not appear on a launch slide: whether you can actually get it, what your specific bill looks like, and whether the job you have is the job the model is built for.

Can your business actually get GPT-6 Astra today?

Maybe. This is the part most coverage skips.

Astra is rolling out in phases. Per OpenAI's own announcement, Pro, Enterprise, and Business Premium users got it first in ChatGPT Work and Codex, along with API access, and Plus and Business users follow in the coming days. Select partners in OpenAI's Trusted Access Program had early API access before any of that.

There is a second gate worth knowing about. Astra is the first OpenAI model to reach the Critical level of cybersecurity capability under the company's Preparedness Framework, and cyber-focused use runs under trusted access. Whatever you read about its security capabilities, that is not the deployment a normal business gets.

The same distinction exists on the other side. Claude Fable 5.1 is generally available. Claude Mythos 5.1 carries identical pricing and is marked limited availability on Anthropic's own pricing page. Identical price, very different answer to "can we use it in October."

The lesson generalizes past this week. Announced and in your account are different dates, and a rollout plan written against the first one will slip. Before a model goes in a plan, someone should open the account and confirm the model ID responds. That check takes four minutes and it is the difference between a roadmap and a wish.

How do the two flagships price long context and caching differently?

Same headline price, different bill. The divergence is in caching and long prompts, which happen to be exactly what agent workloads do all day.

Take one honest example: an agent that re-reads a 300,000-token working context on each turn. That is not exotic. A long-running agent holding a codebase, a document set, or a day of accumulated tool output gets there quickly.

On Astra, 300,000 tokens is above the 272,000 threshold, so the whole request bills at 2x. Uncached, that turn costs $6.00 in input. With the context cached, the read rate also doubles, to $2 per million, so the turn costs $0.60.

On Fable 5.1, the same 300,000 tokens bill at the standard rate. Uncached, $3.00. Cached, at $0.25 per million, $0.075.

Those are the two vendors' published rates and plain multiplication, and we are deliberately not extrapolating them into a monthly saving for your workload, because we do not know your turn count.

The fair flip side: if your prompts sit comfortably under 272,000 tokens, none of that math touches you. And OpenAI has real levers of its own. Batch and Flex run at 50 percent of standard rates, so an overnight job halves. There is a Fast mode at 2x for when latency is the constraint. A short-context, high-volume classification job may find Astra's economics perfectly fine and the long-context comparison irrelevant.

Which is the actual point. "Which model is cheaper" has no answer anymore. "Which model is cheaper for the shape of work we run" does, and you can compute it in an afternoon from two public pricing pages.

What is computer use actually good for in a back office?

Astra's pitch is computer use, and the tool list backs it up: alongside web search and file search, the model supports computer use, a hosted shell, and MCP.

Translated out of vendor language, computer use means the model can operate software that has no API. That is a bigger category than it sounds. For most small and mid-size businesses, the majority of daily software has no usable API: the vendor portal with a login and no export, the state filing site, the insurance carrier's web app, the internal tool nobody has touched since the person who built it left.

Every one of those has produced a recurring human task that no automation project ever reached, because the first question was always "does it have an API," and the answer ended the conversation. Computer use changes the answer to that question, which makes a whole shelf of previously unautomatable work suddenly worth looking at.

The realistic candidates look like this: a nightly reconciliation that lives across two portals, pulling a report from a vendor site that offers no download, the twelve-click task somebody does every Tuesday morning.

The realistic exclusions matter more. Anything that moves money or sends something to a customer should not run unattended, regardless of which lab built the model. That is not a knock on Astra. It is that the failure surface here is different in kind. A chat model that gets something wrong has said something wrong, and you read it and move on. A browser agent that clicks the wrong button has done something, and undoing it is a separate project. Approval gates get more important as the agent gets more capable, not less.

What would we build with it first, and what would we leave alone?

We would start with one browser task with a clear end state. One task, not a category. It needs three properties: a definition of done that a person can check in a glance, a screenshot trail of every step so a failure is diagnosable rather than mysterious, and a human confirmation before any write, send, or submit.

Then measure minutes per task against a person doing the same work. OpenAI is selling time per task, so hold the claim to that standard on your own workflow. If it does not beat the person on your actual portal, with your actual edge cases, the benchmark was not about you.

Two things we would leave alone. Anything requiring the Critical-tier cyber capability, because you cannot get it and building a plan on it is building on sand. And any loop that quietly crosses 272,000 input tokens, because a cheap agent turns into an expensive one at a threshold nobody will notice in a code review. If you build long-context agents on Astra, put a token counter in the loop and alert on it.

Our own stance has not changed this week. We run Google Vertex AI Gemini on a HIPAA workload under a BAA, because the compliance posture decided it. We run Anthropic Claude on a messy multi-step orchestration job, because the reasoning held up under the mess. We would evaluate Astra on computer-use work specifically, and give it nothing else until it earned it.

That is not fence-sitting. It is the position two identical price tags in one week should push any operator toward. Most AI strategy decks pick a lab and stop, which is a bet that the lab you picked in September will still be the right answer in March. This week is decent evidence against that bet. The durable position is to be able to run either one, which mostly means keeping the provider behind an interface you control instead of scattering one vendor's SDK through your codebase.

If you want a hand deciding which of your recurring tasks is the right thin slice, how we figure out what is worth building lays out the method we use, and you can start a conversation from there. If you would rather learn to drive these tools yourself, the 1:1 sessions are the other door.