Building an AI video tool: the two clocks behind “fast”

I’m building FreyaVideo. We’ve just published three source-based guides about AI video models, and one product question kept coming up: which part of the wait does a speed claim actually describe?

This is a build note about that distinction, plus a blank comparison worksheet other founders can reuse. It isn’t a benchmark. We haven’t run a matched H3 Max/Kling/Veo experiment for these guides.

The two clocks I want to keep separate

Submission to first playable preview is the interactive clock. A customer presses Generate and eventually sees a video they can play. Uploading an input, waiting in a queue, server-side prompt processing, generation and delivery may all contribute to that wait. Their order and overlap depend on the service.

Brief to accepted clip is the production clock. It includes reviewing the preview, rejecting a take, changing the prompt and trying again. A quick preview that misses the brief hasn’t finished the customer’s job.

Backend inference is useful diagnostic information, but it belongs in its own column. For example, fal’s H3 Max API defines its reported inference timing as GPU denoising; some routes do not expose that timing. I wouldn’t relabel that value “your video was ready in X seconds.” A provider metric and the customer’s stopwatch can both be accurate while measuring different things.

That distinction is the starting point of our guide to choosing a fast AI video workflow. It shortlists candidates from official capabilities and explains the missing evidence instead of presenting an unmeasured speed leaderboard.

A small experiment before changing a default

Here’s the proposed worksheet. It’s deliberately empty: no numbers below are claimed results.

• Brief and acceptance rule: What must stay correct for this clip to be usable?
• Exact model route: Include the version and tier, not just a family name.
• Inputs and settings: Source image, prompt, duration, resolution and audio requirement.
• Attempt number and submission time: Record every paid attempt, including failures.
• First playable preview and elapsed wait: Use one client-side clock within the same page session for the elapsed measurement; don’t subtract timestamps from unsynchronized machines or raw performance.now() values from different page loads.
• Provider inference time: Record it only when exposed, with the provider’s definition.
• Outcome: Accepted, rejected, failed or still unfinished, plus a short reason.
• Charged cost and revision time: Include the attempts that didn’t produce a keeper.

For a first pass, I’d use one short product shot, a fixed attempt budget and the same acceptance checklist. Alternate the candidate routes rather than testing one only during a quiet period and another only during a busy period. If resolutions differ, record that difference instead of calling the workloads identical.

Then report the completed waits alongside the acceptance count, failures and unfinished requests. With a tiny sample, even the median is only a local observation. It can help choose the next experiment; it can’t establish a universal winner.

Price needs the same discipline

A per-second price doesn’t tell me the cost of an accepted clip. My proposed worksheet calculation is:

Cost per accepted clip = total charged cost of all attempts / number of accepted clips.

If none are accepted, report “no usable clip,” not zero cost. If a provider refunds a failed attempt, use the actual charge rather than assuming every failure is billable.

Model names need equal care. Our H3 Max vs Kling comparison is specifically about H3 Max and Kling 3.0 Standard on fal. It isn’t a comparison of every Kling tier, website subscription or reseller. Promotions also need a date; I don’t want a temporary discount silently becoming a permanent unit-economics assumption.

What we can publish before we have measurements

There’s still value in documenting supported inputs, published controls and a sensible starting brief. The boundary is to label those as documentation and recommendations, then leave measured performance unclaimed.

Our H3 Max first-shot tutorial follows that approach: a starting workflow and review checklist, not a claim that we generated its illustrative images with H3 Max or proved a quality advantage.

For the product, my decision rule would be: shortlist from documentation, test the actual task, then consider changing the default. A cheaper or faster advertised route is a reason to investigate, not sufficient evidence to switch everyone.

For founders building around model APIs: what acceptance rule would you add to the worksheet before letting a latency result influence your default model?

Disclosure: I build FreyaVideo, and the three linked guides are ours. This note was prepared with AI assistance. It contains a proposed experiment, not reported benchmark results.