How to Calculate Real Cost Per Frame Before You Hit Render

“How do I work out what a render actually costs me, so I can quote a client and decide whether to render at home or in the cloud?”

This is the most useful number in your whole pipeline, and almost no one works it out. Cost per frame is what turns a vague feeling that renting is expensive, or that your machine is free, into a figure you can compare and put in a quote. The formula is short, the inputs are things you already know, and once you have run it once you will never guess again. Let me walk you through it for both your own machine and the cloud, including the costs people quietly leave out.

Cost per frame = render time per frame (in hours) × cost per hour of the machine.

For your own machine, cost per hour = electricity + amortized hardware + the value of work time you lose while it renders.
For the cloud, cost per hour = the GPU rate, minus any bonus or credit, plus a small share of boot, upload, and setup spread across all frames.

The input people always forget

The number that flips most of these calculations is the value of your own time while the machine is busy. When a render owns your only workstation for hours, you are not modeling the next shot or taking other work, and for a freelancer that is real income on hold. Put an hourly figure on your work time and add it to your own-machine cost per hour, because leaving it out is exactly how people convince themselves their machine renders for free. Once that line is in, a “free” home render often costs more per frame than it first looked.

The hardware share matters too, and people tend to skip it. Take what you paid for the card and the build, divide by a realistic number of useful hours over its life, and you get a per-hour cost that is small but never zero. It is the slow drip of the machine wearing out and dating, spread across every frame it renders.

How do I calculate the cloud side fairly?

For the cloud, start with the raw rate times your render hours, then make two honest adjustments. Subtract any deposit bonus and credit back you earn, since those genuinely lower what you pay. Then add a small overhead for the parts of a session that are not rendering: the server booting, your scene uploading, and the first setup. Spread that overhead across all the frames in the job, because on a 240 frame sequence a few minutes of boot and upload barely moves the per-frame number, while on a single frame it matters a lot.

This is why cost per frame favors the cloud more on big jobs than tiny ones. The fixed overhead dilutes across many frames, and a strong card renders each frame quickly, so the rate you pay buys a lot of finished images. On a one-off single frame, the overhead is a bigger slice and the comparison tightens.

Putting it to work, and where iRender fits

Run the formula for a real job and the number does the arguing for you. When I priced a recent 240 frame sequence and added my own lost work time, the per-frame figure came out well above the “my machine is free” assumption I had been carrying, and it changed how I quoted the job. The formula does not by itself decide between rendering at home or in the cloud, since that also turns on how steady your render load is, and I walk through that decision in the separate guide on when rendering locally is actually cheaper than the cloud. Cost per frame is the input you bring to that call. With iRender you rent a full RTX 4090 with 256GB of system RAM and set it up as your own, so your render times and results match what you measured locally and your estimate holds, which is what “your renders, your rules” means in practice. Fold one line into the cloud side of the sum: billing starts at boot rather than first frame, and an idle machine keeps charging, so include that overhead and use auto-shutdown to keep it small. For pure batch with no setup, a SaaS render farm prices per frame directly, which plugs into the same formula.