The Routing Table Reads By Task

The routing table is read by task rather than by vendor, and it holds 9 rows. Each row carries 3 things: the model to run, the fallback if that model is unavailable, and the verdict from the test that settled it. Uncensored body and dance work at 4 to 30 seconds runs on 1 renderer, which holds the longest image-conditioned path in the table at 30 seconds. The identity anchor still runs on a 2K reference-guided model at 16:9, with a hosted subscription model as the fallback. Face plus lip-sync runs on the 1 renderer that holds face identity and syncs audio, and there is no fallback for it because there is no second renderer that does it. A 10 second image-conditioned cinematic at 768P runs on a model whose quota is already paid monthly. A 15 second subject-to-video shot on a named character runs on another model in the same family. A dialogue beat with synced speech runs on a distilled model at about 0.175 dollars a run. Long high-resolution work at 15 seconds or more and 2K runs on a credit-metered tier of that family, with a 30 second path as the fallback. The cheap fully-automated pipeline runs on a closed API at about 10 euros an output. It carries no adapters and the output is flat, which is a grading problem rather than a routing one. The last row is the shortest and it is the one that saved the most money: 2 model families are marked never use. Both were retired in favour of the rows above them. Read by vendor, this is a shopping list of 9 names. Read by task, it is a production plan with 1 run and 1 fallback per job, and the verdict column is what stops the list from drifting.

The production renderer runs still first. The still is locked, then it is animated with the still's own URL as the first-frame input. That order is not a preference. A wrong still burned into video costs the video, and 0 video credits are spent on a still that has not passed. Its auth is HMAC-SHA256: a signature over the secret plus a nonce, sent with an API-key header, a nonce header and a signature header. A browser User-Agent is required as well. Leave it off and the edge answers 403 with code 1010 before the request ever reaches the renderer. The number 1 failure is not sexual-content moderation. It is a deepfake guard that runs on the first-frame still, and it rejects a readable face with a real-human-detected refusal while explicit content renders clean. The fix is framing rather than wording: silhouette, from behind, neck down, or in shadow, and never name facial features in the prompt, because naming them invites the guard and the drift at the same time. 2 balance codes decide the shape of a shoot day. 97 is an insufficient balance and a hard stop, which means the balance is checked before a multi-shot run rather than during it. 96 is a concurrent task limit, which means wait 30 seconds or run 1 task at a time. The image parameters are set explicitly because the default is wrong: 2K resolution, 16:9 aspect rather than the 1:1 default, JPEG output, watermark off, and up to 10 reference images. The video parameters are 720p, 16:9, a duration between 4 and 30 seconds, audio generation off, and the first-frame image. There is no separate negative field, so the negative block is appended to the prompt tail as an avoid clause on every render.

1 family of models sits on a coding plan that is already paid for: a language model, an image model, speech, and video share 1 quota of about 5.1 billion tokens a month that renews on 2026-09-28. Because the monthly is fixed, the next render on that plan costs nothing at the margin. That single fact decides the routing for high-volume work: use the plan for the shots that need taking, and reserve the metered specialists for the shots that need winning. The image-conditioned video model on that plan does 6 or 10 seconds, at 768P or 1080P, and the case of the resolution string matters: 768P is accepted and 768p errors. There is no 10 second combination at 1080P, so the longest free shot is 10 seconds at 1364 by 768 at 24 frames a second, verified on the plan key. The image-to-video input has to be a public URL. The longer tier of the same family does 15 seconds at 2K, but it is gated behind a plan check and returns a does-not-support error code of 2013 on the coding key. It lives on metered credits, so it is a paid row and it is treated as one. The subject-to-video model accepts 15 seconds and needs a clear character or face subject. A faceless back-view submission returns an unexpected error rather than a render, so the row only applies to shots with a subject in them. The whole family runs the same 3 endpoints: submit, poll, download. That shape is why it holds the high-volume rows: 1 submit, 1 poll loop, 1 download, and the cost of the next one is 0 dollars at the margin.

