Polymarket Weather Trading Bot Build with Claude ($6k/Month Blueprint)

Everyone told you a trading bot needs fancy AI and a data center.

That's a lie that keeps beginners from ever starting.

Here's the truth: a profitable Polymarket weather bot is a WEEKEND build, and by the end of this you'll have the whole pipeline.

Weather is the opposite of 5-min BTC.

BTC windows are a coin flip you cannot predict, and the speed war is owned by colocated bots.

Temperature is genuinely predictable, resolves over hours so speed means nothing, and the data is free.

It's the last market where a solo dev with a cheap VPS still wins on brains, not hardware.

The whole machine is six steps.

Discover the markets, pull the forecasts, fix the bias, turn it into probabilities, find the 8% edge, size and fire.

That's it.

Let me hand you each piece.

I built hundreds of bots and the ones that print are always this simple, not the over-engineered ones people assume you need.

Here's my public wether bot example: \https://polymarket.com/profile/0xca75fbadcc238afd23c317e253a8b5c47b390a64?via=surfer

Still developing it and going through a lose streak i'm trying to fix.

But still, it's not bleeding all the time like previous versions.

Let's now build you a money printer.

1. Concept and idea

Before code, get the picture clear, cause it makes every step obvious.

Polymarket lists daily temperature markets for cities around the world.

Each one is a set of buckets.

One bucket resolves YES at a dollar, the rest go to zero.

The market resolves on ONE exact airport station, not the city you see in your weather app.

Your bot's job is simple to say.

Figure out the real probability of each bucket better than the crowd, then buy the buckets the market underpriced.

You are NOT forecasting the weather yourself.

Billion-dollar models already did that hours ago.

You're reading their forecast, cleaning it up, and comparing it to the market price.

Where your honest probability is a lot higher than the price, you have an edge.

Everything below is just how to compute that gap and act on it without fooling yourself.

Keep every setting in a config file, not hardcoded, so you can tune without touching logic.

Starting balance, max trade, minimum edge, price caps, Kelly fraction.

All of it lives in one place you can edit in seconds.

2. Discover the markets

The bot starts by scanning Polymarket for active temperature markets worth trading.

You don't want to trade all of them.

You want a filter that throws out the junk before you waste a forecast call or a dollar.

Three filters do most of the work:

> Volume floor

Skip thin markets under a few thousand in volume.

Thin books have wide spreads and prices you can't trust.

> Time window

Only trade markets resolving between about 2 and 72 hours out.

Under 2 hours the edge is already priced in.

Past 72 hours the forecast is too uncertain to lean on.

> Price cap

Skip buckets already trading above about 45c.

At that price the market has priced in most of the edge and your upside is thin.

Each surviving market points at a city, a date, and a resolution station.

That station is everything, so you store its exact airport coordinates and its ICAO code, never the city center.

Using city-center coordinates can introduce a 3-8 degree error before your bot even starts thinking.

Now you have a clean list of tradeable markets, each tied to the precise spot the forecast has to target.

3. Ingest the forecast (code)

Now you pull forecasts for each market's exact station, from more than one source.

One model is an opinion.

Three models let you see agreement and disagreement, which is information by itself.

Your anchor is ECMWF, the global gold standard, free through Open-Meteo, no key needed.

For US cities on short horizons you add a higher-resolution model that reads real-time observations.

Here's the ECMWF fetch:

1def get_ecmwf(lat, lon, unit):
2url = (
3"https://api.open-meteo.com/v1/forecast"
4f"?latitude={lat}&longitude={lon}"
5f"&daily=temperature_2m_max&temperature_unit={unit}"
6"&forecast_days=7&models=ecmwf_ifs025"
7"&bias_correction=true"
8)
9data = requests.get(url, timeout=(5, 8)).json()
10return data["daily"]["temperature_2m_max"]

That \bias_correction=true\ flag matters - it applies a first pass of location-based error correction for free.

For US cities within about 48 hours, prefer the higher-res model:

1def get_hrrr(lat, lon):
2url = (
3"https://api.open-meteo.com/v1/forecast"
4f"?latitude={lat}&longitude={lon}"
5"&daily=temperature_2m_max&temperature_unit=fahrenheit"
6"&forecast_days=3&models=gfs_seamless"
7)
8return requests.get(url, timeout=(5, 8)).json()["daily"]["temperature_2m_max"]

Simple rule: high-res for US short-range, ECMWF for everything else.

Request each city in its own unit, US in Fahrenheit, the rest in Celsius, and keep every comparison on the same scale.

4. Fix the bias (this is where money is)

This is where winners separate from everyone else.

Every model is systematically wrong in a consistent direction.

GFS runs a cold bias, it underestimates temperature, and the size of that miss depends on the city, the hour, and how far out the forecast is.

If you skip this, your edge is often just the model being wrong in its usual way.

That's not edge.

That's noise in an edge costume.

So before you compute a single probability, you correct the model using its own past errors.

Bias is dead simple to define.

> bias = forecast minus actual

You measure it separately per city, per horizon, per time of day, then shift new forecasts by that known error.

The simplest version that works is a decaying average of recent errors, so newer misses count more.

You do NOT need a neural network for this.

A basic decaying average or a small regression gets you 60-80% of all the improvement available.

Ship that first.

The fancy ML bias correction is real, but it's the last 20%, and it only matters once the simple version is already printing.

