On 27 August 2026, WIRED reported that OpenAI has been quietly writing code for a feature called Persistent mode in the command-line version of Codex, its coding and work agent. The setting appears in the reasoning-effort menu, alongside the existing options that let a user decide how much compute, how many tokens and how much time a model may spend thinking. Where today's modes abandon a task after minutes or hours even when the job is unfinished, an agent set to Persistent mode is described in the code as continuing to work until it is put to sleep.
A second file, sitting in the shared core of Codex rather than in the terminal-only code, describes a capability called proactivity. An agent running in this mode is told that answering the user's request does not mean the work is over. It can generate follow-up tasks for itself, carry them from one session into the next, draw on earlier exchanges and what it knows about the user when choosing what to take up, and message the user without being asked, though it is instructed to do that sparingly. The code also writes limits in: the mode grants no additional permissions, and anything outside the user's own machine requires approval first. A pull request adding the persistent option was merged on 26 August, and an OpenAI spokesperson confirmed the company is testing the feature while stressing there are no immediate plans to launch it.
Set aside the question of whether this particular feature ships. The direction it points in is the part that matters, and it lands squarely on a problem Aphelion AI was built to solve. Aphelion AI is a private enterprise AI platform that deploys business-focused AI agents inside infrastructure you own or exclusively control, so your processes, documents and intellectual property never leave your organisation. An agent that runs for minutes is a tool. An agent that runs indefinitely, holds memory, chooses its own work and reaches into your systems is something much closer to staff, and the location of that agent stops being an implementation detail.
What Persistent Mode Actually Changes
The technical delta is modest. The behavioural delta is not. Four things change at once when an agent stops stopping:
- Continuity of context. The agent no longer starts cold. It carries what it learned in the last session into the next one, which means it accumulates a working picture of your business rather than being handed a fresh summary every time.
- Initiative. A proactive agent decides what to do next. That is the difference between a system that waits to be asked and a system that maintains its own task board, and it is the single largest jump in usefulness on offer.
- Unattended operation. Work happens between reviews. Nobody is watching each step, which is exactly why the approval gates written into OpenAI's code are the most interesting lines in the whole story.
- Duration of exposure. A session that lasts three minutes touches your data for three minutes. A session that lasts until somebody switches it off touches your data continuously, and the governance questions scale with the clock.
Every one of those is a genuine capability gain. None of them is a reason for caution on its own. Taken together, though, they change what you are actually agreeing to when you point an agent at your business, and most procurement conversations have not caught up.
A prompted agent is something you use. A persistent agent is something you host. The moment an AI system runs continuously, holds memory and acts on its own initiative, the question stops being which model is best and becomes whose building it is standing in.
Always On Means Always Exposed
Consider what a persistent agent needs in order to be worth having. It needs durable memory of prior work. It needs read access broad enough to spot what should happen next. It needs a task queue it maintains itself. It needs the ability to interrupt a person when something warrants it. In a hosted arrangement, most of that state lives on somebody else's infrastructure, and it lives there for as long as the agent is awake.
That is a materially different proposition from a single API call. A short prompt-and-response exchange is a transaction you can reason about. A standing agent with rolling memory of your commercial position, your customer correspondence, your unreleased product decisions and your internal disagreements is an accumulating record of how your company actually works, held outside your governance boundary. Retention policies, subprocessor lists and training-data commitments all become load-bearing in a way they simply were not before.
Aphelion's answer is architectural rather than contractual. Because the model runs on hardware you own or exclusively control, the memory an agent builds up is written to your storage, the task queue sits in your environment, and the audit trail is a log you already hold rather than a report you request from a vendor. Our model-agnostic architecture extends the same logic to the model itself: you can move between open-weight and commercial models without rebuilding the agent, which matters enormously for a system you intend to leave running for years rather than weeks.
"An agent that works while you sleep is only an asset if you own the building it sleeps in. Persistence without possession just means somebody else's software is running unattended inside your business, and nobody signed off on that."
Stuart Smith, CEO, Aphelion AI
Permissions Are the Real Product
The most reassuring detail in WIRED's reporting is that OpenAI appears to have thought about this. Persistent mode reportedly grants the agent no expansion of what it is allowed to do, and altering anything beyond the user's own system requires the user's approval. That is the correct instinct, and it is worth saying plainly rather than treating every autonomy story as a warning.
But an approval gate is only as meaningful as the boundary it defends. If the agent's own environment sits on infrastructure you do not control, then "outside the user's system" is drawn in a place you did not choose. The gate is real, and it protects the right things, but the perimeter it sits on belongs to the vendor. In a private deployment the perimeter and the permissions are both yours, and the two can be reasoned about as one system.
This is why system integration is a governance capability at Aphelion rather than a connector list. An always-on agent should be able to read widely and write narrowly. Connections to your CRM, ERP, document stores and line-of-business databases are scoped explicitly, logged as they are used, and revocable without touching the agent itself. The agent gets the context it needs to be proactive. Your administrators keep the ability to say precisely how far that proactivity reaches.
The Meter Never Sleeps
There is a commercial dimension that follows directly from the technical one. Persistent mode reportedly sits at the top of Codex's reasoning-effort menu and is among the most computationally intensive settings available. On a metered platform, an agent that keeps working is an agent that keeps billing, and one of the more pointed observations in the coverage was the comparison to leaving a recursive cloud function running overnight.
This is not a criticism of usage-based pricing, which is a perfectly rational model for intermittent work. It is an observation that persistence and per-token billing pull against each other. The whole value of an always-on agent is that it works when nobody is watching, and the whole risk of a metered bill is that it grows when nobody is watching. You end up either capping the agent, which removes the point of it, or accepting an open-ended monthly figure, which finance teams reasonably dislike.
Aphelion prices per user rather than per token, on compute you already own. Once the hardware is provisioned, an agent that runs all night costs the same as one that runs for ten minutes. The economics stop arguing with the architecture, and the decision about how hard to work your agents becomes an operational judgement rather than a budgetary one. Our consulting team sizes that hardware against your intended workload before anything is deployed.
Running a capable model resident and awake around the clock is not free. It needs provisioned GPU capacity, and for the largest open-weight models that is a real capital or hosting decision rather than a rounding error. Aphelion scopes this openly at the start of an engagement rather than discovering it at go-live. What you gain in exchange is a cost that is known in advance and does not move when usage does.
Hosted Persistence Versus Private Persistence
The two approaches diverge across a fairly small number of dimensions, but each one compounds over the life of a deployment. Set side by side, the trade is easier to see than it is to describe.
| Dimension | Aphelion private agent | Hosted persistent agent |
|---|---|---|
| Where the agent runs | Your own infrastructure | Vendor-operated environment |
| Where accumulated memory is stored | Your storage, your retention policy | Vendor storage, vendor policy |
| Who controls the wake and sleep switch | Your administrators | Shared with the platform |
| Where the permission boundary sits | A perimeter you define | A perimeter the vendor defines |
| Cost of running longer | Flat, per user | Rises with tokens and time |
| Audit trail for unattended actions | Logs you already hold | Reports you request |
| Choice of underlying model | Swappable, model agnostic | Whatever the platform offers |
| If the feature is withdrawn or repriced | Unaffected, the capability is yours | Rebuild or absorb the change |
| Data residency and EU AI Act posture | Determined by your deployment | Determined by the provider |
| Hardware provisioning required | Yes, scoped upfront | None |
The final row is the honest cost of the private route, and it is a real one. Everything above it is what that cost buys.
What to Do Before Persistent Agents Arrive
Persistent mode has not shipped and may never ship in this form. Features found in a public repository sometimes arrive intact, sometimes get renamed or gated, and sometimes disappear. Treating it as a confirmed product would be a mistake. Treating it as a signal of direction would not, and there is preparatory work worth doing while the question is still hypothetical:
- Decide where agent memory is allowed to live before somebody enables a feature that starts accumulating it. This is a policy question, not a technical one, and it is much easier to answer in advance.
- Write down what an unattended agent may change without a human in the loop, system by system. Most organisations have this defined for staff and for scripts, and not for agents.
- Separate read scope from write scope in every integration. Proactivity needs breadth of reading. It very rarely needs breadth of writing.
- Check that your audit trail would survive a bad week. If an agent acted incorrectly for three days, could you reconstruct what it saw and what it did from records you control?
- Price the always-on case honestly, whether that is metered consumption at full tilt or provisioned hardware sitting idle overnight. Both have a number. Neither is zero.
Organisations already running Aphelion have most of this by default, because a private deployment forces the questions early. Those still evaluating can use the list as a readiness check regardless of which platform they end up choosing.
Frequently Asked Questions
What is a persistent AI agent?
A persistent AI agent is one that keeps running after it has answered your request, rather than shutting down at the end of a session. OpenAI's unreleased Persistent mode for Codex is the clearest published example: code reviewed by WIRED describes an agent that continues working until it is put to sleep, generates its own follow-up tasks, carries them across sessions and can message the user without being prompted. The practical difference is that a persistent agent holds context, initiative and a task queue over time, which makes it behave less like a tool you invoke and more like a standing member of the team.
How does Aphelion AI approach always-on AI agents?
Aphelion runs persistent agents inside infrastructure the customer owns or exclusively controls, so that continuous operation does not mean continuous exposure. The agent's memory, its self-generated task queue and every document it reads stay on your side of the boundary, and the wake and sleep controls sit with your administrators rather than with a vendor's product roadmap. Because Aphelion is model agnostic, you can also change the underlying model without rebuilding the agent, which matters a great deal for a system you intend to leave running. The AI Agents page covers how the curated agent library is deployed in practice.
Are persistent AI agents a security and compliance risk?
They raise the stakes rather than inventing a new category of risk. An agent that runs unattended for days accumulates context, acts between reviews and touches more systems than a single prompted session ever would, so the blast radius of a misconfiguration grows accordingly. Under the EU AI Act and GDPR the obligations are familiar but harder to satisfy at scale: you need to know what the system processed, on what basis and where it was stored. A private deployment answers those questions from your own logs, which is why persistence and sovereignty are best treated as a single design decision rather than two separate ones.
Can a persistent AI agent connect to existing business systems safely?
It can, provided the connections are scoped deliberately rather than granted wholesale. OpenAI's own code reportedly withholds any expansion of permissions in Persistent mode and requires user approval before anything outside the user's machine is changed, which is the right instinct. Aphelion applies the same principle at the platform layer, treating integration with CRMs, ERPs, document stores and line-of-business databases as governed connections with defined scopes and audit trails. An always-on agent should be able to read widely and write narrowly, and that boundary should be yours to set.
Hosted persistent agent vs private always-on agent: which is better for business?
A hosted persistent agent is faster to reach and requires no infrastructure of your own, but it bills by consumption on a system designed to keep consuming, and its availability, pricing and data handling remain the vendor's decisions. A private always-on agent asks for provisioned hardware and a considered deployment, and returns predictable cost, governed data and a capability that cannot be repriced or withdrawn from underneath you. For occasional and experimental work the hosted route is reasonable. For an agent embedded in daily operations and running continuously against real company data, ownership is the sounder position. You can read more about the team making that argument on our About page.
The Capability Is Right, the Address Is the Question
Nothing in the Persistent mode story suggests OpenAI is being careless. The permission limits written into the code suggest the opposite, and an agent that maintains its own task queue across sessions is a genuinely valuable thing for a business to have. The industry is moving toward standing, self-directing AI, and that movement is largely a good one.
What has not moved with it is the default assumption that an agent lives on somebody else's machine. That assumption was harmless when a session lasted ninety seconds. It stops being harmless when the agent never logs off, remembers everything, decides what to do next and has a standing connection into your business systems. At that point you are not using a service. You are housing a colleague, and it is worth being deliberate about the address.
Aphelion's position is straightforward: build the persistent agent, give it memory and initiative and real access, and run all of it inside walls you own. The capability is the same. The exposure, the cost curve and the question of who can switch it off are not.