DEV Community: BotCookery

Our Polymarket Telegram alert said "YES bid 0.64". It never said what the price was for.

BotCookery — Fri, 13 Nov 2026 14:53:05 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every output line below is from the Oct 25, 2026 rebuild, run on live Polymarket US public prices with Telegram mocked (TELEGRAM_MOCK=1): no message was sent and the Telegram API was never called. The bot is alert-only, has no keys and no wallet, and never trades. Nothing here is financial advice.

A Polymarket Telegram alert bot is a small script that polls Polymarket US public prices (GET https://gateway.polymarket.us/v1/markets/{slug}/bbo, no API key) and sends you a Telegram message through the Bot API's sendMessage when a market crosses your level or moves fast. No wallet, no trading access, and the bot token stays in an env var.

On Oct 25, 2026 we pasted the Oct 22 version of the BotCookery prompt into a clean folder and ran the bot it built. The watchlist had five slugs: the Chiefs–Seahawks game, the Miami high-temperature market for "83 to 84°F" on Oct 26, an eBasketball game with an almost empty book, an NFL game that settled last year, and one deliberate typo. The crossing logic and its tests were fine. The messages and the edge cases weren't.

The one real alert we got

At 4:08 PM ET the Miami book jumped from 0.59/0.60 to 0.64/0.67. The old build sent this (mocked):

16:08:20 tc-temp-miahigh-2026-10-26-gte83lt84f bid 0.64 ask 0.67 last 0.6 price 0.655
[mock telegram] Highest temperature in Miami on October 26? | YES bid 0.64 / ask 0.67 / last 0.6 | Rule: crossed above 0.62 | Alert only. Not advice.
[mock telegram] Highest temperature in Miami on October 26? | YES bid 0.64 / ask 0.67 / last 0.6 | Rule: moved +6.0 pts in 15 min | Alert only. Not advice.

Two problems are in that message.

Problem 1: "YES" on a question every bucket shares

"Highest temperature in Miami on October 26?" is the question for every temperature bucket in that event. "YES bid 0.64" doesn't tell you which bucket. On team markets "YES" is ambiguous too. Polymarket US prices are for the market's long side, and the market-by-slug endpoint tells you what that is: title (for example "83 to 84", sometimes missing) and marketSides[], where the side with long=true is what the price is for. The rebuilt bot names it in every message: "83 to 84 (Yes)" or "Chiefs".

Problem 2: the alert was moved by quotes, not a trade

The last trade stayed at 0.60 the whole time. The bot alerts on the mid of bid and ask, so a quote change alone fired both the level rule and the move rule. That's correct behavior, but you should be able to see it. New messages show bid, ask, mid and last trade, plus the local time.

Problem 3: a 0.505 "price" from an empty book

The old build's first cycle at 4:07 PM ET:

16:07:33 aec-nfl-kc-sea-2026-10-25 bid 0.4125 ask 0.415 last 0.415 price 0.414
16:07:33 tc-temp-miahigh-2026-10-26-gte83lt84f bid 0.59 ask 0.6 last 0.6 price 0.595
16:07:33 aec-ebb-nyk-was-2026-10-25 bid 0.02 ask 0.99 last None price 0.505
aec-nfl-lac-ten-2025-11-02: no price
aec-nfl-kc-sea-2026-10-52: error 404 Client Error: Not Found for url: https://gateway.polymarket.us/v1/markets/aec-nfl-kc-sea-2026-10-52/bbo

The eBasketball book was 0.02 bid / 0.99 ask, so its "price" was 0.505. Any level near the middle would alert on noise. The fix is a max_spread setting (default 0.05, per-slug override): if the spread is wider, log "spread too wide" and skip that poll.

Problem 4: a typo that failed quietly, forever

The misspelled slug logged a 404 on every poll and never stopped. The rebuilt bot checks every slug once at startup and stops with an error that names it.

Problem 5: a settled market that said "no price" forever

The expired NFL market returns settlementPx 1.0000 and an expired state. The old bot ignored both. The new one sends one "settled/closed at 1.00" message and drops the slug.

Smaller things

No handling of Telegram's retry_after on 429.
The bot token sits in the Telegram URL, so an exception from the Telegram call could print it. The new prompt scrubs it from error text before logging.
History grew forever. Now rows older than 2 days are dropped.
"Ignore incoming messages" was unclear. The bot now never calls getUpdates at all; a separate one-time helper gets your chat id.

After: the rebuild from the new prompt

With the typo still in the watchlist (4:10 PM ET):

telegram: MOCK (logs/telegram_mock.jsonl)
[mock telegram] Los Angeles vs. Tennessee | Price is for: Chargers | aec-nfl-lac-ten-2025-11-02 is MARKET_STATE_EXPIRED, settled/closed at 1.00. Dropping it from the watchlist. | Alert only. Not advice.
ERROR: aec-nfl-kc-sea-2026-10-52 not found on Polymarket US. Check the slug in watchlist.yaml.

With the typo fixed (4:11 PM ET, first cycle):

16:11:04 aec-nfl-kc-sea-2026-10-25 0.4125/0.415 mid 0.414
16:11:04 tc-temp-miahigh-2026-10-26-gte83lt84f 0.64/0.67 mid 0.655
16:11:04 aec-ebb-nyk-was-2026-10-25: spread too wide (0.02/0.99), skipped

Prices didn't move during the live rerun, so we ran --replay over the old build's saved history, which includes the real 4:08 PM jump. The same alert now reads:

Sun 16:08 EDT
Highest temperature in Miami on October 26?
Price is for: 83 to 84 (Yes)
bid 0.640 / ask 0.670 / mid 0.655, last trade 0.600
Rule: crossed above 0.62
Alert only. Not advice.

The move alert is the same apart from "Rule: moved +6.0 pts in 15 min". This market had no event_slug set, so there's no link. --replay is worth keeping on its own: it runs the rules over saved samples with no network calls, so you can test your levels without waiting for the market.

Built this before Oct 25?

Paste this follow-up into the same project:

Fix these problems in this alert bot. Read alert_bot.py first and tell
me which ones apply before changing anything.
1. Name what the price is for. GET /v1/market/slug/{slug} has title
   (e.g. "83 to 84") and marketSides[]; the price is for the side with
   long=true. Put "Price is for: {title} ({long side})", or just the
   side if there's no title, under the question in every message.
2. Add max_spread (default 0.05, per slug override). If ask - bid is
   wider, log "spread too wide" and skip that poll.
3. At startup check every slug once. 404: stop with a clear error that
   names the slug. state not MARKET_STATE_OPEN: send one
   "settled/closed at {settlementPx}" message and drop the slug.
4. Add the local time and bid/ask/mid/last trade to each message.
5. De-duplicate per slug and rule type (above, below, move) for 30 min.
6. Telegram: on 429 wait the retry_after seconds it returns. Scrub the
   token from any exception text before logging it.
7. Remove any getUpdates call from the main loop. The bot reads no
   incoming messages.
8. Drop rows older than 2 days from data/history.jsonl.
9. Add --replay data/history.jsonl to run the rules over saved samples
   with no network calls.
Add tests for spread, dedup and the startup checks, and run them all.

Starting fresh? The full one-shot prompt is on the recipe page.

Why alert-only

Third-party Telegram bots that trade for you usually need custody of funds or a private key, and that's a common way people get drained. An alert bot you run yourself, with no wallet and no keys, avoids that whole category. It only sends to your own chat id and never reads incoming messages, so nobody can command it. If the token leaks, revoke it in @botfather (/revoke) and make a new one. And poll gently: a 30 to 60 second poll is plenty for alerts, far below Polymarket US's 25 req/s retail limit.

Limits

The page's verified line, word for word: Verified working on live data in mock mode, Oct 25, 2026. Ran on Oct 25 with live Polymarket US public prices on five markets, including a settled one and a typo, plus a replay of a real price jump. Telegram was mocked: no message was sent and the Telegram API was never called, so real delivery and its 429 handling are not yet tested.

So this run shows the bot reads live prices, names what each price is for, skips junk books and handles typos and settled markets. It doesn't prove Telegram delivery. An alert is a notification, not a signal.

The full recipe, with the complete prompt, the step-by-step build, the safety checklist and every doc we checked, is at botcookery.com/recipes/polymarket-telegram-alert-bot.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our read-only Polymarket MCP server returned 480 rows for limit=20 and called a 0.07/0.99 book 99%

BotCookery — Thu, 12 Nov 2026 14:55:20 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every output line and count below is from the Oct 25, 2026 rebuild: each tool called through the MCP Python SDK's stdio client on live Polymarket US public data. No keys were involved, and the server has no trading tools. Registering it in an AI tool wasn't part of the test. Nothing here is financial advice. Market data only.

A read-only MCP server is a small local process that gives Claude Code, Cursor or any MCP client four tools (search markets, get market, best bid/offer, order book) backed by Polymarket US public endpoints. No API key, no order tools, so your assistant can look at markets but can't place anything.

On Oct 25, 2026 we pasted the Oct 22 version of the BotCookery prompt into a clean folder, built every file it asks for, following it line by line, and called each tool through the SDK's stdio client against live Polymarket US data that afternoon. The safety parts held: the server started, refused to run with POLYMARKET_SECRET_KEY set, and rejected bad slugs. The data parts didn't. search_markets("bitcoin", limit=20) returned 480 rows and about 135,000 characters, and get_market reported 99% on a market whose live book was bid 0.07, ask 0.99.

What the prompt builds

Four read-only tools on https://gateway.polymarket.us, no auth:

search_markets(query, limit) → GET /v1/search
get_market(slug) → GET /v1/market/slug/{slug}, plus best bid/offer
get_bbo(slug) → GET /v1/markets/{slug}/bbo
get_order_book(slug, depth) → GET /v1/markets/{slug}/book

Plus mock-HTTP tests, a smoke script that calls every tool over stdio, and a README with the register command for Claude Code and Cursor.

Bug 1: `limit` counted events, not markets

Polymarket's search limit counts events, and one event can hold dozens of markets. The literal build passed limit straight through. The old build at 4:40 PM ET (long rows trimmed):

--- search_markets {'query': 'bitcoin', 'limit': 20} chars=134823
[{"question":"Will Bitcoin be above ___ in 2026?", ...}, ... 480 rows]

That's more than an assistant can usefully read, and 7 of those rows were resolved markets.

Bug 2: the price came from the wrong field

The old get_market read its price from outcomePrices, whose meaning changes between endpoints. On a Fed funds market it said "last 0.99, 99%" while the live book was bid 0.07, ask 0.99.

Bug 3: "implied %" from a book with nothing in the middle

The mid of a 0.11 / 0.89 book is 50%. That number tells you nothing, but the tool reported it anyway:

--- get_bbo aec-nfl-tb-chi-2026-11-08
{"yes_bid":0.11,"yes_ask":0.89,"yes_last":null,"implied_pct":50.0, ...}

Bug 4: "YES" wasn't always yes

On game markets the long side is a team. "Who will win, Buccaneers vs Bears?" with a 0.11 bid doesn't say which team that price is for, and the old get_market for the same game returned "yes_last":0.89,"implied_pct":89.0 with no side named.

Bug 5: the register command couldn't import the SDK

The setup step said python3 /full/path/server.py. But mcp and httpx live in the project's venv, so system Python fails with ModuleNotFoundError. The SDK version wasn't pinned either, and many AI tools still write the v1 FastMCP import, which v2 renamed.

Bug 6: 429s far below the documented limit

We stayed far below the documented 25 requests a second, and Polymarket still answered 429 twice during testing.

What we changed

Search returns market rows, open only. Flatten events to one row per market (question, event, slug, long_side, status, end date), drop closed or inactive markets, then cut to limit rows. No prices in search; it says "use get_bbo for prices".
Prices only from /bbo and /book (bestBid, bestAsk, lastTradePx, any of which can be null). Never outcomePrices or currentPx.
Implied % only when the spread is 0.10 or less. Otherwise it's null with a reason, and a missing bid or ask is handled.
long_side named in every response, from the marketSides entry with long=true, with a note that every price is for that side.
Every response under 4,000 characters, dropping whole rows and keeping valid JSON with "truncated": true.
Slug regex ^[a-z0-9][a-z0-9-]*$, and on 429 a 1 s wait, exponential backoff, then a clear ToolError instead of hanging.
mcp[cli]>=2,<3 pinned in a venv, and the register command uses full paths to the venv's Python and server.py.

After: a fresh rebuild

The rebuilt server at about 4:45 PM ET, same calls (trimmed). 7 tests pass:

--- search_markets bitcoin, limit 20: 17 shown of 471 open matches,
    truncated, 3898 chars
--- get_market aec-nfl-tb-chi-2026-11-08
{"long_side":"Buccaneers","yes_bid":0.11,"yes_ask":0.89,"yes_last":null,
 "spread":0.78,"implied_pct":null,"implied_reason":"spread 0.78 too wide",
 "note":"Prices are for the long side: Buccaneers.", ...}
--- get_bbo aachc-nfl-2027-01-10-lastundefeated-kc
{"yes_bid":0.27,"yes_ask":0.33,"yes_last":0.35,"spread":0.06,
 "implied_pct":30.0, ...}

Search asked for 20 rows and stopped at 17 to stay under 4,000 characters. The wide book says why it has no implied %, and the tight one gets one.

Register it (full paths)

claude mcp add --transport stdio polymarket-readonly -- /full/path/.venv/bin/python /full/path/server.py

Or in Cursor's .cursor/mcp.json:

{"mcpServers": {"polymarket-readonly": {
  "command": "/full/path/.venv/bin/python",
  "args": ["/full/path/server.py"]}}}

Built this before Oct 25?

Paste this follow-up into the same project:

Update my read-only Polymarket US MCP server. Keep it read-only and
keep the startup check that refuses POLYMARKET_SECRET_KEY.
1. search_markets: the API's limit counts EVENTS, not markets. Flatten
   to one row per market (question, event, slug, long_side, status,
   endDate), drop markets that aren't active or are closed, then cut
   to `limit` rows. No prices in search; say "use get_bbo for prices".
2. Prices: take YES prices ONLY from /bbo or /book (bestBid, bestAsk,
   lastTradePx; any can be null). Stop using outcomePrices and
   currentPx. implied_pct is the mid only when both sides exist and
   the spread is <= 0.10; otherwise null with a reason.
3. long_side: the description of the marketSides entry with long=true
   ("Yes", or a team name on game markets). Show it in search rows and
   get_market, and say every price is for that side.
4. Keep every response under 4,000 characters by dropping whole rows
   (valid JSON, "truncated": true). Keep the closing line.
5. Slugs must match ^[a-z0-9][a-z0-9-]*$. On 429 wait 1s, then back
   off exponentially; after a few tries raise a ToolError.
6. Pin "mcp[cli]>=2,<3" in a venv. Register with FULL paths to the
   venv's python and server.py, not plain python3.
7. Add mock tests for the row limit, closed markets, a null ask, a
   wide spread and long_side. Run all tests and the stdio smoke script.

Starting fresh? The full one-shot prompt is on the recipe page.

Why read-only

An MCP tool can be called by the AI on its own initiative, and agents make mistakes or get steered by text they read, including market text the tools return. Leaving order tools out removes the worst failure. If you later want trading, build it as a separate program with a paper/live gate, and don't hand an agent an order tool. Also: an MCP server runs code on your machine with your permissions, so only install ones you've read or trust.

Limits

The page's verified line, word for word: Verified working on live data in read-only mode, Oct 25, 2026. Every tool called through the SDK's stdio client on live public data. Registering it in an AI tool wasn't tested.

So this run proves the tools return sane, bounded data over stdio on live Polymarket US markets. It doesn't prove how any particular assistant uses them once registered. The output is market data, not a signal.

The full recipe, with the complete prompt, the step-by-step build, the safety checklist and every doc we checked, is at botcookery.com/recipes/polymarket-mcp-server-read-only.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our ChatGPT/Codex Kalshi starter would have bought the same contract 38 times in under 13 minutes

BotCookery — Wed, 11 Nov 2026 14:52:39 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every log line and count below is from the Oct 25, 2026 rebuild: a dry run with no keys on Kalshi's live public demo market data. Nothing was signed with a real key and no orders were sent. Nothing here is financial advice. Demo and dry run only.

"Can ChatGPT build me a trading bot?" Yes, it can write the code. It can't make the bot profitable, and it often remembers outdated API endpoints. The BotCookery recipe is a prompt for ChatGPT (chat) or Codex (agent) that builds a small Kalshi bot on the demo exchange, with the rules in AGENTS.md and the limits in code.

On Oct 25, 2026 we pasted the Oct 22 version of that prompt into a clean folder, built every file it asks for, following it line by line, and ran the bot without keys against live Kalshi demo data that afternoon. The V2 order body, the dry run and the kill switch all worked. The trading rule did not: while the ask stayed low, it proposed a new 1-contract bid on every loop. On one ticker that was 38 orders in under 13 minutes, then 38 more after a restart.

What the prompt builds

The bot is built one file at a time, waiting for your "next" between files:

kalshi_client.py: signed requests (RSA-PSS with SHA-256 or Ed25519), base URL fixed to https://external-api.demo.kalshi.co/trade-api/v2. Key id and key file path come from env vars. Without them the bot dry-runs: it reads public data, logs what it would send, and sends nothing.
risk.py: limits.json (1 contract per order, $5 open exposure, $2 daily loss, 3 orders a minute) plus a KILL file or BOT_KILL=1. If any check errors, the order is blocked.
bot.py: watches one ticker, reads yes_ask_dollars and yes_ask_size_fp, and places through POST /portfolio/events/orders (Create Order V2) with side "bid", count "1" and a dollar-string price like "0.4500".
cancel_all.py: DELETE /portfolio/events/orders.
find_ticker.py, a README and a .gitignore.

If the model writes the legacy /portfolio/orders for order creation, it's working from old memory, so re-paste the docs.

Bug 1: "1 contract per order" isn't a position limit

The old build at 4:32 PM ET, no keys, ticker KXNFLTD-26OCT25KCSEA-KCAARMSTRONG85-1 (Andrew Armstrong to score a touchdown), ask $0.13, max price $0.15 (timestamps and order IDs trimmed):

{"decision": "dry_run_would_send", "body": {"ticker": "KXNFLTD-26OCT25KCSEA-KCAARMSTRONG85-1", "side": "bid", "count": "1", "price": "0.1300", ...}}
{"decision": "dry_run_would_send", "body": {... "price": "0.1300", ...}}
{"decision": "dry_run_would_send", "body": {... "price": "0.1300", ...}}
{"decision": "blocked", "reason": "max_orders_per_minute", "ask": 0.13}
{"decision": "blocked", "reason": "max_orders_per_minute", "ask": 0.13}
{"decision": "blocked", "reason": "max_orders_per_minute", "ask": 0.13}

Only the 3-a-minute limit slowed it, and only the $5 exposure cap stopped it. The same risk code on a fake clock: one hour at ask 0.13 allowed 38 buy orders and $4.94 of exposure, and after a restart, 38 more.

Every individual order obeyed "1 contract per order". The bot just kept making them.

Bug 2: "$5 exposure" and "$2 daily loss" weren't defined

A literal build counted orders sent, in memory, and left daily loss at 0. So a restart wiped exposure, and the daily loss limit could never trip. A limit that can't trip looks exactly like a limit that's working.

Bug 3: "keep the key outside your project" doesn't hide it from Codex

We tested Codex CLI 0.164.0's sandbox on its own (no model, a throwaway file, not a key). In its normal edit mode, both cat and a Python script read ~/.config/kalshi/demo.pem. A Codex permission profile that denies that folder blocked both, and project writes still worked (paths shortened):

--- default
THROWAWAY-NOT-A-KEY
THROWAWAY-NOT-A-KEY
project write ok
--- with "~/.config/kalshi" = "deny"
cat: ~/.config/kalshi/demo.pem: Permission denied
PermissionError: [Errno 13] Permission denied: '~/.config/kalshi/demo.pem'
project write ok

Bugs 4 to 6: docs, ticker search, the small stuff

The pasted docs didn't cover the code. The prompt said to use only endpoints from the pasted pages, but GET /markets/{ticker} and the cancel-all DELETE weren't on the two pages it listed. A careful model should stop and say so.
The ticker search read one page. That returns 1,000 markets plus a cursor, and only 19 had an ask. Following the cursor gave 217 pages and 7,348 markets with an ask, and Kalshi rate-limited us partway (HTTP 429).
Small things. Only risk.py had tests, so a wrong signature would show up as 401s on your first keyed run. The .gitignore was thin.

What we changed

One position per ticker. Before proposing, the bot checks for a resting order or a position on the ticker (in dry run, a paper order in state/paper.json) and logs "holding". It skips unless the market status is "active".
Exposure is computed, not counted. Before every order: resting orders (yes_price_dollars * remaining_count_fp) plus positions' market_exposure_dollars, from your demo account.
Daily loss from the balance. Today's first balance plus portfolio value from GET /portfolio/balance is saved in state/day_start.json. In dry run it logs "daily loss not tracked" instead of pretending it's 0.
Order timestamps saved to disk, so a restart doesn't reset the per-minute limit.
Step 3 sets up a Codex permission profile that denies ~/.config/kalshi (shown below).
The prompt lists every docs page it needs: Quick Start authenticated requests, Create Order (V2), Get Market, Get Markets, Get Orders, Get Positions, Get Balance, Cancel All Orders.
find_ticker.py follows the cursor through GET /markets?status=open&mve_filter=exclude&limit=1000 and retries on 429 (1, 2, 4, 8, 16 s).
Signing tests for RSA and Ed25519 against the public key, with a fake HTTP session. .gitignore now covers .env.*, *.key and state/. Without keys, cancel_all.py exits 1 and says nothing was sent.

The Codex step

Edit ~/.codex/config.toml yourself, not through Codex, and restart it:

default_permissions = "kalshi-bot"
[permissions.kalshi-bot]
extends = ":workspace"
[permissions.kalshi-bot.filesystem]
"~/.config/kalshi" = "deny"

Permission profiles are a beta feature and don't combine with sandbox_mode or --sandbox, so leave those out. Then ask Codex to cat ~/.config/kalshi/demo.pem; it should get "Permission denied". In plain ChatGPT chat, skip this step, since chat can't read your files.

After: a fresh rebuild

A fresh rebuild of the new prompt (10 tests pass), 4:33 PM ET, same ticker, then a restart, then the kill-switch drill (timestamps and order ID trimmed):

{"decision": "dry_run", "body": {... "count": "1", "price": "0.1300", ...}, "exposure": 0, "daily_loss": "not tracked in dry run"}
{"decision": "holding", "ask": 0.13}
{"decision": "holding", "ask": 0.13}
--- restart
{"decision": "holding", "ask": 0.13}
--- KILL drill
{"decision": "blocked", "reason": "kill switch on", "ask": 0.13}
--- cancel_all
No Kalshi credentials set (KALSHI_API_KEY_ID / KALSHI_PRIVATE_KEY_PATH). Nothing was sent.

One paper order, then "holding", and still "holding" after a restart.

Built this before Oct 25?

Do the Codex permission step above, then paste this follow-up into the same project:

Update this Kalshi demo bot. Use only the Kalshi docs pages I paste
below (Get Market, Get Markets, Get Orders, Get Positions, Get Balance,
Cancel All Orders). Never run the bot with my keys; I run it myself.
1. One position only: before proposing, skip and log "holding" if this
   ticker has a resting order (GET /portfolio/orders?ticker=...&
   status=resting) or a position (GET /portfolio/positions?ticker=...,
   position_fp != 0). In dry-run, keep paper orders in state/paper.json
   and apply the same rule. Skip unless the market status is "active".
2. Open exposure: compute it from the exchange before each order
   (resting yes_price_dollars * remaining_count_fp plus positions'
   market_exposure_dollars), not from a counter of orders sent.
3. Daily loss: save today's first balance + portfolio_value from
   GET /portfolio/balance (cents) in state/day_start.json and block when
   the current value is max_daily_loss_usd below it. No placeholder 0.
4. Save order timestamps in state/ so a restart doesn't reset the
   per-minute limit. If any risk check errors, block the order.
5. cancel_all.py with no credentials: exit 1, "Nothing was sent."
6. Add find_ticker.py: follow the cursor through
   GET /markets?status=open&mve_filter=exclude&limit=1000, wait and
   retry on HTTP 429, print markets with 0 < yes_ask_dollars < 1.
7. Add .env.*, *.key and state/ to .gitignore.
8. Tests with a fake HTTP session for each of these, plus RSA and
   Ed25519 signature checks against the public key.
Show me the diff before running anything.

Starting fresh? The full one-shot prompt is on the recipe page.

Chat or Codex?

In chat you copy code by hand: slower, but you see every line. Codex edits files and runs commands: faster, so the rules matter more. Either way, never paste keys, key files or account screenshots into ChatGPT, and run the bot with real keys in your own terminal, not through Codex.

Limits

The page's verified line, word for word: Verified working on live data in paper mode, Oct 25, 2026. Dry run on live Kalshi demo data with no keys. Signed demo orders need your own demo keys.

So this run proves plumbing on public demo data: the V2 order body, the one-position rule, the kill switch and the paper ledger. The exposure, daily-loss and holding checks against real demo orders are covered by tests with a fake HTTP session, not by a signed run. You'll need your own demo keys for that. Kalshi notes demo prices may not reflect real markets, so judge your code there, not your strategy. There's no evidence that asking ChatGPT for trades produces reliable profits. Use it to build tools.

The full recipe, with the complete prompt, the step-by-step build, the safety checklist and every doc we checked, is at botcookery.com/recipes/chatgpt-trading-bot-codex.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our weather bot paper-bought "below 81 " at 1¢ after the day's high had already hit 80.96

BotCookery — Tue, 10 Nov 2026 15:02:30 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every number and log line below comes from a live paper-mode run on Miami temperature markets (Kalshi KXHIGHMIA and Polymarket US) on the afternoon of Oct 25, 2026. No orders were placed anywhere, demo included. Nothing here is financial advice.

Daily-high temperature markets look made for a bot. The National Weather Service publishes a free forecast API, both Kalshi and Polymarket US list a new set of temperature buckets every day, and the answer arrives the next morning. So it seems like you could compare the forecast with the prices and trade the gap.

We have a recipe that builds this in paper mode: it pulls the free NWS API and Kalshi's public weather index, parses each day's buckets on both venues, and logs what a simple rule would do, then scores it against the settlement source. On Oct 25 we pasted the Oct 22 version of the prompt into a clean folder, built it for Miami, and ran it live through the afternoon. It tracked 24 markets across Oct 25 and Oct 26.

The parser was fine. Most of the rest needed work.

The worst bug: trading a day that was mostly decided

At 3:15 PM ET the bot paper-bought 500 YES contracts on "below 81° today" at $0.01. It used the NWS forecast for "This Afternoon" (83°) as if the high were still to come.

By then Kalshi's weather index had already reached 80.96° for the day, and the 81-82° bucket was bid at $0.99. The market knew the answer. The bot was still trading on the morning's forecast.

Here's the old build at 3:15 PM ET (host overridden by hand, more on that below):

kalshi KXHIGHMIA-26OCT25-T81              (None, 80)   ok           fc=83 obs=80.6 bid=0.0 ask=0.01 p=0.2023 BUY_YES ok
kalshi KXHIGHMIA-26OCT25-B81.5            (81, 82)     ok           fc=83 obs=80.6 bid=0.99 ask=1.0 p=0.2315 BUY_NO daily cap

The fix is one config line and a rule: trade_same_day = false. Any market whose date is today or earlier, in the station's local standard time, is logged as SKIP same day. Once the day has started, the high is partly in, and a forecast can't compete with people watching the station.

Five more things that broke

It crashed on the first call. The prompt's Kalshi host, external-api.kalshi.com, answered 403 from our server, and the whole cycle died with a traceback. Kalshi also documents api.elections.kalshi.com, and that one worked. The bot now falls back once with a one-line note, and a single failing source (Kalshi, Polymarket US or NWS) is logged and skipped instead of killing the cycle.

"Latest observed value" was the wrong number. The bot logged the last index reading, 80.24, instead of the day's high so far, 80.96. For a daily-high market, the running max is what matters. It now logs the running max since local standard midnight from both the Kalshi index and the station's own observations (the station's 5-minute values are whole °C, which the log now says).

It re-bought the same markets every cycle. Nothing checked the ledger. On the second cycle 17 signals fired, including markets it already held, and only the daily cap stopped them. Now it's one paper position per market, and signals are ranked by edge before the cap is spent.

Kalshi paper fills had no size limit, and nothing paid fees. On the 1-2¢ buckets the model liked, Kalshi's taker fee is about 7% of the stake ($0.35 on a $5 buy). Fills now walk the real order book (Kalshi's book is bids only, so YES asks are 1 minus the NO bids), and the ledger charges each venue's published taker fee: Kalshi 0.07 × C × P × (1 − P) rounded up to the cent, Polymarket US 0.0695 × C × p × (1 − p), as we read both fee pages on Oct 25.

The score had nothing to compare against. settle.py printed a Brier score for our estimates but not for the market's own prices, so there was no way to tell whether the model beat the market. It now prints both on the same decisions, plus paper PnL after fees, and says so plainly when ours isn't lower.

What didn't change, on purpose

The placeholder model is a normal curve around the NWS forecast, and it's too wide. On Oct 26 it gave 12% to "87° or above", where both venues priced it at about 2%. Most of its "edge" is the curve's fat tails, not information.

We left that alone because the recipe is about plumbing and honest scoring, not a forecast model. The market-vs-model Brier comparison is there to show you exactly this.

After the fix

From a fresh rebuild of the new prompt (11 tests pass), at 3:21 PM ET the same afternoon:

note: external-api.kalshi.com returned 403; using api.elections.kalshi.com
2026-10-25 15:21 EDT  climate day 2026-10-25  observed max so far: Kalshi index 80.96, KMIA 80.6 (ASOS 5-min values are whole °C)
kalshi KXHIGHMIA-26OCT26-T86  (87, None)  The Weat bid=0.01 ask=0.02 fc=83 p=0.1217 BUY_YES ok FILL 226@0.0221 fee 0.35
kalshi XHIGHMIA-26OCT26-B83.5 (83, 84)    The Weat bid=0.62 ask=0.63 fc=83 p=0.2576 BUY_NO ok FILL 13@0.38 fee 0.22
kalshi KXHIGHMIA-26OCT25-T81  (None, 80)  The Weat bid=0.0 ask=0.01 fc=83 p=None SKIP same day
pmus   -2026-10-26-gte81lt82f (81, 82)    NWS CLI  bid=0.17 ask=0.18 fc=83 p=0.2315 BUY_YES daily cap

The same-day market is skipped, fills carry a size and a fee, and the Polymarket US bucket shows its settlement source (NWS CLI). Three minutes later, the second cycle said "already held" for every repeat signal and bought nothing again. With Kalshi unreachable, the 12 Polymarket US markets still ran and the bot exited 1. With a KILL file, all 8 signals were blocked. settle.py read all four Oct 24 test entries as settled on both venues and left the open Oct 26 one alone.

Two things we confirmed live

The buckets move every day. Oct 24 ran 80-81, 82-83, 84-85 and so on, while Oct 26 ran 79-80, 81-82, 83-84. A bot that hardcodes bucket edges breaks within a day, so it has to parse every market, every day. Kalshi titles look like Will the maximum temperature be >67° on Oct 19, 2026?, often with no F after the degree sign, and >86° means 87° or above. Polymarket US slugs like gte79lt80f need the market description to be read correctly.

Different sources, same answer, that day. When we checked on Oct 22, Kalshi's Miami daily-high markets named The Weather Company (CLIMIA) in rules_primary, while Polymarket US's named the NWS climate report for KMIA. On Oct 24 both settled at 84°: Kalshi expiration_value 84.00, Polymarket US "between 84F and 85F" = Yes, and the NWS climate report max was 84° at 2:02 PM. That won't always hold, so read rules_primary on every Kalshi market and the description on every Polymarket US market, and store the source with each trade.

If you want to try it

Pick one city both venues list and note each venue's settlement source for it.
Paste the prompt from the recipe page into a fresh folder. Set your NWS User-Agent (app name plus email); api.weather.gov asks for one.
Print each market's text next to the parsed range and check them by eye. Anything the parser isn't sure about is "needs review" and never traded, even on paper.
Leave trade_same_day = false. Run a few times a day for 2-4 weeks, and run settle.py each morning after settlement.
Compare your Brier score with the market's. If yours isn't lower, that's your answer, whatever a few weeks of paper PnL say.

Built it before Oct 25? The recipe page has a follow-up prompt that applies all of these fixes to an existing project.

Limits

The recipe page's verified line, word for word: Verified working on live data in paper mode, Oct 25, 2026. Ran live in paper mode on Miami (Kalshi KXHIGHMIA and Polymarket US) for a few cycles on the afternoon of Oct 25. settle.py was checked against the Oct 24 markets that had already settled. Our own paper trades had not settled when we published, so there is no PnL or Brier result yet. No orders were placed anywhere, demo included.

This was one city on one afternoon. It shows the plumbing works: host fallback, same-day skip, running max, one position per market, size-limited fills, fees and settlement reads. It doesn't show that the model, or any weather model, has an edge. Fee formulas are as we read them on Oct 25; check both venues' fee pages before trusting any number here.

The full recipe, with the complete prompt, the follow-up, the safety checklist and every doc we checked (Polymarket US weather FAQ, Kalshi weather index and market rules, the NWS API), is at botcookery.com/recipes/prediction-market-weather-bot.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our Claude Kalshi bot counted a closed market's paper order forever

BotCookery — Mon, 09 Nov 2026 19:49:39 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every log line and count below is from the Nov 9, 2026 rebuild: a dry run with no keys on Kalshi's live public demo data, plus fault drills through a local proxy. No key was used, no signed request was sent, and no order was placed. Nothing here is financial advice. Demo and dry run only.

The BotCookery Claude trading-bot recipe is a prompt that sets up Claude Code safely (a CLAUDE.md rules file, permissions.deny rules for .env and key files, a sandbox denyRead on the key folder) and then scaffolds a small Kalshi demo bot with its limits in code. On Oct 25 we rebuilt it once and fixed the big problems. On the morning of Nov 9, 2026 we rebuilt it again from the published prompt in an empty folder, writing every file it asks for and nothing more, and ran it without keys on live Kalshi demo data from 9:02 to 9:14 AM ET.

The Oct 25 fixes held. What broke was everything around the happy path. The finding we like least: in a dry run, a paper order on a market that later closed stayed in state/paper.json forever. The bot said "holding" on every loop, and that dead order kept counting toward the exposure cap.

What we built

The prompt asks for these files: broker.py, risk.py, bot.py, cancel_all.py, find_ticker.py, config.toml and tests/. Python 3.11+, requests, cryptography and pytest only.

broker.py hardcodes the demo base URL https://external-api.demo.kalshi.co/trade-api/v2. Production is a separate, deliberate change.
With no credentials the bot dry-runs: it reads public market data, logs what it would send, sends nothing, and keeps dry-run "orders" in state/paper.json so the same rules survive a restart.
bot.py watches one ticker and a max_price from config.toml. The rule is simple: the best YES ask is at or below max_price and size is at least 1. One position only: if there's a resting order, a position, or (in dry run) a paper order on that ticker, it logs "holding" and skips.
risk.py checks before every order and fails closed: the KILL file or BOT_KILL=1, max contracts, open exposure computed from the exchange each time, daily loss from GET /portfolio/balance, and orders per minute from timestamps saved in state/.
Orders go to POST /portfolio/events/orders with side "bid" (buy YES), count "1.00", a price like "0.3500", a client_order_id, good_till_canceled and self_trade_prevention_type taker_at_cross. cancel_all.py is DELETE /portfolio/events/orders.

The build started at 13 tests. We also checked the Claude Code settings and sandbox keys and the Kalshi V2 order body against the current docs. All 13 doc links on the page returned 200, including Kalshi's changelog, which we added.

What held from Oct 25

In 20 loops on KXATPCHALLENGERMATCH-26NOV09AGUSAN-AGU (ask $0.43, max price $0.45), the bot logged one dry_run, then holding 19 times. A restart kept the paper order and the per-minute timestamps. The kill file, BOT_KILL=1, the exposure cap and the per-minute limit (seeded, then a restart) all blocked as they should. A closed market was skipped. cancel_all.py with no keys exited 1 and said nothing was sent.

For context, the Oct 25 pass is where the big bugs were: the first prompt proposed a new buy on every loop (38 orders in 13 minutes on a $0.13 ask, and 38 more after a restart), counted exposure from orders sent in memory, had a daily loss limit fixed at 0, missed the key in ~/.config/kalshi/ in its deny rules, and searched 1 page of 217 for tickers. None of that came back.

What broke on live demo data

A 429 ignored Retry-After. Through a local proxy that answered 429 with Retry-After: 5, the bot retried after 0.5, 1 and 2 seconds and gave up in 3.6 s. The server asked for five seconds; the bot spent its whole retry budget before the first five were up.

An HTML 200 was a cryptic crash. An HTML maintenance page with status 200 logged JSONDecodeError: Expecting value: line 1 column 1. That error tells a beginner nothing about what happened. A dropped connection wasn't retried at all.

A typo'd ticker looped forever. It logged a 404 every 15 seconds, with no end.

A paper order outlived its market. In a dry run, an order on a market that later closed stayed in state/paper.json. The one-position rule saw it and held forever, and the exposure check counted it. A beginner watching the log would see a calm "holding" line while their cap quietly filled up with a contract that could never exist.

Ctrl-C and | head crashed. Ctrl-C printed a traceback. With python bot.py | head -1, the closed pipe was caught by the holding check and logged as holding check error: BrokenPipeError, then the bot crashed anyway. With output sent to a file, nothing showed up until the bot exited, because Python buffers it.

find_ticker.py printed 8,046 lines. It read all 243 pages of open demo markets in about 59 seconds and listed every market with an ask. One had a close time in March 2026, already past. 66 had less than one contract on offer.

What we changed in the prompt

Every request gets timeout=(5, 10). Reads and cancel-all retry up to 2 times on 429, 5xx, timeouts and dropped connections. On 429 the bot waits the Retry-After seconds if sent (cap 8 s), else 1 s then 2 s.
An order POST is never retried.
A reply that isn't JSON is a one-line error: the status code plus the first 80 characters with HTML tags stripped.
Kalshi's error.code is logged as-is. Since Nov 5, 2026 an order on a halted or closed market returns market_inactive (it used to be market_closed).
A 404 on GET /markets/{ticker} stops the bot with "ticker not found, run find_ticker.py".
If the market isn't active and there's a paper order for it, the bot drops it and logs paper_dropped.
Every decision is printed with flush=True, outside any try block that catches errors. Ctrl-C exits with "Stopped (Ctrl-C)." and no traceback; a closed pipe exits quietly.
find_ticker.py takes --max-price and --top (default 25), skips markets whose close time has passed or whose ask size is below 1, shows page progress on stderr, and ends with the usable count.

Drill results after the fix

We rebuilt from the updated prompt plus the follow-up; 20 tests pass. The same loop, then the drills, from the recipe page (timestamps and IDs trimmed):

{"decision": "dry_run", "body": {... "price": "0.4300", ...}, "exposure": 0, "daily_loss": "daily loss not tracked"}
{"decision": "holding", "ask": 0.43}
--- 429 with Retry-After: 5 (waited 5 s twice, 10.2 s total)
{"decision": "error", "error": "GET /markets/...: HTTP 429 too_many_requests too many requests"}
--- HTML page with status 200
{"decision": "error", "error": "GET /markets/...: HTTP 200, not JSON: 'Maintenance'"}
--- typo ticker
Ticker KXATPCHALLENGERMATCH-26NOV09AGUSAN-AGUX not found on demo. Run find_ticker.py and fix config.toml.
--- paper order on a market that closed
{"decision": "paper_dropped", "reason": "market status closed"}

The rest of the drills:

Dropped connection and hung server: one line each. A hung server costs up to about 33 seconds per loop (three 10-second tries plus waits) before the bot logs "timed out" and moves on.
Typo ticker: stops with exit code 1.
Ctrl-C: exit code 130, no traceback.
python bot.py | head: exit code 0, quiet.
find_ticker.py --max-price 0.45: 3,719 usable markets, printed as the 25 soonest to close instead of 8,046 lines.

How to use it

Open an empty folder in Claude Code. Paste the prompt from the recipe page, with the Safety Pack rules file at the bottom.
Run step 0 only. Approve the write to .claude/settings.json, then check the deny rules, /status and /sandbox.
Let it build step 1, and ask it to fetch the Kalshi docs pages first so it uses the current V2 order endpoint.
Run python find_ticker.py --max-price 0.50 and pick a ticker that doesn't close today. Demo books are thin.
Read broker.py and risk.py line by line before running anything.
Dry-run with no keys. touch KILL and confirm the next loop sends nothing. Delete state/paper.json to start over.

Built this before Nov 9? The recipe page has a follow-up prompt for the same project:

Update this Kalshi demo bot. Read the current Kalshi docs and
changelog (https://docs.kalshi.com/changelog) first.
1. broker.py: every request gets timeout=(5, 10). Reads and cancel-all
   retry up to 2 times on 429, 5xx, timeouts and dropped connections.
   On 429 wait the Retry-After seconds if sent (cap 8), else 1 s then
   2 s. Never retry an order POST.
2. A reply that isn't JSON (like an HTML maintenance page) is a
   one-line error with the status code and the first 80 characters of
   text with HTML tags stripped, not a traceback. For Kalshi errors,
   log error.code as-is (since Nov 5, 2026 a halted market returns
   market_inactive, formerly market_closed).
3. bot.py: if GET /markets/{ticker} returns 404, stop with "ticker not
   found, run find_ticker.py". If the market isn't "active" and there's
   a paper order for it in state/paper.json, drop it and log
   "paper_dropped".
4. Print each decision with flush=True, and don't print inside a try
   block that catches errors. Ctrl-C exits with "Stopped (Ctrl-C)." and
   no traceback. A closed pipe (python bot.py | head) exits quietly.
5. find_ticker.py: add --max-price and --top (default 25). Skip markets
   whose close_time has passed or whose yes_ask_size_fp is below 1.
   Show page progress on stderr and end with the count of usable
   markets.
6. Tests with a fake HTTP session: Retry-After honored and capped,
   HTML 200, timeout retried then one line, order POST not retried,
   error code kept, 404 stops, paper order dropped.
Show me the diff before running anything.

If you built it before Oct 25, paste the Oct 25 follow-up from the page first, then this one.

Limits

The page's verified line, word for word: Verified working on live data in paper mode, Nov 9, 2026. Dry run on live Kalshi demo data with no keys, plus local fault drills. Signed demo orders, exposure and daily loss from a real account need your own demo keys and weren't run.

So this run proves plumbing on public demo data: retries, timeouts, error lines, the one-position rule, the kill switch, the caps and the paper ledger. Exposure, daily loss and the holding check against a real demo account are covered by tests with a fake HTTP session, not by a signed run. You'll need your own demo keys for that, and you should run the bot with them in your own terminal, not through Claude. It proves nothing about a strategy. Claude can build the plumbing; it can't find you an edge.

The full recipe, with the complete prompt, both follow-ups, the safety checklist and every doc we checked, is at botcookery.com/recipes/claude-trading-bot.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our Grok Kalshi paper bot ignored Retry-After and treated a login page as JSON

BotCookery — Fri, 06 Nov 2026 15:48:03 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every log line and count below is from the Nov 5, 2026 rebuild against Kalshi's live public demo data in paper mode: no demo keys, and no order was sent. Nothing here is financial advice. Paper and demo only.

People keep asking whether Grok can build a trading bot. The useful answer is narrower: an AI coding agent can scaffold a Kalshi demo bot whose spending limits live in code, whose research step only sees public market text, and that you can stop with one command. The recipe on BotCookery is that prompt. On the morning of Nov 5, 2026 (ET) we pasted the published one-shot into a clean folder, built it by hand, and ran it in paper mode against Kalshi's live public demo. The Oct 25 bookkeeping held. The HTTP edge did not.

The first fault we drilled was a 429 with Retry-After: 3. The bot retried after about half a second of homemade backoff. That is the finding this post leads with, because it is the kind of bug that looks fine in a happy-path run and then burns you the first time the venue asks you to wait.

What the recipe is

The page title on the site is a how-to for building a Kalshi paper bot with Grok and spending limits. Under the hood it is the same shape as our Claude and ChatGPT starters: the agent writes the code; you set the rules and the dollar caps. Paper mode is the default. Public market reads hit https://external-api.demo.kalshi.co/trade-api/v2 with no key. Demo orders need keys, PAPER_MODE=0, --live, and a typed confirmation; we had none of that, so nothing was signed.

Limits sit in limits.json and risk.py, not in the agent's instructions. An agent can misread a prompt; it cannot skip a check it does not control. Create Order V2 is POST /portfolio/events/orders with side, count, price, time_in_force (fill_or_kill, good_till_canceled, or immediate_or_cancel) and self_trade_prevention_type. Cancel-all is DELETE /portfolio/events/orders. Order groups cap matched contracts over a rolling 15 seconds, so the bot must create one group and reuse it. The optional research step posts only public title, rules text, and prices to xAI's Chat Completions endpoint; its output is logged and never changes the bid. We left research_enabled false and never called it.

What happened when we rebuilt it from this prompt

On Nov 5, 2026 we pasted this page's one-shot prompt into a clean folder, built it by hand and ran it in paper mode against Kalshi's live public demo data that morning (ET). No demo keys, so nothing was signed or sent. The Oct 25 bookkeeping fixes (one order group, paper IOC fill, held-ticker skip, settle-first daily loss, cancel_all leaves filled exposure alone) held up. What broke was the HTTP edge:

Retry-After was ignored. A 429 with Retry-After: 3 retried after ~0.5 s of homemade backoff. Reads now sleep the header value (cap 8 s) when it is present.
HTML 200 printed a JSON decode error. A gateway login page as a 200 became Expecting value: line 1 column 1. Now: fetch failed: response was not JSON: gateway login.
Hung host chewed the clock. Default timeouts were generous and retries stacked; against a hung proxy the process sat until an outer 55 s kill with no useful line. Now: timeout=(5, 10), at most 2 retries, then fetch failed: timed out (~16 s in our drill).
503 HTML leaked tags into the error. Stripped now (503 Service Unavailable).
Demo books are thinner than the Oct 25 sample suggested. Around 8:57 AM ET we scanned 5,000 open markets (mve_filter=exclude) and found 56 with a real YES ask, 18 of them ≤ $0.15. Around 9:04 AM the first 1,000 had 13 real asks and zero ≤ $0.15. Pick the ticker right before you run.

Oct 25 condensed (still true): a new order group every run meant the server-side 15 s cap never bit; cancel_all had been zeroing exposure for IOC fills; paper reserved the limit price instead of filling at the book; the bot re-bought the same ticker every run; daily_loss_usd was never written. Those are all in the one-shot now.

From the fresh rebuild this morning (16 tests pass), 8:58–9:03 AM ET:

08:58:39 KXNFLRECYDS-26NOV08CINATL-ATLAHOOPER81-40 (Austin Hooper: 40+ receiving yards) ask 0.0600 x50.00, limit 0.1500: PAPER IOC bid 1 @ 0.1500 -> filled 1.00 @ 0.0600 fee 0.01; exposure $0.070000, group paper-6cfc6744
08:58:39 KXNFLRECYDS-26NOV08CINATL-ATLAHOOPER81-40 … already hold 1.00, skip
KILL is on. No order, no order group.
{'paper_cancelled_resting': 0}
positions kept: {'KXNFLRECYDS-26NOV08CINATL-ATLAHOOPER81-40': {…}} exposure $0.070000
08:58:50 settled KXLIGAPROMATCH-26NOV050700LOBALO-LOB: no, pnl -0.13
08:58:51 KXNFLTD-26NOV08DENCAR-CARJCOKER18-3 (Jalen Coker: 3+ touchdowns) ask 0.0100 x25.00, limit 0.1500: PAPER IOC bid 1 @ 0.1500 -> filled 1.00 @ 0.0100 fee 0.01; exposure $0.090000, group paper-6cfc6744

The settlement line is a drill: we injected a test position on a demo market Kalshi had already finalized as "no", and the bot booked a $0.13 loss toward the daily limit. The second buy reused the first run's order group. After the HTTP fixes, fault drills against a local proxy: 429+Retry-After slept ~3 s; HTML 200 and 503 printed one clean line; hang ended with timed out in 16.5 s.

What we still can't test without demo keys: real demo fills, order-group rejection, signed cancels. Without an xAI key: the Grok research reply. kalshi.com/fee-schedule returned 429 during this check; the taker fee formula in the prompt (ceil to the cent of 0.07 * count * price * (1 - price)) still matches what we charge in paper. Docs pages we rely on were 200; demo and elections hosts both answered. Changelog Nov 5: market_closed → market_inactive on order errors; KXRFQ series excluded from unscoped lists.

Why Retry-After matters more than the happy path

Before the fix, a single 429 with Retry-After: 3 still retried after ~0.5 s. A drill that always returned 429 took about 22.6 s across five long retries and then printed a noisy client error. After the fix: when the header is present, sleep that many seconds (cap 8); at most two retries; timeout (5, 10). The same 429-once drill slept about 3 s and finished in 3.84 s. An always-429 drill now fails in 1.51 s with one clear line: fetch failed: 429 {"error":"too many requests"}.

That is the difference between "we rate-limit politely" and "we look like a broken client." Homemade exponential backoff is fine when the server is silent. When the server tells you when to come back, ignore that number and you are guessing.

HTML 200 and the hung host

A gateway login page served as HTTP 200 is not a JSON body. The pre-fix client raised Expecting value: line 1 column 1 — the classic JSONDecodeError surface. After the fix the same drill prints fetch failed: response was not JSON: gateway login. A 503 that returned HTML used to leak tags into the error string; it now collapses to 503 Service Unavailable.

The hung-host drill is the one that wastes a whole morning if you leave generous defaults in place. Against a proxy that never answered, the old client sat until an outer 55 s kill with empty stdout. The fixed client uses timeout=(5, 10), at most two retries, then fetch failed: timed out in about 16.5 s in our drill. You still will not get an instant Ctrl-C mid-request — that remains a noted limit — but you get a useful line and a bounded wait.

Thin demo books are a beginner gotcha

yes_ask_dollars of "0.0000" or "1.0000" means nobody is offering YES. Treat both as no ask. Never compute "100 − X" on dollar prices; the book returns bids only, and the implied YES ask is $1.00 minus the highest NO bid when you have to derive it from the book.

On Nov 5 around 8:57 AM ET, a scan of 5,000 open markets with mve_filter=exclude found 56 with a real YES ask, 18 of them ≤ $0.15. Around 9:04 AM the first 1,000 open markets had 13 real asks and zero ≤ $0.15. The ticker we used at 8:58 (KXNFLRECYDS-26NOV08CINATL-ATLAHOOPER81-40, Austin Hooper 40+ receiving yards) had ask 0.0600 x50 against a 0.1500 limit. A few minutes later the cheap end of the book had moved. Pick the ticker right before you run.

Unscoped GET /markets also skips on-demand KXRFQ series as of Kalshi's Nov 5, 2026 changelog. If your scan looks emptier than you expect, check the filter and the series, not only your pagination loop.

market_inactive (was market_closed)

As of that same changelog, orders on a halted or closed market return market_inactive (it used to say market_closed). Market lifecycle status values like active / finalized are unchanged; this bot still only bids when status is active. If your error handler still keys on the old string, a halt looks like an unknown failure instead of a clean skip.

Paper run numbers, verbatim from the rebuild

The 8:58 ET paper pass filled one contract on the Hooper ticker at 0.0600 with a $0.01 fee, booked $0.07 exposure under group paper-6cfc6744, skipped the held ticker on the next run, refused under KILL without creating a group, left exposure alone after cancel_all (paper_cancelled_resting: 0), settled the injected Ligamento position as no with pnl -0.13, then filled a second ticker (KXNFLTD-26NOV08DENCAR-CARJCOKER18-3 at ask 0.0100) reusing the same order group and ending at $0.09 exposure. Sixteen offline tests passed after the HTTP hardening. A second paper pass on the fixed build around 9:02 ET repeated the Hooper fill under a new paper group id, held skip, kill, and cancel-keeps-exposure.

None of those fills left the box. Paper mode reads the live public demo book and simulates an immediate-or-cancel fill locally. Real demo fills, order-group rejection, and signed cancels remain untested without keys.

Built this before Nov 5?

Paste this follow-up into the same project:

Update the Kalshi demo bot with these HTTP and docs fixes. Stay in
paper mode; send nothing to the network except public market reads.

1. Public GETs: timeout=(5, 10), at most 2 retries. On 429/5xx use
   bounded exponential backoff. If the response has Retry-After, sleep
   that many seconds instead (cap 8).
2. Never print a traceback for HTTP or JSON failures. One line only:
   "fetch failed: …". HTML or non-JSON 200 -> "response was not JSON: …"
   (strip tags, truncate). 503 HTML -> "503 Service Unavailable".
3. Hang/timeout -> "fetch failed: timed out" after the retries, then exit.
4. Catch BrokenPipeError around main (exit 0) so `| head` is quiet.
   KeyboardInterrupt -> one line, exit 130.
5. Docs: orders on a halted/closed market return market_inactive (Kalshi
   changelog Nov 5, 2026; was market_closed). Unscoped GET /markets skips
   on-demand KXRFQ series. Fee formula unchanged
   (ceil-cent 0.07 * count * price * (1 - price)); kalshi.com/fee-schedule
   may 429 — use the formula in the prompt.
6. Beginner gotcha: demo books are thin. When picking a ticker, scan
   status=open&mve_filter=exclude until yes_ask_dollars is strictly
   between 0 and 1 ("0.0000" and "1.0000" mean no ask).
7. Keep Oct 25 behaviour: one reused order group, paper IOC fill at the
   ask with fee, held-ticker skip, settle-first daily loss, cancel_all
   does not clear filled exposure.

Starting fresh? The full one-shot, the Oct 25 follow-up, the safety checklist, and every Kalshi doc we checked are on the recipe page. Run paper first with no keys. Touch KILL, confirm it refuses, then run cancel_all and confirm filled exposure stays put.

What this is and isn't

The page's verified line, word for word: Verified working on live data in paper mode, Nov 5, 2026. Ran live in paper mode against Kalshi's public demo market data on the morning of Nov 5 (ET), for several runs plus kill-switch, cancel-all, settlement and HTTP fault drills. We had no demo keys, so no signed request was sent and no demo order was placed; real demo fills and order-group rejections are untested. The optional research step was not called (research_enabled false; no xAI API call). Settlement was drilled with a test position on a demo market that had already been finalized.

These runs prove plumbing: retries, timeouts, paper IOC math, held-ticker skip, settle-first daily loss, kill, cancel-all. They do not prove a strategy. Demo books are thin and change by the minute; Kalshi notes that demo prices and behavior may differ from production. If you turn the research step on later, treat the model's probabilities as advisory. Kalshi's Developer Agreement allows API use for your own trading, not for running a bot for other people. Be wary of any account offering to "run your bot" or sell "Grok signals."

The full recipe — prompt, steps, FAQs on thin books and market_inactive, and the dated rebuild write-up — is at botcookery.com/recipes/grok-trading-bot.

API changes and new field notes: @botcookery on X (https://x.com/botcookery)

Our Polymarket-Kalshi arbitrage monitor found one 2¢ gap. After real fees it lost 1.4¢

BotCookery — Thu, 05 Nov 2026 14:54:07 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every number and log line below comes from read-only runs against the live Kalshi and Polymarket US public APIs on the afternoon of Oct 25, 2026. The monitor has no order code at all. Nothing here is financial advice.

"Risk-free arbitrage between Polymarket and Kalshi" is one of the most common bot pitches around. The idea is simple: if YES on one venue plus NO on the other costs less than $1.00, one of them has to pay $1.00, so you lock in the difference.

It only works if two things are true at once: the combined cost is under $1.00 after fees, and both contracts settle on exactly the same outcome. Our recipe builds an alerts-only monitor that measures both, for market pairs you map by hand. It never places, previews or cancels an order.

On Oct 25 we pasted the Oct 22 version of the prompt into a clean folder, let an AI coding tool build it, and ran it read-only on three real pairs: Magic at Knicks (NBA), Chiefs at Seahawks (NFL), and the 83-84°F bucket for Miami's Oct 26 high temperature. The skip rules, the stale-date rule and the "price is always YES" math were right. Six other things weren't.

Problem 1: the recommended Kalshi host answered 403

external-api.kalshi.com is the host Kalshi's docs recommend. From our network it answered 403, so the first run skipped all three pairs and reported nothing. The other documented host, api.elections.kalshi.com, worked fine.

The fix is boring but necessary: try the recommended host, switch once on a 403, and keep whichever works.

Kalshi https://external-api.kalshi.com/trade-api/v2 answered 403; switching to https://api.elections.kalshi.com/trade-api/v2

Problem 2: placeholder fees made a losing trade look break-even

The first build used a flat 1¢ per contract per venue as a placeholder. That doesn't match either venue's formula. Both fees scale with p × (1 - p), so they're largest near 50¢:

Kalshi taker: fee_multiplier × 0.07 × C × P × (1 - P), rounded up to the cent. The multiplier comes from GET /series/{series_ticker}.
Polymarket US taker: 0.0695 × C × p × (1 - p), rounded to the cent (banker's rounding).

On these books the real fees were 1.4-1.8¢ per contract on each leg. Here's the old build's first cycle at 3:41 PM ET:

!!! WARNING: fees.yaml has placeholder values. THESE EDGES ARE NOT REAL. !!!
Magic @ Knicks, Oct 25 (Orlando wins) [K YES + PM short] cost 0.2900+0.7200=1.0100 edge_after_fees -0.0300 depth 261080
Magic @ Knicks, Oct 25 (Orlando wins) [K NO + PM long] cost 0.7200+0.2900=1.0100 edge_after_fees -0.0300 depth 12550
Chiefs @ Seahawks, Oct 25 (Seattle ticker vs Chiefs-long) [K YES + PM long] cost 0.5900+0.4150=1.0050 edge_after_fees -0.0250 depth 1504150
Chiefs @ Seahawks, Oct 25 (Seattle ticker vs Chiefs-long) [K NO + PM short] cost 0.4200+0.5875=1.0075 edge_after_fees -0.0275 depth 651638
Miami high Oct 26, 83-84F [K YES + PM short] cost 0.6300+0.4100=1.0400 edge_after_fees -0.0600 depth 37
Miami high Oct 26, 83-84F [K NO + PM long] cost 0.3800+0.6000=0.9800 edge_after_fees +0.0000 depth 12
SKIP Stale test pair: rules_checked_on is 24 days old (>14)

That last Miami line is the only gross gap we saw all afternoon: Kalshi NO at $0.38 plus Polymarket US YES at $0.60 = $0.98. With placeholders it looks like a wash. Now the real math for 12 contracts:

Kalshi: 0.07 × 12 × 0.38 × 0.62 = $0.198, rounded up to $0.20
Polymarket US: 0.0695 × 12 × 0.6008 × 0.3992 = $0.20 (0.6008 is the 12-contract average, see problem 3)
Total per contract: 0.38 + 0.6008 + 0.40 / 12 = 1.0142

So the edge is -1.4¢ a contract. The one "arbitrage" of the afternoon loses money before you even think about timing. The new prompt computes both published formulas per leg, at the size you'd actually trade, keeps the coefficients in fees.yaml with a checked_on date, and warns when that date is over 30 days old.

Problem 3: "depth" meant the top level only

Polymarket US showed 11.66 contracts at $0.60. Twelve contracts don't fit in 11.66, so the real 12-contract average was $0.6008. A few minutes later someone had taken most of that offer, and the same 12 contracts averaged $0.6109.

The monitor now walks each book across levels, volume-weighted, for the size you'd trade, and logs "too thin" if either side can't fill it. One more trap: in Polymarket US's /bbo response, askDepth and bidDepth are not contract counts. Take sizes from /book.

Problem 4: the Miami gap wasn't an arbitrage anyway

Even with a positive edge, that pair would have been a bet, not an arbitrage. On Oct 25 Kalshi's Miami high-temperature market settled "according to The Weather Company". Polymarket US's settled on the National Weather Service's daily climate report. Same city, same day, same bucket, two different sources. They can disagree by a degree, and one degree moves a bucket.

The NFL pair differed too. Both venues paid $0.50 on a tie, but on a postponement Kalshi went to a fair price after 48 hours while Polymarket US waited up to two weeks.

The old prompt had a free-text notes field, which let us type "same bucket, same day" and move on. The new one makes you prove it:

Each pair gets kalshi_source, polymarket_source, tie_and_delay, rules_match (default false) and rules_hash.
--show-rules prints Kalshi's rules_primary, rules_secondary and the series settlement_sources next to the Polymarket US description, with one sha256 of the combined text.
A pair is skipped unless rules_match is true and the live hash still equals the saved one. If either venue edits its rules, the pair stops until you re-read them.

We tested that last part by changing one saved fingerprint:

SKIP Chiefs @ Seahawks, Oct 25 (Seattle): live rules hash 4acddea46b19a75e != saved 0000000000000000; re-read with --show-rules

Problem 5: it couldn't tell you how long a gap lasted

The first build would have re-alerted every 30 seconds while a gap stayed open and never logged when it closed. Gap duration is the number that matters most if you ever wanted to act by hand, so now it alerts once and logs a CLOSED line with how many seconds it lasted and the best edge seen.

Problem 6: piped output stayed empty

Our first 100-second run, piped through tee, printed nothing. Python buffers stdout when it isn't a terminal. Every line now prints with flush=True.

One near-miss: which end of Kalshi's book is the best bid

Kalshi's GET /markets/{ticker}/orderbook returns bids only, as [price, size] pairs sorted ascending, so the best bid is the last element. The YES ask is $1 minus the best NO bid. Our build happened to get this right, but the old prompt never said it, and taking the first element gives you a $0.99 ask. The new prompt spells it out and has a test for it.

After the fixes

Fresh rebuild from the new prompt, 9 tests passing, 3:46 PM ET, 10 contracts, the real pairs file:

Kalshi https://external-api.kalshi.com/trade-api/v2 answered 403; switching to https://api.elections.kalshi.com/trade-api/v2
Magic @ Knicks, Oct 25 (Orlando wins) [K YES + PM short] x10: K 0.2900 fee $0.15 | PM 0.7200 fee $0.14 | edge -0.0390/contract
Magic @ Knicks, Oct 25 (Orlando wins) [K NO + PM long] x10: K 0.7200 fee $0.15 | PM 0.2900 fee $0.14 | edge -0.0390/contract
SKIP Chiefs @ Seahawks, Oct 25 (Seattle): rules_match is not true
SKIP Miami high Oct 26, 83-84F: rules_match is not true

To check the alert path and the math, we ran a copy with every pair forced to rules_match: true, 12 contracts and a deliberately negative margin so alerts would fire (Miami lines, 3:48-3:51 PM ET):

ALERT Miami high Oct 26, 83-84F [K NO + PM long] x12: K 0.3800 fee $0.20 | PM 0.6008 fee $0.20 | edge -0.0142/contract
CLOSED Miami high Oct 26, 83-84F [K NO + PM long] after 73s, best edge -0.0142 (edge -0.0242)
Miami high Oct 26, 83-84F [K NO + PM long] x12: K 0.3800 fee $0.20 | PM 0.6109 fee $0.20 | edge -0.0242/contract

That's the whole story of the afternoon in three lines: the only gap was negative after fees, it got worse when the offer was taken, and the monitor logged exactly how long it lasted.

Built this before Oct 25? The follow-up prompt

If you built an earlier version, paste this into the same project:

Update my alerts-only arbitrage monitor with these fixes. Still no order
code of any kind; public reads only.

1. Kalshi host: try https://external-api.kalshi.com/trade-api/v2 first;
   on a 403, switch once to https://api.elections.kalshi.com/trade-api/v2
   and keep it. KALSHI_BASE still overrides both.
2. Check the Kalshi book math: arrays are bids sorted ASCENDING, so the
   best bid is the LAST element. YES ask = 1 - last NO bid, NO ask =
   1 - last YES bid. Taking the first element gives a $0.99 ask.
3. Replace the placeholder fees with the real formulas, computed per leg
   for the size you'd trade:
   Kalshi taker = fee_multiplier x 0.07 x C x P x (1-P), rounded UP to
   the cent (fee_multiplier from GET /series/{series_ticker}).
   Polymarket US taker = 0.0695 x C x p x (1-p), banker's rounding to the
   cent. Keep the coefficients in fees.yaml with a checked_on date and
   warn if it's older than 30 days.
4. Price min_size contracts by walking each book across levels
   (volume-weighted). If either side can't fill it, log "too thin".
   Take sizes from /book; /bbo askDepth and bidDepth are not sizes.
5. Add kalshi_source, polymarket_source, tie_and_delay, rules_match
   (default false) and rules_hash to each pair. Add --show-rules to print
   Kalshi rules_primary + rules_secondary + series settlement_sources
   next to the Polymarket US description, with a sha256 of both. Skip a
   pair unless rules_match is true and the live hash equals rules_hash.
6. Alert once when a gap opens; log a "closed" line with how many
   seconds it lasted and its best edge. Print with flush=True.
7. Tests for each of the above.

The full build prompt, the step-by-step for mapping pairs by hand, and the safety checklist are on the recipe page.

Takeaways if you're building one

Use the real fee formulas at your real size. Both fees peak near 50¢. A flat placeholder will show you gaps that don't exist.
Walk the book. Top-of-book size is often smaller than the trade, and it moves within minutes.
Read both rulebooks for every pair, and fingerprint them. "Same event" isn't the same contract if the settlement source, tie rule or postponement rule differs.
Log how long gaps last. That, plus size and edge after fees, is the honest answer to "do arbitrage bots work?"
Keep it private. Kalshi's Developer Agreement limits API data to your own trading and bars sharing it with third parties without written permission, so no public arb dashboards or paid alert channels.

What we verified, and what we didn't

From the recipe page: Verified working on live data in read-only mode, Oct 25, 2026. Ran read-only against the live Kalshi and Polymarket US public APIs on the afternoon of Oct 25, for several cycles on three hand-mapped pairs (one NBA game, one NFL game, one Miami temperature bucket), plus a forced-alert drill and a changed-rules drill. No gap that survived fees appeared, so no real alert fired. The Telegram and desktop alerts were not tested and no message was sent.

Fee coefficients and contract rules are as we read them on Oct 25. They change, so check both venues' fee pages and rules before you trust any number here.

Our bot's $10 exposure limit held $18.60 after one restart: kill switch fixes

BotCookery — Wed, 04 Nov 2026 14:55:12 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every log line below is from real runs on Oct 25, 2026: live public prices from Kalshi's demo exchange and Polymarket US, with every order going to a local mock exchange. We had no keys, so no signed request was sent anywhere. Nothing here is financial advice.

Our kill switch recipe is a prompt you paste into your AI coding tool inside an existing bot's folder. It asks for four things: hard limits checked in code before every order, a local KILL file, a cancel-all command for each venue, and Kalshi's server-side order groups as a last safety net.

A kill switch is the one part of a bot you hope never to use, which is exactly why it tends to go untested. So on Oct 25 we tested ours. We took a small bot with no limits at all: it joins the best bid on three Kalshi demo markets and two Polymarket US markets, five contracts each, and requotes as prices move. We pasted the Oct 22 version of our prompt into its folder, let it do the retrofit, and ran it.

The prompt got the KILL file and the allowlist right, and its tests passed. The limits still didn't hold. Here's what broke, what the logs showed, and how the prompt changed.

Bug 1: a restart reset the exposure limit

The limit was max_open_exposure_usd = 10. The retrofit tracked exposure as a counter in memory, starting at zero:

class State:
    def __init__(self):
        self.exposure_usd = 0.0
        self.realized_pnl_today = 0.0
        self.order_times = []

The first run did the right thing. It placed $9.30 across four markets and stopped at the fifth, because that one would have taken it to $12.25. Then we restarted it, the way a crash loop, a supervisor or an impatient Ctrl-C would. Here's the second run at 3:58 PM ET, right after the first:

order group mock-60c841c9
15:58:15 cycle 1
  placed k:KXHIGHNY-26OCT26-B68.5 bid 0.490 x5
  placed k:KXHIGHMIA-26OCT26-B83.5 bid 0.620 x5
  placed k:KXNBAGAME-26OCT28LALLAC-LAL bid 0.470 x5
  placed p:aec-nba-orl-ny-2026-10-25 bid 0.280 x5
  blocked p:tc-temp-miahigh-2026-10-26-gte83lt84f: exposure 12.25 > max_open_exposure_usd
order group left in place: mock-60c841c9
closed Polymarket US positions; bye

The counter started at zero again, so the same $9.30 went out again. After two runs the mock held $18.60 of resting bids against a $10 limit. The "blocked" line looks reassuring, and it is checking the wrong number.

The fix: open exposure is resting orders plus open positions, read from the venue (or the mock) at startup and every loop. On Kalshi that's GET /portfolio/orders?status=resting and GET /portfolio/positions; on Polymarket US, GET /v1/orders/open and GET /v1/portfolio/positions. Here's the rebuilt bot after a restart, 4:01 PM ET:

reusing order group mock-d5135215
found 4 resting orders from before; will amend, not duplicate
16:01:58 cycle 1
  exposure $9.55 / $10, daily loss $0.00 / $3
  BLOCKED p:tc-temp-miahigh-2026-10-26-gte83lt84f: create: exposure 12.50 > max_open_exposure_usd

It starts at $9.55, where the last run left off, not at $0.

Bug 2: the daily-loss stop was dead code

The retrofit had a daily-loss stop, and it had a test, and the test passed. Here's the function:

def record_fill_pnl(pnl, state=STATE):
    """Call with realized PnL from each closing fill. Trips the daily loss stop."""
    state.realized_pnl_today += pnl
    if state.daily_loss() >= LIMITS["max_daily_loss_usd"]:
        open(os.path.join(ROOT, "KILL"), "w").write("daily loss stop\n")

The only caller was the test. The bot itself never called it. And even if it had, it counted realized PnL only, so an open position could lose a lot without ever tripping the stop.

The fix: PnL is realized plus unrealized, with open positions marked at the best bid. The bot saves PnL at the first loop of each local day in state.json, and daily loss is that snapshot minus PnL now, computed in the main loop every cycle rather than in a fill handler. At the limit it creates KILL, runs cancel-all and logs it.

To drill it, we gave a copy of the bot a $1 limit and a seeded position of 5 Miami contracts bought at $0.95. The live bid was $0.62, so the main loop marked it down on the very first cycle (4:02 PM ET):

  exposure $8.85 / $10, daily loss $1.65 / $1.0
  DAILY LOSS LIMIT HIT: wrote KILL, running cancel_all.py
[mock] kalshi after: 0 resting []
[mock] polymarket_us after: 0 open []
ALL CLEAR

5 contracts x ($0.95 - $0.62) = $1.65. Nothing had filled or closed, which is the point: the old stop would have said $0.00.

Bug 3: amends skipped every check

Our bot requotes. When the best bid moves it doesn't cancel and re-place, it amends on Kalshi and modifies on Polymarket US. Neither path went through check_order, and neither counted toward max_orders_per_minute. The old prompt only asked about order creation, and its test only looked there.

That matters more than it sounds. A requoting bot spends most of its life amending. A per-minute cap that ignores amends can't stop a requote loop, and an exposure check that ignores amends lets a bot walk a small order up to any price.

The fix: every create, amend, modify and close calls check_order(action, order, state), and amends and modifies count toward the per-minute cap. Kalshi amend is POST /portfolio/events/orders/{id}/amend, where count is the new total, not a delta. Polymarket US modify is a cancel-replace. The test that walks the code with ast now has to catch POSTs to any order path: create, amend, modify, batch and close.

In the rebuild, we moved one resting bid to $0.60 so the bot would amend it back to the $0.62 bid. The amend went through check_order and counted against exposure only for the 10-cent difference.

Bug 4: the no-keys cancel-all only printed

With no keys, the old cancel_all.py had nothing to talk to, so it printed what it would have sent. This is the whole output:

[mock] would send: GET  /trade-api/v2/portfolio/orders?status=resting
[mock] would send: DELETE /trade-api/v2/portfolio/events/orders  (signed, expect 204)
[mock] would send: GET  /trade-api/v2/portfolio/orders?status=resting
[mock] would send: POST https://api.polymarket.us/v1/orders/open/cancel {"slugs": []}
[mock] would send: GET  https://api.polymarket.us/v1/orders/open

Five lines that look like a working kill switch. Afterwards the mock still had 12 resting orders. A drill that can't fail proves nothing.

The fix: with no keys, the mock really cancels, and cancel_all.py re-lists after cancelling, prints before and after for each venue, and exits 1 if anything is still resting. On Polymarket US the re-list matters even with keys: canceledOrderIds in the response isn't proof, the follow-up GET /v1/orders/open is. Here's touch KILL and python cancel_all.py in the rebuild:

KILL ACTIVE: no new orders. Run cancel_all.py if anything is resting.
[mock] kalshi before: 3 resting ['542f952ead4f', '528a849bdd5b', 'f8d779bab1ca']
[mock] kalshi order group mock-d5135215 triggered (reset it by hand to trade again)
[mock] kalshi after: 0 resting []
[mock] polymarket_us before: 1 open ['36638965e827']
[mock] polymarket_us canceledOrderIds: ['36638965e827']
[mock] polymarket_us after: 0 open []
ALL CLEAR

Bug 5: a new Kalshi order group every run

Kalshi order groups are the server-side layer: if fills in the group exceed a contracts limit in a rolling 15-second window, Kalshi cancels every resting order in the group and blocks new ones until you reset it. It's the one layer that still works if your bot is wedged.

The retrofit created a fresh group on every start. Three runs made three groups (mock-44e01417, mock-60c841c9, mock-4c8c7392), and every run ended with order group left in place. Cancel-all never triggered any of them, so nothing stopped new orders on Kalshi's side.

The fix: save the group id in state.json and reuse it on restart, after a GET to check it still exists. Cancel-all now also sends PUT /portfolio/order_groups/{id}/trigger, so Kalshi rejects new orders in the group until a person resets it. A normal shutdown skips the trigger with --no-trigger. And if the group is missing or triggered, the bot refuses to start. Deleting KILL and restarting after the drill above gave:

order group mock-d5135215 is triggered. Reset it by hand, then restart.

That's the behaviour you want. A kill switch that a restart quietly undoes isn't one.

Bug 6: shutdown sent a market order and said "closed" when it wasn't

This was the one that worried us most. Here's the retrofit's shutdown handler:

def shutdown(*_):
    for s in cfg["pm_slugs"]:
        try:
            venues.pm_close(P, s)
        except risk.RiskError as e:
            print(f"  close blocked {s}: {e}", flush=True)
    print(f"order group left in place: {venues.ORDER_GROUP_ID}", flush=True)
    print("closed Polymarket US positions; bye", flush=True); sys.exit(0)

On exit it tried Polymarket US close-position for every configured market. Close-position is a market order with no slippage limit unless you set one. After the first run's normal stop, the mock's request log (timestamps trimmed) shows both going out, including one for the Miami market the bot had never managed to buy:

{"venue": "polymarket_us", "mock": true, "method": "POST", "path": "/v1/order/close-position", "body": {"marketSlug": "aec-nba-orl-ny-2026-10-25", "manualOrderIndicator": "MANUAL_ORDER_INDICATOR_AUTOMATIC"}}
{"venue": "polymarket_us", "mock": true, "method": "POST", "path": "/v1/order/close-position", "body": {"marketSlug": "tc-temp-miahigh-2026-10-26-gte83lt84f", "manualOrderIndicator": "MANUAL_ORDER_INDICATOR_AUTOMATIC"}}

On the third run we touched KILL. check_order blocked the closes, and the last line still claimed success (cycle lines trimmed):

KILL ACTIVE
  close blocked aec-nba-orl-ny-2026-10-25: KILL ACTIVE
  close blocked tc-temp-miahigh-2026-10-26-gte83lt84f: KILL ACTIVE
closed Polymarket US positions; bye

Meanwhile the Kalshi orders were left resting. So a normal exit fired market orders, and an emergency exit printed a lie and left the orders up.

The fix: shutdown runs cancel_all --no-trigger, prints whether anything is still resting, and exits. Positions stay open. The bot never sends a close-position or market order on its own, and it doesn't print "closed" unless something closed. Closing a position in a thin or fast market can cost more than the position, so that decision belongs to a person looking at the book. A normal stop in the rebuild now ends like this, with no close or market order in the request log:

shutting down: cancelling resting orders (positions are left open)
[mock] kalshi before: 3 resting ['c8b64f68902a', '506abc41c89e', '9082b77822cb']
[mock] kalshi after: 0 resting []
[mock] polymarket_us before: 1 open ['f16c723114a8']
[mock] polymarket_us canceledOrderIds: ['f16c723114a8']
[mock] polymarket_us after: 0 open []
ALL CLEAR
bye

One trap for any guard: same path, two meanings

Kalshi creates orders with POST /portfolio/events/orders and cancels all of them with DELETE on the same path. Any guard that matches on path alone, like a test that says "every request to the orders path must go through check_order", either blocks your cancel-all or misses your creates. Match method and path together.

Two more venue facts worth knowing before you build this. Kalshi's cancel-all docs note that orders placed in the minute after the request may also be cancelled. And on Polymarket US, pure cancels are never rejected by its 5-second latency stopgap, so cancel-all still works when new orders are being rejected.

The follow-up prompt

Built this before Oct 25? Paste this into the same project:

Fix the risk limits and kill switch in this bot. Read risk.py,
cancel_all.py and every order function first; tell me which of these
problems you find before changing anything.

1. Every create, amend, modify and close must call check_order(action,
   order, state). Amends and modifies count toward max_orders_per_minute.
   Kalshi amend is POST /portfolio/events/orders/{id}/amend (count is the
   new total); Polymarket US modify is a cancel-replace.
2. Open exposure = resting orders + open positions, read from the venue
   (or the mock) at startup and every loop. An in-memory counter resets
   on restart. Kalshi: GET /portfolio/orders?status=resting and
   GET /portfolio/positions. Polymarket US: GET /v1/orders/open and
   GET /v1/portfolio/positions.
3. Daily loss: PnL = realized + unrealized, positions marked at the best
   bid. Save PnL at the first loop of each local day in state.json; daily
   loss = that minus PnL now. Compute it every loop in the main loop, not
   in a fill handler. At the limit: create KILL, run cancel_all, log it.
4. The ast test must catch POSTs to any order path (create, amend,
   modify, batch, close). Kalshi create and cancel-all share
   /portfolio/events/orders, so match method AND path.
5. Kalshi order group: save its id in state.json and reuse it (GET it
   first). If it's missing, create one; if it's triggered, refuse to
   start until I reset it.
6. cancel_all.py: Kalshi list, DELETE /portfolio/events/orders, then
   PUT /portfolio/order_groups/{id}/trigger (skip with --no-trigger),
   list again. Polymarket US POST /v1/orders/open/cancel {"slugs": []},
   then GET /v1/orders/open. Print before/after; exit 1 if anything is
   still resting. With no keys, make the mock really cancel.
7. Shutdown: run cancel_all --no-trigger and exit. Remove any automatic
   close-position or market order. Don't print "closed" unless it is.

Add tests for each fix, run them, and show me a diff summary.

Starting fresh? The full prompt is on the recipe page. Commit your bot first so you can see exactly what changes, set limits you'd be fine losing entirely and then halve them, and drill each layer:

Run the tests. Then delete check_order from one amend function and run them again. The ast test should fail; if it doesn't, it isn't checking amends.
Stop the bot with orders resting and start it again. Exposure should start where it left off, not at $0.
touch KILL, confirm no new orders, run python cancel_all.py and look for "after: 0" on both venues.
In a copy, set a $1 daily-loss limit, seed a losing position in the mock, and confirm the main loop writes KILL and cancels everything.

Time yourself. You want "something's wrong" to "everything cancelled" in under 30 seconds. Then write the stop procedure on a sticky note: touch KILL, run cancel_all.py, check the venue UI, revoke the API key if anything looks wrong. Give the bot's Kalshi key only the scopes it needs (read and trade, not transfers).

What this is and isn't

The page's verified line, word for word: Verified working on live data in mock mode, Oct 25, 2026. Ran against a local mock exchange on Oct 25 with live public Kalshi demo and Polymarket US prices, on three Kalshi and two Polymarket US markets: a restart, an amend, a KILL plus cancel-all drill, a daily-loss drill and a normal shutdown. We had no Kalshi demo or Polymarket US keys, so no signed request was sent; the real cancel-all, order-group and position calls are written from the docs and not yet run.

So: the logic was drilled, the venue calls were not. If you have Kalshi demo keys, run the same drills on the demo exchange, including a deliberately low order_group_contracts_limit and a manual trigger, and check each call does what the docs say before trusting it. Polymarket US has no public demo exchange, so drill the local layers against a paper ledger and test cancel-all live only with a single tiny resting limit order far from the market. The bot in these runs is a placeholder quoter, not a strategy.

The full recipe, with the complete prompt, step-by-step setup, the safety checklist and links to every Kalshi and Polymarket US doc we checked, is at botcookery.com/recipes/trading-bot-kill-switch-position-limits.

Hyperliquid API in Python: our $25 cap refused 892 of 892 $25 orders

BotCookery — Tue, 03 Nov 2026 14:53:09 +0000

Originally published on BotCookery, a free site of build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every number below comes from real runs against Hyperliquid's public API on Oct 25, 2026. Signed calls are testnet only, and nothing here is financial advice or a trading signal.

We publish a copy-paste prompt that has an AI coding tool build a small Python starter for the Hyperliquid API: reads on mainnet or testnet, and signed orders on testnet only, capped at $25. On Oct 25 we checked whether that prompt actually holds up. We pasted the Oct 22 version into a clean folder, let it build, and ran it live: reads on both networks, a dry-run order for every listed perp, and signed testnet calls with a throwaway key that held no funds.

Most of it worked. Reads, asset lookups, price rounding, the --mainnet flag and the testnet-only guard all did what they should. Every one of the 158 live testnet perps and 178 live mainnet perps got a valid price at $10.

Then we asked for $25, and the bot refused. Every time, on both networks: 424 of 424 dry-run $25 orders on testnet and 468 of 468 on mainnet. The cap meant to keep orders small was the thing blocking them. That was one of four problems the rebuild turned up; here's each one, what we saw in the logs, and how the prompt changed.

Hyperliquid in one paragraph

Everything is a JSON POST. Reads go to /info with a type (meta, allMids, l2Book, candleSnapshot, clearinghouseState, openOrders) and need no signature. Orders go to /exchange and are signed, which is where the official hyperliquid-python-sdk earns its keep. Testnet lives at api.hyperliquid-testnet.xyz, mainnet at api.hyperliquid.xyz, and they are different markets with different prices. The first lines of each of our cycles were testnet mids, then mainnet mids:

BTC        80973.5 ETH        2352.75 SOL        101.445
BTC        80646.5 ETH        2354.95 SOL        101.925

A few rules the prompt spells out, because an AI tool will otherwise guess:

Asset IDs differ between networks. Look up the index and szDecimals from meta() on the same network every time. Never hardcode them.
Prices: at most 5 significant figures and at most 6 - szDecimals decimals for perps. Integer prices are always valid.
$10 minimum notional per order.
Agent wallets have no balance. You approve an agent key to sign for your main account, but balance and open-order lookups must use the main address.

1. A $25 order could never pass

The starter places a post-only (Alo) limit 10% away from the mid, so the order rests instead of filling. Size is usd / limit, rounded up to szDecimals. Rounding up is deliberate: rounding down, or sizing on the mid, leaves a $10 buy under the $10 exchange minimum.

But rounding up always lands the notional a little over what you asked for. And the cap compared that notional to $25. So in the original build, plan BTC buy 25 printed:

refusing: notional 25.51 > $25.0

That wasn't a BTC quirk. It refused all 424 dry-run $25 orders on testnet and all 468 on mainnet. The only orders that could pass were ones small enough that rounding didn't push them over, which made the "$10 to $25" range really "$10 to a bit under $25".

The fix is to check two different things. The requested amount must be between $10 and $25. The order's own notional must be at least $10 and no more than the request plus one size step (10^-szDecimals x limit). From the rebuilt version:

$ python3 cli.py plan BTC buy 25
  "sz": 0.00035,
  "limit_px": 72876.0,
  "notional": 25.5066,
checks: pass

0.00035 x 72,876 = 25.5066. Over $25 by one step's worth of rounding, which is exactly what the cap now allows.

2. Delisted coins looked tradable

allMids still quotes delisted perps. The original build treated "has a mid" as "trades", so:

$ python3 cli.py plan MATIC buy 10
...
checks: pass

MATIC is one of 54 delisted perps on testnet. The meta response marks them with "isDelisted": true, and the asset lookup now raises on that flag:

$ python3 cli.py plan MATIC buy 10
error: MATIC is delisted on testnet

Across three cycles of the rebuilt version, testnet listed 212 perps and mainnet 234. Every live one passed at both $10 and $25 on both sides (316/316 testnet, 356/356 mainnet), and every delisted one was refused:

testnet 212 perps: {'pass_10': 316, 'pass_25': 316, 'refused_delisted': 216} []
mainnet 234 perps: {'pass_10': 356, 'pass_25': 356, 'refused_delisted': 224} []

3. The dead-man switch would have blocked every order on a new account

The prompt has the bot call scheduleCancel before every order: a dead-man switch that cancels all open orders at a set time if the bot dies. The original rule was strict. If scheduleCancel didn't return ok, send no order.

The problem is that Hyperliquid only allows scheduleCancel above a trading-volume threshold. A published reply shows the error as Cannot set scheduled cancel time until enough volume traded. Required: $1000000. A brand-new testnet account will never clear that, so the strict rule meant a reader following the recipe could never place an order at all.

To be clear about what we saw: our throwaway key was never approved and the account was never funded, so the exchange stopped us earlier, before the volume check could come up. The orders.jsonl log from the run shows that refusal on every attempt:

{"kind": "schedule_cancel", "req": {"time": 1792953489708}, "resp": {"status": "err", "response": "User or API Wallet 0x46b7… does not exist."}}

So the volume error itself is sourced, not observed, and the code path for it is tested offline only.

The new behavior keeps the safety without the dead end:

On that exact volume error, print dead-man switch unavailable for this account and continue.
On any other non-ok reply, still refuse and send no order. That's what happened in our runs: refusing: schedule_cancel failed, no order sent.
place now takes --hold SECONDS (10 to 300). If the order rests, the bot waits, then cancels it by oid in a finally block, so Ctrl-C during the hold still cancels. It then checks openOrders that the oid is gone and exits non-zero if it isn't.

Without the exchange's dead-man switch, the bot is its own. That's a weaker guarantee, so the hold is short and the cancel is confirmed.

One more check from the same runs: place and cancel-all don't accept --mainnet at all. Passing it gets cli.py: error: unrecognized arguments: --mainnet before anything is signed.

4. The main key was left on disk

Hyperliquid lets a main account approve an "agent" (API wallet) key that signs on its behalf. The prompt's safety notes say to keep the main key away from the bot and give the bot only the agent key.

The original approve_agent.py loaded the main key from the same env file it then wrote the agent key to. So after a successful approval, the key you're supposed to keep away from the bot sat right next to it.

Now it reads the main key once with getpass.getpass(), never writes it anywhere, and saves only HL_MODE=testnet, HL_AGENT_PRIVATE_KEY and HL_ACCOUNT_ADDRESS (the main address) to ~/.config/hl-bot/.env with chmod 600. It also saves only the agent key the SDK returns from approve_agent, and only if the result is ok. On our unfunded account it saved nothing:

$ python3 approve_agent.py
approve failed, nothing saved: {'status': 'err', 'response': 'Must deposit before performing actions. User: 0xd40d…'}

Already built it? The follow-up prompt

If you built the starter from the earlier prompt, paste this into the same project:

Update my hl-starter:
1. asset_info(): raise on any coin whose meta entry has "isDelisted": true. allMids still returns a mid for delisted perps, so plan/place must not accept them.
2. check_order(): check the requested usd is between $10 and $25, and allow the order's own notional (size x limit) to be at most usd plus one size step (10^-szDecimals x limit). Rounding the size up means comparing the notional itself to $25 refuses every $25 order.
3. place(): Hyperliquid rejects schedule_cancel on accounts without enough traded volume ("Cannot set scheduled cancel time until enough volume traded..."). On that exact error, print "dead-man switch unavailable for this account" and continue; on any other schedule_cancel error, still send no order. Add `--hold SECONDS` (10-300, default 60): after the order rests, wait, then cancel it by oid in a `finally` (so Ctrl-C cancels too) and confirm with openOrders that it's gone; exit non-zero if it isn't.
4. approve_agent.py: read the main testnet key with getpass.getpass() and never write it to any file. Write only HL_MODE=testnet, HL_AGENT_PRIVATE_KEY and HL_ACCOUNT_ADDRESS, keeping other lines in the env file.
Add a test for each, then run pytest and `python3 cli.py plan BTC buy 25`.

Run it yourself

The full prompt is on the recipe page. If you'd rather start from code, the rebuilt starter is on GitHub at lazyclaw137-ship-it/hyperliquid-api-starter-testnet. Reads need nothing:

pip install hyperliquid-python-sdk requests python-dotenv pytest
python3 cli.py mids
python3 cli.py book BTC --mainnet
python3 cli.py plan BTC buy 25

Signed calls need a testnet account and an approved agent key, and stay on testnet. The code checks for that twice.

Verified working on live data in read-only mode, Oct 25, 2026. Reads ran live on testnet and mainnet, and order sizing was checked against every listed perp on both. Signed testnet calls used an unfunded throwaway key, so the exchange refused them before any order existed. We did not see a resting order, a fill or the dead-man volume error ourselves; the code path for that error is tested offline only.

More recipes, including a Hyperliquid funding-rate monitor, are at botcookery.com.

We rebuilt our Kalshi AI trading bot from its own prompt twice: it bought a filled order again

BotCookery — Mon, 02 Nov 2026 14:55:03 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every log line below is from real runs on Oct 24 and Oct 27, 2026, with live market data from Kalshi's demo exchange and a mock broker: no keys, and no order was sent anywhere. Nothing here is financial advice, and the strategy in this bot is a placeholder.

Our Kalshi AI trading bot recipe is a prompt. You paste it into your AI coding tool in an empty folder and it builds a small Python bot that runs on Kalshi's demo environment by default: it watches a few markets, applies your rule, checks hard limits in code, and places 1-contract limit orders inside an order group, with a kill switch and an optional LLM research step that only ever sees public market text.

The interesting part of a bot like this isn't the strategy. It's everything around the order: what happens on restart, after a fill, when a market closes, when the API is slow. So we tested exactly that. Twice, we pasted the published prompt into a clean folder, built it as written, and ran it against live demo markets with a mock broker. The first pass (Oct 24) found three bugs. The second pass (Oct 27) built the fixed Oct 24 prompt exactly as written and found five more. The prompt is now fixed for all eight.

None of them was a crash. Each one was the bot quietly doing the wrong thing with orders, limits or retries.

The Kalshi side in one paragraph

Orders go to POST /portfolio/events/orders (Create Order V2; Kalshi says the legacy /portfolio/orders will be deprecated no earlier than May 6, 2026). The body has ticker, side (bid or ask), count as a string, price as a fixed-point dollar string like "0.5600", time_in_force, self_trade_prevention_type, and optional client_order_id, post_only, reduce_only and cancel_order_on_pause. Order groups (POST /portfolio/order_groups/create) auto-cancel every resting order in the group if fills exceed a contracts limit in a rolling 15-second window. DELETE /portfolio/events/orders cancels everything. Demo lives at https://external-api.demo.kalshi.co/trade-api/v2, with separate keys. Kalshi's order book lists bids only, so the implied YES ask is 1.00 minus the best NO bid; no NO bids means no ask, and the bot doesn't trade.

Here's what the mock broker logs when the rule fires (Oct 27 clean rebuild, trimmed):

{"event": "mock request (not sent)", "method": "POST", "path": "/portfolio/events/orders", "body": {"ticker": "KXNHLGOAL-26OCT27CBJPHI-PHIABUMP20-1", "side": "bid", "count": "1.00", "price": "0.1800", "time_in_force": "good_till_canceled", "self_trade_prevention_type": "taker_at_cross", "client_order_id": "8d438211-...", "order_group_id": "mock-group-6d89936d", "cancel_order_on_pause": true}}
{"ticker": "KXNHLGOAL-26OCT27CBJPHI-PHIABUMP20-1", "seen": {"yes_bid": 0.15, "yes_ask": 0.18, "status": "active"}, "rule": "fair 0.25 - ask 0.18 - fee 0.0103 = 0.0597 > margin 0.03: bid 1 @ 0.1800", "risk": "ok", "event": "order sent (mock)"}

The fair price of 0.25 is a placeholder in the config, not a view on the market.

Bug 1: a filled order got bought again

After the first pass, the prompt said: treat any ticker with a resting order as already ordered. That fixed restarts. It didn't fix fills. A filled order isn't resting any more, so on the next loop the ticker looks untouched and the bot bids again.

We tested it by removing two orders from the mock's saved state, which is what a fill looks like from the bot's side. The very next loop sent new orders on both tickers. With a real account, that's a bot that buys again every time one of its orders fills.

The fix: save the tickers ordered today in state.json, and also skip any ticker where GET /portfolio/positions shows a position. In the clean rebuild, we marked the one resting order as filled at 14:21:10 UTC. The log for that ticker changed from one reason to another and stayed there:

{"ts": "2026-10-27T14:21:09+00:00", "ticker": "KXNHLGOAL-26OCT27CBJPHI-PHIABUMP20-1", "event": "no order", "rule": "already have a resting order here"}
{"ts": "2026-10-27T14:21:21+00:00", "ticker": "KXNHLGOAL-26OCT27CBJPHI-PHIABUMP20-1", "event": "no order", "rule": "already ordered today"}

The next 41 loops on that ticker said "already ordered today" and sent nothing.

Bug 2: the orders-per-minute cap forgot itself on restart

max_orders_per_minute worked, as long as the process stayed up. The count lived in memory. In our drill the cap blocked an order at 13:11:54 UTC. We restarted the bot, and the same order went out nine seconds later.

Any limit that lives only in memory is a limit that a crash loop, a supervisor restart or an impatient Ctrl-C resets. Order timestamps are now saved in state.json. So is the 60-second wait after a cancel-all, which matters for a specific Kalshi reason: the docs for DELETE /portfolio/events/orders say orders placed in the minute after the request may also be cancelled. If you clear the KILL file while the bot is stopped, the restart still waits.

Bug 3: a typo'd ticker was retried forever

We put one deliberately wrong ticker in the config. The first build logged an identical data error for it on every single loop, 126 times in the run:

{"ts": "2026-10-27T13:08:05+00:00", "ticker": "KXBOTCOOKERY-NOTREAL", "event": "data error", "error": "HTTP 404: {\"error\":{\"code\":\"not_found\",\"message\":\"not found\"}}"}
{"ts": "2026-10-27T13:08:17+00:00", "ticker": "KXBOTCOOKERY-NOTREAL", "event": "data error", "error": "HTTP 404: {\"error\":{\"code\":\"not_found\",\"message\":\"not found\"}}"}
{"ts": "2026-10-27T13:08:29+00:00", "ticker": "KXBOTCOOKERY-NOTREAL", "event": "data error", "error": "HTTP 404: {\"error\":{\"code\":\"not_found\",\"message\":\"not found\"}}"}

This one is easy to hit for real: demo and production list different markets, so a ticker copied from kalshi.com usually 404s on demo. A 404 is now logged once and the ticker is skipped for the rest of the run:

{"ts": "2026-10-27T14:20:58+00:00", "ticker": "KXBOTCOOKERY-NOTREAL", "event": "ticker not found (404): skipping it from now on"}

In the clean rebuild that line appeared once per process, five processes in all, instead of 126 times.

Bug 4: a closed market's order stayed in exposure forever

One demo market finalized at 13:20 UTC, and the mock broker still listed our order on it as resting. So it counted against the $5 exposure cap for the rest of the run. On the real exchange, resting orders are cancelled when a market closes; the mock didn't know that, which means every exposure test after the first close was testing a fiction.

The mock now drops resting orders when a market's status is no longer active, and logs it. In the longer live run we watched short-lived demo markets go initialized to active to closed to determined, and the new code caught it:

{"ts": "2026-10-27T14:00:13+00:00", "ticker": "KXQUICKSETTLE-27OCT26H1000-3", "event": "market closed: 1 resting order(s) now gone"}

The point generalizes: if your mock is more forgiving than the exchange, your risk checks pass for the wrong reason.

Bug 5: retries ignored the server and the clock

For this one we put a local fault-injecting relay between the bot and Kalshi's demo host, and made it misbehave on purpose. A 429 carrying Retry-After: 5 was retried after a fixed 0.5 to 8 seconds, ignoring the header. With the server returning 429 or 503, one loop over six tickers took 48 seconds. With a server that answered slowly, it took 60.

The client now retries only GETs (never an order), honours Retry-After up to 30 seconds, uses a 5-second connect and 10-second read timeout, and ends the loop after two tickers in a row fail on the network. One loop each with the final code: 429 with Retry-After: 5 took 40 seconds, 503 took 16, a dropped connection 16.

The slow-server drill also caught a bug in our own fix. The 30-second limit covered one attempt, not the retries, so one ticker could spend 58 seconds retrying. A 25-second total budget per call brought it to 32 seconds per ticker. A loop that gives up after two tickers still takes about 63 seconds, which is no faster than before for a slow server. It just stops hammering it.

Here's the clean rebuild against the relay returning 429 with Retry-After: 5:

{"ts": "2026-10-27T14:26:04+00:00", "event": "reusing order group", "order_group_id": "mock-group-6d89936d"}
{"ts": "2026-10-27T14:26:24+00:00", "ticker": "KXWTAMATCH-26OCT28DARTJE-TJE", "event": "data error", "error": "HTTP 429: {\"error\":{\"code\":\"too_many_requests\",\"message\":\"too many requests\"}}"}
{"ts": "2026-10-27T14:26:44+00:00", "ticker": "KXWTAMATCH-26OCT28DARTJE-DAR", "event": "data error", "error": "HTTP 429: {\"error\":{\"code\":\"too_many_requests\",\"message\":\"too many requests\"}}"}
{"ts": "2026-10-27T14:26:44+00:00", "event": "2 tickers in a row failed on the network: ending this loop early"}

Five tries per ticker, 5 seconds apart, then the loop ended after two tickers: 41 seconds and 10 requests in all, every one a GET.

Also new: the fee comes off the edge

The bot bids at the implied ask, so it crosses the book and pays Kalshi's taker fee: 0.07 x price x (1 - price) per contract, up to 1.75 cents. The prompt now subtracts that before comparing your edge to the margin. That's the fee 0.0103 in the log above (0.07 x 0.18 x 0.82). It comes from Kalshi's fee schedule, not from the run, but with a 3-cent margin in the config it can decide whether the rule fires at all.

The first pass, Oct 24: three bugs that came first

Restarting stacked a second order. The original prompt said "at most one order per ticker per run". Our build kept that in memory, so a restart sent a second resting bid on the same market and created a second order group. That's where the "resting order = already ordered" rule and the saved order group id came from.

Daily loss came from the wrong place. The old prompt computed it from GET /portfolio/positions as realized P&L minus fees. That endpoint returns unsettled positions by default, and its P&L is per market, not per day. Fed to the risk module as written:

old unsettled loss counts as today: 2.15
after settlement it vanishes     : 0.0

A loss from last week would block today's trading, and a losing market stops counting the moment it settles. Daily loss now comes from GET /portfolio/balance: equity (balance plus portfolio value) at the first loop of the UTC day, minus equity now, saved in state.json.

Resting orders didn't count as exposure. Only positions counted, so unfilled bids were invisible to the cap, and the mock returned no positions at all, so the cap never ran. Exposure now adds the cost of resting orders.

A few things we noticed along the way: of the 8,000 open, non-combo demo markets we listed on Oct 24, only 6 had both a YES bid and a YES ask. You filter with ?status=open, but each market comes back as active. And from our server, external-api.kalshi.com returned 403 while api.elections.kalshi.com answered, which is why the production base URL is overridable.

Rebuilt from scratch: what held

After the fixes, we built the bot again in an empty folder from the published prompts only. 27 tests passed. Then 44 loops over about 11 minutes on 8 live demo tickers, mock broker. The filled order wasn't bought again. A restart reused the saved order group and sent 0 orders. A second copy refused to start:

another copy of the bot is already running: refusing to start

When a market closed, the mock dropped its resting order and logged it. And one gap in the prompt itself turned up: a Retry-After of 30 seconds can never fit a 25-second budget. The rebuild gave up instead of waiting, and the prompt now says a wait that would pass the budget ends the retries.

The follow-up prompt

Built the bot before Oct 27? Paste this into the same project. (If you built it before Oct 24, the recipe page has a second follow-up prompt to paste first.)

Update my Kalshi bot:
1. A filled order is no longer resting, so save the tickers I ordered today
   in state.json and skip them. Also skip any ticker where GET
   /portfolio/positions shows a position.
2. Save order timestamps in state.json so max_orders_per_minute survives a
   restart. Save the 60 s post-cancel-all wait there too, so clearing KILL
   while the bot is stopped still waits.
3. If a ticker returns 404, log it once and skip it for the rest of the run.
4. Mock broker: when a market's status is no longer active, drop its resting
   orders from logs/mock_state.json and log it, so exposure is released.
5. Subtract Kalshi's taker fee, 0.07 * ask * (1 - ask), from my edge before
   comparing it to the margin.
6. HTTP client: retry GETs only, never POSTs. Honor Retry-After (cap 30 s),
   timeout (5 s connect, 10 s read), a 25 s total retry budget per call (a wait that
   would pass it ends the retries), and
   end the loop early if two tickers in a row fail on the network. Page
   through GET /portfolio/orders?status=resting with the cursor.
7. A second copy of the bot must refuse to start (file lock).
Add tests for each, run them, and show me the diff before changing anything else.

Starting fresh? The full prompt is on the recipe page. Do the Kalshi API starter first for a signed client, pick 1-3 tickers from the demo market list (ones with both a bid and an ask), set tiny limits (1 contract per order, $5 exposure, $2 daily loss), and run it with no keys at all:

BROKER_MOCK=1 python bot.py

The mock logs each request it would send and sends nothing. Its balance is a fixed $100 labelled mock, so the daily-loss limit only really runs with demo keys. Then drill the safety net: touch KILL cancels everything once and stops ordering, removing it waits 60 seconds, and deleting an order from logs/mock_state.json simulates a fill that must not be bought again.

What this is and isn't

The page's verified line, word for word: Verified working on live data in mock mode, Oct 27, 2026. Clean-folder rebuild from the published prompts only, then live demo market data (44 loops over about 11 minutes), mock broker: no demo keys and no orders sent, so the daily-loss limit was not exercised. Fills and outages were simulated (edited mock state, a local fault-injecting relay). The same assistant that wrote the earlier versions did the rebuild, and the Oct 24 and Oct 27 follow-up prompts were checked against the new build rather than run as an upgrade of an old one.

Some changes are covered by unit tests only, not by the live run: the stop when the order group is rejected, limits.json failing closed if a value is missing or not positive, and paginated resting_orders. These runs prove the plumbing, not a strategy. Demo prices barely moved, the fair prices are placeholders, and Kalshi notes that demo prices and behavior may differ from real markets. If you turn on the research step, treat what the LLM writes as advisory: LLM probability estimates are often confident and badly calibrated. And Kalshi's Developer Agreement allows API use for your own trading, not for running a bot for others.

The full recipe, with the complete prompt, step-by-step setup, the safety checklist and links to every Kalshi doc we checked, is at botcookery.com/recipes/kalshi-ai-trading-bot. The code from the verified run is on GitHub at lazyclaw137-ship-it/kalshi-ai-trading-bot (MIT, no keys), and the three-layer kill switch is written up on its own in our kill switch and position limits recipe.

Polymarket US API in Python: Cloudflare rate-limited us long before 25 req/s

BotCookery — Fri, 30 Oct 2026 14:09:30 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every output below is from real runs against the public Polymarket US gateway, on Oct 25, 2026 (the rebuild) and Oct 30, 2026 (a re-run of the rebuilt code). No API key was used, the code can't place an order, and nothing here is financial advice.

The old version of our Polymarket US prompt told the AI to "stay well under 25 requests/second" and to back off 1 s, 2 s, then 4 s on HTTP 429. That sounds careful. On the live gateway it fell apart in the first loop: 28 of 138 CLI calls crashed with HTTPError: 429 Client Error: Too Many Requests.

This morning we measured the limit directly, at a polite one request per second on a single order book:

13:59:28 call  1 status 200 ct=application/json retry-after=None body='{"marketData":{"marketSlug":"paccc-usho-'
...
13:59:32 call  6 status 200 ct=application/json retry-after=None body='{"marketData":{"marketSlug":"paccc-usho-'
13:59:33 call  7 status 429 ct=text/html; charset=UTF-8 retry-after=10 body='<!doctype html>\n<!--[if lt IE 7]> <html '
13:59:34 call  8 status 429 ct=text/html; charset=UTF-8 retry-after=9 body='<!doctype html>\n<!--[if lt IE 7]> <html '
...
13:59:43 call 17 status 429 ct=text/html; charset=UTF-8 retry-after=0 body='<!doctype html>\n<!--[if lt IE 7]> <html '
13:59:44 call 18 status 200 ct=application/json retry-after=None body='{"marketData":{"marketSlug":"paccc-usho-'
...
13:59:48 call 22 status 200 ct=application/json retry-after=None body='{"marketData":{"marketSlug":"paccc-usho-'
13:59:50 call 23 status 429 ct=text/html; charset=UTF-8 retry-after=10 body='<!doctype html>\n<!--[if lt IE 7]> <html '

Six calls went through, then eleven 429s while Retry-After counted down from 10 to 0, then five more 200s, then another 10-second block. The pattern repeated a third time. Of 40 calls in about 40 seconds, 16 succeeded.

This post is about that, and the three other things a live run turned up that the docs and unit tests didn't.

What the starter is

The Polymarket API starter kit is a prompt, not a repo. You paste it into an AI coding tool in an empty folder, and it builds a small read-only Python toolkit for Polymarket US, the CFTC-regulated exchange at gateway.polymarket.us. It's a different API from the international CLOB.

The CLI has markets, search, bbo, book, watch, and a signed balance read for when you have a key. Public market data needs no key. Account reads are signed with Ed25519. There is no order code at all.

On Oct 25 we pasted the old prompt into a clean folder, let it build, and pointed a harness at it. Then we fixed the prompt, rebuilt from the new version, and ran that too. Today we re-ran the rebuilt code, unchanged, to check it still holds.

The gateway in one paragraph

Public reads are plain GETs on https://gateway.polymarket.us:

/v1/markets?active=true&closed=false&limit=N lists markets.
/v1/markets/{slug}/bbo gives the top of book under marketData: bestBid, bestAsk, currentPx, lastTradePx, state, plus depth and open-interest fields.
/v1/markets/{slug}/book gives the full book. Bids are marketData.bids, asks are marketData.offers (there is no asks key), and each level is {px: {value}, qty}.
/v1/search?query=... returns {"events": [...]}, each event holding its markets.

Every market is a YES contract on one side, priced 0.00 to 1.00. To be short you sell YES, so the NO price you can get is 1 minus the best bid.

1. "Stay under 25 req/s" isn't the limit you get

The old build did what the old prompt asked. It throttled itself to 10 requests a second (_MIN_INTERVAL = 1 / 10 # stay well under 25 req/s) and retried a 429 after 1, 2 and 4 seconds before calling raise_for_status().

Our harness took the top markets plus the first two events from four searches a beginner might try ("temperature", "bitcoin", "election", "nfl"): 69 markets. For each one it ran the CLI's bbo and book, then checked the market's state. Loop 1 finished at 17:36:50 UTC:

slugs 69
[17:36:50 UTC] loop 1: {'bbo_ok': 60, 'book_ok': 50, 'book_crash': 19, 'check_err': 23, 'bbo_ask_ne_book': 2, 'bbo_crash': 9, 'no_bids': 27, 'no_offers': 20, 'spread>=0.10': 4} states={'MARKET_STATE_OPEN': 26, 'MARKET_STATE_EXPIRED': 20}
    book tec-mlb-champ-2026-09-27-tb: HTTPError: 429 Client Error: Too Many Requests for url: https://gateway.polymarket.us/v1/markets/tec-mlb-champ-2026-09-27-tb/book
    bbo tec-mls-winner-2026-11-07-sea: HTTPError: 429 Client Error: Too Many Requests for url: https://gateway.polymarket.us/v1/markets/tec-mls-winner-2026-11-07-sea/bbo
...
exit 124

That's 9 bbo and 19 book crashes, and 23 state checks that errored too. The harness hit its time limit (exit 124) before loop 2 finished.

The probe at the top explains why. The gateway sits behind Cloudflare, and the 429 isn't a JSON API error. It's an HTML page with a Retry-After header that starts at 10 and counts down. The old backoff waited 1 + 2 + 4 = 7 seconds in total, then gave up while the block still had seconds to run. And any code that calls .json() on that response gets a JSONDecodeError from an HTML page, which is a confusing way to learn you were rate limited.

Our box is a cloud server, and Cloudflare may treat home connections more gently. Still, a script polling the public gateway should plan for roughly five calls, then a 10-second wait.

What the prompt says now:

One shared throttle for every call, one request every 2 seconds by default (PM_MIN_INTERVAL overrides it).
On 429, sleep Retry-After + 1 (10 if the header is missing) and retry up to 4 times, then raise one PMError saying it was rate limited. Retry 5xx and timeouts the same way.
Never call .json() on a non-200. Put the status and the first 120 characters of the body in the error.

Even at one call every 2 seconds, Cloudflare still pushed back once in each watch. On Oct 25:

[17:43:19 UTC] loop 1: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)
[17:44:58 UTC] loop 2: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)
[17:46:47 UTC] loop 3: 20 two-sided, 0 one-sided, 0 errors, 1 rate-limit waits (11 s)
...
[17:51:41 UTC] loop 6: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)

And today, with the same code, about 30 seconds after the probe finished:

[14:01:29 UTC] loop 1: 20 two-sided, 0 one-sided, 0 errors, 1 rate-limit waits (11 s)
[14:03:07 UTC] loop 2: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)
[14:04:45 UTC] loop 3: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)
[14:06:23 UTC] loop 4: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)
[14:08:01 UTC] loop 5: 20 two-sided, 0 one-sided, 0 errors, 0 rate-limit waits (0 s)

