How to Build a Kalshi Weather Trading Bot With AI

By the end of this guide you'll have a Kalshi weather bot running on a server, placing trades while you sleep, while you work, and while you do absolutely anything else.

We're building it from scratch. Every step, including the exact prompt that writes the code for you — you don't need to know how to program.

I have a degree in meteorology, which is probably why this particular market caught my attention. Kalshi runs markets on daily high and low temperatures, split into buckets. If your forecast says a bucket is more likely than its price implies, there's a mispricing to buy.

That's the whole idea. Now let's turn it into software that trades it automatically.

Disclosure: the Kalshi referral link is the only monetization here — it currently pays $25 in credits when you trade your first $25. I have no affiliation with DigitalOcean, GitHub or any other tool mentioned; I just use them.

Table of Contents

• What Are Kalshi Weather Markets?
  • How the Temperature Buckets Work
  • Where the Edge Comes From
• Prerequisites: What You'll Need
• The Prompt That Builds the Bot
  • How to Fill It In
• Step-by-Step: From Prompt to Live Bot
  • Step 1 — Paste the Prompt Into Your Coding Agent
  • Step 2 — Review What It Built
  • Step 3 — Read the Decision Table
  • Step 4 — Set Up GitHub and a Droplet
  • Step 5 — Deploy and Confirm It Runs on Boot
  • Step 6 — Create Your Kalshi API Key
  • Step 7 — Turn Off Dry Run
  • Step 8 — Verify the First Live Trade
• Why Long Shots Are Not a Bug
• Why Fill Rate Matters More Than Theory
• Keep Your Brain in the Loop
• Common Mistakes to Avoid
• Tips and Best Practices
• Frequently Asked Questions
• The Bottom Line

Key Takeaways

• You don't write any code. A detailed prompt does the heavy lifting; you direct and verify.
• Kalshi splits daily temperature into buckets, and each bucket's price is roughly its implied probability.
• Edge = your forecast's fair probability minus the Kalshi ask.
• The bot models the forecast as a bell curve, using your forecast spread as the standard deviation.
• Dry run is on by default — it prints decisions without placing anything until you explicitly turn it off.
• A $6/month DigitalOcean droplet is enough to start; $24/month buys more space as data grows.
• Your GitHub deploy key must be read-only. Leave the write access box unticked.
• Start at $1 per trade. The first live order in this build cost 97 cents for 7 contracts.
• Long shots aren't a flaw — a 5¢ contract pays $1, so a low hit rate can still be profitable.
• Claude Code desktop is easier than the web version for this kind of multi-step deployment.

What Are Kalshi Weather Markets?

Open the climate section on Kalshi and you'll find markets on high temperatures in New York City and Chicago, whether a hurricane makes landfall in Hawaii this year, and plenty more.

The appeal is immediate. If you're confident no hurricane makes landfall in Hawaii this year, you can take the No side and turn roughly $10 into about $11.51. That's not life-changing money in absolute terms, but the percentage return on a high-confidence view is genuinely reasonable.

Kalshi also pays interest on both your cash and your open positions, which quietly improves the math on holding anything to settlement.

The limitation is obvious the moment you try to scale it: you can't be everywhere at once. There are dozens of cities, two markets per city per day, and every one of them reprices constantly. That's precisely the kind of problem software solves.

How the Temperature Buckets Work

Take Austin, Texas as the working example. The National Weather Service publishes a forecast high. Kalshi runs a market on that exact number, split into buckets:

• 95 or below
• 96 to 97
• 98 to 99
• 100 to 101
• and so on

Each bucket's price is roughly the market's estimate of the odds. A bucket trading at 23¢ implies about a 23% chance. A bucket at 5¢ implies about 5%.

One important mechanical detail: the official temperature is a whole number, so a "98° to 99°" bucket actually covers 97.5 to 99.5 on a continuous probability curve. That rounding matters when you calculate fair value.

Where the Edge Comes From

The edge is a disagreement between your forecast and the market's price.

Suppose your model says there's a 68% chance the high lands between 67 and 68 today, and Kalshi is pricing that bucket at 64¢. You're buying something you believe is worth more than it costs. Do that repeatedly with a genuine edge and the math works in your favor.

The edges will be small. This isn't a 90%-win-rate machine. But consider the arithmetic: if you can capture a one-cent edge consistently, every single day, that compounds — especially with size. The constraint then becomes how much size these markets can actually absorb, which is a real limit worth discovering early.

Prerequisites: What You'll Need

