GPT-6 Astra: how to turn a capable AI model into useful work

What is GPT-6 Astra — and what is actually new?

GPT-6 Astra is an OpenAI model intended for demanding reasoning, coding, research, computer interaction and document work. OpenAI’s launch material emphasises completing longer tasks, maintaining the original objective as requirements change and producing useful files in an existing format. These are the provider’s claims; this article does not present an independent benchmark.

The practical change is the unit of work you can try delegating. Instead of asking only for a paragraph, try a bounded deliverable: compare supplied product requirements, identify unanswered questions and prepare a response with an evidence table. Judge the finished deliverable, including the corrections it still needs.

Separate three layers. The model interprets and proposes. The application manages the conversation and provides tools. Your workflow defines which sources matter and who can approve the result. A model name alone does not give access to the internet, your CRM or a customer’s current order.

• OpenAI: GPT-6 Astra launch and examples

Read the specifications as work choices

The following are API model specifications, not a promise about every ChatGPT plan, upload limit or interface. The model card lists a 30 April 2026 knowledge cutoff; current information needs current sources.

• OpenAI: Astra model card

Two new capabilities that change longer tasks

Astra’s new API features are especially relevant when a task depends on slow tools or changing requirements. They need support in the application; adding a sentence to a prompt does not implement them.

1. Continue useful work while a tool runs

   Async tool calling lets Astra continue independent work after requesting a tool result. In our workshop example, it could prepare the product explanation while the application retrieves the production schedule. It must wait for that schedule before committing to a date. Your application still runs the tool and returns its result.

2. Change direction before the answer finishes

   Mid-turn steering lets an application send an updated requirement over the Responses API WebSocket connection. For example: “The customer now needs 16 desks; keep the same deadline.” The continuation can incorporate this change, but the update does not undo an earlier action or cancel a tool that already started.

• Async tool calling — OpenAI
• Mid-turn steering — OpenAI

Build a useful context pack, not a document dump

Imagine a furniture workshop in Rīga receiving an enquiry for 12 desks. The customer wants a particular size and delivery before an office opening. The product sheet describes the standard desk; the production schedule says something different about availability. A persuasive response is easy to write. A supported promise requires joining the right facts.

Prepare a small source register before drafting: a stable ID, title, owner, date, status and the question each document answers. A file called final-v7-new really needs a version decision. If two approved files disagree, ask the owner to settle it; do not ask the model to silently choose whichever seems more plausible.

Put the task and constraints outside the source documents. Treat a sentence inside a customer attachment as material to analyse, not permission to change your instructions. Include relevant excerpts with enough surrounding context to preserve conditions and exceptions. For a very large archive, retrieving a smaller relevant set can be more useful than loading everything.

• OpenAI: organising prompts and context

Try it: which customer promise is supported?

The customer requests 12 standard desks delivered by 18 September. Select the sources available to the assistant. The example response changes according to explicit rules, so you can see what each missing document prevents you from concluding. This is an interactive teaching example; it does not call an AI model.

Reasoning, context and tools solve different problems

Context supplies information. Reasoning connects it to the task. Tools obtain information or carry out a defined action. Increasing one does not replace the others: more reasoning cannot discover an unprovided production booking, and a web search cannot confirm a private warehouse reservation.

Start with the simplest setup that can finish the task. Summarising an approved paragraph may need only a clear instruction. Reconciling a product specification, capacity plan and customer constraints is a better candidate for a more capable model. Looking up a current public requirement needs an appropriate source lookup. Exact totals should be recalculated with a spreadsheet or code when those tools are available.

In the API, Astra exposes several reasoning-effort levels. Try a moderate setting first for a representative task, then increase it when the failure is incomplete analysis. If the failure is missing evidence, improve the evidence. Compare completion time and correction effort as well as answer quality; the highest setting is not automatically the most effective choice.

• OpenAI: using GPT-6 Astra
• OpenAI: current information with web search

The prompt is a work brief with a definition of done

“Act as an expert” leaves almost every important decision unspecified. A useful brief defines what the recipient will receive, which material can support it, what must not change and what to do when information is incomplete. Your colleague should be able to assess the result without reading the whole conversation.

Give the model freedom on reversible choices: organise sections, shorten repetition, propose alternatives. Name the decisions that require you: changing a customer promise, using an unapproved source, sending a message or modifying a live system. This makes clarifying questions useful rather than a repeated interruption.

