Jellyfish (Forget-C/Jellyfish): an AI short drama production workspace in Python

What Jellyfish is actually for

Jellyfish targets a specific production shape: the vertical short drama made in batches. The README lists short and micro-drama creators, AI studios producing video content in batches, solo creators exploring vertical drama production, education and training teams making lesson videos, and brands producing story-driven promos. What those groups share is volume. One clip generated from one prompt does not need a workspace. Twenty shots across five chapters, each with a character who must look the same in every frame, does.

The problem the project names is consistency. Its core value list puts it plainly: characters, scenes, props and costumes are managed centrally so that identity and style do not drift from shot to shot. In practice, drift is the failure mode of AI video pipelines. A model regenerates a face slightly differently each time, and the audience notices within two cuts. Jellyfish answers that with a shared entity model plus reusable candidate assets, rather than with a model-side fix.

The second problem is bookkeeping. Generation is slow and asynchronous, and the README states that text, image and video jobs all go through one async task system with status, cancel and recovery. Anyone who has run a batch of video jobs across several providers knows what happens without that layer: tabs, filenames, and a spreadsheet that is wrong by the end of the day.

Script breakdown to shot ready: the workflow the repository encodes

The README gives the main workflow as a chain: script breakdown, shot preparation, candidate confirmation, shot ready, generation workspace. That ordering is the architecture, and it is worth reading as a state machine rather than a menu of features.

A chapter script enters the system. AI processing splits it into shots and extracts characters, scenes, props, costumes and dialogue. Those extractions become candidates, not facts. The preparation step is where a human refreshes candidates, accepts or ignores asset candidates, accepts or ignores dialogue candidates, links existing entities, and corrects shot-level fields such as title and summary. Only when the readiness state says the shot is prepared does it become ready, and only ready shots enter the generation workspace.

The README draws one boundary explicitly: prepared is kept distinct from currently generating. That is a small design decision with real consequences. A shot can be fully specified and still not have been sent to a model. The readiness flag answers whether the inputs are complete, not whether work is in flight. Teams that conflate those two states end up re-running shots that were merely queued.

Generation itself is shot-level. The workspace handles keyframes, reference images and video prompt preview, runs single-shot and batch pre-checks, launches image and video tasks, and writes outputs back into the shot and media system. Supporting all of it are model management with default settings per category, prompt templates, file and media handling, and an OpenAPI contract between frontend and backend.

Installing Jellyfish: what the README states and what it does not

The README is a product tour, not an installation guide. It documents a Docker Compose section that is cut off mid-sentence in the repository description, and the top-level repository layout includes a deploy/ directory, which is where the compose file would live. If you intend to run Jellyfish, start by reading deploy/ rather than the README. Nothing in the README states a supported Python version, a database, or which model providers must be configured before the generation workspace is usable.

The one command the README does give is the OpenAPI client regeneration step. With the backend dev server running at http://127.0.0.1:8000, the documented sequence is:

cd front
pnpm run openapi:update

That command reads the backend spec, writes a cached copy to front/openapi.json, and regenerates request helpers and types into front/src/services/generated/. If you have changed backend routes, this is the step that keeps the frontend compiling against them. If it fails, the mismatch is between your running backend and the spec it serves, not in the generated code.

The frontend is React with Vite and the backend is FastAPI, per the README badges. Beyond the port above, the README does not list environment variables, a database URL, or provider API keys, so treat any such value as something you must discover in deploy/ and backend/ yourself.

Where Jellyfish will frustrate you

The documentation gap is the first limitation. The README describes capabilities in confident, well-organized prose and then stops short of the operational detail. There is no documented quickstart, no stated prerequisites, no provider configuration example, and no rollback or recovery procedure for a failed batch. The task center supports cancellation and recovery, but the README does not explain what recovery means when a provider has already accepted a job and billed for it.

Second, the readiness gate assumes a human in the loop. Candidates must be accepted, ignored or linked, and shots must be corrected before they are ready. That is the right design for consistency and the wrong design for throughput. If your goal is to fire a hundred prompts at a model and keep whatever looks good, the preparation workflow is friction, not help.

Third, the project is young. The most recent release listed is v0.3.2 from 2026-04-17, and the last push to the repository was on 2026-07-30. The version number is honest about maturity: pre-1.0 software with an evolving OpenAPI contract, which means the generated frontend services can shift between releases.

Finally, Jellyfish does not generate anything itself. It orchestrates models you supply. Multi-provider and multi-model management are listed as capabilities, but the README does not name a single supported provider, so evaluating quality means evaluating your own model choices behind the workspace.

How Jellyfish differs from a node-based generator like ComfyUI

The closest comparison is ComfyUI, and the difference is philosophical rather than technical. ComfyUI is a node graph over diffusion models: you wire samplers, loaders and control nodes, and the graph is the artifact. It is excellent for experimenting with generation technique and poor at holding state across a series, because nothing in the graph knows that shot 12 and shot 47 are supposed to feature the same character.

Jellyfish inverts that. Generation is a step inside a production record. The persistent objects are projects, chapters, shots, characters, scenes, props and costumes, and the media is attached to them. The README's shot preparation workflow exists precisely because the entity model, not the graph, is the source of truth. The cost is flexibility: you get the generation controls the project exposes, and the README does not claim arbitrary node-level control over sampling.

A second, quieter difference is the async task layer. ComfyUI runs a queue you watch in a browser tab. Jellyfish's task center tracks status, progress, elapsed time and results, supports cancellation, and lets you jump back to the related project, chapter or shot. For a solo creator that is convenience. For a studio running batches overnight, it is the difference between a job list and a guess.

Licence, maintenance and what an upgrade costs

Jellyfish is licensed under Apache-2.0, per the README badge and the LICENSE file at the repository root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which matters if you build a product on top of the workspace. It also requires that you preserve the licence and notice files and state significant changes. That is a description of the terms, not legal advice; if your use is unusual, read the licence text or ask a lawyer.

On maintenance, the facts are narrow. The repository is not archived. Its last push was on 2026-07-30. The newest release listed is v0.3.2 from 2026-04-17, with v0.3.1 and v0.3.0 earlier that same month. The README does not document a deprecation policy, a migration guide between minor versions, or a support window.

The upgrade cost concentrates in one place: the OpenAPI contract. Frontend request helpers and types are generated from the backend spec into front/src/services/generated/, so a backend change that alters routes or schemas propagates into the frontend at build time. That is a healthy arrangement, because breakage surfaces as a compile error rather than a runtime surprise. It also means you should pin a commit or a release tag and regenerate deliberately with pnpm run openapi:update rather than tracking main.

Editorial conclusion

Adopt Jellyfish if you already have API access to image and video models and you want the surrounding production machinery (shots, candidates, assets, task tracking) rather than another single-purpose generator. Do not adopt it if you only need one image or one clip, or if you expect the README to tell you how to run the stack end to end. Before committing, open deploy/ and read the compose file, then run the backend on 127.0.0.1:8000 and the pnpm run openapi:update step in front/ to confirm the generated client matches the spec your backend emits.

Frequently asked questions

Official sources

1. Forget-C/Jellyfish on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases