CineGen AI Director turns a script into a shot list and then into video

One pipeline rather than a folder of prompts

CineGen AI Director is described as a browser-based production workbench for AI manga videos, motion comics, animated comics, animatics and short dramas.

The sentence that describes the design is the one about the workflow. Its script, assets, keyframes, video workflow connects story planning, character and scene references, shot design and video generation in one place.

That is the whole proposition. The production of an AI comic is a sequence of steps that normally live in different tools. You write or plan the story somewhere, generate character reference images in an image model, decide the shot list in a document, generate a keyframe per shot in another session, and then produce a video clip per shot. Each handoff is a folder, a file name and a note to yourself about which prompt went with which shot.

This project puts those steps in one application with one data model, so the character reference image is attached to the character rather than to a folder, the shot carries its own start frame, and the clip is linked to the shot it came from.

The model providers are named. It uses Google Gemini for script and image generation and Veo for video clips.

So the tool is a director's workbench rather than a generator. The interesting part is not that it can make an image, since that is what the models do, but that it structures the production around a script with scenes, characters and shots and then gives you a grid to work through.

The project is TypeScript, with the default branch main and the last push on 2026-09-25. There are no GitHub releases and the package version in the manifest is 0.0.0, which is consistent with a project distributed as source rather than as a published package.

The four phases

The workflow is documented as four steps, and they are worth reading as a production process.

The first is script and storyboard. You enter a story outline or script, choose the output language and target duration, and then use Gemini to structure scenes, characters and shots with visual prompts and camera directions.

The fact that you choose the target duration at this point is the detail that matters. The length of the piece constrains the number of shots, and the number of shots constrains the number of images and clips you pay for. Deciding it before the structure is generated, rather than after, is what keeps the cost of a run predictable.

The second is characters and scenes. You generate reference images for characters and locations, and you can create multiple character looks while retaining a base reference for later shots.

That capability addresses the central problem with generated images of people. A model will produce a different face every time you ask, so a character who looks one way in shot one and another way in shot twelve is not a character. The base reference plus variations approach keeps a consistent anchor while still allowing the outfit or the mood to change per shot.

The third is the director workbench. You manage shots in a visual grid, generate a start frame for each shot and, when needed, an end frame. Scene and character images provide visual context for the image generation, and you use Veo to generate a video clip from the start frame or from both keyframes.

The fourth is preview and production status. You preview generated clips and review the sequence and the shot completion status in the production workspace.

That last phase is more than a preview screen. A production has dozens of shots, and knowing which ones have a clip and which ones do not is what lets you finish. Treating shot completion as a status in the workspace, rather than as a directory listing, is the difference between a tool you can use for a whole episode and one you use for a single clip.

Why keyframes rather than a prompt

The documentation includes a short section titled Why keyframes, and it is the most useful paragraph in the project for anyone deciding whether this approach fits their workflow.

Defining the beginning and optional ending image of a shot gives creators more direct control over composition and transitions than a text prompt alone.

That is the argument. A video model given a text prompt has to guess the composition, the framing and where the camera ends up. A video model given a start frame and an end frame has both ends pinned, and the motion in between is generated to connect two known images.

The consequence is that the transition between shots, which is where AI video usually goes wrong, is controlled. If you know what the last frame of shot one looks like and what the first frame of shot two looks like, you can make them match, and the cut lands instead of jumping. That is a real editing decision, and having the keyframe workflow in the tool means you can make it.

The end frame is optional, which matches how video models actually work. With only a start frame you get the model animating from that image, and the end is whatever it decides. With both you get an interpolation between two chosen images. So the tool lets you pay for the control where you need it and not where you do not.

And there is a caveat in the same paragraph that is worth taking seriously: generated results still require review and iteration.

That is not a throwaway line. Every frame in this pipeline is generated by a model, and models produce inconsistent output, off-model anatomy, wrong text and broken continuity. A workbench that made those problems disappear would be claiming something the models do not deliver. What the workbench does is make the iteration fast, because when a frame is wrong you change the keyframe and regenerate rather than rewriting a prompt in a separate tool and re-importing.

