Bring your own hourly costs and load. This finds the best time-of-use rate for them, tests how complex it should be, estimates what it’s worth, and checks whether it holds up from year to year.
Your file stays on your computer. It’s read in this browser tab, and nothing is uploaded, saved, or sent anywhere. Closing the tab clears it.
What the file needs
Cost
The cost of each hour, in $/MWh, $/kWh, or ¢/kWh. This is what the rate tries to follow.
Load
The customer load in each hour, in any unit. Only its shape matters, since the dollar results are scaled to a household.
Time
A timestamp, or separate month and hour columns. Add a year column to compare years.
It needs at least a full year, so that every month and hour is covered. Two or more full years unlock the year-to-year test. Costs are taken as local time, exactly as written.
What’s in the file
The top 1% of hours hold of the squared gap between cost and a flat price. The more of that gap sits in scattered extreme hours, the less any fixed schedule can capture.
Every hour, sorted from most to least expensive
Design a rate
The analysis starts from the shape BIC prefers on your data. Change anything here and every result below follows.
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.
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
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
Reading these results
It fits cost. It doesn’t model behavior.
Customer response isn’t inside the optimizer. The welfare figures are a first-order estimate laid on top of a curve fit, and they scale directly with the elasticity.
It takes your cost stack as given.
The answer depends on what’s in your cost column. Allocating capacity or distribution cost to hours differently will give you a different rate.
These are marginal-cost prices, not a tariff.
A real rate also has to recover the rest of the revenue requirement. There’s no weekday and weekend split here, and no bill-impact analysis.
Past data sets a future price.
A rate fit on your file describes those years. If you have more than one, the durability section shows how far the answer moves between them.
The method is explained on the method tab and in the working paper.