Agile pricing explained

For a recent example, prices dropped to -10.08p/kWh at 3am on the 3rd Jan 2022, and -4.63p/kWh at 3pm on the 11th Jan 2022.

But Agile has never never been done before, and that’s because of the complexities involved in energy pricing. We’ve broken down the pricing model below.

‘Agile’ pricing

We wanted to:

1. Keep energy transparent by reflecting the complete cost-breakdown involved
2. Make Agile simple for customer useability

Balancing these two key things, an example Agile price algorithm is:

In this equation,

• D is a coefficient that includes our distribution costs, which varies based on where you are in Britain;
• W is the wholesale cost of electricity for that period in pence per kilowatt-hour (p/kWh);
• P is the peak-time premium, which ranges from 11 - 14 based on where you are, and is only applied between 4pm and 7pm.
• 95 is chosen to ensure the price is capped at 100p/kWh once VAT is added.

In this example…

The Agile price is 2.2 times the wholesale price of energy and between 4.00pm and 7.00pm an additional 12p / kWh is included (but capped at 100p / kWh, come what may).

There’re a few common questions this often prompts:

Why is there a penalty at the peak period? Why is there a 100p cap? How well does Agile reflect renewable supply?

To understand that, we need to look at what makes up our costs.

These are surprisingly complex and made up of a range of variables...

1. Wholesale – the wholesale price of energy can vary heaps, ranging from low negative numbers (when generation is really high, and demand is low) to over 200 p/kWh. Before the energy crisis, it was around 5 p/kWh overnight and 9 p/kWh at peak, in the current market conditions, it is around 22 p/kWh overnight and 36 p/kWh at peak.
2. Transmission costs (TNUoS) – this depends on your region but can range from 4p/kWh to 9p/kWh and is only applicable for usage in peak periods (4-7pm). It’s more expensive in the South, generally, because of the North-to-South transmission direction (i.e. there’s more energy generation in the North and demand in the South).
3. Balancing costs (BSUoS) – typically around 1 p/kWh and is quite volatile. More expensive at night when the scarcity of demand and generation on the grid means more balancing actions are required (this is probably a gross simplification for anyone who’s worked in the National Grid control room).
4. Distribution costs (DUoS) – these are priced in blocks, and generally around 5-16p / kWh in peak and close to zero off-peak. For a non-half-hourly (standard, single rate) tariff, there’s a flat distribution rate.
5. Capacity Market – can work out at around 5-10p/kWh for winter peak usage (4-7pm weekdays between Nov and Feb) and varies by region.
6. Renewable Obligations – flat fee of around 2.6 p/kWh.
7. Feed-in Tariff – flat fee of less than 1 p/kWh.
8. Contract for Difference – varies daily before the energy crisis it was typically around 3-5p/kWh, but in the current market conditions it is around -0.8p/kWh due to high wholesale prices.

To revisit the question – why is there a penalty at the peak 4-7pm period?

If you add up the peak costs outlined above that we have to pay (TNUoS, DUoS, and Capacity market) it’s actually higher than 12 pence. Although in part this is compensated for by the 2.20 multiplier. The challenge for us is deciding that multiplication factor for the whole day and the additive element to cover the peak period extra costs we have to pay.

Why is Agile’s unit rate capped at 100p / kWh?

The Ofgem price cap for standard variable tariffs is currently at 52p /kWh, so a 100p cap may sound high in comparison. BUT: our wholesale costs can exceed 200p / kWh in peak periods. If we exposed the full peak wholesale cost in Agile’s pricing, the peak rates would get totally extortionate for a domestic customer.

A completely flat rate tariff aims to average out the whole day variability of all the different charges, but with Agile we can’t do that. To avoid issues we set a cap at 100p / kWh.

What else could we have factored in?

There are a few elements that aren’t reflected in Agile’s pricing, for the sake of simplicity, like the regional difference in transportation costs (TNUoS) and seasonal difference between winter and summer.

These factors – particularly regional variation – we may work into Agile’s pricing as we learn more from customers and refine the algorithm.

This really illustrates the challenge with a tariff like this (and why no one’s had the resource or wherewithal to try it before now) – you have to strike a balance between simplicity for the sake of usability, and ensuring the prices are as reflective of the highly complex and diverse costs involved as possible.

Carbon Intensity data

With the cost made up of so many complex factors already, Agile pricing isn’t as officially tied to the ‘greenness’ of energy as we’d like. Given that we designed Agile Octopus to encourage energy use at times with low demand, and the stuff being produced is mostly green, we’ll definitely look to factor in National Grid Carbon Intensity data to more closely track renewable supply. The low Agile price periods do generally coincide with high renewable energy generation.

The real drive for Agile is using price to help change behaviour. You need only look at the effectiveness of Uber’s surge pricing model to see how dynamic, capacity-based pricing can be used to effectively control supply and demand. Similarly our own Agile report showed significant impact too.

As Agile is designed to get closer to reflecting the truly dynamic costs of energy - and seeing how users respond - the formula exaggerates the difference in the costs *we* face (ie peaks are disproportionately high; and cheap periods are disproportionately cheap). This is because we are trying to reflect the realities of the physics of the system - but there are many subjective questions, such as how fixed costs are shared, or whether peak costs should be borne by the marginal user, etc. We do this because we want Agile, and reactions to it, to inform changes to the way we (and other companies) pay for access to networks and the grid.

As a result, Agile may be a big lossmaker for us, or may be excessively profitable. It's still experimental, so we might amend the formula or introduce new variables into the mix, but will of course give plenty of notice should that happen.

Agile is exciting because it's really paving the way to the energy system of the future and we, and the customers who use it, are part of that experiment.

Agile Billing

Our Agile tariffs are billed based on your usage during 48 half-hourly periods of the day.

Statements and rounding

There's two typical Agile statements below, the first for import only, and the second showing export. There's a lot of rows. A lot a lot.

You'll see the daily charges / credits are broken down by the half-hour / unit rate of a particular half-hourly period.

Agile import statement

Agile export statement

On the left hand side of the statement you'll see:

Total Rebate

The total figure we'll credit back to your account.

This is calculated by multiplying the unit rate for each half-hourly period by the kWh exported during that period.

We round this figure by 3 decimal places, e.g. 0.3516p is rounded to 0.352p.

When we've calculated the rebate for every half-hourly period, we'll round the total from all periods to the nearest whole pence, e.g. 0. 516p is rounded to 0.05p.

Total export

This is the total export figure for all 48 half-hourly billing periods. This figure is rounded to 2 decimal places, i.e. 4.759 kWh is rounded to 4.76 kWh.