Polymarket Weather Bot: How Automated Trading Works

Why Weather Markets Are Well-Suited to Automation

Automated trading exists wherever three conditions are present: a quantifiable signal, a repeated decision structure, and a human execution bottleneck. Polymarket daily temperature markets satisfy all three.

A quantifiable signal. The input to every weather trade is a temperature forecast. Forecasts come from numerical weather prediction models — software systems that output structured data on fixed schedules. GFS updates at 00/06/12/18 UTC. ECMWF at the same cycle. HRRR every hour. This is structured, programmatic input that a bot can consume directly.

A repeated decision structure.Daily temperature markets reset every 24 hours. There are 10–15 active markets on any given day, across multiple cities and sometimes multiple lead times. The same decision — “is this bucket mispriced?” — repeats dozens of times a day, every day, forever.

A human execution bottleneck. Responding to six model updates per day, across 15 markets, comparing model output to live prices, sizing bets, and placing orders — manually — requires hours of work and constant attention. A bot does this in milliseconds.

What a Weather Bot Actually Does: The Core Loop

Every Polymarket weather bot, regardless of sophistication, runs some version of this loop:

1. Market discovery — Identify all active Polymarket daily temperature markets via the Gamma API.
2. Forecast ingestion — Pull temperature forecasts for each city's resolution station from one or more weather data sources.
3. Probability estimation — Convert the forecast into a probability distribution over the market's temperature buckets.
4. Price comparison — Query current market prices from the CLOB API or WebSocket.
5. Edge calculation — Compare model probability to market price for each bucket.
6. Sizing — Apply Kelly Criterion (or fractional Kelly) to determine position size.
7. Order placement — Submit a signed limit order to the CLOB API if edge exceeds threshold.
8. Risk management — Check daily loss limits, max exposure per market, dead-man switches.
9. Loop — Wait for next model update or price change, repeat.

The Three APIs Every Polymarket Bot Uses

1. The Gamma API (Market Discovery)

gamma-api.polymarket.com — A read-only API that requires no authentication and returns metadata about all active Polymarket markets: slugs, tags, condition IDs, token IDs, resolution sources, market descriptions, and end times.

A bot queries Gamma at startup and on a periodic refresh (e.g., hourly) to discover new weather markets and extract the token IDs needed to place orders on the CLOB.

Key endpoint: GET /events?closed=false&tag=weather. Rate limits: approximately 500 requests per 10 seconds on the events endpoint.

2. The CLOB API (Order Execution)

clob.polymarket.com — The trading API. Requires API key, secret, and passphrase, all derived from a signed message from your EOA wallet.

Key operations:

• POST /order — Place a single order (GTC, GTD, FOK, or FAK).
• DELETE /orders — Cancel open orders.
• GET /orders — Query open/filled order history.
• POST /orders — Batch order placement.

3. WebSocket (Real-Time Price Feeds)

wss://ws-subscriptions-clob.polymarket.com/ws/market — Subscribes to live orderbook updates for specific token IDs. The bot receives: initial orderbook snapshots, incremental price changes, last-trade events, and market-resolved events.

This is how a production bot knows market prices without polling REST endpoints — crucial for responding to model updates in near-real-time.

How the Forecast Stack Works

Approach 1: Commercial Weather API

Services like Visual Crossing, Tomorrow.io, and Open-Meteo provide pre-processed forecast data at specific coordinates via JSON REST APIs. The upside: simple, reliable, no GRIB parsing. The downside: you're consuming a processed product — you don't know which underlying models it blends or how fresh the data is.

Open-Meteois particularly notable for weather trading use: it's free, provides raw model output from ECMWF, GFS, ICON, UKMO, and other models individually, and includes ensemble members via the Ensemble API. You can query the 51 ECMWF ensemble members and the 31 GFS members by coordinate, getting exact bucket-by-bucket probability counts with no distributional assumptions.

Approach 2: Direct Model Ingestion (GRIB/BUFR)

