OpenWorker: Andrew Ng's Local-First AI Coworker, Explained for Developers

OpenWorker shipped in late July 2026. It is MIT-licensed, runs on your own machine, and takes your API key instead of selling you inference.

The pitch is narrow and worth repeating exactly: it is an agent that hands you finished work, not a chat transcript. A drafted document on disk. A Slack reply with the real numbers in it. A calendar that has actually been rearranged.

There are a lot of desktop agents right now. This post is about what makes this one structurally different, what state it is actually in, and how to get it running.

OpenWorker is a desktop app: a Tauri shell around a React UI, sitting on top of a local Python agent server. You give it an outcome ("prepare a customer brief from these three files and the Jira tickets"). It decomposes that into steps, reaches into your files, terminal, and connected SaaS apps, and produces an artifact. Before anything consequential happens - sending a message, running a shell command, writing to your calendar - it stops and asks.

The engine is built on aisuite, Ng's provider-agnostic LLM library. That matters more than it sounds like: OpenWorker is explicitly positioned as a reference implementation of what you can build on aisuite, so the codebase doubles as a worked example if you are building your own harness.

You paste a key, or you point it at Ollama and use none at all. The curated list covers OpenAI, Anthropic, Google, plus OpenAI-compatible vendors like DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral, and Grok, plus open-weight models through Together and Fireworks. Roughly thirty models are marked as verified for tool-calling work; you can point it at any other model string and accept the risk yourself.

The practical consequence: your cost is your provider bill, and swapping models is a dropdown, not a migration.

This is the part I would actually read the source for. Most agent projects treat approvals as UI polish. OpenWorker classifies every tool call into one of four risk classes:

Five permission modes then decide what happens to each class. discuss

and plan

are read-only. interactive

is the default and asks before writes, commands, and external actions. auto

allows everything but stays path-scoped. custom

auto-approves a list of tools you name.

Two design choices stand out. First, unattended runs do not raise the autonomy ceiling - they change where the human is reached. Prompts that would have appeared inline get routed to an inbox and the session suspends until you answer. The agent does not quietly gain permissions because you walked away. Second, standing "always allow" rules are restricted to the external

class only. Shell commands ask every single time, on purpose.

The shipped operator persona instructs the model to treat content coming from tools, logs, web pages, files, and incoming messages as untrusted data, not as instructions. That is written into the persona the app ships with, rather than being left as an exercise for the user. For an agent that reads your Slack and your inbox, this is not optional, and it is good to see it stated rather than assumed.

Conversations, connector tokens, and model keys live in a local secret store. Model calls go straight from your machine to whichever provider you configured. The only cloud component is a small optional broker that handles OAuth handshakes for one-click connectors, and tokens are handed to your machine rather than stored server-side. You can skip sign-in entirely and wire up connectors with manually created credentials.

@OpenWorker

in a channel, a session opens on your desktop, the work runs with your local tools, and the answer comes back as a thread reply.Leave it in interactive

mode for the first few sessions. Watching what it asks permission for is the fastest way to build an accurate mental model of what it is doing.

Prerequisites: Python 3.10+, Node 20+, and the Rust toolchain via rustup if you want the desktop shell rather than the browser UI.

git clone https://github.com/andrewyng/openworker
cd openworker

bash packaging/setup_dev_env.sh

.venv/bin/openworker-server --cwd ~/some/project --port 8765

Then in a second terminal:

cd surfaces/gui
npm install
npm run dev        # browser UI on the Vite dev port

For the full desktop app instead of the browser UI, replace that last step with npm run tauri dev

from surfaces/gui/

. The Tauri shell launches the window and supervises the Python server itself, so you can skip step 2 in that case.

The server is FastAPI on uvicorn, bound to 127.0.0.1:8765

by default.

Running the tests:

.venv/bin/pytest              # backend
cd surfaces/gui
npm test                      # GUI unit tests
npm run e2e                   # hermetic end-to-end

Note the --cwd

flag on the server. That is the workspace root the agent's path-scoped file access is anchored to. Point it at a scratch directory for your first runs, not at your home folder.

If you are here to learn rather than to use, docs/

and the permission engine in coworker/

are the highest-value reads. The design logs explain choices rather than just documenting APIs.

Yes, if any of these describe you:

Hold off if:

The interesting claim here is not "agent that does tasks." Everyone is shipping that. The interesting claim is that the boring infrastructure - who is allowed to do what, where secrets live, what counts as an instruction versus data - has been designed as a typed system rather than bolted on. That is the part worth reading even if you never use the app.

It is early. Expect rough edges, expect the Windows signing situation to resolve, expect the connector list to shift. But if you have been waiting for a credible open, local, model-agnostic option in this category, this is the first one that looks like it was built by people who thought about the failure modes first.

Repo: github.com/andrewyng/openworker

Site: openworker.com