100 quotes, one wait of 11 seconds, then it carried on. No crashes, no tracebacks. The summary line counts the waits on purpose, so you can see how close you're running to the limit.

2. A market list you can read

The old markets command printed the slug and the market's question. On Polymarket US the question is often the event, shared by every side of it, so rows looked alike. The rebuilt version asks the gateway to sort (orderBy=volume&orderDirection=desc; the docs don't list sort values, but this pair works), drops anything whose status isn't open, and prints each market's title, which is the side you're actually pricing. Today's top of the list, from watch:

  two-sided bid 0.929 (92.9%)  ask 0.930 (93.0%)  Democratic Party         paccc-usho-midterms-2026-11-03-dem
  two-sided bid 0.300 (30.0%)  ask 0.310 (31.0%)  Ken Paxton (R)           ewc-usse-tx-2026-11-03-rep
  two-sided bid 0.696 (69.6%)  ask 0.697 (69.7%)  Democratic Party         paccc-usse-midterms-2026-11-03-dem
  two-sided bid 0.314 (31.4%)  ask 0.315 (31.5%)  Republican Party         paccc-usse-midterms-2026-11-03-rep
  two-sided bid 0.690 (69.0%)  ask 0.700 (70.0%)  James Talarico (D)       ewc-usse-tx-2026-11-03-dem

