Building a Weather Bot on Polymarket

Most people approach a weather market like a single bet. The pros treat it as a probability distribution spread across a row of adjacent contracts. That distinction changes everything about how you build a bot to trade them.

The most common form is 'Highest temperature in [city] on [date]?' and the resolution space gets carved into mutually exclusive buckets, each priced from 0 to 100 cents. Exactly one bucket resolves YES, so the prices across all buckets in a market should sum to roughly 100 cents. That's not a coincidence or a convention. It's a hard structural constraint, and it's the first thing your bot should verify on every book snapshot.

That 2°F width is the critical structural fact to internalize before writing a single line of code. A weather model with a mean absolute error of 1.5°F sounds accurate in isolation. Inside a 2°F bucket, that same error is enough to push your probability mass into the wrong contract on a regular basis. You're not forecasting temperature. You're forecasting which specific 2°F slice temperature lands in. Those are different problems.

The Bucket Ladder in Practice

Each bucket trades as a separate instrument with its own token_id, its own order book, and its own bid-ask spread. You can be long one bucket and short its immediate neighbor at the same time. The market doesn't enforce any relationship between adjacent bucket prices. That's your job.

• Each bucket has its own token_id and independent order book.
• Bucket prices range from 0 to 100 cents, representing an implied probability.
• All bucket prices in a single market sum to approximately 100 cents.
• Buckets are typically 2°F wide for temperature markets.
• Precipitation markets exist too, and they often resolve over a full calendar month rather than a single day.

Liquidity Is Not Uniform

Don't assume every weather market trades the same. A busy NYC daily-high market can clear six figures of volume in a single day. A quieter secondary city might do a fraction of that. Thin books mean wider spreads and more slippage, which changes the edge threshold you need before placing an order. Build city-level liquidity tracking into your data model from day one, not as an afterthought.

observed Sum-to-100 divergence in a scraped book snapshot is a reliable signal of a stale or malformed response. Re-fetch before acting.

# Pseudocode: validate a market snapshot before use

def validate_bucket_snapshot(buckets: list[dict]) -> bool:
    """
    buckets: list of dicts, each with keys:
        token_id  (str)
        label     (str, e.g. '88-90°F')
        best_bid  (float, cents)
        best_ask  (float, cents)
        mid       (float, cents)  # (best_bid + best_ask) / 2
    """
    total_mid = sum(b['mid'] for b in buckets)

    TOLERANCE = 5.0  # cents, adjust based on observed spread width

    if abs(total_mid - 100.0) > TOLERANCE:
        # Snapshot is stale or malformed. Do not trade.
        return False

    return True

# If validate_bucket_snapshot returns False, re-fetch the order book.
# Never place an order against a snapshot that fails this check.

Most people assume you need a proprietary forecast to beat a prediction market. Actually, the pros aren't building better models than ECMWF or NOAA. They're just reading ECMWF and NOAA output before the crowd does, and acting on the gap before it closes.

The three major numerical weather prediction models, ECMWF IFS, NOAA GFS, and the GEFS ensemble, run on fixed six-hour cycles at 00Z, 06Z, 12Z, and 18Z. Each completed run produces a revised predicted daily maximum. When that revision is large enough to shift a bucket's fair value, the market should reprice immediately. It doesn't, because retail participants are reading weather apps and news articles, not raw model output feeds. That lag is the window.

The Window Splits by Liquidity

Not all markets reprice at the same speed. The mispricing window splits cleanly along liquidity lines, and that split should drive every architectural decision you make.

observed NYC and London have compressed from a 30 to 60 minute window in 2024 down to roughly 5 to 15 minutes today. That compression is ongoing, not a one-time event.

That asymmetry is structural, not accidental. Liquid markets attract more sophisticated participants who have already built faster pipelines. Secondary markets haven't hit that threshold yet. Build your architecture around which market you're targeting first, because the latency requirement for NYC is an order of magnitude tighter than for Seoul.

