Open Dots: A Self-Hosted, Open-Source Alternative to OpenAI Dots

OpenAI announced Dots at DevDay on 29 September 2026: always-on personal agents, built on GPT-6 Astra, that pursue goals in the background. You can reach a dot from ChatGPT, Slack or Teams, and it launched for ChatGPT Pro and Business Premium subscribers in eligible markets (TechCrunch). Each dot works on a cloud computer with a browser and integrates with more than 4,000 apps, and NBC News reported it was not available in Europe or the UK at launch.

Open Dots is an open-source answer for everyone who wants the idea without the subscription, the region lock or someone else's cloud. It is a self-hosted AI agent workspace, released under the MIT license, that you run on your own machine. You create assistants, chat with them on the model of your choice, connect apps, search the web, and optionally hand them a sandboxed computer. Everything is stored locally, and any action with real consequences waits for you to approve it.

It is built by Anil Matcha and is independent of OpenAI. The README is unusually direct about where it stands: Open Dots is "an early prototype, not a feature-equivalent replacement" for OpenAI Dots, Meta Muse, Grok Bot, Manus Cue, Claude Cowork or ChatGPT agent, all of which it names as products it can be evaluated against. This page takes that at its word and covers what the code actually does today.

The two share a name and an idea, not a feature list. Here is the honest side-by-side:

If you want an agent that keeps working while you sleep and answers you on Slack, Open Dots does not do that yet. Where it wins is in the rows that matter most to a developer: you can read every line of the code that decides what your agent is allowed to do, choose the model, and keep the conversation history on your own disk.

This is the design choice that makes Open Dots worth reading even if you never run it.

OpenAI's safety documentation for GPT-6 Astra, the model behind Dots, describes auto-review: a second model "evaluates the safety of certain commands that run outside a pre-specified sandbox," and blocks the ones it judges unsafe (OpenAI deployment safety). The safeguard it describes is a model screening a model.

Open Dots puts a person there instead. Every tool call goes through an action gateway in server/app/services/action_gateway.py, and the gateway is deny-by-default: an action that is not registered is refused outright, and a registered one must match its definition, pass its arguments as a JSON object and include a human-readable preview. Each action carries a risk class (read, write or external), and the dangerous ones pause for your approval:

Three details show real care. Approvals expire after 120 seconds by default, and an expired request is never executed. An approval is consumed before the action runs, so one click allows at most one execution; a contributor fix (pull request #125) closed a gap where a cancelled, already-approved action could have been replayed. And every step (requested, approved, denied, expired, started, completed, failed) lands in an audit log, with anything that looks like an API key, token, password or cookie redacted before it is written.

The computer is optional, and it is off by default: the default fake provider exists for development and returns deterministic results. To give your assistants a real browser, you build the bundled Docker image, which runs Playwright:

docker build -t open-dots-computer:1.62.1 ./runtime
export COMPUTER_PROVIDER=docker
export COMPUTER_DOCKER_IMAGE=open-dots-computer:1.62.1

Each assistant gets its own workspace, and the container launch flags in the source are conservative: a read-only root filesystem with small temporary mounts, dropped Linux capabilities, no-new-privileges, a non-root user, an optional seccomp profile, and limits of 2 CPUs, 2 GB of memory and 512 processes by default. A remote provider can point at a compatible external computer service instead.

The README is explicit that this is "not a hardened sandbox for hostile websites". Containers reduce what a compromised browser can reach; they do not make it safe to point an agent at arbitrary untrusted pages with your credentials loaded. Review network egress and what the container can see before you do anything serious with it.

Workspace file tools have their own boundary. Every path is resolved and rejected if it lands outside WORKSPACE_ROOT, and single files are capped at 128 KB by default.

OpenAI Dots runs on GPT-6 Astra and nothing else. Open Dots runs on whatever you point it at, within one constraint worth knowing before you install.

In Settings, Model provider, you enter an API base URL, an API key and the model IDs you want, and pick one of two wire protocols:

• Responses API: any OpenAI Responses-compatible service. Requests stream from /responses, conversation roles are preserved, and attached images are sent as data URLs.
• Prediction: the original adapter, which sends a request to {base_url}/{model_id} and uploads images separately.

The catch: the classic Chat Completions protocol is not implemented. A provider that only speaks /chat/completions will not work until that lands.

New assistants default to gpt-5-mini, and you can change the default in settings. API keys and custom headers are encrypted at rest with a Fernet key and never displayed again after saving. Because you bring the model, the cost is whatever your provider charges per token, with no subscription in the middle.

Each assistant is a persona with its own instructions, model and visual identity, so a cheap fast model can handle one assistant while a stronger one handles another.

OpenAI Dots advertises 4,000+ integrations. Open Dots ships a short list on purpose, and says so.

• Composio connectors handle app sign-in through explicit OAuth. The built-in actions are narrow: list GitHub issues (read-only, no approval) and create a GitHub issue (approval required). Arbitrary tool discovery and writes are not implemented.
• Web search works from chat with /search <query>. It runs through the You.com MCP server, and no key is required: without YDC_API_KEY it uses You.com's keyless free profile with a reduced read-only tool set. Adding a key raises the limits. Because you typed the command yourself, it does not pause for approval, but it still writes audit events like every other action.

Chat itself covers the expected ground: streaming responses, Markdown rendering, image attachments, locally saved conversations and voice dictation in browsers that support speech input.

You need Python 3.10+, Node.js and an API key for a compatible model provider. Start the API:

git clone https://github.com/Anil-matcha/open-dots.git
cd open-dots/server
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python run.py

Then the web client in a second terminal:

cd open-dots/client
npm install
npm run dev

Open http://127.0.0.1:3000 and sign in with the owner token. On first start the server generates it into .auth-token under ~/.open-dots, alongside the encryption key, and writes both with permission mode 600 so only your user can read them. If you ever restore that folder from a backup, a chmod calculator confirms you have put the same owner-only permissions back. Your model provider's key is separate, and goes into App Settings after you sign in.

Sessions use HttpOnly cookies with server-enforced expiry, and restarting the API signs everyone out. Even loopback requests must authenticate.

Before exposing it beyond localhost, the README asks for four things: set APP_AUTH_TOKEN on the server only, serve it over HTTPS with AUTH_COOKIE_SECURE=1, keep CORS_ORIGINS narrow, and never put a credential in a NEXT_PUBLIC_* variable, because those are compiled into the JavaScript every visitor downloads. If you set your own token, make it long and random; a random string generator does that in one click. And since the project asks contributors never to commit credentials or local transcripts, start your fork with a .gitignore that excludes .env files before the first commit.

The README lists its own limitations, which saves you finding them the hard way:

• One owner. No user accounts, roles or multi-user permissions.
• Local SQLite only. No multi-instance storage or built-in backups, and sessions are not shared across API workers.
• No Chat Completions and no generic provider plugin interface.
• No always-on agents. No scheduled routines, no durable memory service.
• No mobile or desktop client. No Slack, SMS or phone access, which is how many people reach OpenAI Dots.
• Narrow connectors, by design.
• The computer runtime is not a hardened boundary for hostile web content.

Read that list as the gap between Open Dots and the product it is named after. Background autonomy, long-term memory and messaging channels are exactly what makes OpenAI Dots a different kind of product. Open Dots today is closer to a well-governed agent workspace than an always-on assistant.

OpenAI's announcement produced several open-source namesakes within minutes. Three GitHub repositories with the name gained their current code on 29 September 2026, about twenty minutes apart:

If background, always-on behavior is what drew you to OpenAI Dots, CopilotKit's project is the closer match on paper. If what you want is a self-hosted workspace where you can inspect and gate every action, this one is built around exactly that. Also note that a pair of Shokz earbuds and a crypto token use the name too, so add "github" to your search.

The repository shows 5,483 stars and 649 forks at the time of writing, and that number needs context. The repository was created in May 2023, and its commit history shows the Open Dots code arriving on 29 September 2026 in a commit that swapped out a previous project. Most of those stars were earned by earlier projects in the same repository, not by Open Dots, which was one week old when this page was written.

The first week is still encouraging. An outside contributor landed five merged pull requests, including the approval-replay fix above, explicit owner login with revocable sessions, and fixes for silent record loss. More pull requests are open, including runtime hardening and an alternative search backend. The server ships with a test suite of 15 files covering the action gateway, authentication security, the Docker and remote computer providers, connectors and search.

Good fit if you want to study or build on a clean, readable implementation of approval-gated agent actions; you want a self-hosted assistant workspace where no conversation leaves your machine except to the model you chose; or you are outside the regions where OpenAI Dots launched.

Poor fit if you want an assistant that works unattended in the background, reaches you on Slack or by phone, or is ready for a team. It is a single-owner prototype, and the README says so on its first screen.