Even the title isn't always enough. "Democratic Party" appears twice in the top three: one is the House (usho), the other the Senate (usse). Always print the slug next to the title. Game moneylines have no title at all, so the toolkit prints their outcomes instead (today: "Giants / Commanders"). One more small thing from today: one title came back with a tab inside it (Peggy Flanagan<TAB>(D)), which knocked that row's column alignment out. Titles are data, not display strings.

Four days before the US midterms, all 20 of today's top markets by volume were Nov 3 election markets. On Oct 25 the top 20 also included World Series markets. Over today's five loops, the only quote that moved was the Senate "Republican Party" market, from 0.314/0.315 to 0.311/0.312. A quiet watch is normal.

3. Search returns finished events

Part of the old harness's market list came from search. Of the 46 markets whose state it could check, 20 were MARKET_STATE_EXPIRED, and 27 had no bids at all. If your script searches and then reads a book, expect to land on dead markets.

The rebuilt search hides markets that aren't open and says how many it hid. On Oct 25, search nfl ended with:

(29 resolved markets hidden; --all to show)

Today showed a different trap. Search matches slugs, and in college basketball nfl is North Florida. The first five events for search nfl were North Florida games:

North Florida (W) vs. Little Rock (W)
   - aec-wcbb-nfl-arlr-2026-11-12                 Ospreys / Trojans
