aurora-blue-alpha, aurora-green-alpha and aurora-red-alpha: What OpenAI's Three Undocumented IDs Actually Tell You

Three identifiers appeared in the O​penAI API's model list on 17 October 2026, inside a ninety-seven-second window of each other: aurora-blue-alpha at 01:13:49 UTC, aurora-green-alpha at 01:13:55, and aurora-red-alpha at 01:15:26. Their owner field reads "system", and none carries a shutdown date. Roughly 26 hours later — at 02:59 UTC on 18 October — someone posted about them, and the three names started circulating as a possible new O​penAI release. This is what we know so far, and it is deliberately short: no O​penAI announcement, no documentation page, no price, no changelog line, and no confirmation from anyone — including the people reporting on them — that a single successful request has ever been made against any of the three. Everything below is labelled with who says it, because on this particular story the sourcing is the story. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

What is actually on the record

The strongest evidence in circulation is a first-hand read of an authenticated model list, published by CellCog on 18 October. Its author queried O​penAI's model-list endpoint with their own key, got 144 models back, and found the three aurora entries among them. That is a materially better source than a screenshot of somebody else's terminal, and it is still only a listing: CellCog says explicitly that it listed the models and did not call them, so it cannot describe behaviour, speed or cost.

Crypto Briefing's report, dated 17 October with coverage landing the next day, adds the framing most readers will have seen — that O​penAI "quietly listed" three identifiers with no documentation and no official comment — and is candid that the public conversation traces back to a single X post by @scaling01 which it describes as unverified and speculative. RuntimeWire is the most useful of the three, because it draws the line the others leave implicit: the post the coverage rests on does not establish that the models are callable, and treating an unverified identifier as a shipped model means developers end up building against access and behaviour that have not been documented anywhere.

So here is the ledger, with each item attributed:

• The names — aurora-blue-alpha, aurora-green-alpha, aurora-red-alpha. Agreed by every source that has looked, including an authenticated model-list read (CellCog, 18 October 2026).

• Creation timestamps — between 01:13 and 01:15 UTC on 17 October 2026, per CellCog's read of the list. Two minutes for three entries is what a single deployment looks like; it is not what three separate experiments look like.

• Owner field — "system", with no shutdown date attached to any of the three. Also from CellCog's read.

• Documentation — none. Neither O​penAI's changelog nor its public models page contains the string "aurora", checked on 18 October. Our own capture of the vendor's model documentation on that date shows the flagship tier — GPT-6 Astra, GPT-6.1 Sol, G​PT-6 Luna — with no aurora entry and no alpha-suffixed entry at all.

• Price — none published. Not "expensive", not "free": absent. There is no number to budget against.

• Callability — unverified by every source we can find, and flatly disclaimed by two of them. This is the single most important line in the ledger and the one the aggregate coverage blurs.

• Capability — nothing. No context window, parameter count, architecture, modality or reasoning-effort field has been published, leaked or claimed by a partner.

Why a model-list entry is much weaker evidence than it looks

The instinct to read a new API identifier as a shadow launch is understandable — that is how several real models have surfaced over the past year, and it is how the aurora name first appeared in February. But a model-list entry proves exactly one thing: that an identifier exists in the account's listing. It does not prove that a request against it will succeed, that it will succeed at a usable rate, that it will still exist next week, or that its output will be stable between two calls a day apart.

Concretely, what a list-only ID can do to you: it can be callable one day and gone the next with no deprecation notice, because it was never documented and therefore was never covered by any deprecation policy; it can be renamed, repriced or repointed without a changelog entry; and it can return output from a checkpoint that is still being swapped underneath you, which means a benchmark you run on Monday does not describe the model you call on Friday. None of that is a reason to panic. All of it is a reason not to put an undocumented identifier on a production path, and the people covering this story most responsibly are saying the same thing in fewer words.

The three readings of the colour scheme, ranked by how much they are worth

Nothing in the signal text or in any coverage establishes what blue, green and red mean. What follows is inference, and it is labelled as inference — nobody outside O​penAI has said anything on the record.

• One deployment, three variants. This is the reading the evidence actually supports, and only because of the timing: three IDs created within two minutes of each other in one account is the signature of a single push, not three unrelated experiments. It says nothing about what varies between them.

• Size or capability tiers. Colour-coded tiers would be a new naming convention for this vendor, whose documented lineup in this cycle is named after celestial and weather phenomena — Astra, Sol, Luna, Terra, Sunburst, Flare, Daybreak — rather than after colours. The astronomical flavour makes an "aurora" codename plausible; it does not make a colour-to-size mapping true. Plausible is not evidence.

• Rollout arms or evaluation variants. Three parallel identifiers is also what an internal A/B or safety-evaluation split looks like when it leaks into a shared listing. If this is the case, the IDs may never become public at all, and the correct response is to do nothing.

What none of these readings supports is the one people are most excited about — that these are Codex coding models. That inference comes from a real precedent, and the precedent is doing more work in the conversation than it can carry.

The Aurora Alpha precedent, and why it is a trap

In February 2026, a cloaked reasoning model calling itself Aurora Alpha surfaced on a third-party routing platform — no named maker, a 128,000-token context window, a default reasoning effort of medium, and no public benchmarks. Three days later, on 12 February 2026, O​penAI announced GPT-5.3-Codex-Spark, an ultra-fast model for real-time coding delivered on Cerebras hardware and claimed at more than 1,000 tokens per second. The proximity of the two, plus the shared emphasis on speed, is why a large part of the community concluded that Aurora Alpha *was* GPT-5.3-Codex-Spark.