What Actually Triggers a Reprice

A new model run doesn't always move the needle. The signal you care about is a revision large enough to shift a bucket's fair value past your edge threshold. Think of it like a price-to-value gap in equities: you don't act on every tick, only when the discount is wide enough to cover your costs and still leave profit. In weather markets, that threshold is a function of how much the new model run moved the predicted temperature and how that movement maps to bucket probabilities.

1. Model run completes and raw output is published (00Z, 06Z, 12Z, or 18Z).
2. Your pipeline ingests the new predicted daily maximum for the target city.
3. Your probability model recalculates fair value across all open buckets.
4. If any bucket's fair value has shifted past your edge threshold, that's your entry signal.
5. The crowd begins repricing minutes to hours later, depending on the market.

# Pseudocode: model-run detection trigger

last_seen_run_timestamp = cache.get('last_model_run_ts')

current_run = fetch_latest_model_output(city='NYC', model='GFS')

if current_run.timestamp != last_seen_run_timestamp:
    cache.set('last_model_run_ts', current_run.timestamp)

    new_fair_values = compute_bucket_probabilities(current_run.predicted_max_temp)
    prev_fair_values = cache.get('last_fair_values')

    for bucket in open_buckets:
        shift = abs(new_fair_values[bucket] - prev_fair_values[bucket])
        if shift >= EDGE_THRESHOLD:   # start at 0.08, tune from backtest
            signal_queue.push({
                'bucket': bucket,
                'direction': 'buy' if new_fair_values[bucket] > market_price[bucket] else 'sell',
                'fair_value': new_fair_values[bucket],
                'market_price': market_price[bucket],
                'shift': shift
            })

    cache.set('last_fair_values', new_fair_values)

Most people building weather bots pull forecast data for a city name or a city-center coordinate. The pros parse the station code out of the market's Rules text before touching any forecast API. The difference isn't academic. A 3 to 8°F offset between a city-center point and an airport station is a consistent directional bias, not noise, and it's driven by three compounding factors: the urban heat-island effect, elevation differences, and proximity to water.

Take New York City as a concrete example. LaGuardia (KLGA) sits on a peninsula in Flushing Bay. Central Park (KNYC) sits inside a concrete grid. Neither matches a midtown rooftop sensor, and Polymarket has cited both across different resolution dates. You cannot hardcode one. If you lock in KLGA and Polymarket resolves against KNYC that week, you've introduced a systematic offset before your model has even run.

observed Polymarket has cited both KLGA and KNYC for New York City across different resolution dates. Parse the station from the Rules text on every cycle.

Confirmed Station Mappings (and Why Each One Matters)

• New York City: KLGA (LaGuardia) or KNYC (Central Park). Must be parsed fresh each cycle, never hardcoded.
• Seoul: Incheon International (RKSI), not downtown Seoul. Airport stations sit outside the urban heat island entirely.
• Wellington: Wellington International (NZWN). The city-center and the airport sit at different elevations with different wind exposure.
• Hong Kong: Hong Kong Observatory (HKO) directly. HKO reports to 0.1°C precision rather than whole degrees, which reprices every boundary bucket compared to a whole-degree station.

Build a Station Registry, Not a City Lookup

The right implementation is a registry keyed by ICAO code. Each entry stores exact lat/lon, data provider, unit system, and reported precision. Precision belongs on the station record, not as a global setting, because HKO's 0.1°C resolution means boundary buckets are priced differently than they would be under whole-degree rounding at a US station.