Face plus lip-sync is 1 row with 1 model in it, because exactly 1 renderer on the list holds face identity across a moving frame and syncs audio to it. Everything else either drifts the face or mutes it. That renderer is reached over OAuth rather than an API key, which changes the shape of the pipeline: there is no key to store, no balance code to read and no HMAC signature to build, and the tools arrive as a connected service rather than an HTTP endpoint. Its default stack is 3 parts: 1 model for stills, 1 for video and the identity-aware model for lip-sync. The stills model is the normal-shot default and the video default is a model from the same family that failed the ethnicity test elsewhere in this table, which is a good illustration of the rule rather than an exception to it: a model can be the right choice for 1 task and the wrong choice for another, and the routing table records the task, not the model. The practical consequence is a 2 stage shoot. The stills and the video run on the stacked defaults, and any shot where a face has to speak is routed to the identity-aware model, because it is the only place in the table where that shot can be finished at all.

A routing table read by vendor is a shopping list. Read by task, it is a production plan.

2 model families are marked never use, and both got there the same way: recommended first, tested second. The first had the worst fidelity of the 3 renderers in a shoot that put b-roll shots b01 through b20 through all 3 side by side. Every 1 of those 20 frames came back with the same loss of realism, so the model was retired as a renderer and kept for 1 narrow job, reading an image and gating it. It still has quirks worth recording: 1 string blocks, another passes, the poll route is not the generations route, and the returned URLs are ephemeral, which means the download has to happen in the same session as the render. The second was retired on 2 failures rather than 1. An unspecified ethnicity defaults to the training majority, so an unlabelled child came back clearly from the wrong region, and the phrase photorealistic combined with a blanket cinematic produces a glossy, uncanny, obviously synthetic look. Both failures are prompt-shaped, which is why the language rule now reads documentary film, 35mm, natural skin texture, visible pores, unretouched, natural light, and why photorealistic and blanket cinematic are treated as traps on every model in the table. 1 more model is not retired but is bounded, and the boundary is the most useful line in the file. A distilled 4-forward dialogue model returns video and synced audio from 1 prompt at about 0.175 dollars a run, with 15 seconds native at 345 frames and 24 frames a second, fixed 16:9, at 480P or 768P only. It is text-to-audio-video with no image conditioning and no reference input, so identity does not carry across generations: the same seed and a byte-identical identity block hold the scene at roughly 85 to 90 percent, the same room and light and archetype, while the face and the clothing still drift. That is a scene lock, not a character lock. The fix that makes it usable is a framing lock rather than a better prompt: a byte-identical identity block, a fixed seed and locked framing turn it into a shot and reverse-shot tool with 1 actor across takes. The gate did not accept a character lock. It accepted framing.

The table is not a document that gets written once. It is rebuilt every morning at 6 am from live probes, because the parts that age are the limits rather than the names: a plan that renews, a quota that is spent, a model that gets gated, a balance that runs out. Every model is scored 1 to 5 on 7 axes: fidelity, consistency, control, cost, speed, availability and whether it can render the shot at all. The axes are weighted per task type rather than averaged globally. For video the weighting is 30 on fidelity, 25 on consistency, 20 on control, 10 on cost, 10 on speed and 5 on uncensored, which is the arithmetic behind every row in the table: the production renderer wins the rows where consistency and control carry the weight, and the plan model wins the rows where the marginal cost is 0 dollars. 3 rules close the loop. A routing decision changes only when a new model beats the incumbent on a live render or an API test, never on an announcement. Every row records the run, the fallback and the verdict, so the next person to read it inherits the test rather than the opinion. And a model is retired on a render that fails the gate, not on a bad first impression. The same discipline built companies across twelve countries: it restructured a EUR 75 million industrial group, deployed 210 energy systems across Africa and Asia, and built 200 wood-gasification machines across the UK and Europe. 1 pattern holds in all of it. Measure the tool on the job it will do, write the numbers down, and let the table decide. 9 rows, 1 run and 1 fallback each, 7 axes behind every verdict. A model list is not a loyalty. It is a set of measured limits, and the table is the only part of the stack that gets cheaper every time it is rebuilt. The probability that a model recommended by a press release survives its own test render sits near 1 in 10. The probability that a change carrying a number from a live probe survives sits near 9 in 10. That gap is the whole argument for rebuilding the table every morning instead of trusting it once.