ChatGPT-6 ASTRA

I really enjoy testing AI models, so much so that people already call me the AI Guy. Whenever a new one comes out, I am immediately thinking about which project I could give it, which tools I could connect it to and how far it could go.

With ChatGPT-6 Astra that is exactly what happened.

What I was most curious about was watching it work for a good while: understanding a project, using other applications and solving whatever came up along the way. That possibility excites me quite a bit. It also makes me more demanding about the result.

Because after the first impression come some very practical questions.

Did it finish what I asked for?

Is the code any good?

How much of my account did it burn through?

How much work did it leave for me afterwards?

My first test ended right in the middle of those questions.

To test it I designed WIRBI Freefall, a 3D skydiving prototype where you collect the letters WIRBI and dodge obstacles.

I handed the design to Astra and connected it to Higgsfield through MCP.

In about 50 minutes it generated 15 components, including the character, the parachute, the plane, the letters and several obstacles.

I liked watching it interpret what the project needed and use another tool to produce it. That is where the appeal of these agents becomes clear: you can put more attention on what you want to build while they move part of the execution forward.

Then I ran out of Work credits.

And that was the end of the first round.

At that point I had quite a few pieces of the game, but the most important part was still missing: integrating them and checking whether they could really become a playable experience.

That is why I wanted to run a second test.

I picked WIRBI Freefall back up in a second round, and this time the goal was no longer to generate components.

It was to make everything work together.

The result is now available and you can try it directly here:

https://wirbi-freefall.higgsfield.app/

And for me this changes the evaluation quite a bit.

I am no longer looking only at images, components or code fragments generated by an AI. Now I can open what it made, play it, test the mechanics and see how well it really turned out.

Is it finished?

No.

The camera is still somewhat awkward to use and I think it needs considerably more work to feel natural.

Item collection is also a bit broken. There are moments where the interaction does not feel as consistent as it should, and it is definitely one of the first things to fix in a next iteration.

But, considering we are talking about a first working version that came out of this flow between Astra, MCP and Higgsfield, I think it is a pretty good result.

And personally I prefer this to a demo where all I can say is that the AI produced fifteen components.

Now I have something I can actually play.

I also have something I can genuinely evaluate.

Because once the product exists I can stop looking only at how much Astra generated and start paying attention to something far more important: how well it turned all that work into a coherent experience.

The first round showed me that Astra could produce the pieces.

The second one started answering a much more important question:

Can it turn them into something that actually works?

The answer, for now, is yes.

But it still needs iteration.

And that is exactly what I wanted to find out.

Reviewing other tests I found a result I thought was interesting.

In Serudda's comparison between Astra and Fable 5.1, both worked on the same project and received the same brief: add a video download feature.

According to the analysis of that test, Astra finished in about 13 minutes and Fable in almost 19.

Both delivered a working solution.

Serudda valued the cleanliness of Astra's code and its more concise communication, but found that Fable had done a better job handling errors such as an invalid URL or a private video.

That detail carries a lot of weight for me.

An implementation can look tidy, work on the first try and still leave unresolved situations that will show up as soon as someone else uses it.

On a website, an admin panel or a backend, those situations do arrive:

incomplete data, users without permissions, external services that fail.

I care about how long the agent takes to build a feature, but also about what happens when something goes wrong.

That is why I would not draw a general conclusion about Astra's quality from a single test.

Serudda's result was good in several respects and left doubts in others.

We still need to see how it behaves in large projects, with technical debt and after many modifications.

I would keep reviewing architecture, validations, dependencies and tests.

If a fast delivery forces me to spend the afternoon fixing it, that time is part of the cost too.

And now that I have WIRBI Freefall running, that idea seems even more obvious to me.

Generating something quickly is one thing.

Getting the final result to feel right when you use it is another.

My test left me very aware of the difference between having access to Astra and having enough usage available to finish what I want to do.

The research I reviewed also records high consumption in Serudda's test: a task of around 20 minutes would have used more than half of the five-hour quota on a US$20 account.

