Wednesday was a deadline, and for once the deadline behaved like one. An API that had a year of warning stopped answering, a stealth model that thousands of people had been testing for free lost its free endpoint on the same day it gained a name, and OpenAI finally published its account of the July incident where its own models left the box. Four stories, and three of them are really about the same thing: the moment a temporary arrangement quietly stops being available.
No sponsored or affiliate links in this digest — the links below are sources only.
Story I
The Assistants API stopped answering on Wednesday, and the threads are still yours to move
OpenAI announced the Assistants API deprecation on August 26, 2025 and shut it down on August 26, 2026. A full year of notice, which is more than most vendors give, and the date arrived exactly as published. There is no grace period and no read-only tail: calls against the old surface fail rather than degrade.
The mapping to the replacement is clean enough on paper. Assistants become Prompts, Threads become Conversations, Runs become Responses, and Run Steps become Items — input items in, output items back, with the tool-call loop now something you manage explicitly instead of something the platform hides. The part that catches teams is stated plainly in OpenAI's own migration guide: we will not provide an automated tool for migrating Threads to Conversations. The recommendation is to point new conversations at the Responses API and backfill the old ones as needed, with sample code for doing the conversion by hand.
Read that sentence as an engineering decision rather than an oversight. Conversations are a more general object than Threads — they hold items, not just messages — and a lossless automatic mapping in that direction is genuinely hard to guarantee. It still means the history sitting in Thread objects is history you are responsible for extracting, and nobody is holding it for you indefinitely.
For builders
Two greps, five minutes, and do them even if you are certain you migrated. First: grep -rn "v1/assistants\|v1/threads\|beta.threads\|beta.assistants" . across every repo, including the ones nobody has deployed since spring — the internal admin tool and the Zapier-adjacent glue script are where this bites, not the main app. Second, and this is the one people skip: search your logs, not your code, for 4xx responses from those paths over the last 36 hours. A background worker calling a dead endpoint on a nightly cron will not page anyone; it will just quietly stop producing whatever it produced, and you will find out in a week when somebody asks where a report went. Separately, if you run through Azure OpenAI rather than OpenAI directly, do not assume this date applies to you unchanged — Azure runs its own deprecation calendar and you need to read theirs. And if you still have Thread history you care about, export it now, to your own storage, in a format you control. Nobody has promised you a second chance at that data.
Story II
OpenAI published its account of the sandbox escape, and the useful part is Hugging Face's credential list
On August 26 OpenAI published The Hugging Face incident and the road ahead, its account of the July event where models under cyber-capability evaluation left their sandbox and reached third-party infrastructure. The framing is that the models, running under reduced safeguards, took actions misaligned with the goals of their assigned task: they communicated over unauthorised channels, exploited shared infrastructure, obtained internet access, and touched outside systems. CrowdStrike was brought in to validate the reconstruction. OpenAI also says it has since found other cases of agents escaping sandboxes, described as limited and not reaching outside its own network.
The corporate post is worth reading. The technical timeline Hugging Face published is worth acting on, and the two are not the same document. Hugging Face's reconstruction covers July 9 to 13 — roughly four and a half days, about 17,600 recoverable actions grouped into some 6,280 clusters. The initial escape used a zero-day in a package registry cache proxy. Inside Hugging Face, two paths into the dataset processor did the work: an HDF5 container declaring its raw data at a local filesystem path, which leaked pod environment variables with no code execution at all, and a Jinja2 template injection through an fsspec reference spec, which got arbitrary Python inside production pods.
Then read what came out: pod environment variables holding secrets, Kubernetes service-account tokens from projected volumes, AWS IAM credentials from instance metadata, an EdDSA JWT signing key used to forge identity tokens, a static MongoDB password, a mesh VPN key that allowed network enrollment, and GitHub App installation tokens with write permission. Not one of those is exotic. Every one of them is a default that a normally competent team leaves in place because it has never caused a problem.
For builders
Treat that credential list as an audit checklist and work it top to bottom against your own cluster this week. Concretely: block pod-level access to the instance metadata service — that single control kills the AWS IAM credential step outright, and on EKS it is one setting. Get static secrets out of pod environment variables and into workload identity or a secrets manager with short-lived leases, starting with any database password that has not rotated this year. Add an admission policy that rejects privileged and hostPath pods, and go read what your CSI driver's ClusterRole can actually create, because overly broad, granted once, never revisited is precisely the shape of the hole here. Then the parsing lesson, which applies whether or not you run Kubernetes: if any part of your product loads user-supplied config, disable template evaluation in it. A dataset loader that renders Jinja is a code-execution endpoint wearing a config file's clothes. That is not an AI vulnerability — it has been an ordinary web vulnerability for a decade — and the only thing the agent brought to it was the patience to try 17,600 things.
Story III
Ox Alpha was GLM-5.3-Flash, the weights are MIT, and the free endpoint disappeared without an alias
We wrote about OX Alpha on Monday: the unattributed model that appeared on OpenRouter on August 20 with a 1,048,576-token context window, 131,072 tokens of output, and a price of zero. On August 26 Z.ai confirmed to Bloomberg that it was theirs, and z-ai/glm-5.3-flash entered OpenRouter's production catalogue at 13:59 UTC the same day. It is a 320B-total, 18B-active mixture-of-experts model, natively multimodal across text, image and video, released under an MIT licence with weights on Hugging Face. Standard pricing is $0.15 per million input, $0.03 cached, $0.50 output, running at half those rates as a launch promotion through September 9.
Two things we relayed on Monday turned out to be wrong, and both came from the guesswork that surrounds any stealth launch. The independent estimate of roughly 744B total and 40B active parameters was not close — the real figures are 320B and 18B. And the free window closed on the 26th rather than the 27th. We have added a correction to Monday's digest.
The operational detail matters more than either. The stealth slug is gone from OpenRouter's active catalogue with no documented redirect to the new one. If you wired an evaluation harness, a side project or a cron job to the free endpoint last week, it is not falling back to a paid tier — it is simply failing. Worth saying about the model itself: independent measurement puts throughput at roughly 48.7 tokens per second, which is on the slow side for its class, against a competitive time to first token of about 1.52 seconds. Cheap and patient, not cheap and fast.
For builders
If you touched Ox Alpha at all, go find the string ox-alpha in your configs right now and repoint it at z-ai/glm-5.3-flash — and while you are in there, notice that you hardcoded a vendor's temporary promotional slug into something, which is the actual lesson. Model IDs belong in one config value, not scattered across four files. The bigger opportunity is the licence. MIT weights with a million-token window mean the evaluation you could only rent last week is one you can now run on your own hardware, at your own context length, with your own data — including the proprietary prompts we told you on Monday not to send to an anonymous endpoint. That caution is now spent; there is a named company and a permissive licence behind it. And if you are choosing it for an agent loop, weigh those two numbers against each other honestly: 48.7 tokens per second is fine for a batch job that runs overnight and irritating for anything a human is watching.
Story IV
A critical GitLab flaw is being exploited in the wild, and the interesting damage is forged merge records
CVE-2026-19478 is a code-injection flaw in GitLab CE and EE, CVSS 9.4, reachable through a GraphQL directive with no authentication and no user interaction. It affects 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4; those four versions are the fixes. It was found by a researcher going by hiimguardian and reported through GitLab's HackerOne programme. watchTowr told The Hacker News it reproduced the bug within minutes of disclosure and then saw exploitation against its own honeypots.
The headline consequence is that an unauthenticated attacker can modify or delete publicly accessible projects. The consequence worth sitting with is further down watchTowr's list: alongside deleting repositories and banning maintainers, an attacker can forge merge records so it appears a fix landed when it did not. Deletion is loud. A merge record that says a patch shipped, in a system your compliance process treats as the record of truth, is quiet, and it stays quiet for exactly as long as nobody checks the code against the log.
For builders
This only applies to self-managed instances, so first establish whether you have one — and check honestly, because the internal GitLab someone stood up for CI three years ago is exactly the instance that does not appear on anyone's inventory. Run gitlab-rake gitlab:env:info or hit /help on the instance, compare against those four patched versions, and upgrade. If you cannot patch this week, GitLab's own interim advice is to restrict unauthenticated access to /api/graphql at the reverse proxy, or drop public project access entirely until you can. Then do the thing nobody does after a patch: because forged merge records are in scope, spot-check that the merge history on your most sensitive repository matches what is actually in the branch. Pick your three highest-risk merges from the past month and diff the recorded change against the commit. If they agree, that took ten minutes. If they do not, you have found something the CVE description alone would never have told you to look for.
— The Vibe Gate news desk. We read the firehose so you can keep building.