-
-
Formula I used in script.
Inspiration
Watched several videos on prediction markets, and saw how user based tools could be built in order to create an edge on these bets. Weather markets on both Kalshi and Polymarket (however chose Kalshi due a free API, which ended up not working how I wanted it too) caught my attention specifically — people were betting on whether Phoenix would hit 95°F on a given day, and it struck me that this was a problem meteorology had essentially already solved. Professional forecast models are extraordinarily accurate at short range. The market just wasn't reflecting that.
What it does
Frontedge pulls real-time forecast data from three of the world's leading numerical weather prediction models — NOAA's GFS, the European Centre's ECMWF, and the UK Met Office — and combines them into a weighted ensemble forecast. It then fits a Gaussian probability distribution over the range of likely temperatures, computes the probability that the maximum temperature will exceed a given threshold, and compares that against what the prediction market is implying. The result is a live dashboard that flags where the crowd is likely wrong.
How I built it
The core is a single-page web app built in HTML, CSS, and JavaScript. Weather data comes from the Open-Meteo API, which aggregates multiple global models into a single endpoint with no API key required. The ensemble weighting reflects real-world model skill — ECMWF carries 50% weight given its consistently superior performance in peer-reviewed verification studies, with GFS and UKMO splitting the remainder. The probability distribution is computed using a Gaussian PDF centred on the weighted ensemble mean, with standard deviation derived from inter-model spread. Edge detection compares model-implied probability against market-implied probability using a normal CDF approximation.
Challenges we ran into
The biggest technical challenge was the Open-Meteo multi-model API response structure — each model returns data under its own named key rather than a unified array, and null values appear where shorter-range models have no forecast. Handling this gracefully required dynamic weight renormalisation so the ensemble remains valid even when only two models have data. The second challenge was Kalshi's API, which enforces strict CORS restrictions that prevent direct browser-based requests. Live integration ultimately requires a backend proxy server, which we noted as a known limitation.
Accomplishments that we're proud of
Building a tool that applies genuine meteorological methodology — ensemble weighting, inter-model spread as uncertainty proxy, tail probability estimation — in a clean, accessible interface. The probability distribution chart in particular makes the uncertainty visible in a way that raw numbers don't. Most prediction market tools just show odds. Frontedge shows why those odds might be wrong.
What we learned
Inter-model disagreement is itself a signal. When GFS, ECMWF, and UKMO all converge on the same temperature, the distribution is tight and the edge is small. When they diverge, uncertainty is high — and that's exactly when markets are most likely to be miscalibrated. Quantifying disagreement rather than just averaging it out is where the real information lives.
What's next for Frontedge
The immediate next step is a lightweight backend server to enable live Kalshi API integration, which would make the edge detection genuinely actionable rather than just for show. Beyond that, extending beyond temperature markets — wind speed, precipitation probability, even hurricane landfall markets — would significantly expand the addressable market. Longer term, historical backtesting against resolved Kalshi markets would let us validate whether the ensemble edge is real and quantify expected value per bet.