STATION_REGISTRY = {
  "KLGA": {
    "lat": 40.7772,
    "lon": -73.8726,
    "provider": "nws",          # api.weather.gov/points/{lat},{lon}
    "unit": "fahrenheit",
    "precision": 1.0            # whole degrees
  },
  "KNYC": {
    "lat": 40.7789,
    "lon": -73.9692,
    "provider": "nws",
    "unit": "fahrenheit",
    "precision": 1.0
  },
  "RKSI": {
    "lat": 37.4691,
    "lon": 126.4505,
    "provider": "open_meteo",
    "unit": "celsius",
    "precision": 1.0
  },
  "HKO": {
    "lat": 22.3020,
    "lon": 114.1740,
    "provider": "hko_direct",   # separate query path, not on standard aggregators
    "unit": "celsius",
    "precision": 0.1            # 0.1°C resolution changes bucket boundaries
  }
}

def get_station_for_market(market_rules_text: str) -> dict:
    """Parse ICAO code from Rules text. Return registry entry.
       Raise UnresolvableMarket if code not found in registry."""
    icao = extract_icao_from_rules(market_rules_text)  # regex over known codes
    if icao not in STATION_REGISTRY:
        raise UnresolvableMarket(f"Unknown station: {icao}. Review manually.")
    return STATION_REGISTRY[icao]

For US stations, the NWS api.weather.gov/points/{lat},{lon} endpoint resolves coordinates to the correct forecast gridpoint and also exposes hourly station observations. That gives you forecast and historical actuals from one pipeline. For international stations, use published ICAO coordinates with Open-Meteo. For Hong Kong, build a separate HKO query path entirely. HKO data isn't on Weather Underground or any standard aggregator.

Most people assume serious quantitative work requires expensive data subscriptions. The free stack here is genuinely complete: ensemble probabilities, intraday station observations, and decades of archive-grade ground truth, all without a single invoice.

Open-Meteo: The Core Forecast Engine

Open-Meteo aggregates more than 30 numerical weather models, including ECMWF IFS, NOAA GFS and HRRR, DWD ICON, and the 31-member GEFS ensemble. It processes over 2 TB of data daily from national weather services worldwide, requires no API key or account, and is free for non-commercial use under CC-BY 4.0. That's a serious data pipeline, not a hobbyist project.

Rate limits are tiered at 10,000 calls per day, 5,000 per hour, and 600 per minute. For a bot tracking roughly 20 active market groups with hourly polling, that ceiling is comfortable. You'd have to work hard to hit it.

The Most-Overlooked Feature: Historical Forecast API

There's a critical difference between what the model predicted on a past date and what actually happened. Most people only pull observed outcomes. That's the wrong dataset for bias-correction training.

observed Open-Meteo's Historical Forecast API covers data from roughly 2021 onward and returns what the model predicted on a specific past date, not the verified observation. Pair those archived predictions against NOAA GHCN-Daily actuals and you have a ready-made bias-correction training set.

The Full Free Stack

NWS only requires a User-Agent header in your requests, which is a one-line addition to any HTTP client. NOAA GHCN-Daily is a flat-file archive you can download once and update incrementally. Neither requires registration.

# Open-Meteo: pull all 31 GEFS ensemble members for a specific station
import openmeteo_requests

om = openmeteo_requests.Client()

params = {
    "latitude": 40.7769,       # KLGA exact coords, not Midtown
    "longitude": -73.8740,
    "models": "gefs025",       # 31-member ensemble
    "hourly": ["temperature_2m"],
    "forecast_days": 7
}

response = om.weather_api("https://ensemble-api.open-meteo.com/v1/ensemble", params=params)

# Historical Forecast API: what did the model predict on 2024-01-15?
hist_params = {
    "latitude": 40.7769,
    "longitude": -73.8740,
    "models": "gfs_seamless",
    "hourly": ["temperature_2m"],
    "start_date": "2024-01-15",
    "end_date": "2024-01-15"
}

hist_response = om.weather_api(
    "https://historical-forecast-api.open-meteo.com/v1/forecast",
    params=hist_params
)

# NWS: intraday station observations (User-Agent header required)
import requests

headers = {"User-Agent": "your-bot-name contact@youremail.com"}
obs_url = "https://api.weather.gov/stations/KLGA/observations/latest"
nws_obs = requests.get(obs_url, headers=headers).json()

