A Weather Forecast in Four Kilobytes

In short. Most of what gets written about AI right now is about frontier models with hundreds of billions of numbers inside them. This is about one with 3,521. It reads the pressure, temperature and humidity from a sensor in my garden, and it answers twelve questions every ten minutes: will it be fair, changeable or wet, will it rain, how windy will it be, and is a gale-force gust on the way, at six, twelve and twenty-four hours ahead. Its weights take 4,052 bytes. It was trained on twenty years of weather for twenty-one places along the south coast, and it was then marked against a real rain gauge it had never seen. It beats both the classic barometer forecast and the honest “same as now” guess, and doubling its training data improved it by 0.0003. That last number is the most useful thing in this article.

I spend a lot of time talking about large language models, with clients and in this series. They are remarkable, and they are also the answer to a narrower set of questions than the conversation around them suggests. So this autumn I built something deliberately at the other end of the scale, for a question I actually have: what is the weather about to do on the beach at Worthing?

The question.

A forecast you can trust needs a question you can mark. Mine was specific. Using only what a small sensor can measure, pressure, temperature and humidity, tell me what happens in the next six, twelve and twenty-four hours, in words a household understands.

That rules out the satellite picture, the radar and the national forecast model. It leaves a barometer, a thermometer and a hygrometer, which is what sailors and farmers had for most of history. The interesting question is how much a small model can squeeze out of those three readings, and how honestly it can say so.

The data.

The model learned from ERA5, the reanalysis produced by the European Centre for Medium-Range Weather Forecasts and served free for personal use by Open-Meteo. Reanalysis is a consistent hour-by-hour reconstruction of the past weather everywhere on a grid.

I took twenty years of it, 2006 to 2025, for twenty-one coastal and inland places across southern England: 3,681,720 hourly rows. Two places, Worthing and Cowes, were held back entirely, and so were the years 2024 and 2025. The model never saw those places or those years during training, so the scores below are measured on weather it had to predict cold.

The model.

The inputs are seventeen numbers the sensor can produce: the pressure now and how it has changed over one, three, six and twelve hours; the temperature, humidity and dew point and how they have moved; and the time of day and year.

The model itself is a small neural network with 3,521 weights. Stored as eight-bit integers they take 4,052 bytes, a little under four kilobytes. It is exported as plain C, with no machine learning library on the device, and a fixed set of test cases checks that the C version gives the same answers as the Python one it came from.

Twelve answers come out: the weather class (fair, changeable or rain), rain yes or no, a wind band named in Beaufort terms, and the chance of a gust reaching force 8, each at six, twelve and twenty-four hours.

The kit.

None of it is special, and that is the point.

• Two RuuviTag sensors, one indoors and one in the garden. Each is a sealed, battery-powered Bluetooth sensor that broadcasts temperature, humidity and pressure every second or so, running on a coin cell.
• An ESP32-C3 board that cost about £2. It is smaller than a postage stamp and takes its power from a USB port. It listens for the sensors and passes their readings to the home server over WiFi, and it picks up about five times as many broadcasts as the server's own Bluetooth did: 23.6 readings a minute against 4.9, measured over 45 hours side by side.
• A home server that runs the model every ten minutes, keeps the history and serves the household page. The training ran at home too.
• A LILYGO T-Deck, a pocket-sized ESP32-S3 device with a screen and keyboard, which the model was exported to run on directly.
• A 4.3 inch Waveshare ESP32-S3 touch screen on the wall, which shows the forecast beside the household's energy prices.

Did it work?

Two baselines matter. The first is the Zambretti forecaster, the barometer rule published by Negretti and Zambra in 1915 and still built into weather stations today. The second is persistence: whatever the weather is now, it will be the same then. Persistence sounds naive and is hard to beat at short range.

The headline test is rain yes or no, twelve hours ahead, on the held-out years at the held-out places.

Macro-F1 rewards getting both the wet hours and the dry hours right. The Brier score measures how good the stated probabilities are, so it punishes confidence that turns out wrong. The model wins on both, by a clear margin.

