# OpenWork: an MIT desktop app bolted to a subscription control plane

> OpenWork is a desktop workspace for macOS, Windows, and Linux where AI agents act on your own files, built on OpenCode and model agnostic. Its licensing is split by directory in the GitLab pattern, so the application is free forever while the organization control plane, OpenWork Den, becomes a paid product once a team passes five users.

**different-ai/openwork** — GitHub describes it as The open-source alternative to Claude Cowork (powered by opencode). The repository metadata lists TypeScript as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/different-ai/openwork
- Website: https://openworklabs.com
- Stars: 23,820 · Forks: 2,398
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/different-ai-openwork

## The MIT part is the desktop app, the subscription part is the control plane

OpenWork splits its license by directory, in the same shape GitLab uses. Everything outside ee/ is MIT, which covers the desktop app and the core platform and is free for any use, and no OpenWork account is required to run it locally. Everything under ee/, which is OpenWork Den, the organization control plane, sits under the OpenWork EE License as source available code, published precisely so an operator can audit exactly what they deploy. The conditions are spelled out. Production use of that directory requires a subscription, except that it is free for organizations with up to five users, free to evaluate for thirty days at any size, and always free for development and testing. Each ee/ release also converts to MIT two years after publication, and versions released before this license was adopted stay under their original license, FSL-1.1-MIT. For a reader the consequence is a threshold rather than a surprise. The desktop application costs nothing indefinitely, and the moment a team grows past five users and starts leaning on Den for policy and shared connections, the terms change.

## The agent integration is four tools and a browser sign-in

The OpenWork MCP is the part that matters if you already run an agent, and its surface is deliberately narrow. Four tools are exposed. search_capabilities finds what you can use, execute_capability runs it, list_skills lists your skills, and get_skill reads a single SKILL.md directly. Behind those four calls, the MCP carries your assigned skills, plugins, MCP connections, and Google Workspace and Microsoft 365 capabilities into whichever client hosts it. The consequence for a reviewer is that the trust decision does not live in a configuration file. After the MCP entry is added, the client opens a browser so you can sign in and choose your OpenWork organization, and the capability set you are given afterwards is whatever that organization grants. Since the same four calls also reach Workspace and 365, an agent cleared to search capabilities can discover and execute document work that has nothing to do with code, which is the part worth reviewing before you grant access.

## One remote endpoint, three client configs, identical behavior

All three supported clients register the same remote endpoint, https://api.openworklabs.com/mcp/agent. Codex takes it as a named MCP server with a URL flag, Claude Code takes the same name over http transport, and OpenCode takes a JSON entry in opencode.json that declares the server remote and enabled with an empty oauth object. Any other MCP client can be pointed at the bare URL.

```bash
codex mcp add openwork --url https://api.openworklabs.com/mcp/agent
```

```bash
claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent
```

```json
{
  "mcp": {
    "openwork": {
      "type": "remote",
      "enabled": true,
      "url": "https://api.openworklabs.com/mcp/agent",
      "oauth": {}
    }
  }
}
```

Because the endpoint is identical in all three cases, the difference between clients is configuration syntax rather than capability. A team that standardizes on one client still ends up with the same four tools and the same organization scoped access, so choosing a client does not narrow what an agent can reach.

## The desktop app is optional, Den is where policy gets enforced

The desktop application exists for when you want a dedicated workspace, but the project is explicit that it is not required, since OpenWork can be used from an agent you already have. What genuinely needs the control plane is a larger organization, and there Den stops being a convenience. It provisions inference at scale and decides which members and which teams may use each model provider. It invites teammates, creates teams, and manages access from one place. It sets desktop policies, restricts local model access, and controls which application versions the organization is allowed to run. It publishes skills and plugins through marketplaces and assigns them to the organization, to a team, or to named individuals, and it imports Agent Plugins or Anthropic compatible plugins so their skills and remote MCPs appear through the same MCP endpoint. The consequence for an individual contributor is that these constraints live outside the repository. A policy can forbid the local model you depend on, and a version policy can hold you on a build your code does not target, with no local file to read and no way to override it from the app.

## Model choice is yours, unless an administrator takes it away

Model selection is the project's answer to vendor lock-in. OpenWork works with any model, described as fifty or more providers, and you can bring your own API key, sign in with ChatGPT, or run local models through Ollama or any OpenAI compatible server. Your files stay local and the cloud is optional, which is the concrete difference from a hosted workspace product, and nothing about local use requires an OpenWork account. The constraint arrives through Den rather than through the application. Desktop policies can restrict local model access, and Den is what provisions inference and controls which members and teams may use which provider. For an organization that has standardized on an approved provider, the practical effect is that the local model path described in the documentation is a capability that can be withheld as policy. A team building a workflow around Ollama should therefore confirm what Den permits before writing any of it down as a plan, because nothing in the app itself will object.

