An interactive · time-of-use rate design

Rate Designer

A time-of-use rate takes a year of constantly moving electricity costs and reduces it to a handful of prices. Someone has to decide where the lines go: which months count as summer, when the peak starts, how many periods are worth the confusion. Usually that’s a judgment call.

In 2020 I wrote a paper arguing it could be an optimization problem instead. This is the rebuilt version. It finds the provably best rate for any shape, runs entirely in your browser, and shows its work. To run it on your own costs and load, open Your data.

Southern California Edison’s marginal cost of serving a residential customer, 2018–2019. Each cell averages one hour of the day in one month; darker is more expensive. Switch to the rate to see what the optimizer does with it.
I

How it works

The search sounds enormous, but the problem has a structure that makes it small. There are four steps.

Step 1

Reduce the year to a grid

A rate can only see the month and the hour, so two hours in the same cell will always be charged the same price. The optimizer never needs the individual hours again. It adds them up once into 288 cells, keeping just enough totals in each to score any grouping of cells instantly.

The tail is what makes the problem interesting: hours () cost more than $500/MWh, and the worst reached , nearly all of it capacity cost. The top 1% of hours hold of the squared gap between cost and a flat price, and they’re scattered too widely for any fixed schedule to isolate.

Every hour, sorted from most to least expensive

Step 2

Solve each season on its own

Once a run of months is treated as a season, the best hours for its peak have nothing to do with any other season. So the optimizer takes each possible run of months and tries every way of cutting the day, keeping the one with the smallest error. Error here is the squared gap between each hour’s cost and the price it would be charged, weighted by load.

This is one of possible seasons. Each is solved once and remembered.

Step 3

Try every way of combining seasons

Choosing the seasons is now just a lookup: pick the split, add up the remembered answers. With two seasons of at least three months each, there are only splits, and every one is on this grid. Darker removes more error. Select one to see its rate.

Every two-season split

Step 4

Set the prices

Each bin’s price is the load-weighted average of the costs inside it, so the rate collects exactly what it costs to serve that load, bin by bin.

pbin = Σ ct Qt ∕ Σ Qt

Nothing was sampled along the way. Every feasible rate was scored, so the winner is the global best. The 2020 version used a random-restart hill climber that reached this answer in only 19% of trials. This one scored all ways of cutting the day across those seasons in , on your device.

The best rate here removes only of a flat rate’s squared error, because so much of it sits in that scattered tail. That doesn’t make the rate worth 4% of anything, which is why section V measures value separately.

II

Try to beat it

Here’s a rate a person might draw, in the shape of many California residential rates: summer from June through September, with a 4-to-9 pm peak all year. Select a month label to start or remove a season, and any cell to start or remove a period at that hour. See how close you can get.

III

Design a rate

Set the shape and the rules. Everything below this point follows these settings. To run all of this on your own costs and load, use the Your data tab.

The rate against the cost it approximates

Load-weighted cost by hour Rate
IV

How complicated should it be?

More prices always fit better, but each is one more thing a customer has to remember. The Akaike and Bayesian information criteria charge for that added complexity, and BIC charges more.

Every shape up to three seasons and three periods. Select one to load it.

V

What is it worth?

Fit isn’t value. When a rate moves a price away from a flat rate, customers use more or less, and each kilowatt-hour they move gains or loses the gap between what it costs and what they valued it at. With demand that responds in a straight line, an hour’s gain over a flat price is:

ΔWt = ΔQt ( ½(pflat + p) − ct ),   ΔQt = ε Qt (p − pflat) ∕ pflat

The comparison is with a flat rate, not with perfect marginal-cost pricing, because it only asks about prices customers would actually see. A straight line holds for modest price changes but not huge ones, so the response limit stops load from moving more than a set share in any hour. A time-of-use rate rarely reaches it. It matters for critical-peak pricing, where customers see the full cost of the most expensive hours.

Gain over a flat rate, per household per year

A critical-peak program goes after the expensive hours directly. Here, for the chosen number of hours in each season of each year, the customer pays true cost. That’s perfect foresight and a perfect price signal, so read these figures as an upper bound.

Added value of critical-peak hours on top of the rate, by how far load can fall

VI

Will it hold up next year?

Rates get set on past data and charged on future costs. So fit the same shape to each year separately, then charge it in every year.

Revenue collected as a share of true cost

VII

What this doesn’t do

The method is laid out in the working paper. Costs are Southern California Edison’s total marginal cost, paired with its residential domestic small and medium load profile.