That conclusion has never been confirmed. Not by O​penAI, not by the platform that hosted it, and not by anybody with first-hand knowledge of the cloaked model's weights. A prediction market on the question was still unresolved as of this writing, with its resolution date set for 31 December 2026. A later census of stealth-model launches described the Codex-Spark theory as resting on listing proximity and similar positioning, and noted that its own supporters call that circumstantial — which it is. The shared name is the only link between February's Aurora Alpha and October's three aurora IDs, and the word "aurora" is not rare.

There is a second reason to be careful with the Codex-Spark inference, and it is the one the coverage has largely missed: the model people are trying to map these IDs onto was retired about a month ago. O​penAI's core product lead said publicly in September 2026 that GPT-5.3-Codex-Spark was being retired the following week, citing steadily declining usage and better models being available, and that deprecation has since been reflected in the vendor's own documentation, which lists it as no longer usable in the desktop app, CLI or IDE extension. So the tempting syllogism — aurora-* are Codex models, aurora-alpha was Codex-Spark, therefore these are Codex-Spark-class models — points at a model that no longer exists, with no named successor and no migration path that O​penAI has published.

If the aurora IDs do turn out to be coding models, they would be something new, not a continuation of a model that was switched off in September. Nobody should plan against the inverse.

The falsifiable checklist: four signals that turn a listing into a decision

Rather than argue about what the IDs might be, it is more useful to name the four things that would settle it. Each is checkable, and each is a specific artefact rather than an interpretation. Until at least two of them land, the correct posture is to watch and not to build.

• It appears in the vendor's own model catalogue. Not in a list you can query with a key — in the documentation, with a name and a capability description. This is the threshold that separates an identifier from a product. Today: no.

• A price is published. A rate card is a commitment. An undocumented endpoint with no price cannot be budgeted, cannot be compared against anything, and cannot be put in front of a finance team. Today: no price exists at any tier.

• A changelog entry names it. Changelog entries tend to be the last step before general use, and they carry the deprecation clock with them. A model with no changelog entry has no deprecation policy, which is exactly the property that makes list-only IDs unsafe to depend on. Today: the changelog does not mention aurora.

• Someone outside O​penAI runs it and publishes the result. An independent benchmark, a throughput measurement, a reproducible harness — anything with a method attached. As of 18 October, the honest count of public independent runs against aurora-blue-alpha, aurora-green-alpha or aurora-red-alpha is zero.

When the fourth signal arrives, the safe way to test an unproven endpoint is to treat it as a candidate rather than a dependency: put it behind a routing layer that can fail over to a model you have already validated, so a bad checkpoint or a disappeared identifier degrades a request instead of breaking a product. That is the difference between learning something about a new model and betting a production path on it.

If you have to ship code this week, ship against what is documented

The practical question a developer actually has on 18 October is not what colour red is. It is what to build on while this resolves, and the answer is the models that have names, prices and documentation today. On OrcaRouter those are the IDs you can call right now on one key, with provider list prices passed through at 0% markup, so a vendor price change is live on our side the same day rather than at the next billing cycle:

• GPT-5.3-Codex — $1.75 per million input tokens and $14 per million output, with a 400K context window. The coding-shaped agent workhorse of the current O​penAI line, and the model most readers eyeing "aurora as a Codex variant" are already substituting for it.

• GPT-5.6 Sol — $4 per million input and $20 per million output, 1.05M context. The hard, long-context, multimodal call.

• GPT-5.6 Luna — $0.20 per million input and $1.20 per million output, 1.05M context. The cheap high-volume tier.

• G​PT-5.6 Terra — $2 per million input and $12 per million output, 1.05M context. The middle of that ladder.

• GPT-6.1 Sol — $2 per million input and $10 per million output, 1.05M context. The newest tier of the line, positioned for agentic coding and computer use.

Those figures are read off our own model pages for each of the five models on 18 October, not off a press release, and they are the numbers to budget with. The three aurora identifiers are not on that list, and we are not going to imply otherwise: if and when a vendor publishes a price and a capability description for a model, it becomes routable here in the ordinary course, and today there is nothing to route.

To be explicit about the one claim worth making here: a routing layer is not a way to get access to a model that does not have a documented endpoint. It is a way to keep an undocumented one from becoming a single point of failure once it does.

What to watch, and what would change this article

The reason this story is worth a bookmark rather than a headline is the shape of what is missing. Three names showed up together, in a two-minute window, in an account that belongs to the vendor — and then nothing. No docs, no price, no changelog, no independent run, no confirmation that a request would return anything at all. That pattern is consistent with a staged rollout, with an internal evaluation that leaked into a shared listing, and with a dozen things in between. It is not consistent with a release.

What would move it: any of the four signals above. A price appearing is the loudest, because a rate card is hard to publish and then withdraw. A changelog entry is the second loudest, because it starts a deprecation clock. An independent run is the most useful, because it is the first thing in this story that would be evidence rather than inference. And a quiet disappearance — the IDs dropping out of the list with no announcement — would be the answer too, and should be read as one rather than as a secret launch that got pulled.

Until then, the three aurora identifiers are what their own listing says they are: entries. Calling them a model is a guess, and it happens to be the guess that has already been made once before, in February, about a name that rhymed. That one was never confirmed either — and the model it was supposed to point at was retired in September.