Most people look at a model forecast and think the number is the answer. It isn't. A forecast of 91°F tells you nothing about whether the actual high lands in the 90–92°F bucket versus the 88–90°F bucket. The pros treat that forecast as the center of a distribution, then ask: given how wrong this model typically is at this lead time, at this station, in this season, what fraction of that distribution falls inside each bucket?

Path A: Deterministic Single-Model Run

Apply your bias correction first (Step 04), then treat the corrected forecast as the mean of a normal distribution. The standard deviation comes from your own historical error analysis, fit by station, lead time, and season. Illustrative starting values run from roughly 0.8°F at a 6-hour lead to around 5.5°F at 10 days. Bucket probability is the integral of the normal CDF between the bucket's lower and upper bounds.

from scipy.stats import norm

def bucket_probs_gaussian(mu, sigma, buckets):
    """
    mu     : bias-corrected forecast (°F)
    sigma  : station/lead/season error std (°F)
    buckets: list of (lower, upper) tuples
    returns: probability vector summing to 1.0
    """
    probs = []
    for lower, upper in buckets:
        p = norm.cdf((upper - mu) / sigma) - norm.cdf((lower - mu) / sigma)
        probs.append(p)
    total = sum(probs)
    return [p / total for p in probs]  # renormalize to handle open-ended tails

Path B: Ensemble Output (GEFS 31-Member or ECMWF ENS)

With ensemble output, skip the Gaussian entirely. Each of the 31 GEFS members is an independent draw from the model's uncertainty space, so you already have an empirical distribution. Count how many members land inside each bucket, divide by 31, then optionally smooth with a light Gaussian filter to reduce discretization noise at small N.

import numpy as np
from scipy.ndimage import gaussian_filter1d

def bucket_probs_ensemble(members, buckets, smooth_sigma=0.8):
    """
    members: array of 31 temperature forecasts (°F)
    buckets: list of (lower, upper) tuples
    returns: probability vector summing to 1.0
    """
    counts = np.array([
        np.sum((members >= lo) & (members < hi))
        for lo, hi in buckets
    ], dtype=float)
    if smooth_sigma > 0:
        counts = gaussian_filter1d(counts, sigma=smooth_sigma)
    total = counts.sum()
    return counts / total if total > 0 else counts

Blend, Then Anchor to Climatology

After producing both vectors, blend by skill weight. The deterministic run tends to outperform the ensemble mean inside 48 hours. Beyond 5 days, the ensemble spread is the more reliable signal. Once blended, apply a final pull toward the 10-year climatological base rate for that calendar date at that station. This keeps extreme estimates honest when the model is running unusually hot or cold.

def blend_and_anchor(det_probs, ens_probs, det_weight, climo_probs, climo_weight=0.08):
    """
    det_weight : scalar 0.0–1.0 (higher inside 48 h, lower beyond 5 days)
    climo_weight: fraction pulled toward climatology (start at 0.08)
    """
    ens_weight = 1.0 - det_weight
    blended = [
        det_weight * d + ens_weight * e
        for d, e in zip(det_probs, ens_probs)
    ]
    anchored = [
        (1 - climo_weight) * b + climo_weight * c
        for b, c in zip(blended, climo_probs)
    ]
    total = sum(anchored)
    return [p / total for p in anchored]  # final renormalize

observed The output of this step is a single probability vector summing to 1.0 across all buckets. Subtract market prices from that vector and you have your raw edge before any position sizing.

Most new bot builders skip straight to XGBoost or a U-Net and wonder why the system that looked sharp in a notebook loses money live. The pros do something different: they remove the predictable, systematic error first, using methods that have been battle-tested in operational meteorology for decades, and only then layer on anything fancier. These three methods together remove 60–80% of achievable systematic bias before a single ML weight is trained.

The core problem is that a GFS grid cell near LaGuardia is not LaGuardia. The model's 2-meter temperature carries systematic bias that shifts by location, season, and lead time. That bias is not random noise. It's structured, it's measurable, and it compounds directly into bad bucket probabilities if you leave it in.

Method 1: Exponential Smoothing

This is the fastest to implement and the most common starting point. You track the model's recent errors and fade out the influence of older ones using a decay parameter alpha. Set alpha between 0.95 and 0.98. Higher alpha means older errors stay relevant longer, which is right for slow-moving seasonal drift. Lower alpha lets the corrector react faster to abrupt shifts. The compute cost is essentially zero: one multiply and one add per observation.

# Exponential smoothing bias corrector
# bias_t: current bias estimate
# error_t: (observed - forecast) at time t
# alpha: smoothing factor, typically 0.95–0.98

bias_t1 = alpha * bias_t + (1 - alpha) * error_t
corrected_forecast = raw_forecast + bias_t1

observed Alpha in the 0.95–0.98 range captures seasonal and regional bias effectively at near-zero compute cost. Values outside this range tend to either overreact to single outliers or adapt too slowly to real drift.

Method 2: Model Output Statistics (MOS)

MOS is a meteorology classic that still outperforms most ML approaches on small datasets. You fit a simple linear regression to the raw forecast, using the model output as your predictor and observed surface measurements as your target. The real power comes from adding covariates: cloud cover, wind speed, land type, and elevation all help the regression absorb the diurnal cycle that raw grid output consistently gets wrong. MOS requires a training set, but that's exactly what Open-Meteo's Historical Forecast API provides from roughly 2021 onward.

# MOS: fit a linear corrector per station per lead time
# Features: raw_temp, cloud_cover, wind_speed, land_type_encoded
# Target: observed_temp

from sklearn.linear_model import LinearRegression

X_train = historical_forecasts[['raw_temp', 'cloud_cover', 'wind_speed', 'land_type']]
y_train = historical_observations['observed_temp']

mos_model = LinearRegression().fit(X_train, y_train)
corrected_forecast = mos_model.predict(X_live)

Method 3: Kalman Filter

The Kalman filter is the most adaptive of the three. Instead of fitting a static corrector, it updates the bias estimate continuously in real time, scaling the correction by how much trust the model has recently earned. When the model has been accurate, the filter leans on its own prior estimate. When recent errors are large, it weights new observations more heavily. This makes it the right choice when you're tracking multiple cities or when GFS or ECMWF pushes a version update that shifts the model's baseline.

# Simplified scalar Kalman filter for bias tracking
# bias: current bias estimate
# P: estimate uncertainty
# Q: process noise (how fast bias drifts)
# R: observation noise (sensor/measurement uncertainty)

K = P / (P + R)                        # Kalman gain
bias = bias + K * (observed - (forecast + bias))  # update
P = (1 - K) * P + Q                    # update uncertainty

observed The Kalman filter adapts cleanly to season transitions and model version updates without requiring a full refit. That's a meaningful operational advantage over static MOS when you're running markets across many cities simultaneously.

Most people think edge means being right more often than the market. It doesn't. Edge means being right by enough to overcome the spread, fees, and the irreducible variance baked into short-range forecasts. A model reading of 55% against a market ask of 53% looks like an edge. It isn't. That 2-point gap evaporates the moment you account for the bid-ask spread and the fee on settlement.

The 8% Threshold

The minimum edge practitioners cite to stay profitable is 8%, measured simply: model_prob - best_ask for a YES trade, or best_bid - model_prob for a NO trade. Treat 8% as a calibration starting point, not gospel. Your own backtest across your specific cities and forecast horizons may tell you 6% or 10% is the right floor. But start at 8% and let the data move you.

def compute_edge(model_prob, best_ask, best_bid):
    edge_yes = model_prob - best_ask      # positive = YES has edge
    edge_no  = (1 - model_prob) - (1 - best_bid)  # equiv: best_bid - model_prob
    return edge_yes, edge_no

