What is time-based pricing? Charging by duration, or by when consumption happens
Written by Arnon Shimoni
✓ Expert
Last updated on:
Time-based pricing covers two related things: charging according to how long something is used, and charging different rates depending on when it is used.
The first is old and familiar, from hourly professional services to per-minute telecom billing. The second, peak and off-peak pricing, largely disappeared from software when compute became abundant, and has returned with GPUs.
Field | Detail |
|---|---|
Two forms | Duration-based (how long) and temporal (when) |
Duration examples | Per hour, per minute, per second. See GPU hour |
Temporal examples | Peak and off-peak rates, spot and reserved capacity, seasonal pricing |
Requires | Accurate time metering, and a customer able to shift usage for temporal pricing to work |
Returned to software via | GPU and compute scarcity |
Related |
Duration-based pricing
Charging by elapsed time is the simplest consumption metric there is, which is both its strength and its weakness.
It is easy to verify. Both parties can measure elapsed time, so disputes are rare.
It maps to cost when capacity is reserved. A GPU allocated to one customer is unavailable to another whether or not it is doing useful work.
It does not map to value. An efficient customer completing a task in half the time pays half as much, despite receiving the same outcome.
It penalises your own improvements. If you make the product faster, revenue falls unless the rate changes.
The last point is why time is a poor meter for most software and a reasonable one for reserved infrastructure. Charging per hour for a GPU reflects genuine capacity allocation. Charging per hour for a task rewards you for being slow. See outcome-based pricing for the opposite framing.
Temporal pricing: peak and off-peak
Charging different rates depending on when consumption happens works when three conditions hold: capacity is genuinely constrained at some times, demand varies predictably, and customers can shift when they consume.
Domain | Peak mechanism | Does it work |
|---|---|---|
Electricity | Time-of-use tariffs | Yes. Constrained supply, shiftable demand |
Cloud compute | Spot and preemptible instances | Yes. Real scarcity, batch workloads can wait |
GPU capacity | Spot markets, reserved versus on-demand | Yes, and increasingly important |
SaaS applications | Peak-hour surcharges | No. Capacity is not the constraint, and users cannot shift |
AI inference APIs | Batch versus real-time tiers | Emerging. Batch discounts are the common form |
The SaaS row explains why temporal pricing vanished from software for two decades. When marginal capacity is effectively free, there is nothing to ration.
Why GPUs brought it back
GPU capacity is genuinely scarce, expensive and non-storable. An idle accelerator is lost revenue in exactly the way an empty airline seat is, which restores the conditions temporal pricing needs.
The result is a set of structures software had not needed before: reserved capacity at a lower effective rate, on-demand at a premium, spot or preemptible at a discount with interruption risk, and batch tiers that trade latency for price. See GPU hour and neocloud billing.
Billing for these is harder than billing for a flat rate. Reserved commitments have to be drawn down, interruptions have to be handled without charging for work that was discarded, and a customer running across reserved, on-demand and spot capacity needs an invoice that separates them legibly.
When to use time as a meter
When capacity is reserved. Time genuinely reflects allocation.
When the alternative is unmeasurable. Sometimes duration is the only observable proxy.
Not when speed is your differentiator. You would be pricing against your own roadmap.
Not when the customer controls efficiency. A well-optimised customer pays less for identical value, which inverts the relationship you want.
Consider outcome or unit metering instead. See outcome-based pricing and usage metering.
Where Solvimon fits
Solvimon meters duration-based consumption alongside other units, supports reserved, on-demand and interruptible rate structures, and draws them down against commitments in one contract.
Because the meters and the rates live together, an invoice covering reserved capacity, on-demand overflow and discounted batch usage can present each separately rather than as one blended figure.
Frequently Asked Questions
What is time-based pricing?
Pricing that varies either by how long a service is used, such as per-hour or per-second billing, or by when it is used, such as peak and off-peak rates.
When does charging by time make sense?
When capacity is genuinely reserved, so elapsed time reflects allocation. It makes little sense when the customer controls efficiency, because an optimised customer then pays less for the same outcome.
Why is time a bad meter for most software?
Because it rewards slowness. If you make the product faster, revenue falls unless you raise the rate, which means you are pricing against your own improvements.
Why did peak pricing return to software?
GPU capacity is scarce, expensive and non-storable, which restores the conditions temporal pricing needs. Spot, reserved and on-demand tiers ration capacity the way time-of-use tariffs ration electricity.
What is a batch pricing tier?
A discounted rate for work that can tolerate delay, letting the provider schedule it into spare capacity. It is the AI inference equivalent of off-peak pricing.
What makes time-based billing complicated?
Handling interruptions without charging for discarded work, drawing usage down against reserved commitments, and producing an invoice that separates reserved, on-demand and spot consumption legibly.
Related
GPU hour. The dominant time-based unit in AI infrastructure.
Neocloud billing. Billing models for GPU cloud providers.
Outcome-based pricing. Charging for results rather than duration.
Usage-based pricing. Metering consumption rather than time.
Dynamic pricing optimization. Continuous adjustment based on demand.
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
