Open CoDesign: a local-first, BYOK alternative to Claude Design
Open-source Claude Design alternative. One-click import your Claude Code / Codex API key. Prompt → prototype / slides / PDF. Multi-model (Claude, GPT, Gemini, Kimi, GLM, Ollama). BYOK, local-first, MIT.
At a glance
- What is it?
- Open CoDesign is an MIT-licensed Electron desktop app that turns prompts into prototypes, slide decks and PDFs using whichever model you already pay for. The installer is the easy part; the real question is whether a local-first design tool fits how your team already works.
- Who is it for?
- Adopt Open CoDesign if you already hold a Claude Code or Codex provider config, want prompts turned into HTML, PDF, PPTX, ZIP or Markdown artifacts on a laptop, and are comfortable being the person who debugs provider failures. Do not adopt it if you need a hosted collaborative canvas with a support contract, since neither the README nor the docs site documents one.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 43 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Open CoDesign actually solves, and for whom
The pitch is narrow and worth stating plainly. You have a prompt. You want a prototype, a slide deck, or a marketing asset out of it. You do not want a subscription to a cloud design tool, and you do not want to be told which model to use. Open CoDesign is the desktop application that sits between those two positions.
The README describes it as the open-source Claude Design alternative, aimed at people who want AI-native design speed without subscription lock-in or a single-provider requirement. The relevant paragraph names the audience directly: people who do not want their design workflow locked to one model or one cloud. That is a smaller group than the marketing table suggests, and it is the group the product is actually built for.
The practical trigger is key reuse. If you already have a Claude Code or Codex provider configuration on disk, the app offers a one-click import, and the README claims you are running in under 90 seconds. For someone who has been paying for a coding agent and now wants design output from the same account, that is the whole value proposition in one sentence.
If you do not have a key, or you are happy with a hosted canvas that a colleague can open in a browser, this tool is solving a problem you do not have.
How the desktop app and its provider layer fit together
The repository is a pnpm workspace driven by Turbo. The root package.json lists a build script that runs turbo run build, a dev script that runs turbo run dev, and a test script that runs turbo run test. There are two workspace packages named in the devDependencies: @open-codesign/core and @open-codesign/shared. The top-level entries include apps/, packages/, packaging/, scripts/, docs/, examples/ and website/. That layout is consistent with an Electron app in apps/, shared logic in packages/, and platform packaging manifests in packaging/.
The provider layer is the part that matters most, because it is where the multi-model claim lives. The README lists Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Ollama, and any OpenAI-compatible endpoint, plus direct ChatGPT Plus, Pro and Team subscription sign-in for Codex models. The release notes for v0.1.4 mention CLIProxyAPI one-click import and ChatGPT Plus and Codex subscription support. v0.1.3 records a Gemini models/ prefix fix and an OpenAI-compatible relay instructions required fix. Those entries tell you something useful: the provider layer is broad, and breadth is where the bug reports come from. A relay that truncates server-sent events gets its own hint in the notes, which means users hit it.
Data flow, as far as the README and docs show, stays on the machine. The README states the app is local-first and that data privacy means on-device app state. Version history is described as local sessions plus workspace files. No account server appears anywhere in the repository documentation, which is the strongest structural argument for the local-first label. It also means there is no shared workspace, no browser link to hand a reviewer, and no server-side rendering fallback.
Installing Open CoDesign and generating a first artifact
The README points to a Quickstart section and a docs site at opencoworkai.github.io/open-codesign/quickstart, and the release notes for v0.1.2 mention Homebrew, winget and Scoop packaging manifests. The repository does not reproduce the exact install commands for each platform, so treat the docs site as the source of truth rather than copying anything from a blog post.
If you want to build from source, the root package.json pins the toolchain. Node 22 or newer is required, and the package manager is pinned to pnpm 10.33.4. The workspace install is the standard pnpm flow:
corepack enable
pnpm install
pnpm devThe dev script runs turbo run dev, which starts the workspace packages in development mode. Expect an Electron window to open. There is also a smoke script for provider connectivity:
pnpm smokeThat script runs tsx scripts/smoke-models.ts, and the package.json exposes it under the name smoke. It is the fastest way to find out whether your key and endpoint actually respond before you blame the UI.
For a first real use, the README describes the flow as prompt on the left, live artifact on the right, with the agent planning, writing and self-checking. Start with a single screen rather than a full product, because the export path is what you are really evaluating. The README lists HTML, PDF, PPTX, ZIP and Markdown as editable export formats. Generate one artifact, export it, and open the exported file outside the app. If the HTML stands on its own in a browser, the tool did its job.
Where Open CoDesign breaks down
The first limitation is structural. A local Electron app has no shareable URL. If your review process is a link pasted into Slack, this tool does not participate in it. You export a file and send the file. The README does not document any hosted preview, and the comparison table lists desktop native as an advantage over web-only competitors, which is a fair framing but also the reason collaboration is absent.
The second limitation is provider variance. The changelog entries for v0.1.3, a Gemini models/ prefix fix and an OpenAI-compatible relay fix, are the shape of things to come. Any OpenAI-compatible endpoint is a wide promise, and relays differ in how they stream. v0.1.3 also adds a third-party relay SSE-truncation hint, which implies that some failures are diagnosed rather than fixed. If you route through a self-hosted gateway, budget time for that class of problem.
The third is maturity. The newest tagged release in the repository is v0.2.1 from 2026-05-23, and the last push was 2026-08-04. The README's What's new section leads with a branch, feat/decompose-to-ui-kit, referencing issue #225 and a BENCHMARKS.md. Features on a branch are not features in a release. Anyone evaluating the image-to-ui-kits workflow should check whether it has shipped in a tagged version before planning around it.
Finally, the documentation itself is uneven. The README is long and marketing-shaped, with a comparison table and badge wall, while install specifics live off-repo on the docs site. The README does not document rollback, and there is no described migration path between releases. For a tool that writes workspace files, that gap matters.
Open CoDesign vs Claude Design and the hosted generators
The comparison the README draws is against Claude Design, v0 by Vercel, and Lovable. The differences it claims are open source under MIT, desktop native via Electron, bring your own key across any provider, fully local operation, and editable export to HTML, PDF, PPTX, ZIP and Markdown.
The real difference is not the feature grid. It is where the model call happens and who pays for it. Claude Design is Anthropic-only and cloud-processed, per the table. v0 by Vercel is GPT-4o and web only. Lovable is multi-LLM but hosted. Open CoDesign moves the orchestration onto your machine and lets you point it at whatever endpoint you have credentials for, including a local Ollama instance. That is a genuine architectural difference, not a checkbox.
The cost model follows from it. The README states the app is free and you pay provider or subscription cost only. That is honest, and it also means there is no support contract. When a relay truncates a stream, you are the support desk.
A second practical difference is export. The table marks Claude Design, v0 and Lovable as limited on editable export, and Open CoDesign as exporting HTML, PDF, PPTX, ZIP and Markdown. If your downstream step is a coding agent consuming generated markup, that export path is the reason to pick this over a hosted canvas. If your downstream step is a designer editing in Figma, none of these tools replaces that step, and the README does not claim otherwise.
Maintenance cadence, licence and what MIT does not cover
The licence is MIT, stated in the README badge, the package.json license field, and the repository's LICENSE file. For a desktop application, MIT is permissive: you can fork it, ship a modified build, and embed it in a commercial workflow. There is also a NOTICE file at the repository root, which is worth reading if you redistribute, since it may carry attribution requirements for bundled components. That is a factual observation about the file's presence, not legal advice.
The maintenance picture is mixed and worth reading carefully. The repository is not archived. The last push was on 2026-08-04. The tagged releases are v0.2.1 on 2026-05-23, v0.2.0 on 2026-05-09, and v0.1.4 on 2026-04-23. Between the newest tag and the last push there is a stretch of commits that has not produced a release, and the What's new section describes work on a branch. That pattern is normal for a project doing feature work, but it means the release channel and the main branch are not the same thing.
Upgrade cost depends on how you installed it. If you use the Homebrew, winget or Scoop manifests mentioned in the v0.1.2 notes, upgrades follow that package manager. If you build from source, you are tracking main with pnpm, and the workspace pins Node 22 or newer and pnpm 10.33.4. The root package.json also carries pnpm overrides for @xmldom/xmldom, fast-xml-parser, vitepress>vite and esbuild, which suggests the maintainers are actively pinning transitive dependencies. That is a good sign for supply-chain hygiene and a mild warning that a careless dependency bump can break the build.
Editorial conclusion
Adopt Open CoDesign if you already hold a Claude Code or Codex provider config, want prompts turned into HTML, PDF, PPTX, ZIP or Markdown artifacts on a laptop, and are comfortable being the person who debugs provider failures. Do not adopt it if you need a hosted collaborative canvas with a support contract, since neither the README nor the docs site documents one. Before committing, verify three things: that your chosen provider works through the built-in diagnostics, that the export formats you actually need appear in your build, and that the release cadence visible on the releases page matches the pace your team depends on. The last push was on 2026-08-04, so the repository is moving, but the newest tagged release, v0.2.1, dates to 2026-05-23.
Frequently asked questions
How do I install Open CoDesign?
The README links to a Quickstart section and a docs site at opencoworkai.github.io/open-codesign/quickstart, and the v0.1.2 release notes mention Homebrew, winget and Scoop packaging manifests. To build from source you need Node 22 or newer and pnpm 10.33.4, then run pnpm install and pnpm dev from the repository root.
How do I use Open CoDesign?
The README describes the interface as a prompt on the left and a live artifact on the right, with the agent planning, writing and self-checking as it generates. You bring a provider key or sign in with a ChatGPT subscription, then export the result as HTML, PDF, PPTX, ZIP or Markdown.
Is Open CoDesign safe to use?
The README states the app is local-first and that data privacy means on-device app state, with version history kept in local sessions and workspace files. It is MIT-licensed and open source, so the code can be audited, but the repository does not include a security audit report. There is a SECURITY.md at the repository root for reporting issues.
What is the difference between Open CoDesign and Claude Design?
The README's comparison table lists Open CoDesign as MIT-licensed, desktop native, bring-your-own-key across any provider, and fully local, while Claude Design is closed source, web only, Anthropic-only and cloud-processed. Open CoDesign also exports HTML, PDF, PPTX, ZIP and Markdown, which the table marks as limited for Claude Design.
Which models does Open CoDesign support?
The README lists Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Ollama, and any OpenAI-compatible endpoint, plus direct ChatGPT Plus, Pro and Team subscription sign-in for Codex models. The v0.1.3 release notes record fixes for Gemini's models/ prefix and for OpenAI-compatible relays.
Community notes