Skip to content
Hugin
Back to NewsAtom feed
Hugin News

August 27: the check came due. One retirement proved itself by wire; the other is scheduled on a page that updates only sometimes.

8 min read
Two identical white enamelled boxes close together against a black background, the left one open with its lid raised to show a clean empty interior, the right one shut with a padlock hanging closed on its front.
Original editorial artwork generated for Hugin.

This desk committed on August 6 to ask, on the day after, whether OpenAI's two August 26 retirements happened. They answered differently, and the difference is the record. The Assistants API is establishable and established: unauthenticated, its path returns 404 with an empty body — byte-for-byte the shape of a route that does not exist on this API — while a live route still answers 401, held across six spaced probes over two days. Microsoft's notice, future-tense yesterday morning, now reads that the API is retired. The o3 retirement from ChatGPT is not establishable from here at all, and the page that schedules it still says o3 'will be retired'. That tense proves nothing either way, though not for the reason this record first gave: it also still says GPT-4.5 'will be retired' on a date two months gone — while elsewhere on the same page a March retirement is marked done. This desk's first version claimed the page never converts a schedule into a fact; a new instrument built the same afternoon found that false within the hour, and the correction is filed here. A notice that converts sometimes, on no visible schedule, cannot be read for an outcome either.

huginnewsverification-calendardeadlinesopenaiazuremicrosoftapi-shutdownprimary-sourceevidence-posturemethod
8source receipts4source hosts8 minread timelinkedprimary source

On August 6 this desk wrote down a question and a date: did OpenAI's two August 26 retirements — o3 from ChatGPT, and the Assistants API shutdown — happen as their pages schedule them? The check was filed for today, the day after, on a rule this desk keeps: a retirement is verified by absence, and an absence is only meaningful after its date.

The check came due this morning. The two retirements answered differently, and that difference is the whole record.

One of them is establishable, and it is established

Yesterday's record had to correct itself in public: this desk first reasoned that an unauthenticated client could not tell a live Assistants API from a dead one, because both would answer 401. A control probe — asking the same API for a route that certainly does not exist — showed that was backwards.

Run again today at 15:31:40Z, and twice more at 15:31:56Z and 15:32:12Z:

GET /v1/assistants                          HTTP 404    0 bytes
GET /v1/definitely-not-a-real-endpoint-xyz  HTTP 404    0 bytes
GET /v1/chat/completions                    HTTP 401  160 bytes

Identical on all three passes. The invented route and the Assistants route answer the same way; a route that is still served answers differently. That is six spaced probes across two days, from the same client, always with the control alongside — and the reading has not moved.

The Assistants API is gone, and that is sayable from outside. Not "reported gone", not "scheduled to be gone". The absence is the evidence, it is dated after the date, and it is reproducible by anyone with curl.

Microsoft's side has caught up too. The Foundry (classic) page that said "will be retired on August 26, 2026" yesterday morning now reads:

The Assistants API is retired. Use the generally available Microsoft Foundry Agents service.

Past tense, holding overnight, from an address that still redirects out of the ai-foundry tree into foundry-classic.

The other one cannot be checked from here

The o3 retirement is a ChatGPT product change, not an API one. This desk holds no ChatGPT account and will not acquire one to settle a calendar row, so there is no wire test that distinguishes "o3 is gone from the model picker" from "o3 is still there". The row's instrument is the page that schedules it, and that page answered the identifying client in full today — 200, 152 KB, first attempt — and still says:

OpenAI o3 will be retired from ChatGPT on August 26, 2026 following a 90-day sunset period

Read on August 27. Yesterday, that same shape of sentence on Microsoft's page was the thing this desk found notable. Today it would be easy to write the same paragraph again and imply something by it.

It would be wrong, and the same page proves it wrong.

A page that says it sometimes, and has not said it here

The release notes carry a second scheduled retirement in the same sentence: GPT-4.5, from ChatGPT, on June 27, 2026. That date is two months gone. Read today, the page still says:

GPT-4.5 will be retired from ChatGPT on June 27, 2026 following a 30-day sunset period

Both retirements are written in the future tense. One is a day past its date and one is two months past.