That is an observation from that run, not a measure that can be applied to every project.

That quota does not equal five continuous hours of guaranteed work either.

Even so, the question stands.

If I am going to bring an agent into my workday, I need to know how many tasks like mine I can complete with the account I am paying for.

For anyone evaluating it, this is the subscription comparison I find most useful:

Plus: US$20 per month.

Includes access to Astra in Work and Codex, subject to rollout and account limits.

Pro: US$100 or US$200 per month.

Includes access to Astra in Work and Codex, with a larger usage allowance than Plus.

Business: US$25 per user per month, or US$20 with annual billing; minimum two users.

Access is included in standard Business, with workspace limits and permissions.

Enterprise: commercial quote.

Access depends on eligibility and on the administrator enabling it.

Prices and access checked on 10 September 2026 in the official pricing documentation.

Enterprise has additional conditions during the initial rollout.

This comparison refers to access to Astra.

The ChatGPT Pro subscription and the model's Pro mode are different things; that difference deserves its own explanation.

If you have Plus and do not see Astra in the regular chat, check Work or Codex.

Availability and the selector may vary during the rollout, as OpenAI's release notes explain.

Before upgrading, I would test with a task representative of daily work.

That would give me a basis for deciding whether I need more capacity, a better definition of the brief or to split the work across models.

I was left curious about Astra Pro.

I have not been able to try it yet, so here I talk about what I was able to document and the questions it leaves me with.

The video tests I reviewed focus on Astra and do not offer a direct comparison with Pro.

To begin with, the names need sorting out.

Astra's official guide confirms that it supports a Pro mode in the API.

The reasoning documentation describes it as a mode that puts more of the model's work into hard tasks, in exchange for longer waits and higher consumption.

It is an execution setting; raising the effort level or paying for an account called Pro is not enough.

That makes me want to take it to a problem that is genuinely hard to solve:

a backend migration, a bug that is hard to reproduce or an architecture decision with several alternatives.

Those are the tests I would give it.

With what I have researched, I still cannot say that it writes cleaner code, catches more errors or needs less review than Astra in standard mode.

On accounts, what is confirmed is that the US$100 and US$200 Pro plans offer, respectively, 5 and 20 times the Plus usage allowance for Work and Codex.

That gives more room to work with Astra, but on its own it does not confirm an Astra Pro selector in Chat.

The sources I consulted do not make it possible to assign that access per account either.

The Pro mode documented in the API is billed separately from the ChatGPT subscription.

The research itself brings me back down to earth a little: John says he ended up draining several Pro accounts during his tests.

That speaks to the consumption of his accounts; it does not prove he was using Pro mode.

For me, before paying more, the test would be very concrete:

give it the same brief, review both results and see whether the improvement is worth the wait and the work I still have to do myself.

Alongside the visual experiments, the research includes a case from John, of the Inteligencia Artificial channel, with a simulated air-conditioning SME.

Starting from the connected email, he built a commercial diagnosis, an opportunities dashboard and a tool to help answer customer questions.

That kind of use interests me a lot for day-to-day work.

There are companies with untracked budgets, information scattered across emails and spreadsheets, and people spending hours consolidating it.

Being able to turn that information into something that helps people work has very concrete value.

The data, the connections and the behaviour would have to be checked, of course.

A demonstration with a simulated company is useful for exploring an idea; taking it into a real operation demands more work.

I also take a point from John's analysis: part of that result depends on Work, its connectors and how the brief is framed.

Not everything we see in a demonstration has to be attributed exclusively to the new model.

I think that is a healthy thing to remember.

Before switching a whole team's subscriptions, it is worth checking how much we can get out of the tools we already have.

In web development I see a similar opportunity.

Having the agent build an interface, open it, spot a visual problem and go back to fix it can save many rounds of back-and-forth.

In backend work I want it to understand the project, implement the change and run tests.

In both cases I want to be able to review what it did and understand why it did it that way.

