Forge: CPM Scheduling for Multi-Model AI Film Generation

The problem Forge targets: N backends, N logins, one timeline

The README opens with a concrete complaint. Producing a multi-scene AI film means logging into Kling, CogVideoX and Seedance separately, downloading frames, color-correcting between models, and stitching by hand. It puts an eight-scene short at roughly half a day of that work. Forge's answer is to treat the film as a compiled artifact rather than a sequence of manual sessions. You supply a story; the tool compiles it into a scene graph, assigns each scene to a backend, executes the graph with a worker pool, and writes a single final.mp4. The intended user is someone who is already comfortable calling several video APIs but has hit the ceiling of doing it by hand. It is not aimed at a single-model workflow, where the routing layer has nothing to route.

Story to DAG: what the compiler actually emits

The mechanism is a two-stage compile. A language model reads the story and produces a dependency graph over scenes; the README names GPT-4o as the default, with Claude and DeepSeek as alternatives selected through the llm.provider key. The example in the README is explicit about the output shape. Running forge plan on examples/detective.txt with six scenes prints a dictionary mapping scene IDs to their dependents: S1 to S2 and S3, S2 to S4, S3 to S5, S4 and S5 to S6, and S6 to nothing. That is a plain adjacency structure, and it is the object the rest of the pipeline reasons about. The same command also prints routing decisions, so each scene is tagged dialogue, action or landscape, and each tag maps to a backend name such as kling_light, kling_heavy or cogvideo. The plan output is the cheapest thing to inspect in the whole tool, and it is the first thing I would run on a real script.

Critical path scheduling and where the speedup comes from

Forge applies the Critical Path Method to the scene graph. It finds the longest dependency chain and prioritizes those scenes; scenes with no blocking predecessors can start immediately, up to the worker count. In the README's six-scene example the critical path is S1, S2, S4, S6, and the quoted estimate is 20 minutes parallel against 30 minutes serial with four workers. The README is direct about the scaling rule: speedup scales with scene independence, and a story where half the scenes are parallel runs roughly twice as fast. That is the honest framing, and it is also the main limitation. CPM cannot create parallelism that the story does not have. A linear narrative where every scene follows the last produces a critical path equal to the whole film, and adding workers changes nothing. The two Gantt diagrams in the README are inconsistent with each other, one labelling the CPM run as 15 minutes and the other as 20; treat both as illustrative rather than measured.

Cross-model continuity is a histogram match, and that is the whole trick

When scene B depends on scene A and the two use different backends, Forge extracts A's final frame, applies histogram color matching to align the color distribution, and passes the corrected frame as the image-to-video seed for B. The README frames this as removing jarring cuts between models with different color profiles and exposure levels. It is a real technique and it is cheap, but it is worth being clear about the boundary. Histogram matching aligns global tone and color statistics. It does not reconcile motion style, camera language, character identity or lighting direction, which are exactly the things that differ most between a Kling clip and a CogVideoX clip. The continuity guarantee is narrower than the phrase cross-model continuity suggests. It also only fires along dependency edges, so two scenes that the compiler placed in parallel branches never get the handoff at all.

Getting it running: install, plan, run, webui

The Quickstart requires Python 3.11 or newer and ffmpeg, with CUDA 12 or newer only if you intend to run CogVideoX locally. Installation is a clone followed by pip install -e ., then copying .env.example to .env. The README notes that no API keys are needed if you pass --backend mock, which gives a full end-to-end run with zero external dependencies. The four commands it lists are forge run with --backend mock and --workers 4, forge run on a multi-backend demo file, forge plan with --scenes 6 to inspect the DAG without generating video, and forge webui to launch a Gradio interface locally. Configuration lives in forge.yaml, and the README states every field is optional and falls back to environment variables and defaults. The visible keys are llm.provider and llm.model, imagegen.provider with mock, openai and flux as values, and routing entries such as dialogue mapped to kling_light. The README's configuration block is truncated mid-file, so the full routing and output schema is not documented in the material available.

Library use and the async surface

Forge exposes its pieces as importable objects rather than only as a CLI. The README's example imports ForgeConfig, VisionCompiler and ForgeScheduler, constructs the config from forge.yaml, builds an LLM provider from it, and awaits compiler.compile with a story string and a scene count. It then constructs the scheduler with a generate_fn, a worker count, and runs it with an asset map and an output directory, receiving results and failed as separate return values. The failed list is the interesting part: the API is designed around partial failure rather than all-or-nothing execution, which matches the reality of calling several third-party video backends. What the README does not show is the signature of generate_fn or the shape of asset_map, so anyone embedding Forge will be reading source to wire those up.

Where Forge is the wrong tool

Three cases stand out. The first is a film with a genuinely linear dependency chain. If every scene needs the previous one, the DAG is a path, the critical path equals the total runtime, and the parallel scheduler adds configuration surface without adding throughput. The second is a project that needs continuity stronger than tone matching: recurring characters, consistent camera grammar, or a single unbroken take. The last-frame seed plus histogram match will not hold those together. The third is an environment with neither API keys nor a CUDA host; the mock backend is useful for exercising the pipeline, but it generates no real video, so it validates the scheduler and not the output. There is also no release history in the material, and the version badge reads 0.1.0, so the API surface should be treated as unsettled.

Alternatives and the actual difference in approach

The obvious comparison is a general workflow orchestrator such as ComfyUI, or a hand-rolled script that loops over scenes and calls each backend in turn. The difference is where the intelligence sits. A sequential script has no representation of the story at all; it processes scenes in the order you wrote them, and any parallelism you want, you encode yourself. ComfyUI gives you a node graph you author by hand, which is expressive but static: the graph is the same every run, and the ordering is whatever you drew. Forge derives the graph from the story text at runtime, which is what makes routing and CPM scheduling possible without you specifying either. The trade is control. In a hand-authored graph you decide exactly what depends on what. In Forge the LLM decides, and the README does not describe the prompt or the validation applied to the returned structure, so a misread scene boundary becomes a scheduling decision you did not make.

Licence, maintenance and what to verify before committing

Forge is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained; this is a description of the licence terms, not legal advice, and you should read the LICENSE file for the binding text. The practical maintenance question is dependency drift. Forge sits on top of three named commercial or local video backends plus an LLM provider, and each of those can change its API independently of this repository. The repository has no releases retrieved in the material, the version is 0.1.0, and the last push is recent, so the project is early and active rather than stable. The concrete first step is to run forge plan against your own script and read the printed DAG and routing table before you spend anything on generation. That output tells you whether your story has the independence the scheduler needs, which backends the compiler chose for you, and how long the critical path is. If the DAG comes back as a single chain, the parallel machinery is doing nothing for you.

Editorial conclusion

Forge fits teams already juggling two or more video backends who want the orchestration and the cross-model color handoff handled in one Python package, and who can accept that the speedup is a function of their scene graph rather than a fixed multiplier. It is the wrong choice if your film is a single continuous shot, if you have no API keys and no CUDA host for the local CogVideoX path, or if your continuity needs exceed a histogram match on the previous scene's last frame. Before adopting, run forge plan on your own script and read the printed DAG, because the dependency structure it infers is the thing everything else is priced against, and the README does not say how the compiler decides which scenes depend on which.

Official sources

1. F-R-L/forge-film on GitHub
2. Issues
3. License: MIT
4. README