codingBy HowDoIUseAI Team

How to build an AI agent that trades Kalshi and Polymarket with Claude Opus

Claude Opus 4.5 can research, forecast, and place trades on prediction markets. Here's how the researcher-verifier setup actually works.

A 30-year Treasury yield contract that opens at 6 cents can end a few days later sitting at 85. That's not a rounding error — that's a prediction market completely repricing an outcome that most retail traders never saw coming. And it's exactly the kind of move that's pushing builders to ask a new question: what happens when you point a frontier reasoning model like Claude Opus directly at Kalshi and Polymarket order books?

The short answer is that it gets messy fast, and the interesting part isn't the wins — it's the failure modes that show up when an autonomous agent starts trading real probability markets.

What makes prediction markets different from a normal AI use case?

Prediction markets are brutally honest. A chatbot can hedge, ramble, or sound confident while being wrong, and nobody notices for weeks. A market position gets marked to reality on a resolution date. There's no partial credit.

That's what makes Kalshi and Polymarket such a strange proving ground for an LLM agent. Kalshi is a CFTC-regulated exchange where you trade event contracts on things like interest rates, weather, and elections — and its own API documentation describes how to make your first call and test safely in a demo environment before risking real capital. Polymarket runs a similar model on Polygon, except it's structured as a decentralized order book. As one detailed developer guide explains, users trade binary outcome tokens in USDC priced $0–$1 based on collective market belief, through a hybrid off-chain order book with on-chain settlement via the Conditional Token Framework.

Neither platform cares how smart your model is. They only care whether your probability estimate was closer to reality than the crowd's.

Why does an autonomous research loop break down on its own?

Here's the trap that catches almost every naive trading agent: if you let a model keep everything that looks like a win and discard everything that looks like a loss, it will eventually convince itself that noise is signal. Small random gains get reinforced as if they were skill. The agent starts trusting patterns that are actually just statistical flukes, and confidence creeps up long after edge has disappeared.

The fix that's gaining traction among people experimenting with Opus-class models is architectural, not prompt-based: split the system into two roles. One component — call it the researcher — proposes trade ideas, digs through market data, and builds a thesis. A second, separate component acts purely as a verifier. It doesn't get to fall in love with an idea. Its only job is to stress-test the researcher's reasoning against fresh data and kill anything that doesn't hold up under scrutiny.

This researcher/verifier split matters because a single-agent loop has no built-in skepticism. It just keeps generating ideas and rating its own homework. Separating "propose" from "sealed evaluation" forces a checkpoint where hype has to survive contact with evidence.

How do you actually connect Claude to a prediction market?

If you want to build something like this yourself, the foundation is Anthropic's Agent SDK, which is the same engine that powers Claude Code, exposed as a library. According to Anthropic's own docs, it lets you build AI agents that autonomously read files, run commands, search the web, edit code, and more, giving you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript. That's the layer that turns a chat model into something that can pull live order book data, write its own analysis scripts, and log a trade thesis to a file it revisits later.

For the actual market connection, you're choosing between two very different API philosophies:

  1. Kalshi's API uses RSA key-pair authentication rather than simple bearer tokens. As one current developer guide notes, Kalshi uses RSA key pairs rather than simple bearer tokens, so you generate an API key in your account settings, store the private key securely since it's shown once and can't be retrieved again, and sign each request with your key ID, a timestamp, and an RSA signature. Kalshi also ships an official Python SDK and a full demo environment with fake money, which is the sane place to test an agent before it touches your real balance.

  2. Polymarket's CLOB API splits into separate services: a public Gamma API for browsing markets, and an authenticated CLOB API for actual order placement. One developer breakdown puts it plainly — Polymarket splits its API into two completely separate services, Gamma for discovery and metadata and CLOB for trading, and understanding which one to use for what is the first thing that trips up most developers. Polymarket also publishes official clients, and per its own docs, Polymarket provides official open-source clients in TypeScript, Python, and Rust, so you're not stuck hand-rolling the EIP-712 signing logic from scratch.

What does a working researcher agent actually scan for?

Scanning every open market by hand isn't practical — Kalshi and Polymarket together host thousands of active contracts at any given time. The workable approach is building a lightweight semantic search layer over market titles and descriptions, so the agent can ask something like "any markets related to Fed rate decisions this quarter" and get back a ranked shortlist instead of scrolling a raw list.

Once it has a shortlist, the agent typically pulls:

  • Current pricing and recent volume, which signals whether a market actually has liquidity worth trading
  • Order book depth, since a market can look mispriced on the surface but be untradeable once you account for slippage
  • News and context pulled from web search, feeding the researcher's thesis before it ever reaches the verifier stage

This is also where a semantic scanner earns its keep on the crypto side. Streaming live price data from an exchange like Binance and logging every model suggestion against what actually happened next creates a feedback dataset the agent can learn from over time, rather than trading blind on each new session with no memory of past calls.

How risky is letting an AI place real trades?

Very. It's worth being blunt about this: prediction markets are still gambling with structure. Even a well-designed researcher/verifier system can lose money on individual trades, and a string of early wins can be pure variance rather than genuine edge. If you're experimenting with this, treat any live capital you commit as money you're fully prepared to lose, and lean hard on Kalshi's demo environment or small position sizes while you validate that the verifier stage is actually catching bad theses instead of rubber-stamping them.

It's also worth checking your local regulations. Kalshi is CFTC-regulated in the US, while Polymarket's main site restricts US-based trading — a detail that shows up directly on its own market pages, which note that trading is blocked in the United States on polymarket.com, and traders should switch to polymarket.us to trade prediction markets.

What should you try first if you want to build one of these?

Start smaller than you think. A reasonable build order looks like this:

  1. Get Kalshi's demo environment running first. Follow the Quick Start in Kalshi's docs and confirm you can pull market data and place a fake order before writing any agent logic.
  2. Wire up the Agent SDK with a single tool. Anthropic's own quickstart walks through building a first agent — start with something as simple as fetching and summarizing one market before adding trading logic.
  3. Add the verifier as a second, isolated call. Don't let the same context window that generated the thesis also grade it. Force a clean handoff.
  4. Log everything. Every proposed trade, every verifier rejection, every executed position, and the eventual resolution. Without this dataset you can't tell edge from luck.
  5. Only then connect Polymarket, since its CLOB API involves wallet signatures and on-chain settlement that add real complexity on top of the trading logic itself.

The models keep getting better at reasoning through ambiguous, high-stakes decisions — that's not really in question anymore. What's still an open problem is whether anyone can build the guardrails fast enough to keep an agent from confidently betting on its own noise. That gap, more than the model's raw intelligence, is where the next interesting experiments are going to happen.