• A Kalshi account — you'll create an API key ID and private key partway through.
• A coding agent. Claude Code was used here. Codex or a comparable agent works too. The desktop app is meaningfully easier than the web version for this kind of multi-step deployment.
• A free GitHub account at github.com. Your coding agent connects to it so your code is stored safely and you can go back and edit later.
• A DigitalOcean account. A 1 GB droplet at $6/month is plenty to start. I'm on $24/month now purely for more space. Ask your agent what you actually need based on your data volume and strategy complexity — it'll recommend a tier.
• Python installed on your computer, from python.org. One-time setup.
• A small amount of real capital. The first live order in this build was $1.
• Skill level: no coding required. You need patience for back-and-forth and a willingness to verify what the AI builds.

The Prompt That Builds the Bot

This is the prompt that does the work. Copy it, fill in the settings, and paste it into Claude Code, Codex, or whichever agent you're using.

I want to build a simple trading bot for Kalshi weather markets. I don't know
how to code, so you'll write everything. Explain each step in plain English,
and whenever I need to run a command, tell me exactly where to run it (which
app, how to open it, which folder) and what I should see if it worked.

MY SETTINGS (fill these in; for anything left blank, explain the options and
help me pick before writing any code)
City:               ____________  (e.g., Austin, Denver, Miami, Chicago)
Market:             ____________  (daily HIGH or daily LOW temperature)
Which day:          ____________  (trade tomorrow's market or today's)
Forecast source:    ____________  (default: National Weather Service)
Forecast spread:    ____ °F       (how far off the forecast usually is;
                                   roughly 2-4 for tomorrow)
