Welcome to the AGI era! GPT-6 Astra's System Card Reads Differently

OpenAI launched GPT-6 Astra, a model the company says can perform any computer-based task a human can, with co-founder Greg Brockman declaring the arrival of the AGI era. The accompanying system card reports significant safety improvements, including a lower attack success rate against indirect prompt injection attacks and reduced misaligned behavior compared to its predecessor, while also noting the model reached a critical level of cybersecurity capability under OpenAI's own Preparedness Framework.

On 3 September 2026, two accounts of the same model went out. In the first, OpenAI co-founder and president Greg Brockman is quoted https://venturebeat.com/technology/welcome-to-the-agi-era-openai-launches-gpt-6-astra saying: "I think it's not unreasonable to feel that we are now in the AGI era." He told NBC News https://www.nbcnews.com/tech/tech-news/openai-debuts-gpt-6-astra-security-measures-rcna595940 that Astra "can really do anything a human can do with a computer," and signed off with "Welcome to the AGI era " The second says that OpenAI has "added misalignment monitoring to all tool-using inference involved in our external deployment of Astra, with significant compute cost," and that it "instituted new blocking alignment evaluations and an initial period of restricted deployment before broader internal availability of Astra models as coding agents." Same model, same day. The first is press coverage of the launch, with OpenAI's people speaking on the record. The second is OpenAI's own system card https://deploymentsafety.openai.com/gpt-6-astra . The system card does not contradict Brockman. It never takes a position on whether Astra is AGI. It is a technical safety document doing a different job, so the two texts are not in a fight. What they do have is completely different registers. One is written to make you feel something about where the field is. The other is written to survive a careful reading by a regulator or a security team. Every company with a launch and a safety org produces both. Most of the time you only read the first one, because the first one is what lands in your feed. The card also carries good news, and it is worth seeing what good news sounds like in that register. On 1,810 curated indirect-prompt-injection attacks from Gray Swan's IPI Arena, the card puts Astra's estimated attack success rate at 8.5%, against 27.0% for its predecessor, GPT-5.6 Sol. Across more than 54,000 internal Codex tasks, Astra "received roughly half as many flags for higher-severity misaligned behavior as Sol." Those are the card reporting its own model as measurably harder to attack than the one before it, in the register the whole document uses: a number, and the thing it was measured against. If you are building on this model, the second document is the one that describes what you are integrating with. It says Astra "is our first model to reach the Critical level of cybersecurity capability under our Preparedness Framework" — a bar OpenAI wrote itself https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf , then graded its own model against. The sentence the card uses for what that capability looks like opens with a condition worth keeping: "with the right tools and access, GPT-6 Astra can find previously unknown security flaws and develop new ways to exploit them across many well-protected systems without a person guiding each step." That grade is why the rollout has a shape. VentureBeat's launch writeup https://venturebeat.com/technology/welcome-to-the-agi-era-openai-launches-gpt-6-astra has the first keys going out through OpenAI's Daybreak enterprise access program, with wider access, plus AWS Bedrock and Microsoft Azure, in the days after. At the time of the announcement, all of that was still a plan. Two rows from the set OpenAI reported at launch https://venturebeat.com/technology/welcome-to-the-agi-era-openai-launches-gpt-6-astra . Every figure in that set is vendor-reported, and none of it has been independently verified: | Benchmark | OpenAI-reported | |---|---| | ARC-AGI-3 | 98.6% | | OSWorld 2.0 offline subset | 72.6% | The top row is a knowledge test, close enough to saturated that the remaining points are mostly an argument about the benchmark. The bottom row is a computer-use test, and it is the one your agent lives in. Twenty-six points sit between them. The third-party read is quieter. Artificial Analysis https://artificialanalysis.ai/models/gpt-6-astra-high scores the high variant at 60 on its Intelligence Index, against a median of 36 across the 202 models it tracks. Better than most, in the same league as several others. Now look at the OSWorld row again. That 72.6% came with a figure the headlines leave out: roughly 40 minutes per task, against 75 for the model before it. Forty minutes is a scheduling fact. It decides whether the thing you are building is a request handler or a job queue, and no amount of reasoning quality changes that. That is the general shape of the problem. A benchmark score is measured on a fixed task set, with a fixed prompt, graded by someone who knows the right answer. Your app has none of those. Your users write badly. Your prompt is one you wrote on a Tuesday. Your grader is a JSON.parse call that either works or throws. So a model can sit at the top of every leaderboard on that sheet and still hand your code a string with a trailing comma in it. Those are unrelated events. The leaderboard measures what the model can do at its best. Your error rate measures what it does across every input you did not think of. The most useful line in the third-party listing is the I/O shape: text and image input, text output , inside a 1M-token context window. Text out. A string, produced by a process that has no obligation to your interface, at $10 per million input tokens and $50 per million output tokens on the pricing Artificial Analysis lists. That does not change with model quality. It is the contract. A more capable model gives you a better string, and a string is still the thing you have to parse. Which means the code you write around it in 2026 has the same shape as the code you wrote around a much weaker model in 2024: validate on the way out, retry once with the error, fall back to something deterministic. Start from the record your application wants. Everything else exists to produce this or fail loudly. // ticket.ts export interface Ticket { category: "billing" | "bug" | "feature"; urgency: 1 | 2 | 3; summary: string; } Now the validator. It runs on whatever came back, and its error messages are written to be read by the model on the second attempt, so they name what was wrong. js const CATEGORIES = "billing", "bug", "feature" ; export function parseTicket raw: unknown : Ticket { const o = raw as Record<string, unknown ; if typeof o?.category == "string" || CATEGORIES.includes o.category { throw new Error category must be one of: ${CATEGORIES.join ", " } , ; } const u = o.urgency; if u == 1 && u == 2 && u == 3 { throw new Error "urgency must be 1, 2 or 3" ; } if typeof o.summary == "string" || o.summary { throw new Error "summary must be a non-empty string" ; } if o.summary.length 200 { throw new Error "summary must be 200 chars or fewer" ; } return { category: o.category as Ticket "category" , urgency: u, summary: o.summary, }; } That length check is doing more than it looks like. TypeScript's string has no upper bound, your database column does, and the model has no idea either exists. The type system stops at the compile boundary. Anything crossing in from the model needs the check at runtime. Before you can validate, you have to find the object. Models wrap JSON in prose, in fences, in an apology. Strip the wrapper before you parse, and treat "there was nothing to parse" as its own error rather than letting a SyntaxError bubble up with a useless message. js // extract.ts export function extractJson text: string : unknown { const fenced = text.match / {% endraw %} ?:json ?\s \s\S ? {% raw %} /i ; const body = fenced?. 1 ?? text; const start = body.indexOf "{" ; const end = body.lastIndexOf "}" ; if start === -1 || end <= start { throw new Error "no JSON object in the response" ; } return JSON.parse body.slice start, end + 1 ; } Yes, the provider has a structured-output mode, and you should turn it on. Keep this anyway. It costs ten lines and it is the difference between a degraded response and a 500 when the mode is unavailable, when you switch providers, or when a response gets truncated at the token limit mid-object. The retry only earns its place if the second attempt knows something the first did not. Send the rejection back. js // classify.ts import { extractJson } from "./extract.js"; import { parseTicket, type Ticket } from "./ticket.js"; export interface Message { role: "system" | "user" | "assistant"; content: string; } export type CallModel = messages: Message , = Promise<string ; CallModel is a function type, not a client. Your OpenAI call goes behind it, and so does the fake one your tests use. The loop below never learns which model it is talking to, which is the point: the model is a component you do not trust, and components you do not trust go behind an interface. export async function classify call: CallModel, system: string, body: string, : Promise<Ticket | null { const messages: Message = { role: "system", content: system }, { role: "user", content: body }, ; for let attempt = 0; attempt < 2; attempt++ { const text = await call messages ; try { return parseTicket extractJson text ; } catch err { const why = err as Error .message; messages.push { role: "assistant", content: text } ; messages.push { role: "user", content: Rejected: ${why}. Reply with the JSON object + only, no prose and no code fence. , } ; } } return null; } Two attempts, then null . Not five, and not "until it works." The arithmetic is the reason. At $50 per million output tokens, an unbounded retry loop on a pathological input is a bill with no ceiling, and every attempt is a full round trip on a model that took 40 minutes per task on the agentic benchmark. If the second attempt fails after the model has been told exactly what was wrong, the third one is unlikely to be the one that lands. Cap it where you can predict the worst case: two calls, two round trips, a known maximum spend per request. null is a value your application handles, so handle it. The path that runs when the model fails should be a real path with somewhere for the work to go. js // route.ts const ticket = await classify call, SYSTEM PROMPT, body ; if ticket === null { await humanQueue.push { body, reason: "unparsed" } ; metrics.increment "classify.fallback" ; return { routed: "human" }; } await routeTicket ticket ; metrics.increment "classify.ok" ; return { routed: ticket.category }; The work still gets done, by a person. The counter goes up, so you find out that your fallback rate moved from 0.4% to 6% after a prompt change instead of discovering it in a support thread. And the caller gets a normal return value, so nothing upstream has to catch anything. That counter is the number that tells you whether an upgrade helped. Not ARC-AGI-3. Yours. The launch language and the safety language are both real. The AGI claim came from OpenAI's co-founder and president, about a model his company sells, and you can weigh it however you like. Only one of the two documents is something you can write code against. Build against the string, and give it somewhere to fail that your user never sees. Then swap the model underneath whenever a better one arrives, and watch your fallback counter to find out whether it actually was. The gap between a demo that works and an app that keeps working is mostly this: the shape of the data coming back, and what happens when it is wrong. My book AI That Answers covers that ground — prompts, structured output, validation, and what tokens cost you when a call goes badly. It is book 1 of my AI in TypeScript series, five books that run from your first LLM call through to agents you can leave running in production.