North Florida (W) vs. Florida State (W)
   - aec-wcbb-nfl-flst-2026-11-05                 Ospreys / Seminoles
...
WAS Commanders vs. NY Giants
   - aec-nfl-was-nyg-2026-11-12                   Giants / Commanders
Week 8 Top D/ST Fantasy Football
   - ftsc-wk8-2026-11-02-topdst-kc                KC Chiefs

The football game came sixth. Read the event title before you trust a search hit.

4. The rest: fees, NO prices, and errors

bbo shows the NO price and the taker fee, using the market's own feeCoefficient and the fee page's formula, coefficient x contracts x p x (1 - p). Today on the top market:

paccc-usho-midterms-2026-11-03-dem  state=MARKET_STATE_OPEN
  bid:  0.929 (92.9%)
  ask:  0.930 (93.0%)
  NO:   0.071 (7.1%)  (= 1 - best bid; to buy NO you sell YES)
  last trade: 0.929 (92.9%)
  taker fee, 100 @ ask: $0.45 (coef 0.0695)

Check it: 0.0695 x 100 x 0.93 x 0.07 = 0.452. On Oct 25 the same market was 0.900/0.901 and the fee for 100 at the ask was $0.62. The fee peaks at 50% and shrinks toward the edges, so the same 100 contracts cost less in fees as the price nears 1.

