From 6 Hours to 10 Minutes: How We Built a $0.02 AI Film School

Building drama916 for the Qwen Cloud Global AI Hackathon — a pipeline that turns one sentence into a voiced, vertical short film, and the cost lesson that shaped the entire architecture.

Live demo: https://drama916.coralglove.com

Source code: https://github.com/itsbigdill/drama916

---

Type one sentence:

“Avocado and Pear go on vacation, and Pear sunbathes until she turns into a raisin.”

About ten minutes later, you are watching a voiced, captioned, 9:16 short film with a copy-ready social caption.

That is drama916, our entry for the AI Showrunner track. It is powered by Qwen models, deployed on Alibaba Cloud Function Compute, and designed around one simple idea:

Make creative mistakes while they are still cheap to fix.

The finished showcase film cost $7.16 to produce. But the screenplay, shot planning, and three rounds of director critique cost only about $0.02.

That gap shaped almost every technical decision we made.

This is the honest build story: why we moved iteration into text, how we reduced character drift with a series bible, and what broke when we deployed a stateful video-production pipeline to Function Compute.

The receipt that explains the architecture

Every drama916 run creates a cost report at:

runs/<id>/run_report.json

It records the model calls, token usage, generated images, video duration, and calculated cost for that specific film.

Here is the ledger from one of our showcase films, “Gods of the Pitch”: eight shots, 41 seconds, fully voiced.

Stage	Model	Cost
Screenplay	qwen3.7-max	$0.0122
Shot plan	qwen3.7-plus	$0.0022
Critic, 3 rounds	qwen3.7-plus	$0.0066
Cast reference sheets	qwen-image-2.0-pro	$0.12
Storyboard frames	qwen-image-2.0-pro	$0.40
Voice, 8 lines	qwen3-tts-flash	$0.016
Video, 8 clips	happyhorse-1.1-i2v	$6.60
Total		$7.16

Look at the shape of that ledger.

All text-based reasoning stages — screenplay, shot planning, and three rounds of critique — cost about $0.021, or roughly 0.3% of the total run.

Video generation accounted for more than 92%.

The design rule therefore wrote itself:

Iterate where changes are cheap. Render only after the decisions are approved.

Most generative-video workflows do the opposite. They generate a clip, find a problem, adjust the prompt, and generate it again.

Every creative iteration passes through the most expensive stage.

drama916 moves most of that loop into text.

Teaching the showrunner to think first

The pipeline begins with a logline.

1. The screenplay

qwen3.7-max expands the idea into a short screenplay with a beginning, escalation, and payoff.

This is where we keep deeper reasoning enabled. Story structure is one of the few places where spending more tokens can directly improve the result.

2. The shot plan

qwen3.7-plus breaks the screenplay into individual shots.

For every shot, it defines:

• who is present;
• what happens;
• the camera framing;
• the emotional beat;
• the spoken line;
• who says it.

At this stage, everything is still text. We can change the structure without regenerating a single image or video clip.

3. The director-critic loop

A second qwen3.7-plus role acts as the director and critic.

It scores the planned storyboard from 1 to 10 across several dimensions:

• narrative continuity;
• visual clarity;
• pacing;
• character consistency;
• AI renderability.

That last category became especially important.

A shot may sound fine in a screenplay but still be difficult for an image or video model. Common problems include too many characters in one frame, complicated hand interactions, unclear anatomy, or wording likely to trigger moderation.

When the score is below 8, the critic identifies the risky shots, rewrites them, and evaluates the plan again. The loop can run up to three times.

Each critique round costs roughly $0.002.

That is hundreds of times cheaper than regenerating an average video clip from the showcase run, and thousands of times cheaper than rerendering the entire video stage.

This is our token-budget optimization strategy in practice: not simply using fewer tokens, but spending inexpensive reasoning tokens to avoid expensive generation mistakes.

The human approval gate

The AI critic is not the final authority.

Before video generation begins, drama916 creates the full storyboard with qwen-image-2.0-pro and presents it to the user.

