What is Astra, and when would I use it?

A business wants to open three new locations. Its booking software was built for one. Customers are already booked in, staff rely on it every day, and a replacement cannot bring the operation to a stop.

That is the kind of problem that makes me interested in Astra. There is code to write, but first there are connected decisions about how the business works, what the system owns and how to change it while it is in use.

I will use this fictional business to explain where I would involve Astra, what I would ask it to produce, and which decisions I would keep with the people running the operation.

What is Astra?

GPT-6 Astra is an AI model from OpenAI, built for complex reasoning, coding, research, computer use and document creation. It can work with instructions, documents and code, and request actions through tools. OpenAI’s Astra documentation describes its capabilities.

The application around the model matters. In a chat, you can ask Astra to explain a problem. In a coding application, it may also have access to files, a terminal and a browser. That combination of a model and tools is what lets an agent investigate a website, prepare a change and test it.

With the right access, I can give the agent a broader brief: examine the existing system, compare approaches, prepare a design, implement a selected part and revise the work as new information arrives. Its usefulness depends on the evidence it can access and how well its output holds up to review.

When would I choose Astra, Sol, Terra or Luna?

I would start with the size of the task. Classifying booking requests and planning a live migration are different jobs. These are starting points based on OpenAI’s model descriptions:

Scroll sideways to compare all columns ↔

I would consider Astra when the work spans several concerns and the path is still uncertain. Sol may be a good fit once a substantial implementation is well defined; Terra or Luna may suit narrower work. These are my starting points, not measured results from a head-to-head test. See OpenAI’s model comparison and Luna’s documentation.

Prices above are standard text API rates in US dollars per million tokens, checked 5 September 2026. Input is the material sent to the model; output is what it generates. These are separate from ChatGPT subscription prices.

Check the current model prices before budgeting. Caching, long inputs, tools and retries can change the total. Compare the cost of completing the task, including corrections, alongside the quality of the result.

How Astra appears in ChatGPT and Codex

In ChatGPT, GPT-6 Pro is powered by Astra. In Codex, the model selector shows GPT-6 Astra, as in my screenshot below. Availability can differ between the two during rollout. OpenAI explains the names and availability here.

The issue: grow the business without stopping bookings

Imagine a company that rents meeting rooms. Its original location uses one system for availability, bookings and deposits. It is opening three more locations, and customers should be able to book any of them through one website.

The difficulty is continuity. Existing reservations must remain valid. Staff must still change or cancel them. Two customers must not be promised the same room at the same time. Deposits and refunds must stay connected to the right booking.

The goal is to launch the new locations while keeping one dependable view of what has been booked. A new interface is only one part of that.

This is an illustrative architecture exercise, using invented constraints. It is not a client project or a report of a completed Astra deployment.

The plan: understand ownership before choosing an architecture

I would give Astra the existing data model, relevant code, integration documentation and a few fictional booking journeys. I would ask it to map where availability, reservations and payment records are read and changed, and to separate evidence from assumptions.

We need to support four locations while existing bookings remain active. Map the current booking and payment dependencies. Compare extending the current system, replacing it in one release and migrating in stages. Recommend an approach, explain what would make you change that recommendation, and identify the information still missing. Then outline the first working part we could deliver.

The first useful output would be a map of responsibility: who can reserve a room, which record makes a booking authoritative, and how a cancellation reaches the payment process. I would discuss the gaps with operations before treating the map as a design.

Scroll sideways to compare all columns ↔

For this example, assume the existing system cannot support the new locations, but can keep serving the original one. I would choose a staged migration by location. The original location stays in the existing system; new locations start in the new service. This gives us a clear boundary for deciding where each booking belongs.

The trade-off is real: staff and reporting have to work across two systems for a period. If the existing product could handle all four locations reliably with a modest change, extending it could be the better decision.

The action: turn the decision into a working design

I would ask Astra to develop the selected approach into a short architecture decision record, a data model, interface contracts and an implementation plan. Those outputs should agree: a diagram that assigns booking ownership to one service should not lead to code that writes the same reservation in two places.

The first design rule is straightforward: each room’s availability and reservations have one authoritative system. For now, location determines that system. The website routes each request accordingly; it does not try to reserve the same room in both.

Then I would give the agent a bounded implementation brief: build the journey for one new location in a development environment, from choosing a room to recording a reservation and showing it to staff. This makes the design concrete enough to expose missing rules.

For example, what happens if payment succeeds after a room hold expires? What if the same payment notification arrives twice? The design needs an explicit response, such as retaining an unresolved payment for reconciliation, rather than assuming every step completes in order.

Astra can help carry the decision through the affected files, propose the reservation states, build the integration and inspect the running interface. I would review whether the result preserves the business rules and whether the proposed operational work is manageable.

Then the brief changes

Halfway through the design, the business adds a constraint: customers have prepaid room credits, and they must be able to spend them at any location.

That changes the boundary. Bookings can be owned by location, but a customer’s credit balance is shared. Copying that balance into both systems would allow each to spend money the other has already used.

I would steer the work with this new information:

Keep booking ownership by location. Add prepaid credits that work across all locations. Revisit the data ownership and failure cases, show which decisions change, and update the implementation plan. Do not assume the existing system can reserve credit without checking its integration support.

Scroll sideways to compare all columns ↔

The next action depends on evidence. If the old system supports the necessary integration, the agent can help design a shared credit service with reservations, expiry and reconciliation. If it cannot, I would take the resulting scope or timing decision back to the business. A model cannot make an unavailable integration exist.

This is where I would consider a model built for complex work: following the consequences of a new requirement through the architecture, implementation and delivery plan, while preserving decisions that still hold.

OpenAI documents mid-turn steering, which allows updated instructions during a response where supported. Its asynchronous tool calling also allows independent work to continue while a tool runs. In this exercise, that could mean reviewing the credit interface while a booking test finishes. The application provides and executes those tools.

What would make the design ready to launch?

I would judge the result against the operation we need to run. Passing code tests is part of that evidence; so are a workable staff process and a migration plan that accounts for records created after launch.

Scroll sideways to compare all columns ↔

That last point matters. Switching the website back does not move new reservations into the old system. A recovery plan must say where those bookings will continue to be managed. I would ask Astra to work through that scenario before recommending a rollout.

TASK
Prepare an architecture decision and first delivery slice for a booking business
expanding from one location to four. Write for its technical lead and operations manager.

CURRENT SYSTEM — FICTIONAL FACTS
[S1] One application and PostgreSQL database own room availability, reservations
and deposit references for Location A. Existing bookings must remain changeable.
As in the article, assume this system can keep serving A but cannot support the
new locations by their opening date.
[S2] A payment provider owns payment status. Its callbacks can arrive late or twice.
[S3] New locations B, C and D open in eight weeks. Staff use the system every day.
[S4] A reservation holds one room for a time interval. Two customers must not
confirm the same room for overlapping intervals.
[S5] There are two engineers. No shared customer-credit feature is required yet.

DECISION TO MAKE
Compare extending the current system, replacing it in one cutover, and moving
traffic by location. Recommend one approach under these constraints.

OUTPUT
1. A dependency and ownership map using S1–S5 as evidence.
2. An options table: continuity, consistency, delivery effort and reversibility.
3. A short decision record: context, choice, consequences and unresolved questions.
4. One implementable delivery slice with the state changes and interface contract.
5. A rollout and recovery plan that says who continues to service bookings created
after launch if new traffic is paused.

QUALITY BAR
Separate supplied facts from assumptions. Give each authoritative record one owner.
Explain concurrency and duplicate payment callbacks. Do not assume switching traffic
back copies new reservations into the old database. Do not deploy or contact anyone.

CHANGE REQUEST
Customers can now buy credits and spend them at any location. A credit must not be
spent twice if two locations reserve it concurrently. A room reservation may fail
after a credit hold, and a payment callback may arrive after a timeout.

Revise the previous design. Keep decisions that still hold.
Return a change-impact table covering ownership, interfaces, consistency, recovery
and rollout. Define the credit lifecycle: available, held, spent and released.
Explain how the room and credit holds are reconciled after interruption.
Finish with the smallest additional delivery slice and the decisions operations
must settle. Show why each revision is necessary; do not simply rewrite the first answer.

The work I would bring to Astra

I would bring a problem with several connected decisions: a platform migration, a new capability that crosses existing boundaries, or an integration whose consequences are difficult to see in one place.

The brief should include the business outcome, the existing system, the constraints and the decisions still open. I would ask for concrete outputs at each stage: a dependency map, an options comparison, a decision record and a working implementation of the chosen part.

In this booking example, the value is a path the business can actually follow: launch the new locations, preserve existing reservations and deal explicitly with shared credits. Astra can contribute across that work. My responsibility is to decide whether the proposed system fits the operation.