## Contributors are pinned to Node 24, pnpm 11, and a sign-off

Getting a development build from a fresh clone takes three pinned prerequisites. Node 24 is pinned in .nvmrc, which nvm use reads for you. pnpm 11 is pinned through the packageManager field in package.json, and corepack enable activates that exact version; the instruction is explicit that npm and yarn must never be used. Git commits need a Signed-off-by trailer added with git commit -s, because the project requires DCO sign-off. The clone itself is unremarkable.

```bash
git clone https://github.com/different-ai/openwork.git
cd openwork
corepack enable
pnpm install
pnpm dev   # launches the Electron desktop app with hot reload
```

The consequence of a pinned package manager is that lockfile resolution is not negotiable. An npm or yarn install produces a different dependency tree than the pnpm lockfile the repository ships, and across a workspace this size that divergence surfaces as a failing build rather than as an obvious error. The package manager choice is therefore a build requirement rather than a preference, and the sign-off trailer is a gate on every commit rather than a courtesy.

## Tests are spec files, and local Den wants Docker and an external secret store

Executable coverage is organized as specs rather than as tests scattered through the application. Every spec lives under evals/specs with a .test.ts suffix, app driving journeys use .e2e.test.ts, and the specs are built on a shared harness called @openwork/testkit. Two entry points carry the weight.

```bash
pnpm --dir evals install --frozen-lockfile   # once
pnpm evals:pr specs/<name>.test.ts           # app-less PR-lane spec
pnpm evals:e2
```

Running Den on your own machine is heavier than that. The dev:den path goes through a local script, and the MySQL variant asks Docker Compose to bring up both mysql and redis from a compose file under packaging/docker, waiting for them to report healthy. The repository root carries an Infisical configuration file next to .env.dev, so the local control plane depends on secrets resolved from outside the checkout rather than from one committed environment file. Declarative environments are a separate idea again, defined in worlds/ and consumed through pnpm world. The consequence for a contributor is that a green spec and a working local control plane are different targets, and the second one needs a container runtime and resolved credentials before it will start at all.

## Product code, governance files, and operational artifacts share one root

The repository root mixes product with process. Alongside apps/, packages/, ee/, evals/, docs/, worlds/, integrations/, examples/, infra/, legal/, packaging/, patches/, scripts/, changelog/, scenarios/ and reports/, there are governance documents such as CODE_OF_CONDUCT.md, SECURITY.md, SUPPORT.md, REUSE.toml and a LICENSES/ directory, operational files such as AGENTS.md, DESIGN.md and HANDOFF.md, and two separate statistics documents, STATS.md and STATS_V2.md, with nothing at the root indicating which one is current. Repository specific agent skills live under .opencode/skills/, covering testing, release and Daytona, with a skills-lock.json beside them. The default branch is dev rather than master, so a plain clone lands on the development line instead of a stable one. For a reader deciding whether to depend on this project, the consequence is that no single file answers what state it is in, and both its licensing shape and its operational posture have to be assembled by reading several places and comparing them.

## Conclusion

Adopt the desktop app if you want a model agnostic agent workspace without an account or a cloud dependency. Treat Den as a procurement decision rather than a free extra, confirm which model providers your administrator permits before designing around Ollama, and read ee/LICENSE before running it in production.

## FAQ

### What does Openworks do?

It is a desktop app for macOS, Windows, and Linux where AI agents do real work on your own files, built on OpenCode and usable with fifty or more providers, your own API keys, or local models through Ollama.

### Is OpenWork free to use?

The desktop app and core platform outside ee/ are MIT licensed and need no OpenWork account for local use. OpenWork Den under ee/ is source available and needs a subscription for production, though it is free for organizations up to five users, free to evaluate for thirty days, and free for development and testing.

### how to install openwork

Paste a prompt into any agent that can run commands on your computer, and it installs OpenWork, creates your first workspace, and opens it ready to run. Contributors instead clone the repository, enable corepack, install with pnpm, and run pnpm dev.

### Is OpenWork a legit company?

The project makes no claim about that. What it does set out is licensing: MIT outside ee/, a source available EE license inside it, a subscription required for production use of that directory, and automatic conversion to MIT two years after each ee/ release.

## Sources

- [Official documentation](https://openworklabs.com)
- [Official README](https://github.com/different-ai/openwork#readme)
- [Project repository](https://github.com/different-ai/openwork)
- [Release notes](https://github.com/different-ai/openwork/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/different-ai-openwork