Measure what a long export really costs, then price it from the measurement

In plain words

The problem: A 90-minute video has to come out as one file, assembled from chunks. On Google Cloud Run, temporary files count against the memory the container is billed for, so a small program can still run out of room. And exports have to pay for themselves, because an outside assistant can skip the paid planning steps and only export.
What I did: I made total container memory, not the program’s own memory, the measure that decides whether an approach is acceptable, and proved a single-file assembly within that budget. Then I measured how long rendering really takes and repriced from the measurement.
What happened: The 90-minute export peaked at 7.2 GB of container memory behind a 215 MB process. Rendering took 4.2 seconds per output second against 2.78 modelled, so exports over an hour now cost 2.25 times the base rate instead of 1.5.

My contribution

I set the order in which storage options would be tried, made total container memory the acceptance measure, and decided the price change.

An export must produce one downloadable video even when it is rendered in chunks, and on Cloud Run temporary files count against container memory, so a small process can still exhaust the container during assembly. Outside assistants pay HYVIRAL only to execute their edits, in credits, HYVIRAL’s prepaid units, so the export also has to stand on its own economically.

What the assistant sees

The export quote

The agent asks to export
```
video_export({ project_id: "…" })
```
HYVIRAL answers with the terms1
```
"hyviral/quotedCredits": 30,
"hyviral/estimatedWallClockMs": 173960,
"hyviral/availableForDays": 10
```
“The price includes 5 credits for the automatic quality check that runs after the export.”

1Price, quality-check share, render time and retention arrive before any render starts Decision 2

90-minute synthetic staging export9–10 October 2026 · decimal GB

Total container memory peak7.234 GB

Final artifact size6.894 GB

Temporary storage contributes to container memory.

Memory the process reported215 MB

Only one part of the budget.

Memory boundaries shown conceptually, not to scale.

Pinned source chunksOne temporary MP4Sequential upload

A small process can still require a large container budget.

Decision 1

Budget for the whole container, not the program

I chose to prove bounded temporary storage first, keeping the existing rendering fleet, with a disk-backed assembler as the fallback. A cloud-storage mount was not enough, because the MP4 writer has to go back and rewrite the start of the file when it closes it.

The assembler streams chunks from pinned file versions into one temporary MP4, moves the playback index to the front and uploads sequentially into resumable storage, without a second full copy. A guard refuses output estimates above 24 GB: an admission limit, not a guarantee about total memory.

The tradeoff is format-specific code and a temporary file that still grows with duration and bitrate. Later loudness normalisation needs its own budget.

SourceImplementation + staging receipt

The fallback order, the assembler as built, and the receipt from the test run: 215 MB of process memory against a 7.23 GB container peak.

Read the source

Decision 2

Reprice from measured work

The cost model assumed 2.78 seconds of rendering work per second of output. In the 90-minute run on staging, a test copy of production, the median 120-second chunk took about 503 seconds, roughly 4.2 seconds per output second; running chunks in parallel cut the waiting time, not the cost.

That put the estimated export cost at $5.19, against about $4.07 that the Pro plan allocated to it at the original quote of 2,575 credits. On 10 October 2026 I raised the default multiplier for exports above 60 minutes from 1.5 to 2.25, and the same 90-minute quote rose to 3,850 credits; the 1.5 floor stays configurable.

The customer tradeoff is fewer export minutes per credit grant, chosen over unmeasured future savings. The model assumes one download and ten days of retention, so usage patterns can move it.

SourceMeasured task durations + cost model

Measured rendering time (4.2 s per output second against 2.78 modelled), the cost comparison, and the 1.5 to 2.25 repricing decision.

Read the source

Results

A test run on 9 and 10 October assembled a 90-minute, 6.894 GB video in about 627 seconds. The process reported a peak of 215 MB while total container memory peaked at 7.234 GB, including temporary storage. Process memory alone would have been the wrong acceptance measure.

The frame-count check passed and the upload completed. Synthetic footage says nothing about edit quality; that is evaluated separately.

Measured rendering at about 4.2 seconds per output second, against 2.78 modelled, turned a $4.07 revenue allocation against a $5.19 cost into the repricing above.