ChatGPT Astra for Product People: What Changes When the Model Can Use a Computer

The headline facts, stripped of the froth. Astra is OpenAI's new frontier model, with a context window above a million tokens and, more to the point, a large jump in what OpenAI calls computer use — the ability to look at a screen, understand what's on it, and operate the interface. On OSWorld, the benchmark that measures whether an agent can actually complete desktop tasks, Astra scores 72.6% against 70.2% for Claude Opus 5 and 65.7% for its own predecessor. On grounding UI elements on screen it reaches 92.7%. These are vendor-reported numbers, so hold them loosely — but the direction is not in dispute.

Three practical consequences follow. It can operate applications that have no API, by using their interface the way a person would. It can create and host a working site or app straight from a prompt through Sites in ChatGPT. And it runs long multi-step tasks while keeping its bearings, which is the part previous agent demos always fumbled around minute forty.

I'd add one caveat the launch posts skip: OpenAI classified Astra as its first model to reach a Critical cybersecurity capability threshold, and shipped it with safety checks that can pause or refuse work. In ChatGPT you may be asked to approve an action; through the API a flagged task can simply stop. Plan for interruption in any workflow you build on it.

Buried in OpenAI's own launch material is the detail I find most interesting for our profession, and almost nobody has picked it up.

In a side-by-side, the previous model was asked to build a personal career website and did it autonomously in thirteen minutes. Astra stopped after twenty seconds to ask which career the person was moving into.

Sit with that. The older model was faster and produced a finished artifact. The newer one paused to ask a requirements question — because the answer changed everything downstream. That is not a model being slower. That is a model doing elicitation: recognising that an instruction was underspecified in a way that mattered, and refusing to guess.

For POs and PMs this cuts two ways, and both are worth thinking about. The encouraging read: the tool now behaves a bit more like a good analyst and less like an eager junior who builds the wrong thing beautifully. The uncomfortable read: asking the right clarifying question at the right moment is a large part of what we're paid for, and it just showed up in a product feature. I don't think that's a threat to the role — knowing which question to ask requires knowing the business, the constraints and the politics, and none of that is in the model. But it should sharpen where you think your value actually sits. It isn't in the asking. It's in knowing what the answer implies.

Different jobs, different leverage. Here's how I'd frame it for each.

Enough theory. These are the three I'd actually put in place first, in order of how quickly they pay off.

One: the UAT sweep. This is the fastest win for a PO. Point the model at a staging environment, give it the flows, and have it report rather than fix — you want the findings before anything changes.

Here is the part I care about most, and I've not seen it argued anywhere.

For twenty years, the binding constraint on enterprise automation was integration. The old system had no API, or it had one that nobody had budget to extend, so the business case collapsed before it reached a steering committee. I have personally watched genuinely good ideas die in that exact meeting, more than once. An agent that can operate an interface directly changes what that meeting is about, because the cost of touching a legacy system stops being an integration programme and starts being a prompt and some supervision.

But — and this is the part the vendor blogs won't tell you — the constraint doesn't disappear. It moves. When you can automate any process an agent can see, the thing standing between you and value is no longer technical access. It's whether anyone can state clearly what the process actually is. You cannot delegate a workflow nobody has written down, and most organisations are far worse at this than they believe. The bottleneck migrates from integration debt to process debt, and process debt is a management problem, not an engineering one.

Which is oddly good news for our profession. If the hard part becomes defining the work precisely — inputs, decision points, exception handling, what "done" means — then the scarce skill is exactly the one product people have been practising for years. The transformation programmes that win the next two years won't be the ones with the best model access. They'll be the ones that already know how their own business works.

There's also an honest counterweight to log. UI-driven automation is more fragile than API integration: interfaces change, and an agent that clicks can break in ways a contract-based integration doesn't. It's also harder to audit — "the agent did it on screen" is a weaker evidence trail than a logged API call, and in a regulated environment that distinction is not academic. My read: use computer use to prove value fast and to reach systems you could never justify integrating. Where a process is critical and recurring, an API is still the right long-term destination.

I'm not going to pretend one model now does everything, because it doesn't and the honest split is fairly clean. Astra's edge is doing: operating software, running long agentic tasks, building and hosting something clickable. For written artifacts — PRDs, strategy docs, stakeholder narratives — the model I reach for hasn't changed, for the reasons I laid out in how I use Claude day to day, and my broader comparison of the main assistants for PM work still holds.

So the practical answer is a division of labour rather than a migration. Write and think in one place; delegate execution in the other. If you're on a single subscription and your work is mostly documents, nothing here forces your hand. If a real part of your week is operating tools, testing, or shepherding a process, that's where Astra earns its place.

One note on cost, since it comes up: API pricing runs at $10 per million input tokens and $50 per million output — meaningful money if you're building agent workflows at scale, irrelevant if you're using it through a seat. Model this before you promise savings to a sponsor.

Access is genuinely muddled right now, and I've watched people conclude the model isn't available when it's sitting in a tab they haven't opened.

I'd be doing you a disservice if I stopped at the upside. If you're piloting this inside a real organisation, three items belong on the register from day one.