Running it locally, and where your data lives

The local setup needs Node.js, npm and a Google Gemini API key with access to the Gemini and Veo models used by the project. The documentation is careful to add that model availability and billing depend on your Google account and region.

That last clause is the one to read before you start, because it is the difference between a tool that runs and a tool that runs for you. Veo access is not something every Google account has, and the regions differ. There is nothing the project can do about that, so it states it plainly.

The setup itself is four commands:

git clone https://github.com/UllrAI/CineGen-ShortDrama.git
cd CineGen-ShortDrama
npm install
npm run dev

Then you open the local URL printed by Vite, with the configured development port being 3000, enter your Gemini API key, and create a project in Phase 01.

The Phase 01 reference is worth understanding. The interface is organised in phases, and a new project starts at the first one, so the tool has a defined order of work and you cannot jump ahead. That is a reasonable design for a process with dependencies between the steps, where generating a clip before the character references exist wastes money.

The application interface is primarily in Chinese, and you can choose the generated script's output language in the project settings. So the interface language and the output language are separate decisions, and the second one matters because the script is what drives everything downstream.

Then there is the storage arrangement, which is the most consequential technical detail. The API key is stored in browser localStorage, and projects are stored in browser IndexedDB. Clearing site data removes locally saved projects.

That means there is no server component holding your work. Your script, your generated images and your clips live in the browser on the machine you used. The consequences are worth thinking about before you start a production.

The good ones are privacy and simplicity. There is no account, no upload of your work to someone else's storage, and no per-project server cost. The API key goes straight from the browser to Google.

The cost is that your work is tied to that browser profile and that machine, and clearing site data destroys it. There is no sync, and there is no backup unless you take one. For a side project that is a good trade. For a production with dozens of shots and real money spent on generation, exporting and backing up regularly is not optional, and it is worth knowing before the first expensive run rather than after it.

The licence, the hosted version and the codebase

The licence is the first thing to read, and the documentation says to read it before using, modifying, distributing or deploying the project.

The source is available under the AniKuku Community License, version 1.0, and the description notes that this custom license includes attribution requirements and commercial-use conditions.

So it is not one of the permissive licences. A project that ships a custom community licence with attribution requirements and commercial conditions is making a deliberate choice about how it can be used, and the fact that the documentation points at it three times in one paragraph tells you how much attention it wants.

The commercial relationship runs through AniKuku, which offers a hosted AI manga and motion comic production platform as well as commercial and private deployment options. There is a discount code for a first purchase, subject to the site's current terms.

So the picture is a community-licensed source project alongside a commercial hosted and private deployment offering. That is a common shape for this kind of tool, and the practical advice is the same: read the licence text rather than assuming it is MIT like most of the code you have seen.

The codebase is a small React and Vite application, and the dependency list is short enough to read in one pass. React and React DOM at 19.2, the official Google GenAI SDK at 1.30, and lucide-react for the icons. The development dependencies are TypeScript at 5.8, Vite at 6.2, the React plugin for Vite and the Node types.

Two things stand out. The GenAI SDK is the official one from Google rather than a hand-written HTTP client, which means the request shapes follow the provider's own types and the model names come from the SDK rather than from string constants in the source. And the absence of any state management library, any UI framework and any server code says something about the design: this is a client-side application that talks to the model APIs directly and keeps its state in the browser.

The repository layout matches that. There is App.tsx and index.tsx as the entry points, a components/ directory, a services/ directory which is where the model calls live, types.ts for the shared types, and metadata.json. There are README files in English, Chinese, Japanese and Korean, which tells you the audience it is written for.

Editorial conclusion

Adopt CineGen AI Director if you produce AI manga, motion comics or short dramas and want the story planning, the asset generation and the shot assembly in one tool rather than in a folder of image files. Skip it if you are on a budget that does not cover image and video generation at volume, since the tool calls paid models. Verify first which models your Google account can reach and in which region, since Veo access is not universal, that you read the community licence before deploying it, and where your projects live, because everything is kept in the browser.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. UllrAI/CineGen-ShortDrama on GitHub