OpenWork

Open-source AI coding desktop app, honestly reviewed. No marketing fluff, just what you get when you run it locally.

TL;DR

• What it is: Open-source (MIT) desktop app that replicates the Claude Cowork experience — AI-driven task execution, browser automation, and agentic workflows — without an Anthropic subscription [README][5].
• Who it’s for: Non-technical founders and small teams who want AI automation of knowledge work (file ops, document generation, research pipelines) without paying $20/mo per seat for Claude.ai Pro, plus developers who want a GUI layer over OpenCode.
• Cost savings: Claude Cowork requires Claude.ai Pro (~$20/mo) or direct API spending that scales with usage. OpenWork is free to download; you bring your own API key and pay the model provider directly [README][5].
• Key strength: Multi-model support (75+ LLMs via Models.dev integration) and a permission-first execution model that shows you every step before it commits changes. Self-hostable as a headless server for always-on workflows [README][5].
• Key weakness: macOS-first app with a complicated install involving Rust toolchain and Gatekeeper overrides. Cloud hosting tier (OpenWork Den) has paused public signups. Very few independent reviews exist — this is a young project with 11,897 GitHub stars and still-rough edges [README][5].

---

What is OpenWork

OpenWork is a desktop application that puts a GUI on top of OpenCode, an open-source agentic coding engine. The pitch is direct: it describes itself as “the open source Claude Cowork alternative” and that’s precisely what it means. Where Claude Cowork requires a paid Anthropic subscription and keeps your workloads inside Anthropic’s cloud, OpenWork runs on your machine and routes to whatever model you choose — Claude, GPT-4o, Gemini, a local Llama instance, or 75+ others [README][homepage].

The product is built by different-ai, a YC-backed company. The GitHub repo (different-ai/openwork) sits at 11,897 stars with an MIT license, meaning you can self-host, fork, or embed it without any commercial agreement [merged profile].

The architecture has two components. OpenWork Desktop is a Tauri-built desktop app (Rust shell, web UI) that either spawns a local OpenCode server in host mode or connects to an existing remote OpenCode server in client mode. OpenWork Den is the company’s cloud-hosted tier for “always-on” workers accessible from Slack and Telegram — but Den signup is currently paused while the team onboards enterprise customers directly [homepage].

The underlying metaphor is “agentic workflows as reusable, productized processes.” You describe a task in plain language, OpenWork renders an execution plan as a visual timeline, you approve it, it runs. Unlike Cursor or Windsurf — which are IDE-centric and code-diff focused — OpenWork targets general knowledge work: file organization, document generation, data processing, content migration, browser automation [README][5].

---

Why people choose it

Given how young the project is, independent reviews are sparse. The primary sources that actually cover this OpenWork (as opposed to several other products sharing the name) point to a consistent set of motivations.

The cost argument is the loudest. Claude.ai Pro costs $20/month per user, and Claude Cowork is bundled into that subscription. For a small team of five, that’s $100/month just for the AI layer — before any actual API usage for production workloads. OpenWork’s BYOK model means you pay Anthropic (or whoever) directly at API rates, which for moderate usage is substantially cheaper. There’s no per-seat tax on the software itself [README][5].

Model flexibility matters for teams that don’t want to be locked to one provider. OpenWork connects to 75+ models through OpenCode’s Models.dev integration, letting you swap between Claude, OpenAI, Gemini, or a local Ollama instance per session. If Anthropic’s pricing changes or a cheaper model gets good enough, you switch without migrating your workflows [README][5].

The permission-first execution model is a real differentiator for non-technical users. The execution timeline renders each planned step before committing. The permission system surfaces privileged operations — file writes, external connections, shell commands — and asks: allow once, always allow, or deny. For a founder handing agentic access to files and documents, this matters more than raw capability [5].

The self-host angle. The ScriptByAI review [5] covers it explicitly: your files never leave your machine unless you explicitly authorize an external connection. For teams handling sensitive client data, contracts, or financial documents, local processing removes an entire class of compliance questions that cloud-only tools force you to answer.

---

Features

Core execution engine:

• Host mode: spawns a local OpenCode server within your selected project folder [README]
• Client mode: connects to an existing remote OpenCode server by URL [README]
• Sessions: create and manage separate project contexts [README][5]
• Live streaming via SSE — you watch each step execute in real time before changes are committed [README][5]
• Execution timeline: planned actions rendered as a visual sequence you approve before running [README][5]
• Permission prompts: allow once / always allow / deny for privileged operations [5]
• Templates: save successful workflows as reusable, locally-stored patterns you can share with teammates [README][5]

AI and model layer:

