Choosing a path: local CLI, BYOK, Docker, and artifact types

Choosing how to run OpenDesign is a decision about capability and responsibility, not just a choice between buttons. This chapter compares local coding-agent execution, API/BYOK runs, source and desktop packaging, and Docker deployment against the artifact a person actually needs. The goal is a low-risk adoption judgment: identify which path preserves the necessary handoff and design context, then test that path before adding more agents, plugins, connectors, media providers, or public exposure.

The comparison starts from the boundary established earlier. Every path can use the daemon-owned project and preview model, but not every path gives the agent the same tools, intermediate events, or authority. A good choice therefore begins with the desired work, not with the longest runtime list.

Choose the execution path by the handoff you need

A local CLI path is the natural choice when the task benefits from filesystem-capable agent work. The daemon can launch an installed coding agent in the project workspace, stream structured events, observe file writes, and let the preview update as the artifact takes shape. This is useful for a prototype that needs several files, a deck that must be inspected while it is being assembled, or a refinement task in which the agent should read and edit an existing project.

The price is that the local runtime is part of the operating environment. The daemon must discover the executable, invoke it with the correct argument shape, and work with the authentication and model access that the CLI provides. The runtime may have its own session, stream, permission, and resume semantics. A local agent that is installed but not authenticated is not a usable generation path, and a visible binary does not imply that every model or feature the CLI advertises will work through a headless invocation.

A filesystem-capable runtime also deserves a more demanding definition of success. The useful result is not a fluent answer describing a page; it is a project file that the host can preview and that a later run can inspect. This path is strongest when the user values live progress, file-level continuity, and native tool use more than a minimal configuration surface.

API or BYOK mode makes a different trade. It is the fallback for a user who has a provider endpoint or key but no suitable local CLI, and it can be attractive when the desired artifact is small enough to return as one complete source block. The model does not receive filesystem tools in this profile. Instead, the daemon expects a complete supported artifact block and materializes it into the project workspace after the response arrives.

That can reduce local setup: the user does not need to install and authenticate a particular coding-agent executable. It can also make the provider choice more direct. But the handoff is less interactive. There may be no structured file-write events while the model works, and a response that describes an artifact without returning a complete supported block does not create one. BYOK is therefore a good fit for a self-contained HTML or Markdown deliverable when simplicity and provider choice outweigh live filesystem collaboration. It is a weaker fit when the task depends on several iterative edits, native project inspection, or a runtime-specific tool loop.

The two paths should not be judged by the same superficial test. A local run that produces a file through tool calls and a BYOK run that returns a complete artifact can both be successful. A local run should be checked for project-file creation and preview update. A BYOK run should be checked for a valid artifact envelope and safe materialization. If the same prompt produces a long textual explanation in BYOK mode, the likely issue is not that the daemon lost the answer; it is that the text-artifact contract was not met.

Packaging adds another axis without changing the basic division of labor.