Kuse Cowork: a local-first desktop cowork agent you drive with your own model key

What Kuse Cowork is trying to be, and what it replaces

Kuse Cowork is positioned as an open-source alternative to the Claude Cowork desktop app, built by Kuse, which describes itself as an AI document generator and presentation maker. The project's own framing is a lightweight desktop cowork agent for people who want local-first execution, full model freedom, and privacy control.

The interesting part is not the model. It is who chooses the model. The settings screen lets you pick Anthropic Claude, OpenAI GPT, or a local model endpoint such as Ollama or LM Studio, and the documentation also allows any OpenAI-compatible endpoint under a custom API configuration. Model selection covers temperature, max tokens and system prompts. Keys are entered in the settings and stored locally, and the project states that nothing is shared and that API calls go directly to the provider you chose.

That last point is what separates it from a hosted agent service. There is no telemetry, according to the security section, and all data stays on your machine. The privacy claim is structural rather than a promise about policy: if the app has your key and talks to the provider endpoint directly, there is no Kuse server in the middle to log anything.

It is worth being clear about the category. This is a desktop application for agentic work over local files, not a library you embed in a product. The example tasks are personal chores: organizing folders, reading receipts into an expense report, summarising meeting notes into a TODO list.

Container isolation is the security model, not a bonus

The project states that all external command execution runs inside Docker containers, and lists the properties it claims for that approach: complete isolation from the host system, secure networking with controlled access, resource limits to prevent abuse, and clean environments for each execution.

This matters because the agent's whole job is running commands on your files. Any tool that edits a folder on your behalf has the same reach as your terminal, and the container is the boundary that keeps a mistaken or confused agent from doing damage outside the task it was given. The isolation settings are even exposed in the settings panel under security, alongside the skills and MCP server configuration.

The cost is a hard dependency. The prerequisites list Docker Desktop as required for container isolation features, and a note underneath says that Docker Desktop must be installed and running for those features. Without Docker the application still works, but commands run without isolation. That fallback is the single most important operational fact in the project, and it is easy to skim past.

The security note at the end of the README is unusually blunt for a project with a download button: it is still an early project and you should be very careful when connecting it with your local folders. An early project that runs commands as you, with an optional isolation layer that quietly disappears when Docker is not there, deserves a separate sandboxed folder for the first runs rather than your home directory.

A SolidJS frontend over a Rust agent, packaged with Tauri

The repository layout makes the architecture legible. The src directory holds the frontend, described as SolidJS with TypeScript, split into components for the interface, lib for utilities such as API clients and MCP handling, and stores for state management. The src-tauri directory holds the backend, with Rust source under src and subdirectories for agent, tools, skills, mcp and a database.rs for local data storage, plus Cargo.toml and tauri.conf.json.

The project describes the agent as written in Rust with zero external dependencies, and the feature list gives an app size of roughly 10MB using Tauri. Native builds are called out for macOS on ARM and Intel, Windows, and Linux. The dependency list in the package manifest backs up the frontend story: solid-js, the Tauri API packages for dialog, fs, shell and store, and the Tauri router. The Tauri plugin set is itself informative, since the fs, shell and dialog plugins are what let the desktop app browse folders, read and write files, and spawn processes at the request of the agent.

The MCP directory inside the Rust source is the integration point for external tools. The project lists full Model Context Protocol support for tool integration, and MCP servers are configured from the settings panel as external tool providers. A skills system sits next to it for custom capabilities, with default skills for docx, pdf, pptx and xlsx.

The build and release pipeline lives in .github/workflows for cross-platform builds, and the repository ships a docs directory.

Building it from source with Node, Rust and Tauri

The development path is documented and short. The prerequisites are Node.js 18 or later, Rust for Tauri, Docker Desktop for container isolation, and the Tauri platform prerequisites. The setup sequence is:

# Clone the repo
git clone https://github.com/kuse-ai/kuse-cowork.git
cd kuse-cowork

# Install dependencies
npm install

# Run in development mode
npm run tauri dev

# Build for production
npm run tauri build

The npm scripts in the package manifest back these up, with dev mapped to vite, build to vite build, and the tauri scripts exposing tauri dev and tauri build. A caveat sits right above the setup block: the project says it will update to a clean release build soon, so the quick start is oriented at developers rather than at people who want a downloaded installer.

Because there is no packaged installer in the documentation, a first real use means running the app in development mode, which is also the mode where you are most likely to hit the isolation requirement. Have Docker Desktop running before you start a task, otherwise the agent runs against your host filesystem with no container between it and your files.

Once it is open, the first use is a settings-driven flow. Open Settings from the gear icon, choose a provider, paste the key, pick a model, then create a new task, click Select Project Path to choose the workspace folder, and describe what you want. The documentation suggests starting with something narrow such as organizing folders or summarising notes, which is also the sensible way to learn how it behaves.

The release history says early, and the version numbers disagree

The repository is not archived and the last push was on 2026-10-18, so the code is moving. The release trail is thinner than that suggests.

Only one GitHub release is listed, v0.0.1 published on 2026-01-21. The package manifest carries a different number again, 0.1.0, and the README news section refers to a v0.0.2 dated 2026-01-26 that fixed an issue where the start task button actively needed the user to set a cloud-based API key. Two later entries, dated 2026-01-29 and 2026-01-26, describe experimental work on docx and Excel operations with an integrated UI and working trace tracking.

So the version identifiers disagree in three places, and the dated notes all sit in a two week window in January 2026, while the last push is months later. The documentation excerpt available here does not account for that gap. If you are evaluating the project, that is a reason to read the commit history rather than the release page, because the release tags will not tell you what the current main branch contains.

The same caution applies to the security note. The features list reads like a finished product, including no telemetry, local storage and open source transparency, but the README itself describes the project as still early. The maturity signal to trust is the version number, not the feature list.

MIT licence, and how this compares with a hosted agent

Kuse Cowork is MIT licensed, both in the LICENSE file and in the package manifest. There is no copyleft obligation and no restriction on commercial use or redistribution of the code.

The alternative to this project is not another open-source agent, it is the hosted desktop app it names. The difference in approach runs through three axes.

First, where the code runs. A hosted cowork service runs the agent on someone else's machines, which means your files and your prompts travel to infrastructure you do not control, and the isolation boundary is drawn by that provider. Kuse Cowork runs on your machine, so the files never leave, and the boundary is the container you control.

Second, who owns the model relationship. The hosted app brings its own account and billing. Here the key is yours, the endpoint is yours, and you can point it at Ollama or LM Studio on your own hardware, which removes the provider from the loop entirely.

Third, what you can change. The agent, the skills system and the MCP integration are all in a public MIT repository, so extending the tool with your own skills or wiring it to your own MCP servers is ordinary source work. The trade-off is the one the project states plainly: you own the security posture of a program that executes commands against your files, on your hardware, on your schedule.

Editorial conclusion

Adopt Kuse Cowork if you want a desktop agent that runs on your machine, talks to a model endpoint you choose, including a local one, and keeps your keys and data local. Do not adopt it as a production dependency yet: the security note calls it an early project, the release history is a single tagged version, and the Docker isolation depends on Docker Desktop being installed and running. Verify first that the agent runs inside a container on your platform, that your provider endpoint is reachable from that container, and that the skills you need are present, since the default set covers document formats only.

Frequently asked questions

Official sources

1. kuse-ai/kuse_cowork on GitHub
2. License: MIT
3. Project website
4. README
5. Releases