A Polymarket weather quant trading engine is a pipeline that turns weather forecast probabilities into calibrated trade signals for Polymarket weather markets. Kevin’s open-source project, polymarket-weather-quant, pairs a Polymarket data pipeline (markets, order-filled events, structured trades) with a calibration layer so forecast probabilities can be compared against market prices. This post walks through how the pieces fit.
weather forecasts ──┐
├──► calibration ──► signal ──► trade decision
Polymarket markets ─┤ (buckets) (edge) (size, entry)
order-filled events ┘
│
└──► structured trade data (CSV) ──► backtestWhat is a Polymarket weather quant trading engine?
It is a repeatable pipeline that compares modeled weather probabilities with the prices Polymarket shows for weather markets, and only trades when the gap survives calibration.
Three pieces matter:
- Data. Polymarket market metadata, order-filled events, and the structured trades built from them.
- Model. A weather forecast that produces a probability per outcome bucket (for example, a temperature range for a city on a date).
- Calibration. A step that corrects the raw model probability using past outcomes, so a stated 70 percent actually wins about 70 percent of the time.
Without calibration, a forecast that is directionally right but overconfident will show fake edges everywhere. With it, you get a number you can compare to the market price and defend. The polymarket-weather-quant repo describes itself as a calibrated weather-prediction trading engine for Polymarket, and the data layer underneath it is public.
How the calibrated weather-prediction pipeline works end to end
The pipeline runs in three stages, and each stage writes a file the next stage reads.
- Market data collection. Fetches all Polymarket markets with their metadata, so you can filter down to weather markets.
- Order event scraping. Collects order-filled events from the Goldsky subgraph.
- Trade processing. Transforms raw order events into structured trade data.
On top of that, the project adds the calibration stage: your forecast probabilities get mapped against the settled outcomes in the trade data, a correction is fitted, and the corrected probability becomes the input to the signal layer. The README is blunt about setup cost: first-time users should download the data snapshot and extract it in the main repository directory before the first run, which the README says saves over 2 days of initial data collection. That snapshot is a real shortcut. Rebuilding order events from scratch is slow and rate-limited; loading a known archive first and then appending new events is far saner.
Installation uses UV for package management, so the setup is a UV install followed by dependency install, not a hand-rolled virtualenv dance. Read the repo README for the exact commands rather than guessing.
How to structure Polymarket weather data into quant signals
Raw order events are noisy. You want one row per settled market with the forecast probability, the market price at your entry time, and the outcome, because that table is the entire research surface.
A practical schema looks like this:
| Field | What it holds | Why it matters |
|---|---|---|
market_id |
Polymarket market identifier | Joins markets to trades |
question_bucket |
The outcome being priced | Maps to one forecast bucket |
resolution_time |
When the market settles | Aligns forecast horizon |
market_price |
Price at your entry cut | Your comparison point |
forecast_prob |
Model probability | Raw signal |
calibrated_prob |
Corrected probability | Decision input |
outcome |
1 or 0 | Training label |
Two rules save you pain. First, pick the entry cut before you look at outcomes: for example, price at 24 hours before resolution. If you pick it after, you have already leaked the answer. Second, keep the raw and calibrated probabilities separate so you can measure how much the calibration actually moved things.
How calibration turns forecast probabilities into trade edges
Calibration is the step that decides whether your edge is real, because an uncalibrated model can look sharp and still lose money.
The simplest version is bucketed calibration. Sort your historical forecasts into bins (say, 60 to 70 percent), then count how many actually happened in each bin. If the 60 to 70 bucket settles true only 55 percent of the time, your model is overconfident there and you shrink it. Fit that correction on past data and apply it to live forecasts.
A small worked example helps. Suppose your model says 72 percent that a city’s high lands in a bucket. Your calibration curve maps a stated 72 percent to an observed 64 percent. Polymarket prices that bucket at 58 cents. Raw edge looks like 14 points; calibrated edge is 6. That difference is what stops you from sizing up on a mirage. If the market were at 66 cents, the calibrated engine would pass, and the raw one would too, but for the wrong reason.
Track your calibration curve over time. When the market gets more efficient on weather, your edges shrink, and the curve is your early warning.
How to fetch Polymarket markets and order-filled events with the data pipeline
The pipeline splits fetching into market metadata and order-filled events, because they behave differently: markets are cheap and small, order events are huge and slow.
The market step pulls all Polymarket markets with metadata. The event step scrapes order-filled events from Goldsky, which requires a subgraph API key. The README credits @PendulumFlow for fixing some missing points in the snapshot data, which is worth knowing if you find gaps in older records.
Practical habits that hold up over repeated runs:
- Store raw pulls separately from processed trades, so a bug in processing does not force a re-scrape.
- Append new events on a schedule instead of re-fetching history.
- Keep a run log with timestamps, so you can tell whether a gap is missing data or a failed job.
If you would rather start the analysis today, download the snapshot from the README link and skip the two days of collection.
How to backtest and validate signals before risking capital
Backtesting comes down to one discipline: every input must be available at the moment you claim to have made the decision.
A minimal walk-forward loop:
- Split by time, never randomly. Train calibration on months 1 to 6, test on month 7.
- Recompute the calibration curve on each new window, then apply it to the next unseen window.
- Score results on calibration and on P&L separately. A well-calibrated model that loses money is telling you about fees and fills, not about the forecast.
- Include a fill assumption. Order-filled events show you what traded and at what price, which is more honest than assuming you got the mid.
Report the calibration curve next to the P&L. If your stated 50 percent bucket wins 50 percent of the time but still loses money, the problem is execution, and a bigger model will not fix it.
Can you adapt this engine for agent-driven research in 2026?
Yes, and the cleanest split is to let the agent do research and reporting while your code keeps the trading decisions.
An agent is good at the drudgery: pulling the latest weather markets, summarizing open positions, drafting a report on where the calibration curve drifted, and flagging markets where the model and the market disagree most. Your pipeline should keep the parts that must be deterministic: the calibration fit, the sizing rule, the order logic.
Concretely, an agent can read your processed trade table, produce a “calibration drift report,” and write a blog post from it. Creator OS connects to a WordPress site or a Shopify blog, and the AI writes SEO articles with drafts by default unless publish is set. That is a reasonable way to publish research notes without hand-formatting them. If your research includes short explainer video, OPEN VIDEO EDIT is Kevin’s open-source set of Claude Code skills that turn a raw talking-head clip into an animated short and render locally with Python and ffmpeg. The launch video is worth a watch: Creator OS launch walkthrough, and you can follow more builds on the KevBuildsApps channel.
Be clear about what the agent is not doing. It is not your source of truth on probability. It is a researcher and a writer sitting on top of numbers your pipeline produced. The polymarket-weather-quant repo is the engine; the agent reads its output.
FAQ
How accurate are Polymarket weather markets compared to forecast models?
There is no single answer, and you should not trust a quoted number from anyone. Weather markets price a specific bucket for a specific city and date, and how well they price it varies by market and by season. The honest method is to measure it yourself: keep a record of the market price, your calibrated probability, and the settled outcome, then compare calibration curves. That record is exactly what the pipeline and backtest in this post build.
What data sources does a Polymarket weather quant engine need?
Three layers. Polymarket market metadata, order-filled events pulled from the Goldsky subgraph, and structured trades built from those events. On top of that you need a weather forecast source that produces a probability per bucket, which is a modeling choice rather than a fixed feature of the pipeline. The project README is the place to check what the repo ships versus what you supply.
Can I run the polymarket-weather-quant pipeline without a subgraph API key?
You can start without one by downloading the data snapshot from the README and extracting it in the main repository directory before your first run, which the README says saves over 2 days of collection. To scrape new order-filled events from Goldsky after that, you need a subgraph API key. The snapshot gets you to analysis; the key keeps you current.
How do you calibrate probability forecasts for weather trading?
Bin your historical forecasts by stated probability, then measure the observed win rate in each bin. Where the observed rate is lower than the stated one, shrink the forecast; where it is higher, you can expand it carefully. Fit that mapping on past data only, apply it to future forecasts, and recompute it as new outcomes arrive. Track the curve over time, because edges shrink as markets get more efficient.
Is Polymarket weather trading profitable for small builders?
Nobody can promise that, and you should be suspicious of anyone who does. What small builders can control is process: a calibrated model, an honest backtest with realistic fills, and position sizes that survive a bad run. Fees and fills matter more at small size, so measure them. Treat the engine as a research tool first, and let the backtest decide whether to commit capital.
Get started with Creator OS
Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included. If you want an agent reading your research and publishing the write-ups, that is a workable split: your code decides, the agent reports. Start at https://www.creatoros.ca/sign-up.
Related reading: setting up a Claude agent on Creator OS, scheduling clips for consultants, and explainer reels with free, code-drawn video. Docs are at https://www.creatoros.ca/docs.
And watch the walkthroughs on https://www.youtube.com/@KevBuildsApps.
Get started for $0
Free trial for new subscribers. Cancel anytime.
