Ten creator tools share one Codex runtime
OpenCreator puts ten creator tools beside an agent conversation, then keeps both views pointed at the same task state. You can translate or download video, generate images and video, write articles and social copy, make voiceovers, and build stick-figure animation. The agent side adds projects, approvals, files, schedules, memory, Skills, and MCP connections. That shared state is the useful idea here: a generated asset can be revised through controls or conversation without starting a second project.
The package is larger than a creator dashboard. Our checkout at commit 3e5b48d contained 1,898 files and about 276,389 lines of source before pnpm added anything. A React Web app talks to a local Fastify daemon. Electron supplies desktop access, SQLite holds local project data, and Codex CLI runs the agent loop. FFmpeg, yt-dlp, and Whisper-compatible services cover the media work. Each part makes sense, but together they create a full workstation with several failure surfaces.
Two advertised workflows are still in development
The README labels eight creator workflows available and marks Auto Clips and Digital Avatar as in development. Available tools include video translation, downloading, thumbnail creation, image and video generation, article writing, Xiaohongshu posts, short-video scripts, stick-figure animation, and Smart Dubbing. Creation templates give image and video jobs a repeatable starting point, while version history preserves earlier settings and outputs after each revision.
Provider access sets the practical boundary. Language models come from the active Codex catalog or an OpenAI-compatible service. Image, video, voice, and transcription jobs use credentials configured under AI Services, although options such as Edge TTS do not require an API key. Real model tasks also require a valid Codex login. In other words, the 706 MB dependency install does not buy the models or accounts needed to run every tile on the dashboard.
What happened when we ran it
Our fresh Debian sandbox installed 785 packages in 12 seconds, leaving 706 MB of dependencies on disk. The repository itself occupied 313.7 MB. Installation was the clean part. pnpm build ran for 27 seconds and exited 1. The supplied log tail shows a child process with status 2, followed by Node.js v22.23.2 and two lifecycle failures. It does not expose the earlier message that caused that child process to stop, so we cannot assign a cause from this evidence.
The test command also exited 1 after 24 seconds. Several workspace summaries in the log were green, including protocol, writing-template, and stickman-remotion suites. The failure appeared in packages/skill-market/test/runtime-import.test.ts, where one test failed after roughly 20.6 seconds and five passed in that package. Our run proves that the checked-out commit did not clear its full test command in this container. It does not show why the runtime import failed.
A 313.7 MB monorepo asks for workstation-level care
Source users need Node.js 22 or later, pnpm 9.15.0, Codex CLI, and a valid login. Web development can launch the daemon on demand, while desktop development adds Electron packaging and platform behavior. The documentation distinguishes a runnable desktop directory, a local installer, and the formal release path. It also warns that a Web unit test alone does not establish desktop release readiness. That warning matches the architecture: one UI still crosses browser, daemon, desktop, agent, and media boundaries.
Local data is easier to reason about than the provider matrix. OpenCreator stores its database, attachments, run metadata, and managed workspaces under .runtime/ by default. Codex sessions remain under the active Codex home and need a separate backup. The daemon listens on localhost, protects non-health routes with a bearer token, and stores service credentials through the operating system. Those choices are sensible for one machine, though anyone exposing the browser UI remotely would be designing a deployment the README does not describe.
Same-day code activity leaves a license question open
GitHub recorded 11,905 stars, 30 open issues and pull requests, and a push on September 20, 2026. Release v3.2.1 was published the same day with the new template workspace, video clipping work, imported SRT support, provider changes, and desktop fixes. That is active maintenance. The issue list also contains concrete user reports about incomplete yt-dlp downloads, a Windows installer error, and malformed JSON returned by an Ollama-backed translation flow.
Licensing needs a direct answer before a company commits. The README displays an Apache 2.0 badge, but GitHub's repository response contains no detected license, and issue #326 asks for an MIT or Apache 2.0 file. OpenCreator may be a good fit for a creator already living in Codex and willing to test each provider path. Until the repository itself resolves that license gap, the safest trial is technical rather than organizational: run your actual workflow, inspect its output, and do not assume the badge settles reuse rights.