Open-source OpenAI Dots still needs a runtime

Three kinds of project, one shared word

OpenAI's dots are always-on agents, each with its own cloud computer and browser. They run on GPT-6 Astra and reach more than 4,000 apps through plugins. You talk to one in ChatGPT, Slack or Teams. The launch page describes no source download and no self-host path.

The projects that answer to "open-source Dots" each open a different piece of that idea. Read a few repos and the word starts to mean three things.

The interface

CopilotKit's OpenDots is the most direct copy of the idea. Its authors call it the open-source alternative to OpenAI Dots, and what they ship is a template you host yourself: clone the repo, run npm, bring an agent through AG-UI, point it at any OpenAI-compatible model. Each dot has a name, a role, instructions and tools. Computer access stays off until you grant it. The post is plain about the stage it is at, calling OpenDots an early, single-owner starting point.

What is open is the screen and the wiring. The model still comes from an endpoint somebody else serves.

Wrapped around an engine you already have

The repository behind the Anil-matcha/open-dots link now redirects to Open Duet. It describes named agents with instructions, memory, routines and an approval step before risky actions, plus an isolated Docker container per agent that the README marks experimental. It runs on an engine you have signed into already: Claude Code, Codex, an Agent Client Protocol CLI, or an OpenAI-compatible endpoint. The README states the Apache License 2.0.

OpenClaw takes the same bet to the chat apps. Its README calls it an open-source assistant that runs on your own computer and meets you in Discord, iMessage, Slack, Teams, Telegram and WhatsApp. One Gateway process serves a laptop or a team. Models and agent harnesses (Claude, Codex, local models) are plugins you swap. Tools run on the host for the main session unless you configure sandboxing. Unknown senders wait for a pairing approval. MIT, per its README.

Both projects are real open-source software, and in both the loop that decides a tool call comes from something they do not ship: a vendor CLI, a local model runner, or an endpoint you signed into.

The runtime

Kortix is the third kind, and the difference sits in one folder of the repo. harness.ts resolves the adapter a session boots. The folder beside it holds the adapters, and opencode is registered as the default. One adapter boots per session, and the project's manifest picks which with runtime: in kortix.yaml, so the choice is a line in a file you can read.

Nous Research's Hermes Agent is the other project here that ships its own loop. Its README calls it a self-improving agent: it writes skills from experience, improves them in use, and searches its own past conversations. It carries 40+ tools and runs on seven terminal backends, from local and Docker to Singularity, Modal, Daytona and Vercel Sandbox. Models are a setting, switched with hermes model between Nous Portal, OpenRouter, OpenAI or your own endpoint. Its governance is command approval, DM pairing and container isolation, set per agent.

Kortix and Hermes own the loop, and they are built for different places. Hermes is one person's assistant, installed on a VPS or a GPU box and reached from the chat apps the README lists. Kortix is a company's repo, where the agents, skills, memory and connectors live and the finished work arrives as a change request.

That runtime layer is the one the templates and the wrappers leave out. You can fork the runtime and read the code that runs a turn, and on Kortix the agents and their rules sit in the same repo as that choice. The model stays a setting, on any model provider with your own keys. Open source. Read it, fork it, audit it.

What to check before you call a stack open

Five checks sort most of these projects in a few minutes. Run them in order.

1. 1.Where the loop runs. If the agent loop is a CLI from the model vendor, your repo holds the prompts and the vendor holds the code that picks the next step.
2. 2.Which models it accepts. "Any OpenAI-compatible model" is a real answer. "Our models" describes a different product.
3. 3.Whose machine runs the tools. A laptop, a server you own, or the vendor's cloud. Each one changes what you can audit and what you can take with you.
4. 4.Where the rules live. A line in a file you can diff beats a toggle in a dashboard you cannot.
5. 5.How finished work reaches you. A diff you approve reads differently from a message in a chat window.

The first four decide whether you can leave. The fifth decides whether you can see what happened. OpenAI Dots vs Kortix applies the same tests to OpenAI's own product.