More sophisticated bots pull raw GRIB files directly from NOAA's NOMADS server (for GFS/HRRR) or from ECMWF's API (subscription required). This is lower-level and more complex but gives you the earliest possible access to new model runs and lets you apply your own post-processing calibration before the commercial APIs have processed the run.

This approach is what enables true latency arbitrage: getting the ECMWF 12 UTC run's temperature forecast for Tokyo before Open-Meteo has ingested and published it.

Probability Estimation: The Key to Edge

Getting forecast data is easy. Converting it into accurate bucket probabilities is hard — and this is where bots diverge most significantly in performance.

Method 1: Ensemble Counting

Pull all 51 ECMWF ensemble members (or 31 GFS members). For each member, determine which temperature bucket the forecast high falls into. The fraction of members in each bucket is your probability estimate.

This is the most theoretically clean approach because it makes no distributional assumption. But raw ensembles are underdispersive — they cluster more tightly than the true uncertainty warrants — which means tail buckets are systematically underestimated.

Method 2: Normal Distribution Parameterization

Fit a Normal distribution with mean = ensemble mean and standard deviation calibrated against historical forecast errors at the same station, same lead time, same season. Integrate the Normal CDF over each bucket's edges.

This is simpler to compute and lets you explicitly model the fact that 5-day forecasts have much higher σ than 1-day forecasts. The risk: Normal distributions put too little mass in the tails for convective days or unusual regimes.

Method 3: Post-Processing with BMA or EMOS

Bayesian Model Averaging (BMA) fits a weighted mixture of distributions to each ensemble member's forecast, explicitly correcting for bias and underdispersion. Ensemble Model Output Statistics (EMOS) fits a parametric predictive distribution directly from ensemble statistics.

These approaches typically improve calibration by 20–40% over raw ensembles (measured by Brier skill score) and require a historical training dataset of model output vs. observed temperatures for each station — at least 30–90 days of history.

Station-Level Bias Correction

All methods benefit from adding a station-specific, decaying-average bias correction. Track the difference between the model's predicted daily high and the Wunderground-finalized observed high at each resolution station, for each lead time, over the last 30 days. Apply a Kalman-filter-type update:

bias[today] = α × (forecast − observed) + (1 − α) × bias[yesterday]

Where α is typically 0.1–0.3. This single correction captures microclimate effects, urban heat island offsets, airport-vs.-city differences, and any systematic model bias for a given station.

Edge Calculation and Kelly Sizing

With a probability vector across buckets and current market prices, edge is trivial to compute:

Edge on bucket i = (model_prob[i] − market_price[i])

Only trade when edge exceeds your minimum threshold. Common thresholds: 8% for weather.

Kelly sizing for a YES position with model probability q and market price p:

f = (q − p) / (1 − p)

Multiply f by bankroll to get dollar size. Apply fractional Kelly (0.15–0.25× is typical for weather). Apply absolute cap (e.g., $100 per position regardless of Kelly). The alteregoeth-ai weatherbot uses 0.15× Kelly with a $100 cap. These are conservative but appropriate for a market where calibration errors can be substantial.

Open-Source Bots: What's Available

alteregoeth-ai/weatherbot

Language: Python. Forecast source: Visual Crossing API. Strategy: Single-bucket EV filtering with Kelly sizing; will trade YES or NO on any bucket where edge ≥ 8%. Special features: Simulation (paper-trading) mode; explicit station-level coordinates for each city. Limitation: Uses a single commercial forecast, not a multi-model ensemble; no bias correction layer.

This is the most beginner-accessible public bot — well-documented, clean architecture, runnable in under 100 lines of relevant code.

suislanchez/polymarket-kalshi-weather-bot

Language: Python. Forecast source: Open-Meteo (31-member GFS ensemble). Strategy: Ensemble-counting probability estimation, 0.15× fractional Kelly, cross-platform (trades both Kalshi and Polymarket simultaneously where the market offers higher edge). Limitation: GFS only; no ECMWF; no station bias correction.

