Andrew Ng opened a new repo, andrewyng/openworker, on July 20, 2026. In under two weeks it crossed 13,000 stars and landed at #4 on this week's GitHub weekly rank (8,225 stars of growth). That pace is unusual for a desktop-app project -- the trending boards are normally owned by agent frameworks, model weights, and CLI tools. A locally-installed desktop app climbing this fast signals it hit a real need: AI should not just chat with you, it should get your work done. OpenWorker's pitch is one line -- "AI that gets your everyday tasks done." An open-source AI coworker that lives on your desktop and hands you finished deliverables (a polished document, a Slack reply with the numbers, an updated calendar, a triaged inbox) instead of a to-do list.
What It Is
OpenWorker (github.com/andrewyng/openworker, site openworker.com) is Andrew Ng's open-source desktop AI coworker. Primary language Python, MIT license, currently in open beta (their words: fully usable, updates itself, actively polishing rough edges). As of August 6, 2026, the repo sits at 13,244 stars, 1,781 forks, 391 open issues, 97 watchers, created 2026-07-20, most recent push 2026-08-01.
It is not the same species as the ChatGPT or Claude desktop clients. Those are a chat window in a wrapper; OpenWorker is a local agent engine plus a desktop shell plus 25+ connectors. You give it an outcome -- "prepare a customer brief," "untangle my calendar," "check where the release stands across Jira and GitHub" -- and it breaks the task into steps, calls tools, reads and writes your local files, runs terminal commands, and operates your connected apps, then hands back a deliverable you can actually use. The two things that set it apart are "finished work" and "approval-gated actions" -- more on both below.
The engine is built on Andrew Ng's other project, aisuite -- a lightweight Python library that provides a unified chat-completions API across LLM providers plus an agents layer with tools, toolkits, and MCP support. OpenWorker was originally incubated inside the aisuite repo before moving to its own home. In other words, aisuite is the library for people who want to build their own agent harness; OpenWorker is the app for people who do not want to build one and just want to use one. The README draws that line explicitly.
What Problem It Solves
The README names the pain in one line: AI gives you chat, not finished work. You ask ChatGPT for a customer brief, it hands you a block of Markdown, and then you copy-paste it, go pull the numbers from Jira yourself, format it, and post it to Slack yourself. The AI did 20%; the other 80% -- getting the result into your actual workflow -- still falls on you. OpenWorker is after that 80%.
It targets three concrete scenarios:
- Cross-app coordination. Release status is scattered across Jira and GitHub, so you tab-switch; calendar conflicts mean manual digging; the inbox means clicking one by one. OpenWorker connects directly to GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, monday.com, Gmail, and Google Calendar, and reads and writes across them.
- From conversation to deliverable. What you want is a document you can send, a spreadsheet you can share -- not a chat transcript. OpenWorker drops the finished work as files (documents, spreadsheets, reports, web pages) you can open and share directly.
- Local privacy. Your data stays on your machine. The agent loop, conversation history, connector tokens, and model keys all live in the app's local secret store. The only piece that touches the cloud is a small service brokering OAuth handshakes for connectors, and you can skip signing in entirely and run connectors with manually-created API keys. For anyone handling customer data or internal documents, this is a hard requirement, not a nice-to-have.
Core Capabilities
OpenWorker's feature set breaks into five pieces, all from the README:
| Capability | What it does | Key detail |
|---|---|---|
| Real deliverables | Documents, spreadsheets, reports, web pages land as files | Openable, shareable -- not text in a chat box |
| Slack collaboration | @OpenWorker in a channel | A session opens on your desktop, work happens with your tools, the answer comes back as a thread reply |
| Tool integrations | 25+ connectors + terminal + local files | GitHub/Slack/Jira/Notion/Linear/HubSpot/Outlook/monday.com/Gmail/Google Calendar; any MCP-reachable tool plugs in too, with per-tool control |
| Scheduled runs | Morning brief, weekly report, standing channel watch | Unattended runs land in the app with full transcripts |
| Approval gating | Writes, sends, shell commands are all approval-gated | Unattended runs park their asks in an inbox instead of acting on their own |
Bring your own model is the other pillar. No vendor lock-in: paste your key, switch anytime. Supported out of the box: OpenAI, Anthropic, Google Gemini, Inkling (Thinking Machines), GLM (Z.ai), DeepSeek, Kimi (Moonshot), Qwen, MiniMax, Mistral, Grok (xAI); open-weight models via Together and Fireworks; fully local models via Ollama. The repo keeps a curated list of models verified for tool-calling work. Any model string not on the list works at your own risk, the README is explicit about this.
The README's architecture diagram simplifies to three layers:
┌────────────────────────────────────────────────┐
│ OpenWorker desktop app │ native shell + GUI
├────────────────────────────────────────────────┤
│ local agent server (Python) │ engine · tools · connectors (built on aisuite)
├───────────────┬────────────────┬───────────────┤
│ your files │ your tools │ your model │ everything runs with your keys,
│ & terminal │ 25+ connectors │ any provider │ on your machine
└───────────────┴────────────────┴───────────────┘The repo layout is equally clear; use this map if you want to read source:
| Directory | What's in it |
|---|---|
coworker/ | Python backend: agent engine, model providers, connectors, MCP client, memory, automations |
surfaces/gui/ | Desktop app: React UI + Tauri shell that supervises the server |
stt/ | Speech-to-text sidecar (Rust) for voice input |
packaging/ | Installer builds (macOS DMG, Windows), auto-update manifest, dev bootstrap |
docs/ | Design specs and decision logs |
tests/ | Backend test suite |
Three-Minute Setup
Two paths: install the built app, or run from source.
Fastest: download the installer
- macOS (Apple Silicon): download.openworker.com/mac -- macOS 12+, signed and notarized, auto-updates.
- Windows 10/11 (x64): download.openworker.com/windows -- builds are not yet code-signed, so SmartScreen will warn (signing is in progress).
Open the app, add a model key (or point it at Ollama), and ask for something real.
Run from source (for people who want to modify or inspect it). Prerequisites: Python 3.10+, Node 20+, and the Rust toolchain via rustup for the desktop shell. On Windows the README requires you to run the bootstrap from Git Bash or WSL.
git clone https://github.com/andrewyng/openworker
cd openworker
# 1. One-time bootstrap -- creates the Python venv at .venv
# (on Windows, run from Git Bash or WSL)
bash packaging/setup_dev_env.sh
# 2. Start the local agent server
.venv/bin/openworker-server --cwd ~/some/project --port 8765
# Windows: .venv\Scripts\openworker-server.exe
# 3. In a second terminal, start the UI
cd surfaces/gui
npm install
npm run dev # browser UI on the Vite dev portTo run the full desktop app instead of the browser UI, replace step 3 with npm run tauri dev (still from surfaces/gui/); the Tauri shell launches the window and supervises the server itself.
A few security details are worth remembering. The standalone server creates a per-launch token at <state-dir>/sidecar-8765.token on each start, and Vite reads that user-only file when it boots. For direct API calls, send that token's value in the X-OpenWorker-Token header. The desktop app is different: it uses an in-memory launch token and never writes it to disk. Use a placeholder like sk-xxx for model keys in any shared example -- never commit a real key into config.
Tests: backend .venv/bin/pytest; frontend npm test (unit) and npm run e2e (hermetic end-to-end) inside surfaces/gui. Desktop bundles: packaging/build_dmg.sh for macOS, packaging/build_windows.ps1 for Windows.
Who It's For + Pitfalls
Who it's for
- Engineers, PMs, and ops people who spend the day tab-switching between Slack, Jira, GitHub, Notion, and calendars: OpenWorker can string those tools together and run the flow for you.
- Anyone handling customer data or internal documents who cannot put them on a public cloud: the local-first plus Ollama-local-model path genuinely runs, it is not a slide.
- Anyone who wants a modifiable open-source reference for a desktop agent: OpenWorker is built on aisuite with a clean code structure (see the table above), a solid starting point.
Pitfalls
- It is beta, officially. The README opens with "Beta - actively polishing rough edges." Do not treat it as production-stable; issues are welcome.
- Windows is not signed. SmartScreen will block it, you click "Run anyway," and enterprise machines may kill it via group policy outright. Wait for signing if you need that.
- Not every model can do the work. The repo's "verified for tool-calling" list is a whitelist. Models not on it will run if you force the string, but tool-calling will likely break -- the README says at your own risk.
- OAuth needs the cloud. Despite being local-first, connector OAuth handshakes go through a small cloud broker. For a fully offline, never-touches-cloud privacy setup, you have to use manually-created API keys for connectors rather than OAuth.
- PRs may not land. The team says it is driving against an internal roadmap, and PRs that duplicate in-progress work or deviate from the vision may not be merged. Check the issue tracker before contributing.
- macOS builds are Apple Silicon only. No installer for Intel Macs; if you need it there, compile from source yourself.
How It Compares
OpenWorker has no clean 1:1 competitor. It sits between "desktop chat assistants" and "agent frameworks." Setting it next to both makes the positioning clearer:
| Dimension | OpenWorker | Desktop chat assistants (ChatGPT/Claude clients) | Agent frameworks (LangChain/aisuite etc.) |
|---|---|---|---|
| Form | Desktop app, works out of the box | Desktop/web app | Library/SDK, you write code |
| Deliverable | Finished files (docs/sheets/reports) | Chat text | Whatever flow you implement |
| Model | BYO key, any provider / Ollama local | Locked to vendor | Any |
| Data | Local-first, keys/tokens stored locally | Cloud | Depends on your implementation |
| Tools | 25+ connectors + terminal + local files + MCP | Plugins/tools exist but cloud-bound | You wire them up |
| Approval | Write/send/exec approval-gated | Generally none | You implement it |
| Barrier | Install and go | Install and go | Requires coding |
One line: if what you want is "installs and runs, swaps models freely, keeps data on my machine, and actually finishes my work," OpenWorker is a rare option right now. If all you want is a chat assistant, the ChatGPT or Claude client is less hassle. If what you want is to build your own agent harness, aisuite is the lower-level starting point -- OpenWorker itself is a reference implementation of aisuite.
Take
13,000 stars in two weeks is not because OpenWorker's technology is revolutionary; it is because it turned "AI should ship finished work, not chat" into an app you can install. aisuite solved "a unified API across models"; OpenWorker solves "let a normal person actually use an agent" -- one library, one app, and Ng's playbook is clear. Beta status, unsigned Windows builds, and model compatibility gated by a whitelist are real rough edges, but the combination of local-first plus BYO model plus approval gating plus 25+ connectors is scarce in the desktop-agent space today. If you are the kind of person who spends the day bouncing between a dozen SaaS tabs, it is worth a try; if you just want to chat, it is overkill.
References
- OpenWorker GitHub repo: https://github.com/andrewyng/openworker
- OpenWorker official site: https://openworker.com
- Underlying engine, aisuite repo: https://github.com/andrewyng/aisuite
- MCP protocol official site: https://modelcontextprotocol.io/
- Star/fork/open_issues/watchers/language/license/created and push times per GitHub API (verified 2026-08-06, 13,244 stars)
- Features, architecture, install commands, model list, and repo layout per the OpenWorker README (2026-08-06)