MIN_EDGE = 0.08

edge_yes, edge_no = compute_edge(model_prob=0.55, best_ask=0.53, best_bid=0.50)
# edge_yes = 0.02  -> below threshold, no trade
# edge_no  = -0.05 -> no edge on NO side either

Sizing: Quarter-Kelly With a Hard Cap

Full Kelly is mathematically optimal and practically brutal. One bad streak puts you down 40% before you've had time to diagnose whether the model is broken or just unlucky. The fix is quarter-Kelly with a hard 5% per-market cap. The 5% cap is a ceiling, not a target. Quarter-Kelly keeps you solvent long enough for the edge to compound across hundreds of trades.

def kelly_size(edge, odds, bankroll, kelly_fraction=0.25, max_pct=0.05):
    # edge = model_prob - price paid
    # odds = (1 / price) - 1  (net odds on a binary)
    full_kelly = edge / odds
    fractional = full_kelly * kelly_fraction
    capped = min(fractional, max_pct)
    return capped * bankroll

# Example: edge=0.12, price=0.40, bankroll=$10,000
# full_kelly = 0.12 / 1.50 = 0.080
# quarter_kelly = 0.020  -> $200
# cap check: 2.0% < 5.0% -> position = $200

Spread Across Markets, But Watch Regional Correlation

Trading 20+ markets beats concentrating in 2, but only if those markets are genuinely independent. Weather is regionally correlated: a single cold snap can simultaneously hit Chicago, NYC, and Boston. If your bot fires full-size entries across all three at once, you've accidentally concentrated your risk. Apply a correlation haircut to your Kelly fraction for cities in the same climate zone.

REGIONAL_GROUPS = {
    'northeast_us': ['NYC', 'Boston', 'Philadelphia'],
    'midwest_us':   ['Chicago', 'Detroit', 'Cleveland'],
    'southeast_us': ['Atlanta', 'Miami', 'Charlotte'],
}

CORRELATION_HAIRCUT = 0.6  # reduce Kelly by 40% for same-region co-entries

def adjusted_kelly(city, active_positions, base_kelly):
    region = get_region(city)
    same_region_open = sum(
        1 for c in active_positions if get_region(c) == region
    )
    haircut = CORRELATION_HAIRCUT ** same_region_open
    return base_kelly * haircut

Monitor Model Health With Rolling Brier Score

Brier score measures calibration on a 0.0 to 0.25 scale. A perfectly calibrated model scores 0.0. Random 50/50 guessing scores 0.25. Track it per city and per forecast horizon on a rolling 30-day window. If a city's rolling Brier drifts above 0.15, flag it. Above 0.20, soft-disable it until you've diagnosed the cause. Don't wait for a catastrophic blowup to notice the model has gone stale.

• Brier score = (model_prob - outcome)^2, averaged over all resolved markets in the window.
• Rolling window: 30 days. Recompute after every settlement.
• Flag threshold: 0.15. Log a warning, review recent forecasts manually.
• Soft-disable threshold: 0.20. Bot skips that city entirely until Brier recovers below 0.15 over a fresh 30-day window.
• Track separately by forecast horizon (24h, 48h, 72h). A model that's sharp at 24h can be noisy at 72h.

observed The 8% edge floor and the Brier soft-disable thresholds (0.15 flag, 0.20 disable) are figures practitioners have converged on through live trading, not theory. Your own calibration may shift them, but they're the right starting defaults.

Install the library with pip install py-clob-client. The stable production line is v0.34.6. An early-stage v2 exists but isn't production-ready for a bot that needs to run unattended.

Authenticate Once, Then Trade

Instantiate ClobClient with three things: chain_id=137 (Polygon mainnet), your private key, and a signature_type. Use 0 for a standard EOA wallet, 1 for a Magic or email-proxy wallet, and 2 for a Safe or browser-proxy wallet. Most bots use 0. Pass your funder address as well. Then call create_or_derive_api_creds() once to generate session credentials. Do this before anything else, and set token allowances before your first order or the submission will fail silently with no useful error.