Minimum edge:       ____ points   (how mispriced a bucket must be to buy)
Price range:        ____¢ to ____¢ (skip buckets priced outside this)
Bet type:           ____________  (YES only, or YES and NO)
Max $ per trade:    $____         (start small, e.g., $1)
Max trades per day: ____
Check every:        ____ minutes  (5 is plenty)
My own twist:       ____________  (optional, e.g., "only trade when two
                                   forecasts agree" or "skip weekends")

THE IDEA
A weather service publishes a forecast high or low for my city. Kalshi runs a
market on that exact number, split into buckets like "98° to 99°" or "104° or
above." Each bucket's price is roughly the market's guess at the odds: a 23¢
price means about a 23% chance. If my forecast says a bucket is much more
likely than its price suggests, the bot buys it.

BEFORE ANY CODE
Find the Kalshi series ticker for my city and market. Read the market's rules
to find the exact weather station it settles on, and confirm both with me.
Use the forecast for that station's location, not the city center.

WHERE THE DATA COMES FROM
1. Forecast: my chosen source. If it's the NWS, use api.weather.gov. It's
   free with no key, but every request needs a User-Agent header.
2. Prices: Kalshi's public market data. No login needed to read it.
3. Trading: Kalshi's authenticated API, using my API key ID and private key
   file. The request signing is specific, so follow Kalshi's current docs
   (docs.kalshi.com, full index at docs.kalshi.com/llms.txt). Don't guess.

HOW IT DECIDES
- Treat the forecast as the middle of a bell curve, using my forecast spread
  as the standard deviation.
- The official temperature is a whole number, so "98° to 99°" covers 97.5 to
  99.5 on the curve. Get each bucket's range from the market data, not from
  the ticker name.
- For each bucket: edge = fair chance from the curve minus the Kalshi ask.
- Buy the bucket with the biggest edge, but only if it clears my minimum edge
  and sits inside my price range. Follow my bet type and my own twist.
- Make every setting above easy to change later in one place.
- Every check, print a clear table: bucket, fair %, Kalshi price, edge,
  and BUY or PASS.

SAFETY RULES
- DRY_RUN is on by default: show what it would do, place nothing. Real orders
  only when I set DRY_RUN=false.
- Never exceed my max $ per trade or max trades per day. Save what it bought
  to a file so a restart can't double-buy.
- Limit orders at the current ask only. Never market orders.
- API keys live in a .env file. Never in the code, never printed on screen.
- If anything errors, log it and skip that round. Never blindly retry an order.
- Use my city's local time zone for all dates, even if the computer is set to
  a different time zone.

HOW IT'S BUILT
- Python, with as few files and libraries as possible.
- Checks on my schedule and writes every decision to a log file.

BUILD IT IN 3 STAGES. Stop after each stage and wait for me to say "next."
Stage 1 - Dry run: pull the forecast and prices, print the decision table.
          No Kalshi account needed yet.
Stage 2 - Go live: walk me through creating a Kalshi API key, check my balance
          to prove the login works, then turn DRY_RUN off. If it finds a
          trade, place the order and show me how to confirm it on Kalshi.
Stage 3 - Run 24/7: put it on a small Linux cloud server (like a DigitalOcean
          droplet) as a systemd service that starts on boot, restarts if it
          crashes, and lets me watch the log live.

Start by checking my settings, then Stage 1.

How to Fill It In

The settings block at the top is the part you customize. A few notes on the choices that matter most:

Leave anything blank and the agent will explain the options and help you pick before writing code — that's built into the prompt deliberately.

Step-by-Step: From Prompt to Live Bot

Step 1 — Paste the Prompt Into Your Coding Agent

Open your agent and paste the filled-in prompt. It will start by confirming your settings, then find the Kalshi series ticker for your city and market.

One detail in the prompt does real work here: it instructs the agent to read the market's rules and identify the exact weather station the market settles on — then use the forecast for that station's location rather than the city center.

For Austin, that means the airport, not downtown. Getting this wrong means forecasting one location and settling against another.

Step 2 — Review What It Built

Once Stage 1 is written, the agent will explain what the bot does on each check. For this build, every five minutes it:

1. Gets the forecast high for tomorrow at Austin's airport
2. Gets tomorrow's Kalshi buckets and their prices — the ask being the cheapest price someone will sell you Yes for
3. Draws a bell curve centered on the forecast with a 3°F spread, and works out each bucket's fair chance
4. Calculates edge as fair chance minus the ask
5. Buys the biggest edge if it clears the 10-point minimum; everything else gets a pass
6. Prints the table and saves it to a log, using local Austin time

Is this too simple? Possibly — plenty of people could build the same thing. It's a starting point, not a finished edge. Refinement comes later, and the "my own twist" field is where differentiation begins.

Step 3 — Read the Decision Table

Here's what a real check looks like. Forecast high for tomorrow: 96°F at the Austin airport. Bell curve centered on 96, spread of 3°F.

Read that second row carefully, because it's the whole thesis in one line.

This does not mean the temperature will land at 96–97. The higher-probability outcome is actually 98 or above. What it means is that the model thinks 96–97 is worth about 25–26%, while Kalshi is charging 14¢. That gap is the trade, regardless of whether this particular bucket hits.

Over time you compare what your model predicted against what actually happened, and adjust. Do this 50, 60, 100 times across Austin, across other airports, across other markets — you'll lose plenty and win plenty, and the net is positive if your model genuinely beats the market's pricing.

Step 4 — Set Up GitHub and a Droplet

Two accounts to create before deployment:

GitHub (free, at github.com). Your coding agent connects to it so your code is stored safely in one place and you can return to edit it later.

DigitalOcean, which is where the bot actually lives so it can run with your laptop closed. A 1 GB droplet at $6/month is a fine starting point.

You can also run the bot locally first — install Python from python.org, open the GitHub link, click the green Code button, and choose Download ZIP. But local only works while your computer is on, which defeats most of the purpose.

Step 5 — Deploy and Confirm It Runs on Boot

Create the droplet following the agent's steps, then open the web console from the top of the droplet page. A black terminal opens in your browser, already logged in.

From there it's a loop: the agent gives you something to paste into the console, you paste the result back to the agent, it tells you what's next.

The GitHub deploy key is the one place to slow down:

1. Go to your repository's deploy key settings and click Add deploy key
2. Give it a name and paste in the key
3. Leave "Allow write access" unticked — the key must be read-only
4. Click Add key

I got this wrong the first time. I ticked the write access box, realized it needed to be read-only, and had to delete the key and redo the whole step. Check the deploy keys page afterward and confirm it reads read-only.

Once the code is pulled and running, you should see confirmation that the bot is running in the background, followed by its first decision table using a real forecast and real Kalshi prices.

Finally, confirm the bot starts automatically if the server reboots. The agent gives you a command; the console should print enabled.

A tip that makes this whole stage easier: when you're unsure where you are, screenshot your screen and send it to the agent with "I'm here, what's next?" It's remarkably good at picking up from a screenshot.

Step 6 — Create Your Kalshi API Key

Stage 2 is where it starts trading with real money. First, the credentials:

1. On Kalshi, go to Account and Security
2. Scroll to API Keys — it'll be empty if you've never made one
3. Click Create key and give it a name
4. Leave the permissions selected, then click Create
5. Save the key. Kalshi also downloads a .txt file — keep it
6. Paste the key into the console file the agent specifies, then save and exit
7. Lock the file so only the bot can read it
8. Add your key ID to the settings file

Before this works, your agent may need network access to docs.kalshi.com and api.weather.gov. In Claude Code, that's the environment settings under network access, where you add both as allowed domains.

Then prove the login works. The agent runs a balance check. Mine returned $509.76 available — and usefully, it clarified which portion of that balance sits on the venue where the Austin weather markets actually trade. That's the only part the bot can spend.

Step 7 — Turn Off Dry Run

Everything up to now has been simulated. One setting changes that.

Open the settings file, change DRY_RUN=true to DRY_RUN=false, save, exit, and restart the bot.

The agent should confirm the live configuration back to you. Mine read: live trading, real orders, at most $1 each including fees, at most once per day, buy only if the edge is at least 10 points, checking every 5 minutes, logging to a file.

Read that confirmation carefully before walking away. It's the last checkpoint before real money moves.

Step 8 — Verify the First Live Trade

Then it fires.

Bought 7 contracts. YES on the 100–101 bucket. 97 cents total, Kalshi fee included. Order ID returned. That was the day's single allowed order — no more until tomorrow, with the next check scheduled five minutes out.

Checking the Kalshi account confirms it: Austin 100–101, 13¢ last trade, 7 contracts held, 97 cents cost, $7 payout if correct.

That's the entire loop working end to end. The bot now runs around the clock on the droplet. You can close your laptop.

The natural next step — and the agent will suggest it — is adding a daily scorecard so it tracks performance automatically. That's where you start building out your own tracking: how the edge is holding up, what's actually filling, whether the model needs adjusting.

From there you treat it exactly like any real trading strategy. Add a data feed. Test a change. Measure. Repeat.

Why Long Shots Are Not a Bug

The first live check came back with a pass — best edge was 9.1 points, just under the 10-point minimum. Worth noting that 10 points may be too strict; dropping it is a reasonable early adjustment.

More interesting was where the edges showed up. On this dataset, the bot's edges clustered in the less likely buckets — meaning it would mostly be buying long shots.

That sounds like a warning sign. It isn't necessarily.

Consider the payout structure. Buy a contract at 5¢ when your model says there's a 13% chance, and that 5¢ becomes $1 if the bucket hits. You don't need long shots to land often. You need them to land more often than their price implies.

You don't need many of those to cover a lot of losses. The trap would be assuming a low hit rate means a bad strategy — in a market where contracts pay a fixed $1, hit rate alone tells you nothing without the price you paid.

Why Fill Rate Matters More Than Theory

The prompt deliberately walks you to a live $1 order rather than leaving you in record-only mode forever. There's a specific reason.

If you never place orders, you never learn your fill rate. And without your fill rate, you don't know whether your strategy is actually tradeable.

Here's the mechanic. Kalshi has a bid and an ask, just like a stock — say 55¢ bid, 56¢ ask. Place a limit order at 55¢ and you're a maker, which is cheaper on fees. But you might not get filled at all.

A strategy that looks profitable on paper can collapse once you account for the trades you didn't get. Starting in record-only mode is sensible. Staying there is how you fool yourself.

Small real orders are the cheapest way to learn this. One contract at a time answers the question for pennies.

Keep Your Brain in the Loop

A detailed prompt does a lot of the heavy lifting — that's the point. But there's a failure mode worth naming.

If you stop using your brain, you let the AI decide where this goes. That may not be where you wanted to go, and it will leave stones unturned, because it doesn't think the way you think. Sometimes that's better. Sometimes it's worse. You won't know unless you're still engaged.

There's a competitive angle too. If everyone runs the same generated strategy, will it work? Almost certainly not — especially in prediction markets, where the edge exists precisely because not everyone is doing it.

You want something that makes you different: your data sources, your logic, some component of the model that others don't have. Without an edge, you don't make money. You may well find something that runs roughly break-even, and it's worth being blunt about this — breaking even and making money are very different things in automated trading.

The way I built my first bot was simply asking questions relentlessly. What about this? Can we do that? What if we tried this instead? That back-and-forth is where your version diverges from everyone else's.

Common Mistakes to Avoid

• Ticking "Allow write access" on the GitHub deploy key. It must be read-only. I made this exact mistake and had to redo the step.
• Forecasting the wrong location. These markets settle on a specific weather station — usually an airport, not the city center.
• Leaving dry run on forever. You'll never learn your fill rate.
• Turning dry run off without reading the config confirmation. That's your last checkpoint before real money.
• Setting the minimum edge too high. A 10-point threshold passed on a 9.1-point opportunity; that may be stricter than necessary.
• Putting API keys in the code. They belong in a .env file, never printed to screen.
• Assuming a low hit rate means a bad strategy. Long shots pay $1 on a 5¢ contract.
• Running the generated strategy unmodified. If everyone builds the same bot, the edge is gone.
• Using the web agent for a multi-step deployment. The desktop app handles far more of this for you.

Tips and Best Practices

• Screenshot and ask. When you're lost mid-deployment, send a screenshot with "I'm here, what's next?"
• Use the desktop coding agent. Depending on the permissions you grant, it handles a large share of the steps automatically — this build used the web version purely to show it's possible.
• Start with one city and one market. Expand only once the loop is proven.
• Add the daily scorecard early, so you're accumulating performance data from day one.
• Track model accuracy separately from P&L. Compare what you forecast against what actually verified — that's how you know whether to adjust.
• Ask your agent which droplet size you need based on your data volume rather than guessing.
• Expand across airports and markets once the model proves out. More uncorrelated bets means the net effect of a real edge shows up faster.
• Remember models keep improving. Parts of any build guide age quickly as coding agents get better at these steps on their own.

Frequently Asked Questions

What are Kalshi weather markets?
Markets on weather outcomes such as a city's daily high or low temperature, split into buckets like "96° to 97°" or "100° to 101°." Each bucket's price reflects the market's implied probability — a 23¢ price means roughly a 23% chance. Kalshi also runs markets on events like hurricane landfalls.

Can I build a Kalshi trading bot without coding?
Yes. A sufficiently detailed prompt lets a coding agent write the entire thing in Python. Your job is specifying the settings, verifying each stage, and refining the logic — not writing code.

What does it cost to run a weather trading bot?
A DigitalOcean droplet starts around $6/month for 1 GB, which is enough to begin. Scaling to $24/month buys more storage as your logged data grows. GitHub and the National Weather Service API are free.

Where does the forecast data come from?
The National Weather Service via api.weather.gov, which is free and requires no API key — though every request needs a User-Agent header. You can substitute another forecast source or combine several.

How does the bot calculate fair value?
It treats the forecast as the center of a bell curve, using your forecast spread as the standard deviation. Since official temperatures are whole numbers, a "98° to 99°" bucket covers 97.5 to 99.5 on that curve. Fair probability minus the Kalshi ask equals your edge.

What is a good minimum edge to start with?
Ten points is a reasonable starting threshold, but it may be too strict — in this build it passed on a 9.1-point opportunity. Log your passes and see how often you're declining trades that would have been profitable.

Should the GitHub deploy key have write access?
No. It must be read-only, so leave the write access box unticked. If you tick it by mistake, delete the key and add it again correctly, then verify the deploy keys page shows read-only.

Do I need to keep my computer on?
No, once it's deployed to a cloud server. That's the entire reason for using a droplet — the bot runs continuously with a systemd service that starts on boot and restarts if it crashes.

Why start with such small trades?
A $1 maximum limits your downside while you learn whether the logic works and, critically, what your fill rate is. The first live order in this build cost 97 cents for 7 contracts, paying $7 if correct.

Is the strategy in this guide profitable?
Unknown, and honestly it's deliberately simple. It's a working starting point, not a proven edge. Real differentiation comes from your own data sources, your own logic, and the refinements you make after tracking results over many trades.

The Bottom Line

Going from an idea to a live weather trading bot took a detailed prompt, a $6 server, and a lot of back-and-forth with a coding agent. No programming.

What the AI didn't do is the part that determines whether this makes money: choosing a market you understand, defining logic nobody else is running, and honestly measuring whether your model beats the market's pricing.

Five things that matter most:

1. Fill in the settings deliberately — especially "my own twist," which is where your edge lives
2. Verify the weather station your market actually settles on
3. Keep the deploy key read-only and your API keys out of the code
4. Get to a real $1 order quickly so you learn your fill rate
5. Track model accuracy over many trades before concluding anything

I'll be adding more data feeds, refining the edge, and tracking results over time — with updates on this build and the sports bot to come.

If you want to follow along, you'll need an account for API access. Open Kalshi here — trade your first $25 and you currently get $25 in credits, which covers a lot of $1 test orders while you find out whether your model actually has an edge.

Watch the full video tutorial here: