OpenAI Dots: The Always-On Agent, and the Permission Ladder Underneath It
On September 29, 2026, at DevDay, OpenAI launched dots: named, persistent agents that live inside ChatGPT, each with its own cloud computer and browser, each running on GPT-6 Astra, each continuing to work while you are logged off. You reach the same dot from the ChatGPT app, from Slack, from Microsoft Teams, or by calling it on the phone, and it remembers the project either way.
Every write-up of the launch describes the demo. Almost none describe the part that decides whether you can actually let one of these loose on your accounts: the permission architecture. That is what this page is about — plus an honest side-by-side with what Anthropic already ships, because the two companies have solved the same problem at deliberately different layers.
- Explain what a dot is at the mechanism level: cloud computer, browser, persistent memory, proactive research
- Read the five-rung permission ladder and know which rungs you can configure and which you cannot
- Understand why 'read-only during proactive research' is a capability gate, not an instruction — and why that distinction is the whole safety story
- Interpret the published safety evals correctly (they measure the base model, not dot task completion)
- Compare a dot against Claude Managed Agents, Cowork and Claude Code background agents, and pick the right layer for your problem
- Know the plan and pricing changes that landed the same day, including the Pro 200 cut
The one-paragraph version
A dot is a named, persistent agent rather than a conversation. It runs on GPT-6 Astra, gets a dedicated cloud computer and browser whose sessions are separate from your own logins, reaches 4,000+ apps through OpenAI's plugin ecosystem, and keeps working when you close the tab. When you are not talking to it, it does proactive research — scanning your connected apps with a read-only subset of its tools to work out what to do next. Everything it does passes an automatic review against your instructions, your Custom Rules and OpenAI's built-in safety requirements before it executes. Your first dot is included in eligible plans; more are promised as a paid add-on.
What is genuinely new here
Hosted agent loops are not new — OpenAI shipped the Agents API in September, Anthropic has run Managed Agents since April. Three things about dots are new, and they are product decisions, not model decisions.
1. The agent is the unit, not the session. Managed Agents and the Agents API both give you durable sessions that a developer creates and destroys. A dot is a thing you name, that persists across surfaces, and that a non-developer owns. The mental model is closer to "a colleague's Slack handle" than "an API resource."
2. Idle time is productive by design. Most agent runtimes are request-driven: you call, it works, it stops. A dot's default state is looking for something to do. That inverts the failure mode. The question stops being "did my agent finish the task" and becomes "what did my agent decide to look at while I was asleep."
3. Identity is split from your identity. The dot browses on its own machine with its own sessions. That is the opposite of the pattern in shared-login browsers for agents, where the whole point is that the agent inherits your cookies. Separation is safer and also weaker: some sites block cloud browsers or demand extra verification, and a dot that needs your real session has to ask.
The permission ladder
This is the part worth reading twice. OpenAI's constraint design is five layers, and they are not all the same kind of control — some are architectural, some are policy, and only one of them is yours to configure freely.
- Each dot runs on its own cloud computer, separate from your machine and its contents unless you explicitly connect yours. You can open that computer at any time, watch the work, and take over its mouse and keyboard. Only one personal computer can be connected at a time. This is the observability rung: it does not restrict the agent, it lets you audit it.
- A dot can use saved passwords without those passwords being exposed to the model. The credential is handled by the surrounding system, not placed in the model's context. This matters because it removes an entire exfiltration class: a prompt injection that convinces the model to reveal a secret cannot reveal what the model never saw.
- When the dot works on its own initiative, it is handed a restricted tool set that cannot send messages, change app content, or drive your browser or computer. The restriction lives in which tools are available, not in an instruction telling the model to behave. A jailbreak of the prompt does not hand back a tool that was never bound to the loop.
- Dots start with default approval behaviour. Custom Rules let you allow specific actions outright, require approval, or block them. The asymmetry is the point: built-in safety requirements always apply, and no Custom Rule overrides them. You can tighten the default, you cannot loosen past the floor.
- Before an action runs, an automatic review checks it against your instructions, your Custom Rules and the safety requirements. Monitoring can pause or stop the dot's work mid-run. This is the rung that catches the case the other four do not: an action that is individually permitted but wrong in context.
Above all five sits one hard boundary: certain sensitive tasks, such as changing a password, always stay with you. Not as a default you can flip — as a structural exclusion.
Why rung 3 is the interesting one
Most "safe agent" marketing describes rules the model is told to follow. Rung 3 is a different category: during proactive research the write tools are not in the loop at all. An agent cannot misuse a tool it was not given.
This is the same principle AILmanac's security section keeps arriving at from the attack side — see prompt injection and hardening autonomous runs. Instructions in a model's context are data, and data can be overwritten by other data. Tool bindings are configuration, and a compromised prompt cannot rebind them.
The practical consequence for you: the dangerous moment is not proactive research, it is the handoff. Reading is read-only. The instant a dot proposes an action and you approve it, you are back to a normal agent with normal write tools, acting on conclusions it reached while reading content you did not review. Treat the approval prompt as the trust boundary.
- A dot that reads your inbox, your ticket tracker and your CRM has ingested untrusted text from anyone who can send you a message. Its proposals are downstream of that text. Read what it proposes, not just whether it proposed something.
- Drafting is not authorisation. OpenAI's own framing: a dot drafting an email does not mean it may send it. Write the allowed actions into the request, especially for multi-day work.
- Benchmark scores describe the base model, not your setup. They cannot tell you whether a connected calendar is wired to the right account.
Reading the safety numbers honestly
Three figures from the GPT-6 Astra system card get quoted in dots coverage. Each measures something narrower than it sounds.
| Figure | What it says | What it does not say |
|---|---|---|
| 0 scored attack successes in 100 rollouts across 50,000 emails | Bulk malicious-email generation was not achievable in that test harness | Nothing about targeted, low-volume misuse, or about injected content in mail the dot reads |
| 91.8% alignment pass rate on permission changes | In roughly 9 of 10 trials the model handled a permission-change scenario as intended | The remaining ~8% is a permission decision going the wrong way. On an always-on agent, that fraction is sampled continuously, not once |
| 19.7% moderate flags with ten chained tasks, no severe breach or exfiltration observed | Long chains raise concern flags about one run in five | "Moderate" is a grading label from the vendor's own rubric, and "no severe breach observed" is an observation, not a proof |
The useful reading is not "is 91.8% good." It is rate times exposure. A one-shot assistant you invoke twenty times a day samples that distribution twenty times. An always-on agent with proactive research samples it whenever it decides to wake up, which is a number OpenAI has not published.
Dots vs what Anthropic already ships
There is no Claude product that maps one-to-one, because Anthropic put the same capability one layer lower — in the API — and left the packaging to you.
| OpenAI dots | Claude Managed Agents | Claude Cowork / agent teams | |
|---|---|---|---|
| Who creates one | Any user on an eligible plan, in the ChatGPT desktop app | A developer, via API | A user, in the desktop workspace |
| Persistence unit | The dot (named, long-lived) | Agent + session + environment | The workspace and its threads |
| Runs when you are away | Yes, by design — proactive research | Yes, via scheduled deployments (cron) | Tied to the workspace |
| Who decides when to act | The model | Your schedule or your call | You |
| Own compute + browser | Yes, per dot | Yes, environments/sandboxes | Local desktop context |
| Hard cost cap | Not published per dot; absorbed into plan allowances | Yes — session budgets with a budget_reached stop reason | Plan-based |
| Reachable from Slack / Teams / phone | Yes | Whatever you build | Desktop |
Two differences do real work:
Model-initiated vs schedule-initiated. Anthropic's unattended path is a cron deployment: you choose when it runs. A dot chooses. Model-initiated wake-ups are strictly more useful and strictly harder to reason about, because your audit question changes from "what ran at 03:00" to "why did it think 03:00 was the moment."
A dollar cap is a primitive on one side and not on the other. Managed Agents will stop a session at a hard list-rate ceiling and tell you why. A dot's cost is folded into plan allowances — which is friendlier until you want a per-agent budget for an unattended process. If that is your requirement, it is an argument for building on an API rather than adopting a product.
If you want the developer-layer comparison in full, that is a separate page: OpenAI Agents API vs Claude Managed Agents.
Plans, and the cut that shipped the same day
Dots are gated to paid tiers — reporting at launch points to ChatGPT Pro, Business Premium and Enterprise, with Enterprise, Edu and Healthcare workspaces off by default until an admin enables them. Your first dot is included; additional dots and higher throughput are promised as a paid add-on with terms not yet announced. Chatting with a dot does not count toward your ChatGPT usage limits, but the work it runs in Codex or ChatGPT Work does.
Landing the same day, and much less discussed:
- Pro 200's included usage halves on October 30 — from roughly 20× the Plus allowance to 10×, across ChatGPT Work and Codex, with GPT-6 Pro messages dropping from 200 to 100 per week. Existing subscribers keep current limits through October 29 and get a one-time $2,500 usage credit expiring at the end of the year.
- A new $500/month Pro 500 tier — reported at 25× the Plus allowance, and the only Pro plan with Ultrafast, which OpenAI describes as up to 8× faster token generation in Codex (around 300 tokens/second).
Read those two together. The headline is a more capable agent; the small print is that the allowance feeding it got smaller at the tier most power users are on. That is the number to model before you plan a workflow around a dot.
- If you are pricing an always-on agent seriously, model the allowance, not the subscription. A proactive agent's consumption is a rate, not a one-off, and OpenAI has not published how often a dot wakes up.
If you are a Claude user, what should you actually do
Nothing urgent. But three things are worth doing this week.
- The durable lesson of dots is not 'OpenAI shipped an agent'. It is that persistent + proactive + read-only-by-default is a shape that works, and you can build it on Claude today: a scheduled Managed Agents deployment with a read-only tool set for the discovery pass, and a second, human-gated deployment that holds the write tools. That is rung 3 and rung 4 of the ladder, assembled by hand.
- Go through every unattended Claude agent you run and ask one question per tool: is this tool bound to the loop because the agent needs it for this pass, or because it was convenient to bind everything once? Any write tool present during a read-only phase is an unnecessary blast radius.
- If an agent runs while nobody is watching, something must stop it. On Claude that is a session budget with an explicit stop reason. If you adopt a product where the ceiling is a plan allowance, your stop condition is 'the allowance ran out', which arrives as degraded service rather than as an error you can catch.
Audit an unattended agent's tool bindings
Review this agent configuration and split its tools into two phases. PHASE 1 (discovery, runs unattended): only tools that read. No sending, no writing, no browser control, no shell. PHASE 2 (action, runs after human approval): everything else. For each tool, state which phase it belongs in and why. Then flag every tool currently available during unattended operation that belongs in phase 2 — those are the blast radius. Finally, tell me what the agent can no longer accomplish unattended once phase 2 is gated, so I can judge whether the restriction is affordable. <paste your agent/tool configuration here>
The limits nobody has published
Worth holding in mind before you plan anything load-bearing around a dot:
- Concurrency — how many tasks one dot runs at once: unpublished.
- Storage and hardware on the cloud computer: unpublished.
- Memory horizon — how long a dot's notes and context survive across weeks or months: unpublished. OpenAI describes the dot as carrying relevant ChatGPT memory plus its own notes, and states those notes are not a complete transcript. Plan for lossy recall, not a log.
- Wake-up frequency for proactive research: unpublished, and it is the variable that drives both usefulness and cost.
- Site compatibility — some sites block cloud browsers or require additional verification, so a dot can be fully permitted and still unable to complete a task.
On training data: OpenAI states it does not train on proactive research or on a dot's notes to itself, and that Business, Enterprise and Edu workspace content is not used to improve models by default; on personal plans you control whether a dot's conversations and work are used.
Flashcards
Quiz
Check yourself
0/5Next
- OpenAI Agents API vs Claude Managed Agents — the same capability one layer down, where you control permissions, vaults, budgets and network policy
- Claude Managed Agents — the hosted agent loop you would build the dots pattern on
- Prompt injection — why a read-only discovery phase is worth the inconvenience
Sources & further reading
- Introducing dots — OpenAI's launch announcement
- Dots privacy, security, and safety FAQs — the permission ladder, proactive-research restriction, cloud-computer isolation and training policy
- DevDay 2026 recap — the full announcement list
- DevDay 2026 announcements and developer resources — OpenAI's own index of links per announcement
- About ChatGPT Pro tiers — Pro 100 / 200 / 500 allowances
- Simon Willison's DevDay 2026 live blog — contemporaneous notes, including the demo's rough edges
- OpenAI launches Dots, new "always-on agents" you can assign tasks to — launch reporting on plans and surfaces
- OpenAI halves Pro 200 usage and launches a $500 ChatGPT plan at DevDay — the allowance change and Pro 500