from py_clob_client.client import ClobClient
from py_clob_client.clob_types import OrderArgs, OrderType

client = ClobClient(
    host="https://clob.polymarket.com",
    key=PRIVATE_KEY,
    chain_id=137,
    signature_type=0,
    funder=FUNDER_ADDRESS,
)

# Run once to generate session creds
client.create_or_derive_api_creds()

# Set allowances before first order
client.set_allowances()

Post a Single Limit Order

Build an OrderArgs object with token_id, price, size, and side. Sign it with create_order(), then submit via post_order() with OrderType.GTC for a resting limit. When you want an immediate fill, post one tick through the best ask instead of switching order types. That said, the CLOB does support true market orders via FOK and FAK on MarketOrderArgs. Most weather plays use limits, but knowing FOK and FAK exist matters when your edge is time-sensitive.

from py_clob_client.clob_types import OrderArgs, OrderType, Side

args = OrderArgs(
    token_id=TOKEN_ID,
    price=0.61,
    size=50.0,
    side=Side.BUY,
)

signed_order = client.create_order(args)
resp = client.post_order(signed_order, OrderType.GTC)
print(resp)

Batch Up to 15 Orders Per Call

When your model flags several mispriced buckets in the same market simultaneously, don't submit them one at a time. Sign each with create_order(), collect the signed objects into a list, and fire them all in a single post_orders() call. The batch cap is 15 orders per call. If you're trading more than 15 buckets at once, split into sequential batches and handle partial failures per batch before moving to the next.

signed_orders = []
for bucket in mispriced_buckets:          # up to 15
    args = OrderArgs(
        token_id=bucket["token_id"],
        price=bucket["edge_price"],
        size=bucket["size"],
        side=Side.BUY,
    )
    signed_orders.append(client.create_order(args))

# All orders hit the book in the same state
resp = client.post_orders(signed_orders)

# Handle partial failures before next batch
for result in resp:
    if result.get("status") != "matched" and result.get("status") != "live":
        log_failed_order(result)

observed Batching keeps all legs in the same book state. Submitting them sequentially means the first fill can move the market before the second order lands.

Switch From REST Polling to the WebSocket

Polling REST is fine during development. In production it's too slow. Subscribe to wss://ws-subscriptions-clob.polymarket.com/ws/market instead. Use the book channel for full snapshots on connect, price_change for incremental updates as the book moves, and last_trade_price for confirmed fills.

That 10x gap matters when your edge window is measured in minutes, not hours. A passive limit posted on stale REST data is a passive limit posted at the wrong price.

import asyncio, json, websockets

SUBSCRIPTION = {
    "auth": {"apiKey": API_KEY, "secret": API_SECRET, "passphrase": API_PASSPHRASE},
    "type": "subscribe",
    "channel": "price_change",
    "market_slugs": [MARKET_SLUG],
}

async def stream_book():
    uri = "wss://ws-subscriptions-clob.polymarket.com/ws/market"
    async with websockets.connect(uri) as ws:
        await ws.send(json.dumps(SUBSCRIPTION))
        async for msg in ws:
            event = json.loads(msg)
            handle_price_change(event)

asyncio.run(stream_book())

Rate Limits and Model-Run Windows

The public (unauthenticated) CLOB endpoint allows roughly 100 requests per minute. Route all book queries through the authenticated client and that ceiling rises to roughly 1,000 per minute. Set this up from day one, not after you hit the limit mid-session.

Build exponential backoff into every REST call from the start. Then add one more rule: widen or pause any resting passive quotes around the 00Z, 06Z, 12Z, and 18Z model-run release times. That's when informed flow spikes as traders react to new NWP data. A passive limit sitting in the book at those moments isn't providing liquidity. It's adverse-selection bait.