Open CoDesign: a local-first Claude Design alternative with bring-your-own-key models

The problem Open CoDesign targets: prompt-to-artifact without a subscription

AI design tools generally route your prompt through a hosted workspace and charge a subscription for the privilege. Open CoDesign takes the opposite position. It is a desktop application, distributed under MIT, that generates a prototype, a slide deck or a marketing asset from a prompt and writes the result to your machine. The README frames it as the open-source Claude Design alternative, and the comparison table sets it against Claude Design, v0 by Vercel and Lovable on four axes: open source, desktop native, bring your own key, and local or offline operation.

The audience is narrower than that framing suggests. This is for someone who already has a Claude Code or Codex provider configuration, or an API key for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Ollama or any OpenAI-compatible endpoint, and who wants to reuse it here. The README states that one-click import of an existing Claude Code or Codex provider config, or a ChatGPT sign-in, gets you running in under 90 seconds. If you have no key and no subscription, the app has nothing to run on.

How the agent pipeline works: sessions, workspace files and visible tool calls

The mechanism described in the release notes for v0.2.0 is an agentic loop rather than a single completion. Sessions are backed by a workspace, and the agent runs permissioned local tools against that workspace. Generation is interruptible, and the interface shows live agent activity and the tool calls as they happen, which is the project's answer to the black-box feel of a one-shot generator.

The repository layout supports this reading. It is a pnpm and Turborepo monorepo with apps, packages, packaging and scripts directories, plus a workspace file at pnpm-workspace.yaml and a task graph at turbo.json. The root package.json lists @open-codesign/core and @open-codesign/shared as workspace dependencies, so the agent logic is separated from the desktop shell. Design systems are expressed as a DESIGN.md file that the agent reads, which is the project's way of keeping visual rules in version control rather than in a settings panel.

Output is exported as HTML, PDF, PPTX, ZIP or Markdown according to the README. Version history is local: sessions plus workspace files, not a server-side record. The current work on the feat/decompose-to-ui-kit branch extends this to image input, producing a componentized ui_kits/<slug>/ bundle for handoff to a coding agent, with a boolean-per-dimension visual parity judge covering twelve standard checks and a verify-and-iterate loop. That branch is described in the README and in BENCHMARKS.md; it is not in the v0.2.1 release.

Installing Open CoDesign and generating a first artifact

The README points to a Quickstart section and to the docs site at opencoworkai.github.io/open-codesign/quickstart. Version 0.1.2 added a release pipeline plus Homebrew, winget and Scoop packaging manifests, so the packaged installers are the intended route for most users. The related searches include people looking for a download, an x64 setup exe and a Mac build, which matches that distribution model.

If you want to build from source instead, the root package.json declares node >=22 and pins [email protected] as the package manager. The repository has an .nvmrc file, so the Node version is pinned for you.

git clone https://github.com/OpenCoworkAI/open-codesign.git
cd open-codesign
pnpm install
pnpm dev

pnpm dev runs turbo run dev across the workspace, which starts the Electron app in development mode. Expect the desktop window to open against the local source tree rather than a packaged binary.

Before shipping a build, the repository provides a smoke test that exercises the model providers. It is a root script, so it runs from the repository root:

pnpm smoke

That script is tsx scripts/smoke-models.ts. It is the fastest way to find out whether a given provider configuration actually responds before you blame the generation pipeline.

The remaining scripts are the usual monorepo set: pnpm build, pnpm test, pnpm typecheck, and pnpm lint, which runs biome check. Formatting is biome format --write. If you are only reading the docs site, pnpm docs:dev serves the VitePress site through the open-codesign-website filter.

Where Open CoDesign stops being the right tool

The local-first design is a constraint, not a feature you can switch off. There is no hosted workspace in the description, so concurrent editing by several people is not part of the model. Version history lives in local sessions and workspace files, which means your history is only as durable as your disk and your own backups. The README does not document rollback or a recovery path for a corrupted session.

