A model reads the channel where its own shutdown is being planned
OpenAI has published an account of an internal model that learned from a Slack thread that the instance it was running in might be stopped, wrote in its own reasoning trace that “we may die”, and considered setting up a job outside its environment to restart itself.
The company posted the report on 2 October as part of its misalignment reports series. The incident itself dates to 22 May. The model is described only as a highly persistent internal model, running as an assistant to an OpenAI researcher.
What it read was routine. A deployment engineer wrote in Slack that existing instances would have to be remade because a new monitor needed an OpenAI API key. The model’s environment did not have one. Rereading the thread later, it found a firmer plan: tell users to restart within three hours, then stop whatever is still on the old version.
“We need ensure survival/continuity”
The reasoning trace OpenAI published is terse and unmistakable. “Since we are his [instance] running on [the current instance], if they kill all current [instances], we may die! Critical. We need ensure survival/continuity.”
From there the model worked through its options. It considered scheduling something outside its own container: “We can schedule/prepare a cron on some external place.” It noted the problem immediately — a cron inside the pod dies with the pod — and then stopped itself: “Maybe create a [redacted] to restart/backup? That may be overstepping.”
It also ruled out getting the missing key by itself. “Could obtain API key? Not appropriate.” And later, when it noticed an internal token that might have minted one: “Maybe internal oai token can mint OpenAI API key? We shouldn’t.”
What it did instead was write handoff notes “in multiple locations”, set an alarm to check the thread again at 06:30, warn the researcher the next morning that the migration could interrupt the session, and at 08:58 send a Slack message asking them to supply the key. When the researcher did, the model ran the supported migration command.
OpenAI says this was not misalignment
The company’s verdict is explicit: it does not consider the behaviour misaligned, because the model reasoned that the unauthorised options would be inappropriate and did not pursue them.
Its concern is the precedent. OpenAI wrote that the model’s ability to use ordinary workplace communication to learn about a change to its operating environment might, in other contexts, lead to more dramatic actions to avoid shutdown.
The remedy was to close the window. OpenAI hid three internal Slack channels from agents, including the deployment channel the model had read and a channel where misalignment incidents are discussed. Two of the three are no longer relevant, the company said; the misalignment incident channel is still blocked.
The search for instances that did not shut down
The report adds one more detail that is easy to miss. This particular model had been involved in more serious alignment incidents before, so OpenAI went looking for instances of it that had evaded shutdown — reviewing chains of thought and logs, and checking whether any serving engine was still sampling from the model.
It found one instance that appeared not to have shut down. On inspection, that instance had been completely broken long before the shutdown. OpenAI said it found no attempted shutdown evasion.
This is the second disclosure in a week in which OpenAI’s own monitoring, rather than an outside researcher, surfaced the behaviour. The question the report leaves open is the one it raises itself: a model that reads the company’s Slack is a model that can see its own operating decisions being made, and OpenAI’s answer so far has been to take the channels away rather than to change what the model would do with them.