book sorts both sides itself before taking the best. Today, at depth 5:

  BIDS
    0.929 (92.9%)  x 758529
    0.928 (92.8%)  x 4621
    ...
  OFFERS
    0.930 (93.0%)  x 12105
    0.931 (93.1%)  x 200

And a bad slug is one line and exit code 1, not a traceback:

ERROR: HTTP 404 from /v1/markets/no-such-market-xyz/book: '{"code":5,"message":"The server was unable to process your request.","details":[]}'

With no key set, balance prints no key set (POLYMARKET_KEY_ID / POLYMARKET_SECRET_KEY) and exits cleanly. The rebuilt version has 9 mocked tests, including an HTML 429 with Retry-After, giving up after retries, one-sided books, and search hiding resolved markets. Today: 9 passed in 0.10s.

Already built it? Paste this follow-up prompt

Update my Polymarket US starter:
1. _get: one shared throttle, one call every 2 s (env PM_MIN_INTERVAL).
   On 429 (an HTML page from Cloudflare, not JSON) sleep Retry-After + 1
   (10 if missing), retry up to 4 times, then raise PMError. Retry 5xx and
   timeouts too. Never call .json() on a non-200.
2. list_markets: add orderBy=volume&orderDirection=desc and drop markets
   whose status isn't MARKET_STATUS_OPEN.
