Part 1 of 3 in our series on building the best home energy planner in the world.
Energyplan decides when a battery charges, when a car charges and when a home sells power. We built it at Sourceful and we own it. It is proprietary software. It ships with FTW, our open energy management system, and we built it so that it can ship with other products too.
Our goal is the best home energy planner in the world, and we believe we are on the way. An AI can write something that looks like a planner in an afternoon. A planner that real homes can rely on is a different job. This one rests on years of research, months of measured releases, about 50 billion tokens of AI work, real data, real hardware and real users.
It started long before Energyplan
Two of us came to this from research. Fredrik Ahlgren, our CEO and co-founder, has a PhD in energy efficiency and led IoT research at Linnaeus University. From 2017 to 2019 he trained models to predict the fuel consumption of a cruise ship, using automated machine learning, and that work became two papers in 2018. Tobias Olsson, our CTO and co-founder, has a PhD in computer science and also did his research at Linnaeus University, where he used machine learning to map source code to software architecture. Energy is the same kind of problem: messy measured data, and a prediction that has to hold up against what really happened.
The road from there:
| When | What |
|---|---|
| 2017–2019 | Automated machine learning on a cruise ship's fuel consumption. Two papers in 2018. |
| June 2025 | A first peak-power optimiser |
| August 2025 – January 2026 | EMS Optimizer Light: battery optimisation inside a site's boundary |
| October 2025 | Sourceful's EMS starts: a cloud platform that plans every 15 minutes and controls batteries, solar and chargers |
| November 2025 | The EMS gets its first optimiser |
| January 2026 | Forecasting research for household load and solar starts, and so does peak shaving with V2X chargers under Swedish capacity tariffs |
| February – March 2026 | A forecasting service that builds 24-hour forecasts every 15 minutes, and a first optimisation engine in Rust |
| April 2026 | FTW starts, and gets its first planner two days later |
| July 2026 | FTW's first mathematical optimiser |
| August 2026 | A physics-grounded site simulator starts. It has 474 commits so far. |
| September 2026 | Energyplan becomes a product of its own |
| October 2026 | A dedicated solver research track |
| October – November 2026 | A planner for commercial batteries behind the meter, tested on a real site's recorded data |
In January 2026 Fredrik also asked Claude Code to replicate his 2018 paper on its own, and documented what happened. We run research with agents today, under much stricter rules.
Two lines of optimisation, one company
Energyplan is not Sourceful's only planner, and it did not grow alone.
In October 2025 Tobias started building Sourceful's EMS: a cloud platform where an optimisation engine makes a plan for the next 12 to 24 hours every 15 minutes, and a controller carries it out every 30 seconds against the real limits of the site. 618 of its 898 commits are his. In March he explained how that optimiser thinks in a post on this blog.
A plan only matters if it reaches a battery. Tobias also wrote much of what carries it there: the core platform for telemetry, control and authentication, and the firmware on our gateways. In August he started a physics-based simulator of commercial sites. In October and November he built a planner for commercial batteries behind the meter. It combines peak shaving, spot-price trading and fuse protection in one plan, and we test it on a real site's recorded data with a fitted digital twin of its battery.
FTW and Energyplan took a different route: local, on the home's own box, built for one family of problems. The two lines share a company and the same hard questions about tariffs, fuses and forecasts, and ideas move between them.
A good planner for a simple home
FTW's first planner uses dynamic programming: split the battery's state of charge into steps, and work out for every hour of the coming day which step to move to so the total cost is lowest. It is fast and reliable. For one battery and an electricity price it is close to perfect.
Then homes got more interesting.
- Cars. A car has a departure time and a goal: "80 % by 07:00". A charger has a minimum current: it is either off, or on at 6 A or more, and nothing in between.
- More than one battery. Two batteries, or a battery and a car that can give power back, interact.
- Peak-power tariffs. Many grid fees now depend on your highest hour of the day or month. A single bad hour costs you all month, so a decision at 18:00 is tied to every other hour.
- Limits. Main fuses, hourly import caps, export limits, battery-health limits.
Each of these adds to the number of situations the dynamic program has to track. Add them together and it stops being practical: the planner must either simplify the home or run out of time.
Bring in the mathematics
The tool built for this kind of problem is mixed-integer optimisation: describe every device, limit, price and goal as equations, mark which decisions are yes or no, and let a solver find the cheapest plan that meets all of them. A good solver can also prove that no better plan exists. Part 2 explains how.
On 12 July 2026 FTW got its first mathematical optimiser, on the beta and edge channels. It was a Python worker with its own release track and a protocol negotiated with FTW's Core. It showed how much better plans could get. It also showed the hard parts. A home system does not run on a server. It runs on something like a Raspberry Pi, next to everything else the system does. The plan has to be ready in a second or two, every few minutes, all day and every day. And it can never be wrong.
At the end of August FTW's own planner became the default, and the Python optimiser ran beside it as a measuring shadow. A week later we retired it.
Energyplan
On 7 September 2026, Energyplan became a planner of its own: a dedicated optimiser built by Sourceful, in Rust, for one job, planning a home's energy. It has been proprietary since its first commit.
We made three design decisions on day one, and they still hold:
- A separate worker with a contract. FTW's Core sends a request (prices, forecasts, devices, goals) and Energyplan answers with a plan. The protocol is versioned, and new capabilities are negotiated. An older FTW and a newer planner, or the other way around, still work together.
- Trust, but verify. FTW's Core validates every plan Energyplan returns before it touches real hardware. It replays the plan against the physics of the home. If anything is off, Core rejects the plan and its own planner takes over. That dynamic-programming planner never went away: it runs as a shadow and a fallback.
- Ship in small, measured steps. A beta channel first, with real homes, then stable.
Every version so far
| Version | When | What it brought |
|---|---|---|
| Python optimiser 0.1 | 12 July | FTW's first mathematical optimiser, on the beta and edge channels |
| Python optimiser 1.3–1.4 | 22 July – 4 August | Its own release track, a protocol negotiated with Core, safer handling of battery state |
| Energyplan 0.1–0.3 | 7–8 September | The move to Rust: a dedicated worker, binary packaging and the contract with Core |
| 0.4.0–0.4.2 | 8–12 September | The first versions pinned in FTW, then bundled under the Home Use licence |
| 0.4.3–0.4.8 | 13–22 September | Cars: energy targets with duty cycles, two cars sharing one import limit, charging pulses priced correctly |
| 0.4.9–0.4.10 | 28–29 September | Faster planning for several batteries and for demand tariffs |
| 0.5.0 | 3 October | Better car plans within a Raspberry Pi's budget, and a valid plan that survives a solver failure |
| 0.5.1 | 7 October | Cheaper plans with a car: the battery is planned around the charging |
| 0.5.2 | 8 October | A sunny two-day home case on a Pi's budget: 77 kr instead of 100 kr, where the best possible plan costs 77 kr |
| 0.6.0 | 25 October | Hourly import limits |
| 0.7.0 "ROBUST" | 6 November | Peak hours done right, plans that never go backwards, under a third of the memory, on time on a Pi |
| 0.8.0 "FAST" | in progress | More plans proven optimal, faster |
In October Energyplan also became the default on stable releases.
The last three weeks
Energyplan 0.6.0 added hourly import limits. If your grid connection or your tariff limits how much you may draw in an hour, the planner keeps every clock hour under that limit. It lets the battery cover the house so the car still gets charged, and it says so plainly when a car goal cannot be reached.
Energyplan 0.7.0 "ROBUST" was a release about trust, not new features:
- Peak-power tariffs done right. The planner now plans with the hour already in progress, so each day's peak counts once.
- Never a step backwards. A new plan is never worse for your car goals or your bill than the plan the planner already holds.
- Clear answers when the impossible is asked. If a site's limits cannot all be met, you get the reason and the time slot instead of a failed plan.
- Under a third of the memory. Peak memory on our core test set fell from 223 MiB to 64 MiB.
- On time on a Raspberry Pi. On a Pi 4, the hardware many FTW homes run on, time-budget overruns went from 3 to 0 on our core set. On 500 real replans recorded on a live home they went from 2 to 0, and the plans cost no more.
- Zero rejected plans. FTW validates every plan before it touches your hardware. On our gate test sets it rejected none of 0.7.0's plans, against five of 0.6.0's.
0.7.0 now ships in FTW 0.160.0-beta.1 on the beta channel.
What it took
We build Energyplan with a small human team directing a large team of AI agents. Every agent follows strict rules: test first, measure against the version you run today, pass review by other agents whose only job is to find faults, and merge only when the numbers say so.
Here is the AI work we can still count. Our logs go back to August 2026.
| Work | Tokens processed |
|---|---|
| Energyplan 0.7.0 and the start of 0.8.0, 27 October to 8 November, main build machine | about 6.4 billion |
| Solver research track, October | at least 8.9 billion |
| FTW, Energyplan and everything around them on our main development laptop, since August | about 34.7 billion |
| Total in the logs we still hold | about 50 billion |
That counts all input, cached input and output. About 146 million of those tokens are what the models wrote: code, tests, reviews and reports. Behind them are about 235,000 tool actions, such as builds, tests, benchmarks and edits.
The models:
| Model | Tokens processed |
|---|---|
| Claude Opus 5.5 | 30.9 billion |
| GPT-6.1 Sol | 6.8 billion |
| GPT-6 Astra | 3.2 billion |
| Claude Opus 5 | 3.1 billion |
| GPT-6 Luna | 2.6 billion |
| Claude Sonnet 5.5 | 2.3 billion |
| Claude Fable 5 and 5.1 | 0.9 billion |
| Claude Opus 4.8 | 0.2 billion |
Before August we used the best models of the day as well. We no longer hold those logs, so they are not in the table, and neither is the forecasting and optimiser work from before August. The table also leaves out the rest of the team's machines, including Tobias's work on the EMS and the platform.
The last release alone looks like this:
| 27 October to 8 November, main build machine | |
|---|---|
| Agent runs | 396, in 8 multi-agent release waves |
| Model calls / tool actions | about 31,900 / 33,400 |
| Tokens written | about 29 million |
| Commits | 437 in three weeks |
| Automated tests | 593 in the planner, 395 in the benchmark harness |
| Benchmark steps | 830+, each one comparing a change with the shipped version |
| Test data | 10 benchmark sets, plus 500 real replans from a live home |
A dedicated benchmark machine runs day and night. It knows when other heavy jobs run, and it repeats any measurement they might have disturbed. A speed claim means nothing if the measurement is dirty.
Why you cannot vibe-code this
Anyone can buy tokens. We could not buy these:
- Years on the real problem. The research goes back to 2017. Sourceful's EMS has planned and controlled energy since 2025. The forecasting work started in January 2026, and FTW got its first planner in April. Energyplan took everything we had learned.
- Real data. Each release replays real planning requests from a live home through the old and new versions. A change that looks good on made-up data still has to hold on those.
- Real hardware. The planner has to finish on time on a Raspberry Pi 4, next to everything else the box does. We test on one.
- Real users. Beta users run this with their own batteries, cars and fuses, and they tell us when it goes wrong. By late October we had catalogued 840 known faults, device behaviours and hardware tests, and we are turning them into scenarios in a simulator of a whole site.
- A way to tell better from worse. Ten benchmark sets, measured noise floors and a validator that replays every plan against the physics of the home.
A planner that works in a demo on a sunny day is the easy part. The hard part is a Pi with a cloudy forecast, a peak-power tariff, a fuse near its limit and a car plugged in late. You learn what that takes by running on real homes for months, and that knowledge is what we have built.
Ours, and built to travel
FTW's Core, clients and drivers are open code under AGPLv3, and we want them to stay that way. Energyplan is different. It is the part we keep. FTW receives it as a compiled worker.
The separate worker is also what lets it travel. Anything that speaks its versioned contract can run it. FTW is the first product to ship it, and it does not have to be the only one. Private households get it free with FTW. Commercial use and bundling need a written licence from Sourceful.
A feature we dropped
One idea for 0.8.0 was a smarter rule for when the planner may stop searching. Before writing a line of planner code, we emulated it on 564 real and synthetic requests. It saved 16.7 öre in total, from just two plans, and made the planner 6 % slower.
We dropped it. Every change in Energyplan has to show a measured gain.
What comes next: 0.8.0 "FAST"
0.7.0 was about never being wrong. 0.8.0 is about speed: more plans proven optimal within the time budget, so that the planner knows it found the best plan and not just a good one.
We wrote the targets down against 0.7.0 before looking at any result, so nobody can adjust them afterwards. To pass, 0.8.0 must:
- prove the optimal plan in at least 22 % more of our core cases within the time budget;
- reach that proof 20 % faster (median);
- do 15 % less solver work for the same answers;
- answer more requests within half their time budget;
- be no slower to its first valid plan.
After FAST comes BEST: plan quality, down to the last öre.
Your home makes thousands of small energy decisions a day. Together they decide how much you pay, how long your battery lasts and whether your car is ready in the morning. We think those decisions deserve the same engineering rigour as a power plant's dispatch.
The next two posts go deeper:
- Why planning a home's energy is hard, and how we measure it: the problem, the benchmarks and what state of the art means.
- How we ship a planner you can trust: the rules we work under and the agents that follow them.
Energyplan is Sourceful's proprietary planner. It ships with FTW, whose Core, clients and drivers are open code under AGPLv3. Energyplan itself has its own licence: free for your own private household with FTW, and under a written Sourceful licence for commercial use or for bundling with other products. Talk to us if you want it in yours.