• 75+ AI models via Models.dev integration (Claude, GPT-4o, Gemini, local models) [5]
• Model preference saved per session [5]
• Browser operator for web automation tasks — the homepage demo shows it liking Twitter replies and exporting user CSVs from a plain-language prompt [homepage]
• WhatsApp, Slack, and Telegram connectors for remote task triggering [README]

Skills and extensibility:

• Skills manager: lists .opencode/skills folders, installs from OpenPackage repositories via opkg install, imports local skill folders [README]
• Orchestrator CLI (openwork-orchestrator): run OpenCode + OpenWork server without the desktop UI, installable via npm [README]
• Plugin architecture via OpenCode’s own plugin system — anything OpenCode supports works in OpenWork [README]

OpenWork Den (cloud tier):

• Hosted sandboxed workers accessible from desktop app, Slack, or Telegram [homepage]
• Same skills, agents, and MCP integrations available in cloud environment [homepage]
• Signup currently paused — enterprise onboarding by direct contact only [homepage]

---

Pricing: SaaS vs self-hosted math

OpenWork’s pricing model is simpler than most: the desktop app is free, and you pay your model provider directly.

OpenWork:

• Desktop app: free (MIT license) [README]
• OpenWork Den: contact sales; signup paused for general users [homepage]
• Enterprise: contact sales [homepage]

Claude.ai Pro (the competitor):

• $20/month per user, includes Claude Cowork access
• 5-person team: $100/month, all usage shared within plan limits

API cost comparison for typical knowledge work: A team running 50 agentic tasks per day at roughly 5,000 input tokens and 1,000 output tokens per task, using Claude Sonnet 3.5 (around $3/M input, $15/M output) would spend roughly $7.50/day or $225/month in API costs — more than the flat Pro plan. But lighter usage (10-15 tasks/day) lands well below $50/month, and using cheaper models (Gemini Flash, local Llama) can reduce that further. The break-even depends entirely on your actual workload.

The honest math: If you’re a single founder running casual AI tasks, Claude Pro at $20/month may be cheaper than BYOK overhead once you count API costs. If you’re running a team or heavy-volume workflows, the math shifts quickly. And if you want to route some workloads to a local Ollama instance, that’s essentially free [README][5].

Pricing data for OpenWork Den enterprise tier is not publicly available.

---

Deployment reality check

The install story is where OpenWork shows its rough edges.

What you need for the desktop app:

• macOS (primary supported platform; Linux possible with WebKitGTK 4.1, Windows not mentioned) [README]
• Node.js + pnpm (specific version: pnpm 10.27.0) [README]
• Bun 1.3.9+ [README]
• Rust toolchain via rustup [README]
• Tauri CLI via Cargo [README]
• OpenCode CLI installed and on PATH [README]
• Xcode Command Line Tools on macOS [README]

For the pre-built binary (the realistic path for non-developers):

• Download the .dmg from GitHub releases [5]
• Drag to Applications [5]
• macOS Gatekeeper will block it — notarization is pending [5]

To get past Gatekeeper, you control-click the app icon, select Open, and click Open again in the dialog. If macOS reports the app as “damaged,” you need to run a terminal command to clear the quarantine attribute [5]. This is a solved problem but it is a barrier for non-technical users who will find the Gatekeeper block alarming.

What can go wrong:

• The build-from-source path requires Rust toolchain familiarity that most non-technical users don’t have
• Cargo.lock v4 support requires a current stable Rust — older toolchains will fail [README]
• On Linux, WebKitGTK packages must be installed and discoverable by pkg-config [README]
• OpenWork Den signups are paused — if you need cloud execution without managing a server yourself, there is currently no self-service path [homepage]
• The project is under active development; the dev branch is the working branch, and there is no stability guarantee on feature completeness [README]

Realistic time to a working install: 15–30 minutes for a developer with Rust and Node already installed. For a non-technical user: budget a full hour including Gatekeeper troubleshooting, and have someone technical available if the “damaged app” error appears.

---

Pros and cons

Pros

• MIT license. Full freedom to self-host, fork, embed in your own product, or deploy for clients. No commercial restrictions [merged profile].
• Bring your own model. 75+ models. Not locked to Anthropic. If a cheaper or more capable model ships tomorrow, you switch without migrating workflows [README][5].
• Local-first by default. Files and execution stay on your machine unless you explicitly push to a remote server. Relevant for founders handling sensitive data [README][5].
• Permission-first execution. The timeline view and per-step permission prompts make agentic automation auditable rather than a black box. You review before the agent commits [README][5].
• Templates + Skills manager. Reusable workflow patterns with a package manager-style install path (opkg install) represent a genuine step toward productized automation, not just one-off prompts [README].
• Headless server mode. openwork-orchestrator lets you run the stack without the desktop UI — viable for server deployments, CI pipelines, or always-on use cases [README].
• YC-backed, active development. Real company with funding behind it; not a one-person side project [homepage].