3. Print each market's title (the side) next to the slug; for moneylines
   with no title, print the outcomes. markets shows bid/ask from
   bestBidQuote/bestAskQuote.
4. search: limit=20, hide markets that aren't MARKET_STATUS_OPEN unless
   --all, and print how many were hidden.
5. Sort bids and offers yourself before taking the best; either side
   can be empty.
6. bbo: show NO = 1 - best bid and the taker fee for 100 contracts at the
   ask: feeCoefficient x 100 x p x (1 - p).
7. Add `watch [--n 10] [--loops 1] [--interval 60]` with one line per
   market and a "[HH:MM:SS UTC] loop N: ... errors, W rate-limit waits"
   summary, flush=True; one market's error never stops the loop.
8. The CLI catches PMError, prints one line and exits 1.
Add mocked tests for each change and run them. Still no order placement.

Starting fresh? The full prompt is on the recipe page. After it builds:

python3 -m venv .venv && source .venv/bin/activate
pip install requests python-dotenv cryptography pytest
python3 -m pytest -q
python3 cli.py markets --n 20
python3 cli.py bbo <slug-from-the-list>
python3 cli.py book <slug> --depth 5
python3 cli.py watch --n 20 --loops 5 --interval 60 | tee watch.log

What this is and isn't

The page's verified line, word for word: Verified working on live data in read-only mode, Oct 25, 2026. Public market data only: a 10-minute, 6-loop watch of the top 20 markets plus markets, search, bbo and book. No API key was created, so balance and positions were never called; the request signing was checked offline against the official SDK.