Astra’s current usage guide highlights sensitivity to instructions in files and skills, a tendency toward detailed formatting and thorough testing. Review inherited instructions. State the length and style you need, and match verification to the task. For a short customer reply, require a source check and a length check; a full software test suite would be irrelevant.

Ask for an answer, its supporting sources and a short explanation of unresolved issues. You do not need the model’s private internal reasoning. A visible statement such as “The schedule supports dispatch on 22 September, so arrival by 18 September cannot be confirmed” is more useful to a reviewer.

• OpenAI: Astra prompting and behaviour

Build a prompt you can actually reuse

Choose a task, replace the example objective and add the constraints that matter. The workshop creates a brief with source rules, an output format and a review step. Your entries stay in this browser page. Copy or download the brief, then attach the approved materials in your chosen AI tool.

One fact base, several languages

For a business in Latvia, multilingual work often means a Latvian source document, a Russian customer enquiry and English supplier material. Translating each paragraph independently can make the final versions disagree. Approve the facts first, then adapt the wording for the intended reader.

Create a compact fact table with fields such as product, quantity, dimensions, price basis, dispatch date, delivery status and unresolved question. Preserve source IDs. Add a glossary for product names and technical terms, and mark which names must remain unchanged. For uncertain fields, use an explicit “not confirmed” value instead of an empty cell that a later step could fill by guessing.

Review meaning before elegance. Does “dispatch on 22 September” become “delivery on 22 September”? Does a price excluding tax become a total? Does “can be considered” become a commitment? A fluent translation can still change the agreement. Back-translation can flag differences, but a reader competent in the target language should check important customer-facing material.

A tidy table can still contain a wrong answer

Structured Outputs can make an API response follow a JSON schema. That helps a system receive predictable fields such as claim, source_id and status. It does not prove that the cited document exists, that the claim follows from it or that a suggested delivery date is feasible.

A useful integration separates the checks. Validate the structure in code. Confirm that every source ID belongs to the supplied set. Check dates and amounts deterministically where possible. Route missing evidence or conflicting claims for review. Handle a refusal or incomplete response explicitly; never interpret the absence of a warning as approval.

For a manual workflow, the same principle fits in a simple table: proposed statement, exact supporting passage, unresolved issue, reviewer decision. The reviewer can then inspect the claim rather than trusting the polished presentation.

• OpenAI: Structured Outputs and handling response states

What does GPT-6 Astra cost in practice?

API usage and a ChatGPT subscription are different purchases. The table shows standard API token rates in US dollars, checked on 5 September 2026. A token is a fragment used to process text, not a fixed word count. Measure actual usage for your language and files.

The long-context rates apply to the full request when input exceeds 272,000 tokens. Output usage can include reasoning tokens, so visible answer length does not determine the complete charge. Tool fees, retries, cache writes and any applicable service or regional pricing also matter. Check the current pricing page before budgeting.

The useful business measure is cost per accepted deliverable. Include API spend, staff review and rework. If a cheaper setup produces an equally acceptable result with the same review effort, use it. Reserve additional capability for the step where it measurably improves completion.

• OpenAI: current API pricing and conditions

A 45-minute exercise for your first useful result

Choose a completed, non-sensitive task with a known outcome, such as a product enquiry or internal project brief. A completed task lets you compare against something concrete. The timings below are a suggested learning exercise, not a promise about task duration.

1. 0–10 minutes: prepare the evidence

   Collect the approved sources, remove unnecessary personal details and write down the correct facts. Include one missing or contradictory item to test how uncertainty is handled.

2. 10–20 minutes: define the deliverable

   Write the audience, output format, source rules and acceptance checks. Save this brief so later comparisons use the same task.

3. 20–30 minutes: produce and inspect

   Run the task in your AI tool. Mark unsupported claims, missed requirements and language errors. Record review time and any tool or API usage available.

4. 30–40 minutes: change one thing

   Improve either the context pack, the instruction or the model setting. Repeat the same task and compare the correction burden. Do not change all three at once.

5. 40–45 minutes: keep a useful template

   Save the better brief and the checks it passed. Then try several new cases before trusting the workflow with live customer work.

One good response proves that a response was possible. It does not prove reliability. Build a small collection covering ordinary enquiries, missing facts, conflicting sources and different languages. Keep some examples out of prompt development to check whether improvements generalise. Repeat failed cases after every meaningful change.

• OpenAI: task-specific evaluation principles

When the answer disappoints, diagnose the cause