Cons

• macOS-first with a rough install story. Gatekeeper blocks the binary, the source build requires Rust and Tauri, and Windows support isn’t mentioned. Non-technical users will need help [README][5].
• OpenWork Den is not available for self-service. The cloud tier — the path for non-technical founders who don’t want to manage servers — has paused public signup. Timing unknown [homepage].
• Very young project with few independent reviews. The third-party review landscape for this specific tool is nearly empty. The ScriptByAI coverage [5] is the most detailed public assessment available. You’re early-adopting.
• Depends on OpenCode as a runtime. If OpenCode has bugs or breaks, OpenWork inherits them. The dependency chain (Bun + Node + pnpm + Rust + Tauri + OpenCode) is long [README].
• No Windows support documented. If your team is on Windows, this isn’t your tool yet [README].
• Browser automation maturity unclear. The homepage demo is polished, but there are no third-party assessments of how reliably the browser operator handles real-world complexity vs. demo tasks [homepage].
• No public pricing for Den or enterprise. “Contact sales” for a tool targeting founders is a friction point when you’re trying to evaluate total cost of ownership [homepage].

---

Who should use this / who shouldn’t

Use OpenWork if:

• You’re paying for Claude.ai Pro primarily for Cowork-style task automation and want to escape the per-seat monthly cost.
• You need multi-model flexibility — routing some tasks to local Llama and others to Claude depending on sensitivity and cost.
• You’re technically comfortable enough to clear a Gatekeeper block and install Node + Bun (or have someone who is).
• You want a permission-first, auditable agentic tool where you review each step before it executes.
• You want to productize and share reusable AI workflows across a small team.

Skip it (stay on Claude.ai Pro / Cowork) if:

• You’re running light enough usage that $20/month covers everything and setup friction isn’t worth the savings.
• You need Windows support — not documented here.
• You’re a non-technical founder without someone technical to help with installation. The Gatekeeper issue alone will stop many users cold.
• You need the cloud execution tier now — Den signup is paused.

Skip it (use Cursor or Windsurf) if:

• Your primary use case is code editing and diff-based workflows, not general knowledge work automation. Cursor and Windsurf are purpose-built IDEs; OpenWork is not an IDE.

Skip it (use Aider or Continue.dev) if:

• You work in terminal and want a code-focused agent without a desktop app dependency.

---

Alternatives worth considering

• Claude Cowork (Anthropic) — the incumbent being replaced. Better polish, tighter Anthropic integration, active development, but $20/month per user and no BYOK [homepage].
• Cursor — IDE-first, best-in-class code editing, paid tiers from $20/mo. Not a general automation tool but dominant for engineering teams [general knowledge].
• Windsurf — similar to Cursor, code-first, $15/mo Pro tier [general knowledge].
• Cline — open-source VS Code extension, code-first, BYOK, strong community. Better fit if you want IDE integration rather than a standalone desktop app [general knowledge].
• OpenCode — the underlying CLI that powers OpenWork. If you’re comfortable in terminal and don’t need the GUI layer, OpenCode gives you the same execution engine without Tauri overhead [README].
• Aider — terminal-only, git-integrated, code-focused. Extremely lightweight and battle-tested for developers [general knowledge].
• Dify / Flowise — if your use case is workflow orchestration with visual pipelines rather than agentic desktop automation, these are more mature options [general knowledge].

For a non-technical founder specifically looking to escape the Claude.ai per-seat cost with a GUI tool, the realistic shortlist is OpenWork vs. Cline. OpenWork if you want a standalone desktop experience and general automation beyond code. Cline if you live in VS Code and your work is code-adjacent.

---

Bottom line

OpenWork is a credible, MIT-licensed answer to Claude Cowork for teams that want AI-driven automation without a recurring per-seat subscription. The local-first architecture, multi-model support, and permission-based execution model solve real problems. The trade-offs are real too: it’s macOS-first with an install that will intimidate non-technical users, the cloud tier is currently closed to self-service signups, and the independent review record is thin enough that you’re genuinely early. For a technical founder comfortable with a BYOK setup and willing to work through an afternoon of toolchain installation, the math is straightforward — you get the Cowork pattern without the $20/month/seat. If the install is the blocker, wait for the Gatekeeper issues to be resolved through notarization, or engage someone technical to deploy it once.

---

Sources

1. ScriptByAI — “Free Open-source Claude Cowork Alternative - OpenWork”. https://www.scriptbyai.com/free-claude-cowork-alternative-openwork/

Primary sources:

• GitHub repository and README: https://github.com/different-ai/openwork (11,897 stars, MIT license, YC-backed)
• Official website: https://openwork.software
• Documentation: https://openwork.software/docs
• Download page: https://openwork.software/download