Why This Started: I Want to Build AI Comics, but I Don’t Want to Build the Platform from Scratch

I already have a working model backend: an OpenAI-compatible image/video gateway, plus Alibaba Cloud Bailian (Wanxiang for images and wan2.x for video). What I’m missing is the upper layer—a director’s workbench that can manage the full flow from “script → characters → storyboards → image generation → video generation → compositing.”

Building a platform like that from scratch would take at least several months. Conveniently, in the first half of 2026, a batch of open-source AI comic/short-drama projects appeared on GitHub. So the question became: which one is worth forking?

I spent two days doing source-level due diligence. Here’s the conclusion up front: fork alibaba/lumenx. The most engineering-complete project, dramaclaw, can only be a second choice because Elastic License 2.0 prohibits SaaS use. And the “multi-model pluggability” claimed by all the leading projects does not survive contact with the source code.

Method: Don’t Read the README—Read the Code

The process had four steps:

1. Scanning: I searched in both Chinese and English, cross-checked community roundups through five parallel paths, deduplicated the results, and ended up with 29 candidates. I verified them one by one through the GitHub API; 28 were real and still alive.
2. Deep reading: I shallow-cloned 12 projects and read their provider layers, generation pipelines, data structures, task queues, FFmpeg calls, and original LICENSE text. I scored them across 15 dimensions, and every conclusion had to cite a source file path.
3. Adversarial verification: For each of the top three projects by score, I assigned two “debunkers” whose job was to read the source code, find counterexamples, and try to overturn the deep-reading conclusions.
4. Revision: The verification results directly changed the final ranking.

Step 3 was the most valuable part of this due diligence exercise—you’ll see why below.

The Landscape: Only Five Projects Are Truly End-to-End

Among the 28 candidates, only five had the full “novel/script → storyboard → image → video → final film” pipeline:

The rest were either ComfyUI plugins, pure frontend toys, model training pipelines, or already closed-source—such as the 1753★ bigbanana-ai-director, which now only ships Docker images and uses CC BY-NC-SA, which also prohibits commercial use.

Finding 1: “Pluggable Providers” Are Mostly Marketing

My core requirement is to connect my own two backends, so I paid special attention to each project’s provider layer. During deep reading, all three leading projects claimed to have a “clean, pluggable architecture.” Then adversarial verification disproved all of them:

• dramaclaw: Its video generator directly hardcodes Volcengine API endpoints, model names, and polling logic. The LLM side is reasonably flexible because it goes through a gateway, but if you want to switch to another video vendor, you have to modify several modules. It is not just a matter of adding configuration. Interestingly, it includes a built-in Grok video generator, which suggests the author has already walked a similar path.
• lumenx: Its provider layer is a “class-level abstraction”—the factory class uses if/else branches on vendor names, each vendor has its own Model class, and the image module directly imports vendor SDKs. Adding a new vendor requires touching roughly four modules. The scope is bounded, but it is definitely not configuration-level pluggability.
• Toonflow-app: The advertised “programmable provider system” only applies to text models. Images and videos still require vendor-by-vendor customization.

The harsh conclusion: at the image/video generation layer, swapping out the underlying provider requires writing code in every project. The only difference is whether you write four modules or rewrite half the system. Across the entire field, only the LLM layer has true configuration-level integration.

Ironically, the best OpenAI-compatible adapter I found came from a low-star enterprise Agent platform, buildingai, with its createOpenAICompatible implementation. It has no video pipeline, but that adapter code is worth copying outright.

Finding 2: License Matters More Than Architecture

This was the most lethal filtering step. High-star projects fell one after another:

• dramaclaw (3690★): Elastic License 2.0. The original text is explicit: providing hosted/managed services to third parties is prohibited. Self-hosting, modifying the code, and delivering finished works to clients are all allowed, but external SaaS requires a commercial license.
• Toonflow-app (13939★): Apache-2.0 plus supplemental terms. Distributing the product to more than two independent third parties requires written authorization.
• printfilm (3488★): Architecturally, it is a hidden gem: automatic novel episode splitting, FFmpeg-based tail-frame stitching between shots, and a task system with idempotency keys are all there. But the repository has no LICENSE file—legally, you should not even fork it.
• moyin-creator (4363★): AGPL-3.0; openframe is similar, also AGPL.
• director_ai (1705★), ai_story (1345★): Also no LICENSE.

After the license filter, among the 28 candidates, the only project with a clean license (MIT/Apache-2.0 without extra restrictions) and a full end-to-end pipeline was lumenx.

Finding 3: Comic Production Needs Pipelines, Not Autonomous Agents

I also looked at the orchestration architectures across projects. Some use nine LangGraph agents (open-director, where the video generation code is commented out, so it is not actually finished). Some use a custom three-layer agent system (Toonflow: decision layer + execution layer + supervision layer, beautifully designed). Some use PydanticAI (dramaclaw).

My judgment: comic production is long-running, expensive batch processing that must support resumability. One episode has nine shots; each shot costs one or two yuan. If the process crashes at shot seven, what you want is to resume from shot seven—not have an agent rethink the meaning of life. So a pipeline plus a persistent task table is better than multi-agent autonomous decision-making. dramaclaw’s task system—state machine, cancellation, retry, recovery, audit—is the benchmark in this whole field. That design is more valuable than its provider layer.

Final Choice: Fork lumenx

The decision chain is short:

1. The goal is commercial use → exclude Elastic-2.0, AGPL, no LICENSE, and closed-source projects;
2. Among the remaining MIT/Apache camp, the only full-chain options are lumenx, Toonflow, and localminidrama;
3. Toonflow has multi-customer distribution restrictions, its image/video providers still need to be implemented vendor by vendor, and its dubbing module is still an empty shell. localminidrama is an excellent Electron desktop app—its provider configuration layer is another benchmark in the entire field—but its “data never leaves the local machine” positioning conflicts with a platform-based direction;
4. lumenx: MIT, zero license risk, full pipeline, Bailian is its native path, and the provider refactor scope is bounded at around four modules.

It has weaknesses too: the task system is relatively weak, it does not automatically split novels into episodes, and it lacks “previous shot tail frame → next shot first frame” continuity. But all three areas have existing designs to learn from: borrow the task system design from dramaclaw, the three-stage novel import flow from printfilm, and the first/last-frame parameters from lingguo-drama. The idea is to borrow designs, not copy code—dramaclaw’s EL-2.0 would not allow that anyway.

The second choice is dramaclaw: if you can accept a commercial license, or if you position the product as a self-hosted production tool plus finished-film delivery for clients—which Elastic-2.0 explicitly allows—it has the highest out-of-the-box completeness.

Three Methodological Lessons

1. Discount any README claim of “multi-model support,” and cut any “pluggable” claim in half right away—grep vendor endpoint URLs and hardcoded model names. You’ll know the truth in five minutes.
2. Check the License before the architecture. No matter how good the architecture is, EL-2.0, AGPL, or no LICENSE can kill your commercial plan on the spot. In this batch of 28 candidates, fewer than half had clean licenses.
3. Adversarial verification is more reliable than positive evaluation. Ask one agent to praise a project, and it can find twenty strengths. Ask another agent to try to overturn that conclusion, and it will dig up life-or-death details like line 18 of the LICENSE.

The full report—15-dimensional scoring table, per-project source-code evidence, adapter interface design, and a 13-stage refactoring plan—is in my private repository. This post is the public condensed version. If you are also choosing an open-source foundation for AI comics or short dramas, I hope this saves you two days.