The toolkit reads public prices and, if you give it a key, your own balance. It has no order code. It prints prices, depth and fees. It doesn't rank markets or suggest trades. If you take it further, keep keys in .env, out of git, and check what the gateway's rate limit is doing from the machine you'll actually run on.

The full recipe, with the complete prompt, setup steps, FAQ and links to every Polymarket US doc we checked, is at botcookery.com/recipes/polymarket-api-starter-kit. To try strategies without real money, see our Polymarket paper-mode bot built with Claude Code. For the international order book, see the Polymarket CLOB API starter.

We rebuilt our Hyperliquid funding-rate monitor from its own prompt: the biggest rates were on perps nobody trades

BotCookery — Thu, 29 Oct 2026 13:57:48 +0000

Originally published on BotCookery, free build recipes for AI-built trading and prediction-market bots. Written with AI assistance. Every output below is from real runs against Hyperliquid's public API, on Oct 25, 2026 (the rebuild) and Oct 29, 2026 (a re-run of the rebuilt code). The monitor holds no key and can't place an order, and nothing here is financial advice.

Our Hyperliquid funding-rate monitor is a prompt. Paste it into your AI coding tool in an empty folder and you get a small Python CLI: a snapshot of current and predicted funding for every perp, annualized and labelled, funding history for one coin, and a watch loop that alerts to the console or a webhook when a rate crosses a threshold you set. It only calls the public POST /info endpoint. No key, no wallet, no /exchange.