yangyuan-zhen/PolyWeather

Language: Python. Forecast source: Multi-source aggregator — METAR/TAF live observation, Open-Meteo (GFS + ECMWF), JMA AMeDAS (Japan), KMA (Korea), HKO (Hong Kong), NOAA. Strategy: Ensemble-blended probability estimation; TAF integration for final-24h precision; station-level suppression for known bias patterns. The most comprehensive forecast stack of the open-source options; Asian market emphasis matching where Polymarket weather volume is concentrated.

Infrastructure: Running a Bot in Production

• Hosting:Run on a VPS geographically close to Polymarket's matching engine (hosted on AWS eu-west-2 in London). Providers like QuantVPS, Hetzner (Frankfurt/London), and AWS eu-west-2 directly are common choices. Weather bots don't need sub-millisecond latency for typical strategies — a few hundred milliseconds is fine — but being in Europe rather than the US still matters during model-release windows.
• Runtime: Most open-source bots run continuously in a loop with configurable intervals (30–60 minutes for forecast checking; real-time for WebSocket price monitoring). A simple systemctl service or Docker container with auto-restart handles uptime.
• Monitoring:Log every trade attempt (market, bucket, model probability, market price, edge, Kelly fraction, position size), every fill, and every error. Alert on unexpected behavior: no trades for >6 hours despite markets being open, consecutive losses beyond a threshold, WebSocket disconnection.
• Dead-man switch:Halt the bot and liquidate positions if: cumulative daily loss exceeds 5% of bankroll; rolling 30-day Brier score exceeds 0.35 (indicating calibration failure); or the bot has been unable to connect to APIs for >15 minutes during active market hours.

Should You Build One?

If you want consistent returns at scale: Yes, automation is necessary. The math only works over many hundreds of trades. Human execution of dozens of daily decisions with correct sizing and consistent threshold adherence is not sustainable.

If you want to learn: Building a simple bot against Open-Meteo and the Polymarket CLOB API is an excellent project. The core loop is maybe 300 lines of Python, the math is approachable, and the feedback loop (did this trade win?) is daily. You will learn more about probability calibration from this project than from any textbook.

If you expect to profit immediately: Temper expectations. Running an uncalibrated bot is donating to the wallets of better-calibrated bots. The open-source options require at least 30–60 days of paper-trading to validate that your calibration is actually better than the market before you risk real capital.

The competitive reality: Weather markets were significantly less competitive in 2024 than they are in 2026. New entrants today face better-calibrated competition on the most liquid markets (NYC, London, Tokyo). The edge is still there — the leaderboard keeps growing — but the lowest-hanging fruit is more crowded than it was 18 months ago.

The Minimum Viable Bot

If you want to start with something working rather than perfect:

1. Forecast: Open-Meteo GFS ensemble (free, no API key for basic use, hourly updates) — query by airport ICAO station coordinates.
2. Probability: Count GFS ensemble members by bucket. Apply a ×1.15 spread multiplier to account for underdispersion.
3. Market discovery: Gamma API, filter for tag=weather, extract condition IDs and token IDs.
4. Prices: CLOB API GET /prices endpoint or WebSocket subscription.
5. Edge threshold: 8% minimum.
6. Sizing: 0.15× Kelly, hard cap at $50.
7. Execution: CLOB API POST /order with a limit order inside the current spread.
8. Logging: CSV of every trade with timestamp, market, model_prob, market_price, edge, size.

This is roughly what the alteregoeth-ai weatherbot does. It won't make you a millionaire, but it will demonstrate whether you have any edge — and if you do, that's the foundation everything else builds on.

Related articles

• How to Trade Polymarket Weather Markets: A Complete Step-by-Step Guide
• The Polymarket Weather Leaderboard: Who's Winning and How
• Polymarket Weather Markets Explained: How Daily Temperature Trading Works