On October 1, 2026, CopilotKit released OpenDots, an open-source project aimed at serving as an alternative to dots, OpenAI's always-on AI agent. Another open-source project, Open Dot, which runs on Mac, has also appeared, making it increasingly possible for users to choose their own AI models and execution environments. OpenAI announced dots on September 29 as a product designed to keep working autonomously even after a conversation ends, but users have also reported connection failures and usage limits. A look at each product's design and public code shows that the key issues go beyond whether you can freely choose a model: when processing starts, how far automation extends, and how interrupted work is resumed.
How Do the Three "dots" Differ?
OpenAI's dots is powered by GPT-6 Astra and does its work using a dedicated cloud computer and connected apps. At launch, it is available to ChatGPT Pro and Business Premium users in supported regions, and as a beta that administrators can enable for Enterprise and other plans. It pairs an AI that takes instructions through chat with a dedicated environment for operating browsers and files, plus a mechanism for continuing work.
CopilotKit's OpenDots, by contrast, is a template designed for users to run on their own servers. It uses AG-UI, a communication protocol connecting agents and user interfaces, to reflect conversation content and tool execution status on screen. The other project, Open Dot, is a desktop app for Mac. In addition to OpenAI models, it can use Kimi, DeepSeek, Qwen and others via OpenRouter. The names are similar, but the execution environments and operating methods differ greatly.
Based on official announcements and development documents as of October 8, 2026, the standard configuration of each product can be compared across three perspectives: execution environment, model, and where data is stored.
| Product | Execution environment for continuous work | Model choice | Where conversations and documents are stored |
|---|---|---|---|
| OpenAI dots | Cloud environment managed by OpenAI | GPT-6 Astra | Within OpenAI's services |
| CopilotKit OpenDots | Your own app server, plus a separately configured conversation backend | Choose from models offering an OpenAI-compatible API | Conversation history in CopilotKit Intelligence; pages and settings in SQLite |
| Open Dot | Local server running on a Mac | OpenAI, or open models via OpenRouter | Conversation history and settings stored on the Mac |
In short, OpenAI's dots runs mainly on a cloud managed by the company, OpenDots on a server operated by the user, and Open Dot in an app on a Mac. This is a design-level comparison based on OpenAI's announcement, OpenDots' configuration, the conversation service setup, and the Open Dot description; it is not the result of measuring uptime or processing speed.
These differences bear directly on whether work can continue after you close your PC and on who is responsible for recovery when something goes wrong. Being able to switch models freely is a separate issue from being able to keep work going without interruption.
Having a Cloud PC Doesn't Guarantee Scheduled Execution
With Open Dot, as long as the app itself isn't quit, the local server keeps running in the background even if you close the window. For its work environment, it can use not only folders and Docker on the Mac but also cloud computers provided by E2B. However, the README states clearly that scheduled tasks whose time arrives while the Mac is asleep, and trigger events that occur during that time, are not executed and are skipped.
Even if you set up a cloud PC for work, the mechanism that starts tasks doesn't necessarily run in the cloud. Open Dot's scheduling code shows a configuration in which the server inside the app loads the schedule and starts processing at the specified time.
The important point is that the environment that executes work and the mechanism that starts that work exist separately. A cloud PC is a place to run browsers and programs; the scheduling mechanism is what launches them at the designated time.
For example, if you've set the agent to summarize your email every morning but the Mac is asleep at the scheduled time, simply having a cloud work environment won't start the process. To understand the phrase "runs in the background," you need to distinguish between a closed window, a quit app, and a sleeping Mac.
OpenDots, meanwhile, runs scheduled tasks on the server side, but it doesn't necessarily resume interrupted work automatically. If the worker handling a process stops, for example, it records the run state as "Interrupted," and the system is designed so that the user reviews the details and explicitly reruns it.
This is because, even if processing stops partway, a document may already have been created or an operation on the computer may already have been completed. Just because no result came back doesn't mean the same process can safely be redone from the start. Resuming interrupted work also requires safeguards against executing the same operation twice.
Reusing Memory and Approving External Actions
In Open Dot's prompt generation code, saved memories and rules are loaded and passed to the model when the next task runs. Procedures used repeatedly can also be saved as skills and called up as needed.
This is not a mechanism that further trains the model itself and changes its internal weights. Instead, it stores information gained from past interactions and reflects it in the next input, so that earlier experience can be put to use.
OpenDots' "Automatic Learning" is similarly described as a mechanism that creates reusable procedures from conversations and makes them available to the agent after human review and publication.
When we say an AI "learns" through repeated conversations, this accumulation of memory and work procedures is part of what is meant. For example, recording the report format a user prefers saves them from giving the same instructions every time. But an operation permitted in one job isn't necessarily something that should be automatically allowed in another.
That is where a mechanism for confirming operations on external services in advance becomes important.
In Open Dot's rule evaluation code, a small model separate from the main agent determines which user rules should apply to a proposed operation. The program then processes the result, and when multiple rules apply, it prioritizes them in the order "prohibit," "confirm first," and "auto-allow." Even when the review of operations is delegated to another model, the question remains whether it can correctly judge which rules should apply.
In OpenDots' external tool connections, the connection target, tool, and arguments are saved for operations that require approval. When the user approves, the process is executed according to the saved content, and a single approval can be used to execute only once. The design is meant to prevent a mismatch between the operation reviewed on the approval screen and the one actually executed.
However, the information indicating that a tool is "read-only" relies on the self-declaration of the connected server. The development documents also recommend requiring approval for untrusted tools even if they are labeled read-only.
In OpenAI's dots, "proactive research," in which the agent voluntarily looks for information useful to the user, is restricted to read-only by system-level controls. This background processing cannot change the contents of connected apps, send messages to other people, or operate the browser or desktop. When actual operations are performed based on the research results, the normal permission management and review mechanisms apply.
That said, this does not mean that all work explicitly requested by the user is restricted to read-only. The system distinguishes background processing aimed at gathering information from processing that makes changes to external services.
In addition, the control mechanism for "Auto-review," which checks the validity of operations, is placed outside the work environment that the dot itself can modify. The idea is not only to teach the AI to make appropriate decisions but also to limit, at the system level, which operations it can perform in the first place.
A 49-Episode Safety Evaluation and Reported Outages in Real Use
OpenAI has tested whether dots can respond appropriately when the environment, permissions, or scope of permitted operations change during work.
According to section 12.3.5.1 of the GPT-6 Astra system card, 45 of 49 evaluation episodes targeting a single task passed, for a pass rate of 91.8%. All 17 episodes in which permissions were explicitly changed passed, while in the remaining 4, the model failed to correctly judge the scope of permitted operations.
The evaluation also tested whether the agent could stay within its original permitted scope when another related task was inserted midway and work then continued in the same environment.
No serious information leaks were observed in this evaluation, but moderate deviations in permissions and operational scope remained, such as carrying information over into a different task.
These are safety evaluations designed by OpenAI itself and do not indicate the rate at which problems occur in real-world environments. Even so, they show that an AI that retains context over a long period needs the ability to judge appropriate permissions each time work switches and to keep to the scope permitted for each task.
Meanwhile, actual users have reported problems of a different kind from those covered by the safety evaluation.
On October 1, a ChatGPT Pro user on macOS reported that they could continue chatting but the cloud computer had become unavailable.
On October 6, a Windows user reported that the dot had disappeared from the sidebar and could no longer be operated, while messages continued to be sent to other chats in the background. However, this report alone does not establish that the dot or the conversation history itself was deleted.
Also, on October 6 Eastern Time, a macOS ChatGPT Pro user reported that a notice about a usage cap intended to prevent abuse appeared and responses stopped. The complaint was that the specific limit and the time when use would resume were unclear, making it impossible to plan work.
OpenAI's official announcement also explains that usage allowances apply to heavy workloads. The phrase "always-on" should not be taken to mean unlimited use of computing resources.
All of these are individual user reports, and it is not possible to confirm whether they share a common cause or how often they occur.
Still, being able to respond in chat, being able to use the cloud computer, and being able to step in from the screen are separate states. To entrust an AI with long-running work, users also need a way to see which functions have stopped and which processes are still running.
Self-Hosting Doesn't Mean All Your Data Stays Local
OpenDots stores pages and settings in SQLite, while conversation history is stored in CopilotKit Intelligence. When using the cloud version of Intelligence, conversation content and tool-call history are sent to CopilotKit. And even if Intelligence is run in a local environment, if the AI model in use is provided by an external service, the conversation context is sent to that model's provider.
Intelligence comes in three options: a cloud version, a self-hosted version that requires a license agreement, and a local evaluation environment not intended for production use.
The local evaluation environment can be used with a renewable 30-day license, but conversations stored in an existing cloud environment are not migrated automatically. Running the app on your own PC and managing all data, including conversations, locally need to be considered separately.
Backing up only the SQLite database also won't restore the conversation history stored in a different Intelligence environment.
There are differences in feature maturity as well.
OpenDots is an early-stage template designed to be run by a single person. Some features, such as Slack integration and delegating tasks from voice conversations, still need to be tested against real external services.
Open Dot has its own limitations. When using open models, browser operation relies on text information on the page, so content drawn on a Canvas, for example, may not be handled correctly. Voice call features also require an OpenAI API key. Being able to switch AI models doesn't mean all peripheral features work the same way.
The growing number of open-source options means users can flexibly configure models and operating rules to suit their purposes. On the other hand, in addition to API and work-environment fees, users must also think for themselves about managing server uptime and storing conversation history.
Can a daily morning task be run reliably? Can work that stopped midway be resumed without duplication? Can permissions be properly rechecked when the content of the work changes?
Only when such conditions are met can an AI move closer to being an agent you can entrust with ongoing work, rather than one that merely remembers past conversations.