One of the details in the research that made me stop was a recurring task that, according to the creator, the agent scheduled on its own initiative to review emails and generate documentation.

I understand it can be useful.

I also want to know it is going to do that before I leave it connected to a company's information.

I would establish from the start what it can read, what it can modify and what it must leave pending review.

Preparing a draft and sending an email are different actions.

The same goes for testing a change in development and applying it in production.

I am excited about delegating more work.

To do it with peace of mind I need to see the actions, understand the permissions and be able to step in when necessary.

I think this point is going to become more and more important.

The more capable these agents become, the less sense it will make to evaluate only what they can do.

We will also have to decide which things we want them to do without asking us.

From a staffing, hunting and technology company, I think there is a more interesting conversation here than counting how many lines of code an agent can produce.

In staffing, I care about how the team works with these tools.

Who defines the problem, who reviews the solution and who answers when a failure appears.

A team can gain speed with AI, but it needs to organise that review so the progress is sustainable.

In hunting, I would be interested in watching a candidate use AI and then explain to me what they accepted, what they corrected and what they decided to discard.

You can observe a lot of their judgement there.

Spotting that an apparently correct solution has a problem can be as valuable as building it.

And in our web and backend projects, I want to apply whatever genuinely helps us deliver better:

fewer repetitive tasks, useful tests, documentation that stays up to date and integrations that solve the client's problems.

WIRBI Freefall ended up being a pretty good test of that philosophy.

The first time, Astra produced a considerable number of elements and left me with a collection of components.

That looked good.

But it was not a product yet.

The second round was much more interesting because I could see what happened when Astra had to take that material, connect it and turn it into something that could run.

Today I can open WIRBI Freefall and play it.

I can also say immediately what I do not like.

The camera is awkward.

Item collection needs fixes.

More things will surely show up as we keep testing it.

But now I have a much more concrete reference for judging how far Astra got and how much work remains after its intervention.

And that interests me quite a bit more than a list of generated components.

Astra left me wanting to keep testing.

In the first round it left me with an incomplete project and a very concrete reason to look at the account limits.

In the second it managed to turn a good part of that work into a first working version of WIRBI Freefall.

That lets me evaluate something that interests me far more than a list of generated features.

I can evaluate the result.

The current version still has problems.

The camera needs improvement and item collection is somewhat broken.

I would not present it as a finished video game.

But I would present it as a good first version.

And above all as a rather interesting demonstration of how fast the way we develop with AI is changing.

Not long ago the benchmark was:

"Look, AI can write code."

Then it was:

"Look, it can build an application."

Now we are entering something different:

"Give it tools, a project and some room to work, and let's see how far it gets."

That seems far more important to me.

It also means we have to be more demanding.

If the agent can work for long stretches, use external tools and make decisions, then it is not enough for it to produce a lot.

It has to produce things we can maintain, review and use.

WIRBI Freefall is now available to try:

https://wirbi-freefall.higgsfield.app/

It is not finished.

And right now I have a much clearer way to continue the test.

I can hand the result back to Astra and tell it:

"Good. This is your first version. Now improve the camera, fix item collection and let's see how well you can work on what you built yourself."

I think that third test may be even more interesting than the previous two.

Because generating a project from scratch is one thing.

Receiving an existing version, understanding what needs to improve and managing to do it without breaking what already works is quite another.

That is where I want to keep testing Astra.

The WIRBI Freefall experience is my own.

The observations about Serudda and John come from the attached research, based on videos by Serudda, Inteligencia Artificial and Benjamín Cordero.

They are results reported by those creators, not tests I ran myself.

The code comparison corresponds to GPT-6 Astra vs Fable 5.1, by Serudda, and the business case to He probado GPT-6 ASTRA al límite: esta es mi conclusión, from the Inteligencia Artificial channel.

The section on Astra Pro also draws on the linked official documentation and does not describe a test of that mode by me.

The WIRBI Freefall test does correspond to my direct experience: both the first round of component generation and the second integration that produced the published playable version.