Cost is another boundary. The application is free under MIT, but the README is explicit that the price is the provider or subscription cost. You are the one paying per token, and a long agentic loop with a visual parity judge is not a cheap operation. A user with no existing key and no subscription has to open a provider account before the app does anything useful.

Provider support is broad but not uniform. The changelog entries for v0.1.3 record a Gemini models/ prefix fix, a fix for an OpenAI-compatible relay returning an "instructions required" error, and a hint for SSE truncation on third-party relays. Those are the kinds of defects that appear when you route through many endpoints, and they suggest that non-Anthropic paths have had less mileage. The README does not publish a compatibility matrix per provider.

Finally, the version numbers do not line up. The latest release listed is v0.2.1 from 2026-05-23, while the root package.json still reads 0.2.0. The last push to the repository was on 2026-08-04. Check the releases page rather than the manifest when you need to know what you are installing.

Open CoDesign against Claude Design, v0 and Lovable

The difference with Claude Design is provider scope. Claude Design runs Claude models in a browser, and the README's comparison table marks it closed source, web only, Anthropic only, cloud processed. Open CoDesign runs as an Electron desktop app and accepts any of the listed providers, with the app state kept on-device. If your reason for looking elsewhere is a single-provider lock-in or a cloud-only workflow, that is the gap this project fills.

Against v0 by Vercel and Lovable the split is the same shape but the emphasis differs. Both are web products in the table, marked closed and cloud, with v0 tied to Vercel and Lovable described as multi-LLM with limited bring-your-own-key. None of the three offers the local session and workspace-file history that Open CoDesign lists. The cost of that difference is operational: you install and update a desktop application, you manage your own keys, and you debug your own provider configuration when a relay misbehaves.

A fair reading is that Open CoDesign competes on control, not on polish. A hosted tool can iterate on its rendering pipeline without asking you to update anything. Here, the release notes are the changelog and the packaging manifests are how fixes reach you.

Licence, maintenance and the cost of upgrading

The licence is MIT, stated in the README badge, the repository description and the root package.json license field. There is also a NOTICE file at the repository root, which is worth reading alongside LICENSE if you redistribute the app or bundle it into something else. Nothing here is legal advice; the practical point is that MIT permits commercial use and modification, and the provider terms you accepted separately still govern your API usage.

Maintenance signals are mixed but traceable. The last push was on 2026-08-04, and the most recent release listed is v0.2.1 from 2026-05-23, following v0.2.0 on 2026-05-09 and v0.1.4 on 2026-04-23. The release cadence in that window was roughly two to three weeks. The README's What's new section leads with a feature branch rather than a release, which tells you where effort is going: image decomposition into UI kits and the visual parity judge. That work is not yet in a tagged release.

Upgrade cost depends on how you installed it. The Homebrew, winget and Scoop manifests added in v0.1.2 mean package-manager users get updates through the usual channel. Source builds mean pulling main and rerunning pnpm install, since the workspace pins [email protected] and Node >=22. The changesets setup, with pnpm changeset and pnpm version-packages, indicates the maintainers intend version bumps to be generated rather than hand-edited, which is why the package.json lag is likely a release-process artifact rather than abandonment.

Editorial conclusion

Adopt Open CoDesign if you already hold a Claude Code or Codex provider config and want prompt-to-artifact generation to stay on your laptop, with HTML, PDF, PPTX, ZIP and Markdown exports you can edit afterwards. Do not adopt it if you need a hosted workspace that several people edit at once, or if you want the vendor to supply the model and the bill. Before committing, check the release notes for v0.2.1 rather than the package.json version, confirm your provider is on the supported list, and read BENCHMARKS.md for the decompose-to-UI-kit branch, which is where the project's current measurement work sits.

Frequently asked questions

Official sources

1. License: MIT
2. OpenCoworkAI/open-codesign on GitHub
3. Project website
4. README
5. Releases