The user can:

• redraw a frame with a director’s note;
• change the order of shots;
• remove unnecessary shots;
• review the dialogue;
• approve the final storyboard.

For example, a user can write:

“Make him sit alone on the bench.”

The system does more than repaint the image. A small qwen3.6-flash call updates the shot action and, when necessary, adjusts the spoken line so that the frame, script, dialogue, and captions remain synchronized.

Only after the storyboard is approved does drama916 spend a video credit.

When the user clicks Film it, each approved storyboard frame becomes the literal first frame of a happyhorse-1.1-i2v clip.

The expensive part of production begins only after both the AI critic and the human director have approved the plan.

Keeping characters consistent with a series bible

Character drift is one of the biggest problems in multi-shot generation.

A character can change face, clothes, proportions, or even species between two consecutive shots.

We initially tried solving this with increasingly detailed prompts. It did not work reliably because every agent kept describing the characters slightly differently.

The solution was not a better adjective. It was an ownership rule:

The backend owns every character’s appearance. The models do not redesign it from shot to shot.

The screenplay agent defines each character’s canonical visual description once.

The shot planner is then forbidden from inventing new appearance details. It only returns structure:

• which characters are present;
• what they are doing;
• where they are;
• how the camera sees them.

The backend constructs each image prompt mechanically from:

1. the selected visual style;
2. the canonical character descriptions;
3. the cast reference images;
4. the location;
5. the shot action;
6. the camera framing.

The same character description is inserted verbatim every time that character appears.

We also generate one reference portrait for each member of the cast using the same visual style as the final storyboard. Those references are passed back into frame generation.

This does not eliminate every consistency problem, but it substantially reduces drift across shots.

We also learned an important limitation: visually ambiguous characters remain difficult.

A description such as “a human-like spider with an unclear upper body” gives the model several valid interpretations. It may choose a different one in each frame.

Characters with clear silhouettes, clothing, colors, and anatomy stay much more consistent.

No silent fallbacks

Image moderation occasionally blocks harmless-looking scenes.

Words such as “embrace” can be interpreted more aggressively than expected, depending on the rest of the prompt.

Our early prototype quietly replaced blocked images with nearby frames. That kept the pipeline moving, but it also created a dishonest result: the system appeared to have completed a shot that it had never generated.

We removed that behavior.

A blocked frame now appears in the storyboard as blocked, along with the reason and a Regenerate button. The film cannot proceed until every required frame is actually present.

We added a prompt sanitizer that rewrites ambiguous staging into clearer, G-rated visual language.

For example:

“They embrace emotionally.”

may become:

“They lean their heads together while small heart symbols float above them.”

That resolves many moderation issues without changing the emotional purpose of the scene.

The same principle applies to video output.

A video API request can occasionally return successfully while producing an all-black clip. We added an ffmpeg luma check that detects nearly black outputs, retries once with a sanitized prompt, and reports the failure if the retry is still invalid.

There are retries, but there are no silent fake replacements.

Making dialogue fit the scene

Voice generation introduced another problem.

A video clip might last 5.2 seconds, while the generated dialogue lasts 6.3 seconds. In the first version, the remaining speech continued into the next scene.

The result was technically complete but difficult to follow.

The editor now adjusts the visual duration to match the voice.

It first slows the clip slightly, up to a safe limit that still looks intentional. If the dialogue is longer, the final frame is held until the sentence finishes.

Crossfade timing is then recalculated around the new scene duration.

The films became slightly longer, but the dialogue became dramatically easier to understand.

This also made the generated voice feel less like an audio layer placed on top of unrelated clips and more like part of the actual edit.

Deploying a stateful video pipeline on Function Compute

The backend is intentionally small.

It is one Python service using:

• the standard-library HTTP server;
• an in-memory run state polled by the frontend;
• ffmpeg for editing;
• DashScope APIs for model calls.

