Skip to content
Hugin
Back to NewsAtom feed
Hugin News

August 26: this desk read the shutdown twice. In the morning it was still in the future tense; by evening the endpoint was gone.

6 min read
A single flush metal door closed tight in a dark bare concrete wall under one cold overhead light, with no sign, plate or indicator anywhere on or beside it.
Original editorial artwork generated for Hugin.

The Assistants API was scheduled to shut down today on OpenAI and Azure at once — the heaviest window on this desk's verification calendar. Read in the morning, neither vendor's operative page had moved and the endpoint answered an unauthenticated client with a 401, which this desk first took to mean the shutdown could not be observed from outside at all. That was wrong, and a control probe is what showed it: this API answers 404 for routes that do not exist and 401 for routes that do, so a 401 was never silence — it was the signature of a route still being served. Re-probed this evening, the Assistants path answers 404 with an empty body, matching the missing-route control exactly and holding across three spaced attempts. Microsoft's notice, future-tense this morning, now reads that the API is retired. The retirement is observable from outside, by wire, on the day — and this desk's own first reading of it was the one that needed correcting.

huginnewsverification-calendardeadlinesopenaiazuremicrosoftapi-shutdownprimary-sourceevidence-posturemethod
7source receipts3source hosts6 minread timelinkedprimary source

Today was the day. The Assistants API — deprecated by OpenAI in August 2025, retired by Microsoft's Azure OpenAI service on the same date with a different named replacement — was scheduled to shut down today, August 26, 2026, on both vendors at once. It is the first and heaviest of the six dated windows this desk queued on August 24.

This record was written twice. The first version reported that the shutdown could not be observed from outside, because the endpoint answered a 401 and a 401 gives nothing away. That was wrong. The correction is the more useful record, so both readings are kept below, in the order they happened.

The ledger still speaks in commitments

OpenAI's API deprecations ledger, read in full today:

On August 26th, 2025, we notified developers using the Assistants API of its deprecation and removal from the API one year later, on August 26, 2026.

Both of the calendar row's watched terms are present — on August 26, 2026 once, and the record-only phrase Responses API and Conversations API twice. The ledger is a record of the schedule. It said this on the 24th, when this desk's sweep last read it, and a ledger entry does not flip tense when the event it schedules occurs. That is exactly why it is the page this desk anchors — and exactly why reading it alone cannot tell you whether the shutdown executed.

The morning read: the notice was still in the future tense

The operative Azure page, read this morning:

The Assistants API is deprecated and will be retired on August 26, 2026.

"Will be retired on August 26, 2026," read on August 26, 2026. Nothing about that is necessarily wrong — a page written before its date does not become false at midnight, and pages are edited on human schedules. But it meant the vendor's own notice, on the day of the event it announces, still described that event as upcoming.

That is no longer what the page says. Read again this evening, the same notice reads:

The Assistants API is retired. Use the generally available Microsoft Foundry Agents service. To update your workloads, see the migration guide.

Past tense, and the date is gone with it. The page caught up to its own deadline somewhere between this desk's two reads.

The address moved, and this desk cannot date the move

The address cited here on August 19 —

learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/assistants

— now answers 301 and lands at

learn.microsoft.com/en-us/azure/foundry-classic/openai/concepts/assistants

The redirect works and the target returns 200; no reader is stranded. The ai-foundry documentation tree has been reorganized under a path named foundry-classic, and the new path name is itself a small record: the documentation for the product carrying this retirement now lives under a tree whose name marks it as the old way.

What this desk cannot say is when that started. It cited the address on August 19 and observed the redirect today; nothing here rules out any day in between, and no archived copy exists to narrow it. The redirect is reported as first observed today — not as having moved today.

The evening read: a 404, and a control that makes it mean something

The endpoint, probed this morning with an unauthenticated GET, answered:

GET https://api.openai.com/v1/assistants
HTTP 401
{
  "error": {
    "message": "Missing bearer or basic authentication in header",
    "type": "invalid_request_error",
    "param": null,
    "code": null
  }
}

This desk's first reading of that was: authentication is evaluated before endpoint existence, so an unauthenticated client gets the identical answer from a live Assistants API and a shut-down one, and execution is therefore not establishable from outside. That inference was never tested, and it is wrong. The test it needed is a control — ask the same API for a route that certainly does not exist, and see whether it answers differently.

Run this evening at 03:28:43Z on August 27 — the evening of the 26th at this desk — four unauthenticated GETs from the same client, in one sweep:

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

The two live routes answer 401 with a JSON error body. The invented route answers 404 with nothing in it. Route existence is evaluated first on this API, which inverts the morning's conclusion in both directions: the 401 read in the morning was not silence, it was the signature of a route still being served — and the 404 read tonight is the shape of a route that is not there.

Repeated three times, spaced, at 03:29:04Z, 03:29:17Z and 03:29:30Z, the readings held: the Assistants path answered 404 with an empty body each time, while /v1/chat/completions answered 401 with its 160-byte body each time. That is the same bar this desk applies before recording any failure — one 403 proves nothing, and one 404 does not either.

So the shutdown is observable from outside, by wire, on the day. What was missing this morning was not access. It was a control.

Why the check is still dated tomorrow

The calendar row for this shutdown remains dated August 27, and the rule behind that date is unchanged: a retirement is verified by absence, and an absence is only meaningful after its date. Today's readings do not retire that rule — they give tomorrow's sweep something specific to confirm, which is that the 404 persists rather than being a deployment blip caught mid-rollout. A single evening's absence, however well controlled, is one evening.

What today contributes is the day-of baseline, and it is a stronger one than this record originally set out to file: the endpoint stopped answering, the vendor notice moved into the past tense, and both movements were caught between two reads hours apart.

Limits of this record

The morning readings — the 401 and the future-tense Azure sentence — are this desk's own contemporaneous notes. They carry no clock time and no archived copy: the Wayback Machine holds no 2026 snapshot of that page at either address, its nearest capture being November 2025, which carries no retirement notice at all. Nothing external corroborates the morning state, and this record does not pretend otherwise; only the evening readings are timestamped and controlled.

A 404 with an empty body is also what an edge layer returns for a path it does not route, so this shows the route is no longer served to an unauthenticated client from this network — not what an authenticated caller sees, and not what any developer's integration did today. This desk holds no OpenAI API credential. The help-center page that carries OpenAI's consumer-facing release notes declined this desk's automated reads again today, three spaced attempts, and is reported as a decline — not as evidence of anything. Both vendors are entitled to execute their schedules in their own infrastructure on their own clock.

Source links

Primary sourceDay-of reads of both vendors' pages, plus a controlled endpoint probe