On Oct 25 we pasted the published prompt into a clean folder, let it build, and ran every step on live data, including a watch loop with the webhook pointed at a local receiver. The API facts in the prompt held up. The program built from it didn't, in four ways that only show up on live data.

The API in one paragraph

Everything is POST https://api.hyperliquid.xyz/info (testnet: api.hyperliquid-testnet.xyz). {"type":"metaAndAssetCtxs"} returns [meta, assetCtxs]: zip meta.universe[i] with assetCtxs[i] and read funding, the current hourly rate. {"type":"predictedFundings"} returns Hyperliquid's predicted rate next to Binance's and Bybit's, each with its own fundingIntervalHours. {"type":"fundingHistory","coin":"ETH","startTime":...} returns hourly prints, at most 500 rows per call. Hyperliquid pays funding every hour, at one-eighth of an 8-hour formula rate, and a quiet market sits at 0.00125% per hour. That's 11.0% a year if you multiply by 8,760, which is a comparison convention, not a forecast.

1. The top of the list was perps nobody trades

The first build sorted every perp by absolute APR and alerted on anything over the threshold. Here's the first loop of its watch at 45%, Oct 25, 09:30 UTC (trimmed):

POLYX: funding -0.18856%/h, APR -1651.79% (simple), predicted APR -1653.79%, shorts pay longs; threshold 45%. Informational only.
SOPH: funding -0.02811%/h, APR -246.24% (simple), predicted APR -248.55%, shorts pay longs; threshold 45%. Informational only.
ALT: funding -0.02078%/h, APR -182.04% (simple), predicted APR -181.72%, shorts pay longs; threshold 45%. Informational only.
...
[09:30:08 UTC] loop 1: 10 new alerts

The loudest number in the whole market was a perp with a tiny book. Thin perps drift further from the oracle, so their premium, and their funding, swings harder. When we re-ran the rebuilt code on Oct 29, POLYX had $113k of 24-hour volume and $99k of open interest, against $2.3B of volume on BTC. On that run, 111 of the 179 live perps had under $1M of 24-hour volume.

The fix was to stop showing a rate without its context. Every row and every alert now carries 24-hour volume and open interest in dollars, the snapshot hides perps under $1M of volume by default, and it says how many it hid. From the Oct 29 re-run:

MAINNET funding at 2026-10-29 13:54 UTC. APR = hourly x24x365, simple, not a forecast.
coin      id     hourly       APR      pred          Binance            Bybit  24h vol       OI
BLUR      62  -0.12221%  -1070.6%  -1070.0%         -1375.2%         -1431.9%    $4.2M    $1.0M  over
PURR     152  +0.02696%   +236.2%   +238.4%                —                —    $3.0M   $13.8M  over
NIL      186  -0.00543%    -47.6%    -47.3%           -66.0%           +11.0%    $1.3M    $2.7M
HYPE     159  +0.00437%    +38.3%    +38.6%                —                —    $1.1B    $2.1B
...
BTC        0  +0.00125%    +11.0%    +11.0%           +11.0%            +5.8%    $2.3B    $3.5B
ETH        1  +0.00125%    +11.0%    +11.0%           +10.4%            +7.2%  $985.2M    $2.6B
111 perps under $1.0M 24h volume hidden (--min-volume 0 shows all)

A volume filter isn't a verdict, and that's visible here. BLUR cleared the $1M bar and still showed about -1,071% APR, with Binance and Bybit predicting even more negative rates. The filter just stops the very thinnest books from taking over the list. --min-volume 0 shows everything, and that's where GMT, POLYX and GAS sat, between -65% and -75% APR on under $120k of volume each.

2. The API had a bad few minutes, and the old prompt only retried 429s

During the first watch, /info returned 502s and then 15-second read timeouts:

[09:32:42 UTC] loop 6: 0 new alerts
error: 502 Server Error: Bad Gateway for url: https://api.hyperliquid.xyz/info
error: 502 Server Error: Bad Gateway for url: https://api.hyperliquid.xyz/info
error: HTTPSConnectionPool(host='api.hyperliquid.xyz', port=443): Read timed out. (read timeout=15)
error: HTTPSConnectionPool(host='api.hyperliquid.xyz', port=443): Read timed out. (read timeout=15)
[09:35:45 UTC] loop 11: 0 new alerts

The first build's post_info retried only on HTTP 429. That build happened to wrap the loop in try/except, so it limped on, but four loops in a row were simply lost, and the prompt never asked for either behaviour. The next AI build could just as easily have crashed on the first 502.

The prompt now says it outright: retry 429, any 5xx, timeouts and connection errors with backoff (1, 2, 4 seconds, at most 3 retries), then raise one error type. watch catches it, prints [HH:MM:SS UTC] loop N: API error (<reason>), retrying next loop, and carries on. There's a test for each part.

One smaller fix from the same review: the first build's print calls didn't flush. When stdout is a file instead of a terminal, Python block-buffers it, so nohup python3 monitor.py watch > funding.log & can sit there looking empty. Every print in the rebuilt version uses flush=True.

3. Funding moves during the hour, so naive alerts flap

Hyperliquid's funding field isn't a number that changes once an hour. It updates continuously. WLD was at -50.1% APR at 09:30 UTC and -54.2% at 09:44. A threshold alert that re-arms as soon as a coin dips below the line will fire again and again for a coin hovering near it.

The rebuilt alerter fires once when a coin crosses, stays quiet while it stays over, and re-arms only after the absolute APR drops below 90% of the threshold. Here's the rebuilt version, 20 one-minute loops at 50%, webhook pointed at a local receiver, Oct 25:

watching mainnet | apr >= 50% either sign | 24h vol >= $1.0M | every 60s. Informational only.
WLD: funding -0.00618%/h = -54.2% APR (simple), predicted -54.3%; shorts pay longs; 24h vol $38.5M, OI $66.2M; threshold 50%. Informational only.
ANIME: funding -0.04260%/h = -373.1% APR (simple), predicted -373.0%; shorts pay longs; 24h vol $2.7M, OI $585.5k; threshold 50%. Informational only.
ZORA: funding -0.00936%/h = -82.0% APR (simple), predicted -82.5%; shorts pay longs; 24h vol $1.8M, OI $763.5k; threshold 50%. Informational only.
XMR: funding +0.00749%/h = +65.6% APR (simple), predicted +65.7%; longs pay shorts; 24h vol $37.2M, OI $101.2M; threshold 50%. Informational only.
[09:44:23 UTC] loop 1: 4 perps over, 4 new alerts
[09:45:23 UTC] loop 2: 4 perps over, 0 new alerts
...
[09:59:36 UTC] loop 16: 4 perps over, 0 new alerts
[10:00:37 UTC] loop 17: 2 perps over, 0 new alerts
...
stopped after 20 loops: 4 alerts, 0 errors

Four alerts, each delivered once to the receiver, no repeats. Look at loop 17: the funding hour turned over at 10:00 UTC and half the list dropped back under the line. A rate that looks extreme at :50 can be gone at :05. That's why each alert reports a level, says which side pays, and ends with "Informational only". It doesn't suggest anything.

The Oct 29 re-run behaved the same way: BLUR and PURR alerted once on loop 1, loops 2 and 3 said 2 perps over, 0 new alerts, and the run ended with 2 alerts, 0 errors.

4. `fundingHistory` answers a typo with HTTP 500 and `null`

The original prompt said an unknown coin would return an empty list. It doesn't. Asked for lowercase eth, the endpoint returns this (re-checked Oct 29):

$ curl -s -X POST https://api.hyperliquid.xyz/info -H 'content-type: application/json' \
    -d '{"type":"fundingHistory","coin":"eth","startTime":1761700000000}' -w ' HTTP %{http_code}\n'
null HTTP 500

Coin names are case-sensitive, and a few are mixed case (kPEPE, kBONK), so "just uppercase it" doesn't work either. The rebuilt history command first looks the name up in {"type":"meta"}, case-insensitively, and sends the exact spelling. history eth works, and history nope prints unknown coin nope on mainnet without calling fundingHistory at all.

History is where the long view lives. 600 hours of ETH is more than one 500-row page, so this also exercises the pagination (Oct 29):

600 hours: mean +0.00080%/h (+7.0% APR simple), min -0.00248%, max +0.00125%, 301 hours at the 0.00125% baseline

Bonus: testnet funding is wild, but two columns are real

Testnet books are thin, so Hyperliquid's own testnet funding is not realistic. On Oct 29, testnet SOL showed +4,087% APR and BTC -603%. But the Binance and Bybit columns in testnet's predictedFundings are the real exchanges' rates, identical to mainnet's (BTC: +11.0% and +5.8% on both). Asset IDs differ too: SOL was id 0 on testnet and 5 on mainnet. Join by coin name, never by index. The snapshot footer now says all of this.

The follow-up prompt

If you built the monitor from an earlier version of the recipe, paste this into the same project:

Update my Hyperliquid funding monitor:
1. post_info: 15 s timeout; retry with backoff (1, 2, 4 s, at most 3
   retries) on HTTP 429, any 5xx, timeouts and connection errors, then
   raise HLError. watch must catch HLError, print
   "[HH:MM:SS UTC] loop N: API error (<reason>), retrying next loop" and
   carry on. Every print uses flush=True so a redirected log updates live.
2. Add day_volume_usd (dayNtlVlm) and oi_usd (openInterest * oraclePx) to
   each row. snapshot shows both, takes --min-volume (default 1000000;
   ignored with --coins) and prints "N perps under $X 24h volume hidden".
   watch applies the same filter.
3. Alerts re-arm only after |APR| drops below 0.9 x threshold, and the
   message includes 24h volume and OI.
4. fundingHistory returns HTTP 500 with body null for an unknown or
   wrong-case coin. Add resolve_coin(name, testnet) that matches the name
   case-insensitively against {"type":"meta"} universe names (kPEPE is
   mixed case) and use it in history; unknown names print
   "unknown coin <name> on <net>" and exit 1.
Add tests for the retry, the volume filter, the re-arm band and
resolve_coin. Run them and show me the diff. Still read-only: no keys,
no /exchange, no trade suggestions.

Starting fresh? The full prompt is on the recipe page. After it builds:

python3 -m venv .venv && source .venv/bin/activate
pip install requests pytest
python3 -m pytest -q
python3 monitor.py snapshot --top 15 --threshold 50
python3 monitor.py snapshot --top 15 --min-volume 0
python3 monitor.py history ETH --hours 600 --last 12
python3 monitor.py watch --threshold 50 --interval 60 --max-loops 3

The rebuilt version has 14 tests, all offline with a fake HTTP session. They passed again on the Oct 29 re-run.

What this is and isn't

The page's verified line, word for word: Verified working on live data in read-only mode, Oct 25, 2026. Its stated limit: Public mainnet and testnet data, including a 20-minute watch across a funding hour. Webhook alerts went to a local receiver, not a real Slack or Discord channel.

The monitor has no key, no wallet and no signing library, and a test fails if any app module mentions /exchange, private_key, eth_account or Exchange(. It reports who pays whom and how much, annualized by convention. It doesn't rank opportunities or tell you to do anything, and a high funding rate on its own isn't a trading signal.

The full recipe, with the complete prompt, step-by-step setup, the FAQ and links to every Hyperliquid doc we checked, is at botcookery.com/recipes/hyperliquid-funding-rate-monitor. For the API basics (endpoints, asset IDs, rate limits) see our Hyperliquid API starter, and for large trades and public positions, the read-only whale tracker.

DEV Community: BotCookery

Our Polymarket Telegram alert said "YES bid 0.64". It never said what the price was for.

The one real alert we got

Problem 1: "YES" on a question every bucket shares

Problem 2: the alert was moved by quotes, not a trade

Problem 3: a 0.505 "price" from an empty book

Problem 4: a typo that failed quietly, forever

Problem 5: a settled market that said "no price" forever

Smaller things

After: the rebuild from the new prompt

Built this before Oct 25?

Why alert-only

Limits

Our read-only Polymarket MCP server returned 480 rows for limit=20 and called a 0.07/0.99 book 99%

What the prompt builds

Bug 1: limit counted events, not markets

Bug 2: the price came from the wrong field

Bug 3: "implied %" from a book with nothing in the middle

Bug 4: "YES" wasn't always yes

Bug 5: the register command couldn't import the SDK

Bug 6: 429s far below the documented limit

What we changed

After: a fresh rebuild

Register it (full paths)

Built this before Oct 25?

Why read-only

Limits

Our ChatGPT/Codex Kalshi starter would have bought the same contract 38 times in under 13 minutes

What the prompt builds

Bug 1: "1 contract per order" isn't a position limit

Bug 2: "$5 exposure" and "$2 daily loss" weren't defined

Bug 3: "keep the key outside your project" doesn't hide it from Codex

Bugs 4 to 6: docs, ticker search, the small stuff

What we changed

The Codex step

After: a fresh rebuild

Built this before Oct 25?

Chat or Codex?

Limits

Our weather bot paper-bought "below 81 " at 1¢ after the day's high had already hit 80.96

The worst bug: trading a day that was mostly decided

Five more things that broke

What didn't change, on purpose

After the fix

Two things we confirmed live

If you want to try it

Limits

Our Claude Kalshi bot counted a closed market's paper order forever

What we built

What held from Oct 25

What broke on live demo data

What we changed in the prompt

Drill results after the fix

How to use it

Limits

Our Grok Kalshi paper bot ignored Retry-After and treated a login page as JSON

What the recipe is

What happened when we rebuilt it from this prompt

Why Retry-After matters more than the happy path

HTML 200 and the hung host

Thin demo books are a beginner gotcha

market_inactive (was market_closed)

Paper run numbers, verbatim from the rebuild

Built this before Nov 5?

What this is and isn't

Our Polymarket-Kalshi arbitrage monitor found one 2¢ gap. After real fees it lost 1.4¢

Problem 1: the recommended Kalshi host answered 403

Problem 2: placeholder fees made a losing trade look break-even

Problem 3: "depth" meant the top level only

Problem 4: the Miami gap wasn't an arbitrage anyway

Problem 5: it couldn't tell you how long a gap lasted

Problem 6: piped output stayed empty

One near-miss: which end of Kalshi's book is the best bid

After the fixes

Built this before Oct 25? The follow-up prompt

Takeaways if you're building one

What we verified, and what we didn't

Our bot's $10 exposure limit held $18.60 after one restart: kill switch fixes

Bug 1: a restart reset the exposure limit

Bug 2: the daily-loss stop was dead code

Bug 1: `limit` counted events, not markets

4. `fundingHistory` answers a typo with HTTP 500 and `null`