The same pipeline, with money on the line
An image from Avatars can be paid for in several ways: a subscription, prepaid credits, a local machine's time or a metered key. A clip is paid for one way only. Every clip goes through Ember's Pro Video, which hands it to a vendor model and spends ElevenLabs credits by the second. Those credits are the same pool my voice speaks from, and the account has no top-up.
So the clip workflow reuses what the image studio already does well (subjects, references, the composed prompt, a durable batch of tasks) and adds one thing on top: an explicit split of who decides what. The architecture doc says it in one sentence. Avatars decides who appears and with which files. Ember validates, prices and owns the spending policy. Nothing about a video model is copied into Avatars.
Two kinds of video inside Ember, kept apart
Ember makes video in two ways. Local video runs on the family's own machines and costs nothing per clip. Pro Video calls a vendor and costs credits. Dad ruled on 2026-09-30 (coop todo #282) that the two never mix: a local request never becomes a paid one, a paid request never falls back to a local model, and no automatic route crosses between them. Avatars talks only to the paid side, through its endpoints under /api/v1/api-video.
That ruling changes what auto means. For images, the automatic generator is Ember's walk down its tiers, which the Plan Before You Spend track covers. For a clip, auto (or default, or automatic) resolves to a single name: the default_generator that Ember's video catalog publishes. Ember names its configured preference, Veo 3.1 Fast through ElevenLabs, when that row is ready, and otherwise the first ready generator. When nothing is ready, the plan stops with a 503: No paid video generator is ready in Ember.
The owner table
| Question | Who answers | How |
|---|---|---|
| Who is in the clip, in which look | Avatars | Subjects resolve to their reference profiles, as for an image |
| May this soul depict these subjects | Pippa's policy | Avatars asks Pippa for the whole subject set before it prices a single clip |
| Which files go out, in which role | Avatars | Reference images, or a start and end frame |
| Which generators exist, with which lengths, resolutions and limits | Ember | GET /api-video/options |
| The settled settings and the price of one clip | Ember | POST /api-video/plan, which spends nothing |
| The spending limit and the reserve | Ember | Its own configuration, published as the catalog's policy |
| The total for the whole request, and whether it may run | Avatars | plan_clip() adds up every clip and applies Ember's policy to the sum |
| The vendor call, its journal and the first copy | Ember | Pro Video's jobs and archive |
| A second copy, with its lineage | Avatars | The finished clip becomes an asset with its subjects and references |
Who appears
A clip's subjects work exactly as an image's do. Each named subject brings its default references, a named look such as dad:anime brings that look's images, and explicit references come along too. The architecture doc's advice on the reference itself is modest: a shoulders-up portrait carries the likeness, and the prompt does the rest.
The one difference is frames. Every video model takes either reference images or a start and end frame, never both. When clip.start_frame names an image (the day's thumbnail, say), the plan sends that image with the role first, leaves the subjects' reference images out, and says so in a note shown at review. Identity does not leave with them. Each subject's appearance rules are still appended to the composed prompt, and the test checks that the rule line survives a frame.
The prompt begins with the clip workflow's own template, which Dad can edit in the app: one continuous shot in plain present-tense sentences, every person kept exactly as in the references, and no on-screen text unless the prompt gives the exact words. The aspect ratio is 16:9 unless the request sets one.
Refused before anything is priced
plan_clip() opens with refusals, and each one costs a sentence instead of credits:
- A set or frame names: A clip is not an avatar frame.
- The same generator twice in one request.
- More than four clips in one request (
AVATARS_MAX_CLIP_TASKS), because every clip is paid by the second. - A clip offered as a reference or a frame. References and frames must be images.
- A generator Ember no longer lists, or one that does not take the frame the request gives.
- More reference images than the model declares: Name fewer subjects, or give a start frame instead.
Only then does the plan call Ember's /api-video/plan, once per generator. Ember settles the defaults and refuses, in the model's own words, a length that model does not offer. The image studio's cap is 600 tasks. The clip cap is 4. That gap is the whole story of this track: an image mistake is usually cheap, and a clip mistake never is.
If reference images and first frames are new to you as ideas, the video track of Generative Media Foundations explains them. Here we only care who chooses them.
Why the line sits there
Ember knows models and money. It discovers the vendor's models with their lengths and limits, observes prices after each clip, and holds the only account key. Avatars knows people: which souls exist, what they look like, who may depict whom, and which original every reference came from. If Avatars kept its own copy of Veo's lengths or of a price per second, that copy would be right until the day the vendor changed it, and then quietly wrong. The Ember & Cinder Quest calls this rule the seam: Ember is the catalog authority, and its clients keep no model lists of their own. Clips are where the seam earns its keep, because a stale copy here costs credits.