I finished ten clips in an evening and rendered none of them twice.
Not because the takes were perfect. Because the last third of the job — trimming, reframing, joining, fixing a line that was two seconds short — does not need the model at all. Nine finishing operations run on the file, cost no generation credits, and leave the original intact.
That distinction changed how I plan a shoot. Rendering is for invention; everything after is arithmetic.
The short version. H3 is reachable from the browser, an OpenAI-compatible API, a CLI and an MCP server. Its output drops into nine finishing steps that cost no generation credits.
Which finishing steps cost no credits?
- Resize, crop, format — deliverable dimensions, no re-render.
- Trim — takes that run long.
- Reframe — 16:9 to 9:16 without asking the model again.
- Frame grab — a still for the next shot's reference.
- Audio extract — keep the track the model wrote.
- Audio trim — cut the tail.
- Audio pad — stretch a short line to the clip's length.
- Audio mix — a music bed under the native track.
- Video join — assemble the sequence.
The two I use every session are frame grab and audio pad. Frame grab turns a finished take into the reference for the next one, which is how a sequence keeps its composition. Audio pad stops a spoken line being cut mid-sentence when the clip is shorter than the line — a problem that used to send me back to the model, where it would be solved by luck.
How do you reach the same model four ways?
The same model is reachable from the browser, the HTTP API, the CLI and an agent through the MCP server. Same credits, same task history.
That matters less for convenience than for handoff: I draft in the browser, where I can look at a frame and decide, then re-run the approved brief by script when there are twenty products instead of one.
The API is an ordinary request: model id, prompt, resolution, duration, ratio. Poll the job, download from the signed URL, done.
Why does a network error cost you twice?
A network error on submit is not a failed submit. It is an unknown submit.
If I retry straight away and the first request actually landed, I have paid twice for the same shot. So the client treats an error as "look for the job first" and only resubmits when nothing exists. It has cost me a few seconds of waiting and saved me a duplicate charge twice.
The same logic applies to job states: a completed job with an expired download link needs a new file request, not a new render. They feel identical in a browser and are completely different on a bill.
When not to automate
If the shot is different every week, a script is overhead with extra steps. Automation pays when the same brief repeats with a different product, a different date or a different language — that is when a pipeline stops being engineering for its own sake.
And keep a human on the trigger. An agent can call the endpoint; deciding to spend on a take is still a decision.
The API contract, CLI and MCP setup are documented at the API documentation.
I work on Callirra, so this describes the interfaces we ship, not a reconstruction. If your integration hits a job state I have not listed, that is a documentation bug worth reporting — send the response and I would rather add the state than explain it away.