Scope: I verified the third-party bridge installation and inspected the official setup path in the project’s documentation. I did not complete a Codex-to-canvas generation, and I did not run the desktop application.
If you saw a post saying an open-source design tool is now “free, just connect an API key” inside Codex, two parts of that sentence need unpacking before you install anything.
First, search results mix several similarly named things, and only one of them is the product. Second, what “free” means depends on which execution path you end up on, and the documentation and the marketing sentence are describing different paths.
Here is what I could verify, and what I could not.
This piece covers the Open Design Codex setup specifically: which repository you install, which execution path you land on, and what each one implies for cost.
What you are actually installing
Search results may mix the official repository with similarly named sites and with a separate third-party MCP bridge. This article evaluates two things and nothing else, because an Open Design Codex install starts with picking the right one.
| Identifier | |
|---|---|
| The product | github.com/nexu-io/open-design — Apache-2.0, local-first desktop app, BYOK |
| What I tested | open-design-mcp on npm — a third-party bridge, repository nano-step/open-design-mcp |
Neither is an OpenAI-published Codex plugin. Open Design is a third-party open-source tool that supports Codex as one of its runtimes.
Built-in path versus third-party bridge
This distinction is easy to get wrong, and it changes what you install.
The official README states that Open Design ships as skills, a CLI, and an MCP server, and that once Open Design is installed, a single od mcp install <agent> wires that MCP server into the agent’s config. For Codex the documented command is od mcp install codex. I read this in the official README; I did not run it successfully myself.
The separate npm package is something else: a bridge that connects an editor to an Open Design daemon you are already running.
| Built-in path | Third-party bridge | |
|---|---|---|
| Repository | nexu-io/open-design | nano-step/open-design-mcp |
| Role | MCP capability inside the product | Connects to a running daemon |
| This test | Documentation and code review only | Install, initialize, list tools |
| Codex end-to-end run | Not verified | Not verified |
| GUI output | Not verified | Not applicable |
What “free” actually means in the Open Design Codex setup
The license is Apache-2.0, so the Open Design Codex software itself is free. The cost question is about inference, and it depends on the execution path. The official Quickstart documents two modes.
| Mode | When it applies | Who pays |
|---|---|---|
| Local CLI | Default when the daemon detects an agent CLI on your PATH | Uses the authentication and usage terms of the detected agent CLI. Not verified in this test |
| API mode | Fallback when no CLI is found | Provider API charges may apply, depending on the selected provider, model, and usage, under your own BYOK account |
To state this precisely: according to Open Design’s documentation, local CLI mode can invoke an already authenticated Codex CLI without requiring a separate provider API key inside Open Design. I did not verify the end-to-end Codex flow or its billing behavior. Plan limits, credits, and authentication remain subject to your Codex account.
This is the same habit I apply to model output generally: assume the marketing sentence and the documentation are describing different things until you check. The prompts I actually use are built around that assumption.
So the “just connect an API key” line describes the BYOK fallback, not the local path. That is a meaningful difference, but it is a difference in how requests are routed, and I cannot tell you what it costs you in practice.
Practical step: confirm the selected execution mode before generating anything. If Open Design is using BYOK or API mode, provider charges may apply. The daemon scans your PATH plus common toolchain directories; if you installed a CLI with npm install -g or Homebrew and Open Design still reports it as not installed, the documented fix is to ensure the executable’s directory is on the PATH of the process running the daemon, then use Rescan in Settings, Execution mode.
What I actually ran
$ npm i open-design-mcp
added 95 packages in 14s
# open-design-mcp 0.16.1, Apache-2.0
$ node node_modules/open-design-mcp/dist/src/server.js
[open-design-mcp] starting on stdio
[open-design-mcp] ready
initialize -> {"name":"open-design-mcp","version":"0.16.1"}
tools/list -> 10 toolsEnvironment: Linux, Node v22.22.3, npm 10.9.8, on 2026-08-08. Transport: stdio, initialize then tools/list, with OD_DAEMON_URL set to a placeholder.
od_list_projects od_get_project od_create_project od_update_project
od_delete_project od_save_artifact od_lint_artifact od_compose_brief
od_generate_design od_save_project_file
Runtime verification confirmed installation, initialization, version, and the ten-tool list. Everything below that line comes from source and documentation inspection, not from executing the tools.
Source inspection indicated that nine of the ten tools depend on OD_DAEMON_URL, while od_compose_brief is a pure formatting function with no network call, and od_generate_design requires additional BYOK settings.
That points to the Open Design Codex architecture from the other direction: the bridge is a connector, not the design engine. Its project and generation operations require a running Open Design daemon; od_compose_brief is the one daemon-free exception identified in this review.
One caution before you point an agent at this: source inspection indicates that od_delete_project can remove both the database record and the project directory. I did not execute this destructive operation.
What you need before you start
- The Open Design product itself, not just an MCP package. The bridge alone cannot perform the project and design-generation workflow; those operations depend on the Open Design product and its daemon.
- A running daemon. Source inspection indicates nine of the ten bridge tools require its URL.
- A decision about execution mode, because API key requirements and cost conditions differ between them.
Those three are the whole checklist for an Open Design Codex install. Everything after this is detail.
On system requirements, the official repository currently specifies Node 24 for a source installation, along with pnpm 10.33.2 via Corepack, and lists macOS, Linux, and WSL2 as primary paths with Windows native supported. There is also a documented Docker route that avoids the local Node and pnpm setup.
For clarity about my own test: the third-party bridge initialized successfully under Node 22, but that test did not install or run the Open Design product itself, which is what carries the Node 24 requirement.
Privacy
The project describes itself as local-first, and its documentation also describes telemetry behavior, including analytics settings that are consent-gated and other telemetry that is not. Review the current privacy and telemetry settings before using this for confidential work. I did not inspect outbound network traffic in this test, so I cannot characterize what is actually transmitted.
What I did not verify about Open Design Codex
- The desktop GUI. Never launched. No canvas, no preview, no export
- Output quality. I have not generated a deck, page, or image
- Whether
od mcp install codexworks end to end - Whether the daemon successfully spawns and authenticates Codex
- Any real-world cost, plan-limit, or credit behavior
- Generation time and token limits. The bridge’s own README makes claims about these; I did not execute them, so they are not in this article
- Outbound network behavior
This article will be updated once the GUI is tested, and the date at the top will change when it is.
Who this is for
Worth investigating if you already use an agent CLI such as Codex or Claude Code and want to evaluate Open Design’s documented HTML, PPTX, and PDF workflow, and you are comfortable with a Node, pnpm, or Docker setup. I did not verify those exports in this test.
Skip it if you want a hosted tool with a login, or you need production stability. Tooling in this category is moving weekly and this project is no exception.
If you are weighing which assistant to lean on for this kind of work in the first place, I put Claude and ChatGPT through the same 10-K and wrote down where each one broke.
Frequently asked questions
Is this an official OpenAI Codex plugin?
No. Open Design is a third-party open-source project, Apache-2.0, that supports Codex as one of its runtimes. Its documentation provides od mcp install codex to wire its MCP server into Codex’s config. That is Open Design supporting Codex, not OpenAI publishing Open Design.
Is the software free, and when can API charges apply?
The license is free. Charges depend on the execution path. In API or BYOK mode, provider charges may apply, depending on the selected provider, model, and usage, under your own account. In local CLI mode the documentation describes invoking an already authenticated agent CLI without a separate provider key inside Open Design, but I did not verify the billing behavior, and plan limits and credits remain subject to your own agent account.
What is the difference between the built-in od mcp and the open-design-mcp package?
od mcp install <agent> is part of the Open Design product and wires the MCP server that ships with it. open-design-mcp on npm is a separate third-party bridge that connects an editor to a daemon you are already running. The bridge does not replace the product install.
What did this test actually verify?
Runtime testing on the Open Design Codex bridge verified installation, startup, version reporting, and a ten-tool list. Separate source inspection found that nine tools reference OD_DAEMON_URL. Everything about the Open Design product itself comes from reading its repository and Quickstart, not from running it.
Checked on August 8, 2026. Next check: September 2026, since this project is in active development. Sources: nexu-io/open-design, its Quickstart, and open-design-mcp v0.16.1 on npm. Test record: tarball integrity sha512-jNMOJOr6fbuaHUhZ/JnrFjteRb/ZJ6UavgImxhNfFUyT8tS3L/tGtVesPkmiGqnKEqwntWexDXKARf3SzLSPEQ==, server.js sha256 d1b51249597701c2332414e07881b43957546133e5d32feca3b39c4143800a71.
