Same Source, Two Cost Curves: Local Preview vs GPU Final

Every video tool eventually grows two buttons that mean different economic things: Preview and Export.

In timeline editors those buttons often hide divergent engines. Preview cheats. Export reinterprets. Someone notices during brand review when the fade is denser, the font thicker, the color a half-step off.

Programmable video only works if that divergence is a controlled contract, not an accident. At SceneRok, VidScript and @scenerok/sdk compile to one intermediate timeline. Local-style preview and GPU final are two executions of that same source — with different cost curves.

This post is about designing that split on purpose.

Cost curves, not vibes

Think in curves, not in absolutes.

Preview curve: optimize for iteration count. Agents and humans will hit this path dozens of times while chasing timing. Marginal cost per attempt should feel closer to "save file" than "order a render farm."

Final curve: optimize for delivery honesty. You pay more per run because pixels, codecs, and generative pins matter. You should run it when intent is stable — or when you need a client-facing proof.

If both paths cost like final, people stop exploring. If both paths cheap out like preview, people ship sketches. Hybrid execution is the name for keeping one source while admitting two budgets.

What must stay identical

Samness is not "bit-identical frames in preview." Sameness is semantic agreement:

• Timing: a cut at 3.0s is at 3.0s in both paths.
• Layering: z-order and occupancy match.
• Generative pins: the asset you resolved at compile is the asset both paths use unless you explicitly re-roll.
• Brand rules: safe zones and lockups cannot "approximately" apply.

Where paths may diverge — and should say so — is fidelity class: resolution proxies, shader precision, color management edge cases, encode ladder. Preview can be representative. Final is authoritative. Say that in the product UI, not only in an engineering wiki.

Where money actually goes (qualitative)

Without publishing a fake invoice:

1. Authoring — cheap. Text edits. Agent rewrites.
2. Compile / generative resolves — variable. Model calls dominate when you invent new footage, VO, or music. Pin aggressively once you like a take.
3. Preview composition — should be the bargain bin relative to final: enough fidelity to trust timing.
4. Final composition + encode — the bill you accept when shipping.

A common failure mode in AI video stacks: every scrub silently re-rolls a model. That couples the preview curve to the generative curve and bankrupts curiosity. Keep generative resolution explicit and mostly compile-time, then let preview/final reuse artifacts.

Local preview as a product promise

"Local" here means close to the creator loop — editor-adjacent, low ceremony — not a claim about which chassis runs which binary.

The promise:

• Fast enough to keep flow state.
• Faithful enough that timing decisions survive final.
• Failure modes that explain scene problems vs machine problems.

The anti-promise:

• Silent fallback from accelerated paths to software paths without labeling the delivery class.
• Preview that invents different assets than final.
• A preview that can only run on a heroic laptop configuration.

If you also offer browser-class frame capture for some workloads (see the pool essay), apply the same contract language: lease intent is preview or final; SLOs differ; source does not.

GPU final as a delivery class

Final is where you spend for honesty: stable drivers, predictable color, encode settings you would show a client, headroom for heavy shaders and long timelines.

Patterns:

• Queue finals; interactive-ize previews. Do not block the editor thread on a master encode.
• Idempotent finals. Same pinned inputs + same source revision → safe to retry after infra blips without creative drift.
• Artifact permanence. Keep the compile outputs you paid for. Re-encode should not imply re-imagine.
• Clear progress. Users forgive duration; they do not forgive opaque spinners.

You do not need to name your GPU vendor in a blog post to teach this. You need to teach teams to stop treating export as a surprise boss fight.

Agents change the shape of the curves

Coding agents do not get bored. They will preview in a loop. That is wonderful for product velocity and dangerous for an uncached generative bill.

Design for agents explicitly:

• Validate and preview against pinned assets by default.
• Require an intentional action to re-resolve stochastic functions.
• Prefer patching parameters in source over regenerating the universe.
• Emit compile diagnostics agents can read — duration conflicts, missing inputs — so they fix structure before they burn finals.

Humans need the same defaults. Agents just hit the foot-gun faster.

A practical decision table

Situation	Prefer
Nailing VO against B-roll timing	Preview, pinned assets
Trying three alternate model prompts	Re-resolve only those slots, then preview
Client review / ad upload / launch	Final
Suspected preview/final mismatch	Pixel-compare offline; fix engine agreement; do not "nudge" the timeline by eye forever
CI / PR checks on templates	Validate + cheap preview class, not full final

Caching without self-delusion

Hybrid stacks live or die on caches. The wrong cache key couples unrelated work; the right one makes preview feel free.

Useful keying ideas (conceptual — not our internal schema):

• Source revision of the timeline program.
• Resolved asset set (pins), not the prompt text alone.
• Delivery class (preview vs final) so a cheap proxy never masquerades as a master.
• Capability class (accelerated vs software) so you do not "hit cache" across incompatible paint paths.

Invalidate on purpose when the user re-rolls a slot. Do not invalidate the universe because one text overlay moved. Composition caches and generative caches should be layered: moving a title should not re-invoice an imagine call.

Measuring the curves without fake dashboards

You do not need vanity charts in a blog. You do need internal honesty:

• How many preview iterations per final?
• What fraction of finals re-used compile artifacts vs re-resolved models?
• How often do users complain about preview/final mismatch?

If iterations-per-final is ~1, your preview path is too expensive or too untrustworthy. If mismatch complaints are non-zero, fix agreement before you buy more GPUs. Hardware cannot patch a semantic fork.

Team workflow that respects the curves

A pattern that works for small teams and agencies:

1. Author in VidScript/SDK from a brief.
2. Resolve generative slots deliberately; pin keepers.
3. Preview until timing and copy land.
4. One final for stakeholder review.
5. Parameterize variants (aspect ratio, CTA, locale) from the same source — prefer re-compose over re-imagine.

Agents fit between steps 1–3 if you give them validate/preview tools. Humans still own taste at the pin boundary. That division of labor is the point of programmable video.

Closing

Same source, two cost curves is how programmable video stays both playable and shippable.

Fork the engine accidentally and you recreate the old NLE tax. Fuse the costs accidentally and you recreate the AI-bill tax. Hold the line: one VidScript/SDK truth, explicit generative pins, preview for learning, final for delivery.

Feel it in the product at scenerok.com. Spend curiosity on structure. Spend credits on purpose.