Marked by a real rain gauge.

There is a trap in that table. The model learned from ERA5 and was scored against ERA5, so it could simply have learned ERA5's habits. The fair test is an instrument.

Shoreham Airport, about ten kilometres east, keeps a rain gauge, and it sits in the same reanalysis grid cell as Worthing. Over 20,768 hours from 2023 to 2025, the gauge and ERA5 disagreed about rain on nearly one hour in five. Marked by the gauge instead, the model's score moved from 0.757 to 0.743, and its lead over persistence held at 0.062. It held at every horizon.

The gust warning was harder to check, because the nearest station that records gusts is Kenley, 58 kilometres inland on the North Downs. There, at twelve hours, when the model raises the warning a gale-force gust follows about 27 per cent of the time, against a background rate of 3.3 per cent. That is 8.2 times the background, and it catches 61 per cent of the events. The screen shows it as a percentage, because a probability is what it is.

More data barely moved it.

The first version trained on ten years. Doubling that to twenty years, on exactly the same test hours, moved the exported model's headline score from 0.7551 to 0.7554. Ten extra years of southern England weather bought three ten-thousandths.

That is the finding I would put in front of any board. The model is limited by what three local readings can tell you about the next twelve hours, and nothing else. A bigger network or more data cannot add information the inputs do not carry. The improvements from here come from better inputs: a sensor outdoors, a longer pressure history, and the device's own readings as they build up.

Honest by design.

A small model earns trust by being plain about its limits. When it has not yet seen enough hours of readings, the screen says so, in so many words, with the number of hours it needs. When pressure falls fast, the alert reads “pressure falling fast”. That is a measurement, worded as one, because the measured lead time on that signal was a median of fifty minutes, too short to call it a forecast. Every number on the screen traces back to a reading or a measured score.

Where it runs.

Every ten minutes, at home, the model reads a RuuviTag sensor in the garden and writes its forecast. That forecast feeds a small website the household opens on their phones, a weather page on our energy wall panel, and the handheld device the model was exported for. It runs on hardware we own, with data we hold, and it carries on when the internet does not.

What this means beyond the weather.

Most organisations we work with are asking which large model to use. The better first question is what the job needs. Some jobs need a frontier model. Many need a small, measurable model trained on the organisation's own data, scored against something real, and small enough to run where the data already lives. Those are cheaper to run, easier to explain to an auditor, and yours.

The method transfers directly: write down the question you can mark, hold back data the model never sees, beat the simple baselines on both accuracy and calibration, test against an instrument as well as the source you trained on, and measure whether more data helps before buying more of it.

Part of two larger projects.

This model is one piece of two projects I am writing up as they go.

The first is a home intelligence panel: a wall screen that shows the household the best times to use electricity and to sell it back on its tariff, alongside what the solar panels, the battery and the heat pump are doing, what yesterday cost, and this forecast. It runs on the same principle as the model, small parts, our own data, and plain code wherever plain code will do.

The second is the boat. Before next spring I plan to train a regional version of this model for the Ionian Sea, where she sails, and to build an onboard system that works with no signal: the boat's own instruments, a model of how she actually sails, and a forecast corrected for the waters she is in, running off grid on a Raspberry Pi. That plan is set out at the end of How a Language Model Is Actually Built.

More field notes will follow on both.

Common questions.

How we work.

If you are weighing which kind of model a problem needs, we are happy to talk it through. A thirty-minute call is enough to start.

Sources.

• Weather data by Open-Meteo.com, licensed CC BY 4.0, serving ERA5 reanalysis produced by ECMWF and distributed through the Copernicus Climate Change Service.
• Weather observations from Meteostat, licensed CC BY 4.0, aggregated from NOAA and national meteorological services (Shoreham Airport, WMO 03876; Kenley, WMO 03781).
• The Zambretti forecaster, Negretti and Zambra, 1915.