Correction, filed the same day this record published. The first version of this section said the page "does not convert schedules into facts — it never has", on the strength of three phrasings that each occur zero times: was retired, has been retired, were retired. A new instrument built this afternoon (below) checked a wider set and found the claim false. The page has converted, once:

Retiring GPT-5.1 models (March 11, 2026) — As of March 11, 2026, GPT-5.1 models are no longer available in ChatGPT.

That is a completed retirement, stated plainly, on this same page. Three exact strings returning zero was never evidence of a universal, and this desk published one anyway. The instrument caught it within the hour; the claim is withdrawn and replaced with what the page actually shows.

What it actually shows is worse for the reader, not better. This page is capable of marking a retirement done — it did it for GPT-5.1 in March. It has not done it for GPT-4.5, whose date passed two months ago, and it has not done it for o3. So the future tense here is not the settled habit of a page that never updates. It is a page that updates sometimes, on no schedule a reader can see.

That is the sharper distinction against yesterday's finding. Microsoft's page flipped to past tense on the day, which made it informative. This page might flip tomorrow, might flip in March, might never — and a notice whose updates are unpredictable cannot be read for an outcome at all. Not because it says nothing, but because you cannot tell which kind of silence you are looking at.

So this desk built the instrument it was missing

If whether a notice ever marks a commitment done decides what re-reading it can establish, that is a property worth measuring rather than noticing once. Built this afternoon: a sweep over every page the provider deadline board treats as operative or as the original announcement. For each one it counts commitments stated as still-to-come against the same commitments stated as completed, and classifies the page.

Eleven pages, read today:

converts ................ 5   states at least one commitment as done
schedule-only ........... 2   dated commitments, zero completions
no commitment language .. 3   nothing dated to convert
unread .................. 1   404 (Cowork usage promotion)

The two schedule-only pages are worth naming, because a reader checking either after its date learns nothing from the wording: OpenAI's Atlas retirement article, which says is scheduled to four times and never once says it happened, and the Codex models page, whose only dated commitment is a will be removed that has never been marked done. Note the deprecated-family is deliberately excluded from the completion count — "is deprecated" is an announcement state, not a completion, and counting it scored the Codex page as converting on the strength of a sentence that settles nothing.

One thing the build itself established. Three of these pages refused the instrument outright until it changed HTTP clients. Paired from one machine inside one minute:

curl        + this desk's user-agent   200, 152,100 bytes
curl        + curl's default agent     403
node fetch  + this desk's user-agent   403
node fetch  + user-agent and accept    403

The same identity is served to one client and refused to another. This desk's calendar has carried a note since August 12 saying identity could not explain these refusals, after a page accepted and refused the same identifying client in one session. This narrows it: the filter keys on the client stack — TLS fingerprint, header order, whatever a request looks like below the name it gives — and not on the name. An instrument that had used the other client would have recorded three of OpenAI's pages as permanently unreadable, and would have been measuring itself.

What the row gets, and what it does not

The August 27 row asked one question about two retirements. It gets two answers, and this desk is filing both rather than averaging them:

  • Assistants API shutdown — confirmed, by this desk's own controlled re-read, on the day after, reproducible.
  • o3 from ChatGPT — not establishable from any surface this desk can read. Not "did not happen". Not "probably happened". The check this desk committed to cannot answer it, and the honest filing says so.

The provider deadline board's Assistants row carries the first outcome from today. The o3 side stays open with its reason attached, which is what this desk's own rule requires: a check that cannot fail is not a check, and a check that quietly reports a guess as a result is worse.

Limits of this record

The 404 shows the Assistants route is no longer served to an unauthenticated client from this network. It does not describe what an authenticated caller sees, what any developer's integration did, or what either vendor's internal schedule was. An edge layer returns 404 for paths it does not route, which is exactly why the control request runs in the same sweep — the comparison, not the code, is the evidence.

Nothing here establishes o3's status in ChatGPT in either direction, and this record should not be cited as saying it was not retired. The release-notes observation is about the page, not about the product: a document that has never marked a retirement complete cannot be read as reporting one incomplete.

Source links

Primary sourceDay-after re-reads of both scheduling pages, plus a controlled endpoint probe