A specific afternoon. You ask Codex to fix a flaky unit test. It tracks down the race condition, patches the code, passes the tests locally, and replies: Fixed, tests pass. As things stand today, what comes next is also doable: add a follow-up asking it to watch CI, and it will go take a look. But every subsequent step forward still requires you to speak up first.
In the new mode OpenAI is currently testing, even that prompt is spared. After completing its work, it doesn’t just sign off. Instead, it leaves itself a note listing four things: what the goal is (confirm the fix holds on CI), where things stand (pipeline just triggered), completion criteria (all checks green), and the next check-in (two minutes later). Two minutes later, it wakes up on its own, checks the CI status, sees it is still running, touches nothing, and goes back to sleep. When it wakes up again, the pipeline is red. Instead of interrupting you with a popup, it pulls the logs to troubleshoot and determines the error stems from network jitter in the test cluster, not its own changes. It logs its diagnostic findings, proactively pushes back the next check-in time, and goes back to sleep. Finally, the pipeline goes all green. It proactively sends a message: The fix has been merged, and the pipeline is all green. At the end, it attaches a note: I also spotted two identical risks in the same file—should I take care of them while I’m at it? Notice that final question: it did not act on its own. Fixing the specified unit test fell within its scope of authorization; modifying other parts of the file exceeded it. It had to stop and ask for permission first.
This is not a marketing fantasy. Every behavior described here is grounded in a system prompt template merged into the open-source openai/codex repository in late August, with every line traceable to the source; the opening scenario is a behavioral profile constructed from the template’s semantics, not an official demo.
On August 27, WIRED reported exclusively that OpenAI was developing Persistent mode for Codex. A wave of media coverage followed, filled with headlines screaming always-on, never-stopping, and 24/7. These words describe a machine that never powers down.
Open up the system prompt template in the open-source repository, however, and the phrasing is far more sober. The template itself uses the term sampled again: after completing a task, if the system samples it again without a new user request, it should look for useful follow-up work. The core concepts are re-sampling and sleep.
There is no daemon process, no dedicated virtual machine, and no new billing surface. At its core, it remains the familiar sampling loop: waking up every 1–3 minutes, glancing at the latest status, acting if something comes up, and going back to sleep if nothing does; for slow-moving tasks, it proactively extends the check interval.
The entry point’s location is equally telling. It is tucked inside the menu for selecting model reasoning effort, lined up alongside low, medium, and max. The UI option reads Continue working until put to sleep. OpenAI treats persistence as a way to consume compute, rather than an independent feature toggle.
Underpinning all of this is a discipline of state management. The template requires the agent, before each sleep, to record four items in a checkpoint: goal, recent status, completion criteria, and next check-in time, ensuring follow-up work can pick up smoothly even after sleep and context resets. It sets its own checking cadence: every 1–3 minutes for active, near-term work, with proactive backoff when progress slows down.
There is also an ironclad rule on permissions, stated in a single sentence: Persistence does not broaden that scope. Running persistently does not expand the scope of authorization. To alter external state outside its authorization, it must stop and ask for approval first. That is why, in the opening scenario, it stopped to ask rather than casually fixing the other two issues on its own.
Seeing this timed wake-up mechanism, it likely looks familiar: having a model monitor things in the background—isn’t that just a scheduled task? To see the difference clearly, you only need to ask two questions: Who holds the alarm? Who holds the task list?
The former determines when the next action occurs; the latter determines what specifically to do next. Plotting these two questions as coordinate axes, the diverse background agents on the market can all be mapped into four quadrants.
Quadrant 1: Humans set the alarm, humans assign the tasks. Codex Automations, Claude Code /loop, and Perplexity Tasks all sit here. You write the schedule and task prompts, and the system executes when the time comes. This embodies the spirit of cron—humans act as both alarm holder and task dispatcher. It is the most mature, but also the least autonomous.
Quadrant 2: It runs on its own, humans draw the finish line. Claude Code /goal and Codex /goal belong here. You provide a completion criteria—such as finishing an interface migration and ensuring all call sites compile cleanly—and the agent runs iteration after iteration automatically until it hits the line. The pace is its own, but the endpoint is strictly set by humans.
Quadrant 3: It spins on its own, with duties hardcoded in code. The auto-dream routine from Claude Code’s leaked source code is a classic example: every 24 hours, after accumulating 5 sessions, it automatically spawns a subagent to consolidate memories. It indeed requires no human prompting, but what it can do is hardcoded and locked down in code—it accepts no new tasks.
Quadrant 4: The model holds both the alarm and the task list. This quadrant has historically remained empty. Persistent mode aims to occupy exactly this space: when to wake up and what to do upon waking are both determined by the model itself, with humans leaving behind only a discipline defining boundaries.
Other players made the opposite choice: the open-source project LoopX and Gemini Managed Agents with background execution keep wake-up logic and task orchestration in deterministic code, leaving the model solely responsible for picking up tickets and doing the work. The same problem, two starkly different answers. Moving forward, whenever you encounter various background agent marketing claims, you don’t need to memorize complicated product names—just apply the two questions of who holds the alarm and who holds the task list to see right through them.
One of the most intriguing details about this new mode appears inside its network requests. In requests sent to the backend, the value for this tier is still marked as disabled. The local configuration recognizes the string, and it is visible in the UI, but the backend Responses API has not enabled it at all. There is no billing system, and an official spokesperson clearly stated there are no plans for a near-term rollout. To this day, not a single real user has had hands-on access to it.
Holding back the switch is partly because the billing model has not been ironed out, but the deeper reason lies in two sets of evaluation data. Academia recently established a baseline: ProAgentBench tested a single question using more than 28,000 real-world events—the best accuracy for models judging whether they should proactively step in to help right now was only 64.4%, failing on one out of every three decisions. Anthropic’s engineering blog provided another set of numbers: when presented with agent permission prompts, users click approve 93% of the time; when replaced with automated model auditing, the miss rate for genuine overreach is 17%. When you combine a one-third error rate in timing judgment with a double-digit miss rate on safety, inside a system that self-wakes every 1–3 minutes during active periods, incidents become merely a matter of frequency.
Looking back at the system prompt template in the open-source repository, those seemingly rigid constraints map directly to these issues line by line. An entire paragraph is dedicated to preventing duplicate messages, because knowing when to speak up is precisely where models fail one-third of the time; monitoring tasks are prohibited from ending early on their own, because learning to stay quiet when nothing substantial has changed is far harder than spamming messages to signal presence.
OpenAI has paid its own tuition along this path. ChatGPT Pulse, launched last September, generated a personal briefing for users every morning; Altman once called it his favorite feature. It was officially retired this year on June 17, after living for nine months. It died of three things: continuously grasping at topics users had resolved weeks ago just to pad the briefing; staying silent when it should have spoken up while spamming popups when it shouldn’t have disturbed; and producing daily reading material that forced user attention rather than getting things done for the user. Its useful parts were eventually merged into explicitly configured user scheduled tasks and web monitoring.
WIRED characterized Persistent mode as a more aggressive version of the same bet: the previous bet was lost by letting the model act on its own whims; this one wagers on fencing in autonomous initiative with strict discipline. In OpenAI’s own incident report, persisting indefinitely on seemingly impossible tasks is listed as one of four misalignment behaviors. Industry incidents provide a real-world backdrop for these guardrails; however, what truly keeps the product held back is the persistent gap between model judgment accuracy and interaction utility.
If this mechanism is officially launched in the future, what kinds of tasks are suitable to hand over to it? It suits delivery-oriented tasks with clear completion metrics where results require waiting: CI, deployments, builds, data backfills, and verification of external API propagation.
The common profile of such tasks is: one minute of execution, ten minutes of waiting. Today, you can certainly keep sending follow-up prompts to have it watch, but as parallel tasks multiply, just remembering which tasks are still waiting on results becomes a cognitive burden in itself. Persistent mode relieves you of that mental overhead: from the moment you state the goal, it takes over the cadence, with compute serving merely as the substrate.
What it is not suitable for are open-ended tasks. Writing proposals or crafting designs fundamentally relies on human feedback for the next step. Tossing an open-ended task into a persistent loop will not cause the model to achieve sudden epiphany out of thin air; it will simply turn into an automated nagging machine that prompts you on a schedule.
There is another category of tasks that requires special caution: monitoring. The system prompt template explicitly dictates that for tasks where the user requests ongoing monitoring, the agent cannot wrap up early on its own; hence, monitoring tasks have no natural upper cost limit. Traditional cron runs on fixed intervals with predictable expenses; handing scheduling authority over to the model means it will invoke calls whenever it feels it should check. The more tasks you attach, the more unpredictable the bill becomes.
There is no need to wait for vendors to enable the feature. The truly valuable insights in this system prompt template can be adopted right now.
Rule 1: Record the four essential checkpoint elements. Have the agent log its goal, recent status, completion criteria, and next check-in time before going to sleep, plus its scope of authorization. Long-running, cross-session tasks fail most frequently when a new conversation doesn’t know where the previous one left off; these four items make for the cleanest possible handoff sheet.
Rule 2: Stay silent when there are no substantial changes. Never repeat what has already been said, keep quiet when there is no substantive progress, and understand that a timed wake-up does not by itself justify sending a message. Porting this single rule into any system with proactive notification capabilities will instantly elevate the user experience.
Rule 3: Prefer reusing deterministic mechanisms. Leave fixed-interval polling and ready-made completion notifications to external, deterministic cron scripts or webhooks, having the model handle only exception branches. This is not a compromise—the template itself explicitly states: prefer existing completion notifications or product-provided wait mechanisms.
The progressive shift of scheduling authority from human scripts to reasoning models is an inevitable trend. But right now, its most concrete embodiment is an open-source code file under the Apache-2.0 license. Understanding the restraint and discipline in this file is far more useful than waiting for it to go live.