A bot that watches two platforms and places two orders is limited by how fast it can talk to each. On Kalshi that limit is a token budget set by your account tier. This article summarises what Kalshi's rate-limit documentation says and what it means for an arbitrage workflow. Limits change, so use the live GET /account/limits and GET /account/endpoint_costs endpoints as the source of truth. For the wider API picture see the Kalshi API guide.
Tokens, budgets and two buckets
Every authenticated request costs tokens; most cost the default of 10. Your tier sets a budget, the rate in tokens per second at which your balance refills, and the sustained rate for an endpoint is budget ÷ cost. There are two independent buckets:
- Read: GET endpoints and anything not routed to Write.
- Write: order placement, amends, cancels, order groups, the RFQ quote flow and block trade proposal accepts.
The split is by operation type, and REST and FIX requests drain the same buckets. The account balance endpoint has its own bucket: Basic and Advanced tiers can call it once per second and higher tiers five times per second. Kalshi's advice is to react to fills and settlements rather than poll the balance.
Per-second budgets by tier
The documentation lists these per-second budgets for event contracts (Read / Write): Basic 200 / 100, Advanced 300 / 300, Expert 600 / 600, Premier 1,200 / 1,200, Paragon 2,400 / 2,400, Prime 4,800 / 4,800 and Prestige 12,000 / 9,600. At the default cost of 10 tokens, a Write budget of 100 sustains about 10 order requests per second, and 300 sustains about 30.
Bursting
Each budget is a token bucket that refills continuously. For Basic and Advanced Read buckets, and for Write buckets above Basic, the bucket holds up to three seconds of budget, so after a quiet spell you can spend up to three times your per-second budget at once. Basic-tier Write buckets hold one second. This favours a bot that idles until the market moves, which is the shape of an arbitrage workflow, but it also means a Basic-tier account cannot save up capacity for a burst of orders.
Batches do not save tokens
A batch request costs the same as making each call individually: 25 orders cost 25 × 10 = 250 tokens, and cancelling 25 orders costs 25 × 2 = 50. The whole batch must fit in the bucket when it arrives, or the entire batch is rejected. For a two-leg trade, this matters less for Kalshi alone than for sizing how many pairs you can act on at once.
WebSocket connection caps and 429
Predictions and Perps WebSocket connections share a per-user limit: 200 concurrent connections on Basic, Advanced and Expert, 500 on Premier, 750 on Paragon and 1,000 on Prime and Prestige. A request over the token limit returns 429 Too Many Requests, and so does a new WebSocket handshake once you are at the connection limit.
What it means for arbitrage
- Reading: polling many order books spends Read tokens quickly. The order book endpoint is documented as not needing authentication, which is a separate question from how your overall usage is limited. See how to read the Kalshi order book.
- Writing: the Write budget caps how many legs you can place per second, which only matters if you run many pairs in parallel.
- The other leg has limits too. Polymarket's matching and delays are described in order types for two-leg arbitrage.
- Backing off: on a 429, wait and retry rather than resending at once, and prefer streaming over polling when you can.
Where Arbitrage Agent fits
Arbitrage Agent does the reading and matching for you: it shows validated Polymarket and Kalshi pairs with net edge in a live feed and a step-by-step guide, and you place the orders yourself, so you do not need to build an API client to start. See the plans or start with the Starter plan.
Related articles
- The Kalshi API Explained
- Kalshi Arbitrage Bot: How It Works and What to Expect (2026)
- Why Execution Speed Decides Prediction Market Arbitrage Profit
- The Polymarket API Explained
- Kalshi Order Groups and Rolling Contract Limits
Key terms: Two-Leg Execution · Orderbook · Slippage