Fix the inputs first.

A boring free model, corrected, beats a fancy model fed raw.

5. Turn forecasts into bucket probabilities

Now you convert one corrected forecast number into a probability for each bucket.

Here's the mistake beginners make.

They take the forecast, drop it in whatever bucket it lands in, and call that bucket 100%.

But the forecast is not exact.

It's a center point with a known spread of error around it.

That spread is the whole game.

Say your corrected forecast is 41F and your model's typical error for that city is about 2 degrees.

The real high could easily land a bucket up or down.

So you don't bet one bucket at 100%.

You spread the probability across the forecast bucket AND its neighbors, weighted by how likely each is given your error size.

A tighter historical error means more probability piled on the center bucket.

A wider error spreads it out across the neighbors.

This is exactly why knowing your real error, your sigma, matters so much.

Without it you're guessing your own confidence.

With it, you're turning a forecast into an honest probability distribution the market can be measured against.

That distribution is what you actually trade on, bucket by bucket.

6. Find the edge ad size with Kelly

Now you compare your probability to the market price and only act when the gap is real.

First, expected value, your edge per dollar:

1def calc_ev(p, price):
2if price <= 0 or price >= 1:
3return 0.0
4return round(p * (1.0 / price - 1.0) - (1.0 - p), 4)

If your model says a bucket is 80% and it's trading at 14c:

\0.80 * (1/0.14 - 1) - 0.20 = +4.94\

That's a huge edge.

But you don't fire on every positive number - you set a floor, only trade when EV clears about 8%, so you skip the weak signals.

Then Kelly tells you how much of your bankroll to bet:

1def calc_kelly(p, price, kelly_fraction=0.25):
2b = 1.0 / price - 1.0
3f = (p * b - (1.0 - p)) / b
4return min(max(0.0, f) * kelly_fraction, 1.0)

Two guardrails that keep you alive.

> Use fractional Kelly, a quarter of what full Kelly says

Full Kelly is a rollercoaster, the fraction cuts variance hard.

> Hard-cap every trade at a max bet from your config

Even if Kelly screams to trade big, the cap saves you from a single bad market.

Enter at the ASK, the real price you pay, and treat the bid as your exit, or your backtest lies to you.

7. Execute, stop and log everything

Now the bot acts, and just as importantly, records.

The main loop runs on a schedule, say every hour, and does the same thing in order for each market.

Pull fresh forecasts from all sources

Find the matching Polymarket market and load its record

Save current forecast as a snapshot, cause that history is your future edge

Check stops on any open position

Open a new position only if the EV clears your floor and the price is right

https://x.com/0xSurferX/status/2078620667272896555

Your stops are simple and mechanical.

Close if price drops a set percent from entry.

Close if the forecast moves far enough out of your bucket that the thesis is dead.

Between full scans, run a light pass every few minutes just to watch stops, without re-scanning every city.

And log absolutely everything.

Every forecast snapshot, every market price you saw, every trade, every resolution.

One file per market, appended over time.

That log is not busywork.

It's the raw material for the last step, the one that turns a static bot into one that gets sharper every week.

8. Let it calibrate and get smarter

Here's what separates a bot that guesses from one that KNOWS.

On day one, your bot has no real idea how accurate its forecasts are for each city.

So it shouldn't fully trust itself yet.

It should trade small, log every resolution, and wait.

Once it has enough resolved markets for a city, around 30, it can measure its true error.

You take every forecast you made for that city, compare it to what actually happened, and compute the average miss.

That average error becomes your sigma, your real confidence, for that exact city and source.

And that sigma feeds straight back into step four.

Better sigma means a more honest probability spread across buckets, which means better edge detection, which means better sizing.

The bot literally improves itself as it collects more resolved markets.

This is the same discipline i preach for every bot i build:

Log everything, risk little at first

Let real resolved outcomes measure your true accuracy

Only size up once the data has proven the edge

A weather bot that trusts itself at 90% on day one is the same disaster as a crypto bot deployed off a 10,000% backtest.

Both trusted a number they never earned.

You don't wanna see smth like this, believe me:

Let's move on.

9. Putting it all together

Now let's do some conclusion.

**

Step back and look at what you built:**

Discover clean markets, tied to the exact resolution station

Pull three forecast sources for that station

Correct each model's known bias

Turn the corrected forecast into bucket probabilities using your real error

Trade only when the edge clears 8%

Size with fractional Kelly and a hard cap

Execute, stop, log, and calibrate until it sharpens itself

No neural network required to start, no data center or colocated servers.

Just free forecasts, honest math, and the patience to let it prove itself on real resolutions.

Leave it running two to three weeks before you judge it, cause weather markets resolve daily and you need 50-100 resolved trades to know what you've got.

I built 200+ bots and this exact shape is what actually prints while the fancy stuff sits unfinished.

Simple pipeline, honest calibration, boring discipline.

That's actually all you need.

Weather is the last honest market on Polymarket.

Build the six steps this weekend, let it calibrate, and get in before the crowd wakes up.

Full breakdown of the bias-correction step coming next, don't miss it.

Releasing p.2 on Wednesday.

Also join my small tg chan if you want to connect.

Join here: https://t.me/+jCBHygDAJa9hMTJk

Here we build together, discuss and fix issues.

Hope you found this article useful, cause this is the whole point.

Wish u luck!