openOii: a LangGraph learning project that turns a story idea into a comic video
故事想法 → 多智能体协作 → 漫剧成片 | 基于 LangGraph 的 AI 漫剧生成平台
At a glance
- What is it?
- openOii chains planning, character and storyboard generation, video generation and compositing into one LangGraph run, and puts the intermediate state on a tldraw canvas. The README labels it a learning and demo project, not production software, and that framing should drive the adoption decision.
- Who is it for?
- Adopt openOii if you want a readable reference for multi-stage LangGraph orchestration with resumable runs and WebSocket progress, and you are willing to read the graph and node code rather than treat it as a product.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap openOii tries to fill between a story prompt and a finished comic video
Most text-to-video tooling takes a single prompt and returns a single clip. A comic-style episode is not that. It needs a plan, a cast with consistent appearance, a shot list, per-shot image or video generation, and a compositing step that stitches the shots into one file. openOii's README describes exactly this chain in one line: story idea, multi-agent collaboration, finished comic video. The stated audience is people learning LangGraph, not studios shipping episodes. The README carries an explicit warning block calling it a LangGraph learning and demonstration project whose focus is validating multi-stage orchestration, resumable execution, real-time progress and frontend-backend collaboration, and stating it is not suitable for direct use in a production environment. That warning is the most useful sentence in the repository. It tells you the value is in the orchestration pattern, not in output quality. If you need a finished episode today, this is the wrong starting point. If you want to see how a long-running generative job is split into nodes, checkpointed, streamed to a browser and reviewed on a canvas, the project is aimed at you.
How a run is structured: LangGraph nodes, a checkpointer and a WebSocket channel
The stack listed in the README is FastAPI, SQLModel and LangGraph on the backend, React 18 with TypeScript and tldraw on the frontend, and PostgreSQL plus Redis plus a /static directory for infrastructure. The data flow implied by that combination is a run record persisted through SQLModel into PostgreSQL, graph state checkpointed so a run can resume, and progress events pushed over a WebSocket to the browser. The README names three run behaviours: resumable, cancellable and able to accept feedback. Those three are not free. Resumability requires a checkpointer and a stable thread identifier. Cancellation requires the API layer to signal the running graph rather than just closing a socket. Feedback implies a pause point where a human reviews generated characters or storyboards before the pipeline continues to video generation, which is why the review surface is a canvas and not a chat log. The README does not document the individual node names or the state schema, so the only way to learn the actual graph shape is to read the backend source. Treat the README as a map of capabilities, not of internals.
The tldraw canvas is the part that changes the workflow, not just the demo
Reviewing generated characters and storyboards as a scrolling list of images makes consistency errors hard to spot. openOii puts them on a tldraw infinite canvas, per the README's feature list, alongside the generation process itself. Spatial layout matters here: you can place a character sheet next to the shots that use it and see whether the design drifted between shots. The same canvas is where the generation flow is displayed, so the artifact and the process share one surface. This is the design decision with the most transferable value. It also constrains the project. A canvas-based review step assumes a human is present to accept or reject intermediate output, which is why the feedback path exists and why a fully unattended batch mode is not what this codebase is shaped for. If your pipeline has no human in the loop, the canvas and the feedback endpoints are dead weight you would be carrying.
Getting it running: docker-compose first, uv and pnpm for local work
The README's quick start is two commands. Copy the example environment file, then bring up the stack:
cp backend/.env.example backend/.env docker-compose up -d
The documented endpoints are the frontend at http://localhost:15173 and the API docs at http://localhost:18765/docs. Note that the compose path needs backend/.env to exist before the containers start, and the README does not enumerate which keys inside that file are required, so expect to open it and fill in model provider credentials. For local development the README splits the two halves. Backend: cd backend, then uv sync, then uv run uvicorn app.main:app --reload --host 0.0.0.0 --port 18765. Frontend: cd frontend, then pnpm install, then pnpm dev. The project uses uv rather than pip or poetry, and pnpm rather than npm, so both tools need to be installed first. The README also mentions a frontend environment variable configuration panel for managing models and base services online, which suggests provider settings can be changed from the UI instead of only through the env file. Common commands are given as uv run pytest and uv run ruff check app tests on the backend, and pnpm test and pnpm build on the frontend. Python 3.10 or newer and FastAPI 0.115 or newer are the stated version floors.
What the README does not tell you, and why that is the real risk
There are no releases in the repository metadata, so there is no tagged version to pin and no changelog to read before upgrading. The last push date is recorded, but nothing in the supplied material describes a support commitment, a deprecation policy or a migration path between commits. Dependencies are pinned only by the version floors in the badges, Python 3.10+, FastAPI 0.115+, React 18, which means a fresh uv sync or pnpm install can pull newer minor versions than the author developed against. The README also does not document how generated video is stored or served beyond the /static directory, how long PostgreSQL and Redis retain run state, or what happens to a resumable run after a container restart. These are not cosmetic gaps. A resumable pipeline that loses its checkpoint store on restart is not resumable. The honest position is that the orchestration ideas are legible from the code, but the operational envelope is undocumented, and anyone running this beyond a laptop is filling in that envelope themselves.
Where openOii sits relative to a general-purpose agent framework
LangGraph itself is the alternative, and the difference is one of scope rather than capability. LangGraph gives you the graph, the checkpointer and the streaming primitives, and leaves the domain entirely to you. openOii is a worked example of one domain: it already defines the stages, the review surface, the run lifecycle with cancel and feedback, and the FastAPI plus SQLModel persistence layer around them. Choosing between them is choosing between reading a reference implementation and writing your own. If your pipeline looks like openOii's (plan, cast, storyboard, generate, composite, review in between), reading this codebase will save you design time. If your pipeline diverges at any of those stages, you inherit a structure built for comic episodes, and bending it costs more than starting from the bare framework. A second alternative worth naming is a plain task queue with a database: Celery or similar plus a jobs table. That gets you resumability and cancellation without a graph abstraction, at the cost of expressing the pipeline as a chain of tasks rather than as state transitions you can inspect. openOii's bet is that the graph is worth it. For a pipeline with a human review gate in the middle, that bet is reasonable.
Maintenance cost, licence status and the upgrade question
The README states the licence as MIT, but the repository metadata returns no licence, and those two signals disagree. Until that is resolved, do not assume MIT terms apply to the code you copy. That is a factual discrepancy, not legal advice; if you plan to redistribute or build on it commercially, get the licence file confirmed first. On maintenance, the cost profile is typical for a two-sided demo: a Python backend with LangGraph, FastAPI and SQLModel, a TypeScript frontend with React 18 and tldraw, and PostgreSQL plus Redis underneath. Every one of those is an independent upgrade surface, and the absence of releases means upgrades arrive as commits on main rather than as versioned changes you can review in isolation. The practical consequence is that pinning your own lockfiles after the first successful uv sync and pnpm install is the only way to get a reproducible build, because the repository does not offer one. Budget for reading the graph code before you extend it, since the README does not describe node boundaries or the state shape.
Editorial conclusion
Adopt openOii if you want a readable reference for multi-stage LangGraph orchestration with resumable runs and WebSocket progress, and you are willing to read the graph and node code rather than treat it as a product. Do not adopt it as the generation backend for a commercial pipeline: the README states it is not intended for production, there are no releases to pin, and the licence situation needs checking because the README says MIT while the repository metadata returns no licence. Before anything else, run docker-compose up -d, open http://localhost:18765/docs and confirm the run, cancel and feedback endpoints match the graph you intend to copy.
Community notes