What the hell is a kilowatt-hour?

Flowzart bills workflow compute in watt-hours (Wh) and kilowatt-hours (kWh). On first read, that’s a strange choice. Watt-hours are the unit on the back of an electricity bill, not something a piece of software hands you when you sign up. So why borrow it?

The energy-meter analogy

Picture a meter on the wall, ticking up while the lights are on, the fridge is humming, and the kettle is boiling. The number it spits out at the end of the month is your kWh. You pay for it because the appliances drew real, physical power.

Flowzart’s billing meter works the same way, just for workflow compute. Every workflow run draws resources (CPU, memory, network bandwidth, storage) and the meter records how much. That total is the Wh on the bill.

It’s still a token system underneath, the same way an electricity charge is ultimately abstract euros. But naming the unit “watt-hour” instead of “credit” or “compute unit” is deliberate. It implies the meter is measuring something physical, something real. Because it is.

What a Wh covers

Specifically, a Wh measures Flowzart-side resource consumption:

• Compute. Each node on the canvas has a watt rating, Wh per second of execution. Bigger workloads, longer runs, more nodes firing in parallel: more Wh.
• Memory. RAM held while a workflow is running. Ten kilobytes doesn’t meaningfully tick the meter. Ten gigabytes does.
• Network. Bytes flowing in and out. Pulling a 50 MB file in, pushing a 200 MB result out: both register.
• Storage. Data retained on Flowzart between runs. A workflow that hoards intermediate results is more expensive than one that cleans up after itself.

If a workflow does work, the meter ticks. If it sits idle, it doesn’t. The Wh number on a bill is the sum of all four.

What a Wh does not cover

This is the important part. Flowzart’s meter only counts Flowzart-side resources. It does not count third-party API costs.

If a workflow calls an LLM provider to summarise a document, the tokens that provider charges for are billed directly by the provider against the user’s own API key (bring-your-own). Flowzart doesn’t see that bill. The same goes for any other third-party destination: webhook endpoints, transactional email services, image generation APIs, the lot. Those services bill the user directly, in whatever unit they prefer.

The split is honest about who’s charging for what. Flowzart charges for the compute it ran on its own infrastructure. Everyone else charges for theirs.

How many runs is one Wh

To make the unit tangible: a typical workflow that calls an LLM once and returns a result consumes roughly 125 watt-seconds of Flowzart-side compute. That’s about 0.0347 Wh, roughly one twenty-fifth of a Wh per run.

So one Wh covers about 25 LLM-using runs. One kWh (the unit that shows up on monthly subscription tiers) covers about 25,000.

Two caveats. First, the 125 Ws figure is a working estimate, not a contract; actual usage varies with how complex the workflow is and how much memory and network it touches. Second, it’s deliberately on the conservative side. Most workflows will run cheaper than the estimate suggests, not more expensive.

The point of the analogy isn’t to give precise per-run pricing in advance. It’s to give a unit that scales with reality. If a workflow feels expensive, it probably is doing more work. If it feels cheap, it probably isn’t.

That’s what the meter is for.