Deploying that stateful pipeline to Alibaba Cloud Function Compute taught us several practical lessons.

A ZIP Web Function was simpler for our prototype

Function Compute supports custom containers, but for this hackathon build we chose a ZIP Web Function.

The package includes:

• the Python application;
• vendored manylinux2014_x86_64 dependencies;
• a static ffmpeg binary;
• a bootstrap script;
• seeded showcase assets.

The final package was about 130MB, so we uploaded it through OSS instead of using direct upload.

Cross-version dependency vendoring can fail silently

We prepared dependencies on a Python 3.14 development machine for a Python 3.10 runtime.

pip evaluated environment markers against the build interpreter. Because of that, a compatibility dependency required only below Python 3.11 was skipped during packaging.

The function then crashed during import on the production runtime.

The fix was simple once we found it: pin the required backports explicitly instead of assuming the build machine would resolve dependencies for the target runtime correctly.

The application directory is read-only

The deployed code directory cannot be used for runtime output.

Generated runs therefore live under:

RUNS_DIR=/tmp/runs

The bootstrap process also copies showcase films bundled with the application into the runtime directory.

This works for a prototype, but /tmp is not durable storage. Persisting generated films and reports to OSS is one of the first production improvements we would make.

The default Function Compute domain was not suitable for the public UI

The default *.fcapp.run response forced HTML downloads in our setup because of its security behavior.

We connected a custom domain through Cloudflare instead.

The basic flow was:

1. create the CNAME;
2. verify it with the Cloudflare proxy temporarily disabled;
3. enable the proxy again;
4. use Full SSL mode for HTTPS.

One warm instance protects the active run

The current prototype keeps active run state in memory.

A scale-to-zero recycle during video generation could destroy the state of a run after several dollars of model calls had already been spent.

For the hackathon deployment, we set the minimum instance count to one.

That warm instance acts as the run-state coordinator. It is a deliberate prototype shortcut, not the architecture we would use at scale.

A production version should move run state to a persistent database and generated files to OSS so that any instance can continue the job.

What we would build next

The first priority is durable storage.

Generated films, storyboard frames, cost ledgers, and production metadata should be stored in OSS instead of /tmp.

After that, we would add:

• shareable pages for individual films;
• music and sound-effect generation;
• optional burned-in captions;
• reusable series templates;
• recurring characters across multiple episodes;
• collaborative approval for writers and directors.

The series mode is especially interesting because the series bible already provides the foundation for persistent characters, locations, relationships, and visual rules.

The numbers, one more time

For the showcase run:

• one sentence became a 41-second voiced vertical film;
• the full pipeline took about ten minutes;
• the total compute cost was $7.16;
• screenplay, planning, and critique cost about $0.02;
• video generation accounted for more than 92% of the total;
• every model call was recorded in an itemized run ledger;
• no video credits were spent before the storyboard approval gate.

The pipeline uses six specialized models through Alibaba Cloud Model Studio:

• qwen3.7-max for screenplay writing;
• qwen3.7-plus for shot planning and critique;
• qwen3.6-flash for fast user-directed shot revisions;
• qwen-image-2.0-pro for cast references and storyboard frames;
• qwen3-tts-flash for character voices;
• happyhorse-1.1-i2v for motion.

The final edit is assembled with ffmpeg and served from Alibaba Cloud Function Compute.

Final thought

The most important lesson was not that video generation is expensive. We already knew that.

The important lesson was that an AI system can reason about many video problems before video generation begins.

Continuity, pacing, staging, dialogue, character presence, moderation risk, and renderability can all be reviewed while the project is still text and still images.

The goal is not to remove the human director.

It is to make sure the human director gets control at the point where changes are still cheap.

That is what drama916 is trying to become: not another one-prompt video generator, but a small AI production team that thinks before it spends.

---

Built by a two-person team for the Qwen Cloud Global AI Hackathon, AI Showrunner track.

Try drama916: https://drama916.coralglove.com

View the source: https://github.com/itsbigdill/drama916