Rate limit models compared: weight, count, IP, UID and instrument

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

A rate-limit number is meaningless without its model. “So many per minute” tells you nothing until you know whether it counts requests or weight, whether it belongs to your IP, your account, the endpoint or the instrument, and what the venue does when you cross it. The models differ enough that a limiter tuned for one venue misbehaves on the next.

This page compares the models, not the quotas. Quotas change, and each venue publishes its own on pages linked from its docs; a number copied here would be wrong within months. What follows is what each venue meters, what it keys the meter on, how it tells you where you stand, and what the over-limit response actually means.

The matrix

Venue	What is metered	Keyed on	Usage reported in	Over the limit
Binance Spot	Request weight, raw requests and orders (`rateLimits` in `exchangeInfo`)	Weight: IP. Unfilled orders: account	`X-MBX-USED-WEIGHT-`; `X-MBX-ORDER-COUNT-` on successful orders	HTTP `429`, then `418` IP ban, both with `Retry-After`; `-1003`
Binance USDⓈ-M	Request weight; order rate	Weight: IP. Orders: account	Same headers	`429` escalating to `418`; bans lengthen for repeat offenders
Bybit V5	Two layers: an IP request budget, and per-endpoint request counts	IP; UID + endpoint, rolling per second	`X-Bapi-Limit`, `X-Bapi-Limit-Status`, `X-Bapi-Limit-Reset-Timestamp`	IP layer: HTTP `403`. UID layer: `10006`. Also `10018` (IP)
OKX V5	Requests per endpoint	Public: IP. Private: User ID. Order entry: Instrument ID, shared by REST and WebSocket. Plus a sub-account order limit	We did not find usage headers documented	`50011` (with HTTP 200 or 429); sub-account limit `50061`
Hyperliquid	IP: aggregated request weight. Address: actions against an allowance earned by traded volume	IP; address (sub-accounts count separately)	We did not find usage headers documented	Not documented in our fact card
Alpaca	Requests per minute	Not stated in our fact card	`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`	HTTP `429`
IBKR TWS API	Messages per second from client to TWS	The API client connection	—	Error `100`; TWS will likely disconnect
IBKR Client Portal	Requests per second	Authenticated username	Not documented in our fact card	HTTP `429`

Where the venues actually differ

Binance: weight, and it belongs to the IP

Binance’s docs are blunt: “The limits on the API are based on the IPs, not the API keys.” Several bots with separate keys on one host draw from one weight budget, and creating a new key does not buy more. Endpoints cost different weights, so a budget expressed in requests per minute is the wrong unit — see Binance API rate limits.

Order counts are tracked separately, per account, and reported in the order-count header on successful orders only; rejected orders “are not guaranteed to have” it. Breaking the limit returns 429; continuing gets the IP banned with 418. On futures, “IP bans are tracked and scale in duration for repeat offenders”.

Bybit: two meters, and 403 means three things

Bybit runs two independent layers. The IP layer is a short fixed window applied across the main and regional hosts; breaching it returns HTTP 403 “access too frequent”, and the docs say to stop all HTTP sessions and wait for the ban to lift automatically. The API layer is per UID and per endpoint on a rolling one-second window; breaching it returns 10006, and the three X-Bapi-Limit* headers show the remaining budget on every response.

Three things to know:

HTTP 403 is overloaded. Bybit also returns it for a GET sent with an empty JSON body, and for requests from IPs in the US or Mainland China.
HTTP 429 is not your quota. Bybit describes it as system-level frequency protection under high server load.
Batches can partly succeed. Batch endpoints have their own limit and consume one unit per order; if a batch overruns the remaining budget, the overflow orders fail and the rest go through.

10018, “Exceeded the IP Rate Limit.”, also exists; we did not find official text explaining when Bybit returns 10018 rather than HTTP 403. Limits rise under separate VIP and Pro rules.

OKX: the instrument is the unit for order entry

OKX limits each endpoint separately, keyed on IP for public endpoints and on User ID for private ones. Order placement, amendment and cancellation are keyed on Instrument ID, and that budget is shared across REST and WebSocket: moving order entry to WebSocket does not buy more for the same instrument. Batch and single-order endpoints have independent limits.

A sub-account-level order limit runs in parallel (50061), with a fill-ratio uplift for higher VIP tiers. The ordinary limit error, 50011, appears in OKX’s table under both HTTP 200 and HTTP 429, so check the code field rather than the status. OKX’s own suggestion for more throughput is multiple sub-accounts, each with its own User ID.

Hyperliquid: a budget you earn by trading

Hyperliquid has an IP-based weight limit, with per-request weights that grow with batch size and vary by info request type, plus separate WebSocket limits on connections, subscriptions and messages. The unusual part is the address-based limit on actions:

The allowance accrues with cumulative USDC traded since the address was created, on top of an initial buffer. A new address has only the buffer.
Once exhausted, the address is throttled to a slow trickle of requests.
Cancels have a higher cumulative ceiling, so they keep working when orders cannot.
A batch of n orders is one request for the IP limit but n for the address limit.
Sub-accounts are treated as separate users. During congestion, addresses are further limited by their share of maker volume.

Every figure behind these rules is on Hyperliquid’s rate limits page. Why this catches automated clients on new accounts is covered in rate limits in an MCP trading setup.

Alpaca and IBKR: simpler meters, different failure modes

Alpaca’s Trading API uses a per-minute window and reports it in three X-RateLimit-* headers; the 429 message tells you to use them. Market data streams carry a separate cap on concurrent connections per account, and exceeding it may return 406 or 403.

IBKR’s TWS API limits the rate of messages your client sends to TWS. Error 100 is “Max rate of messages per second has been exceeded.”, and IBKR notes that TWS “will likely disconnect the client application after this message”. A dropped socket is a harder failure than a 429: every subscription and pending request goes with it. The Client Portal gateway meters HTTP requests per authenticated username and returns 429.

What to do in code

Key the limiter on what the venue meters. IP for Binance weight, UID and endpoint for Bybit, instrument for OKX order entry, address for Hyperliquid actions. A single global requests-per-second limiter is wrong for all of them.

Read the headers where they exist. Binance, Bybit and Alpaca report usage on every response. Throttling on reported usage beats throttling on a guessed count.

Honour Retry-After, and treat Binance 429 as a warning. Backing off properly is what keeps you out of 418.

Reserve headroom for cancels. Routine polling should never be able to spend the budget you need to get out of a position. Hyperliquid builds this in; on the other venues you have to.

Never blind-retry an order after a rate-limit error. CCXT classifies RateLimitExceeded under NetworkError, inside OperationFailed, the branch for unknown outcomes. On Bybit a batch can also partly succeed. Query open orders and positions first — see retrying a failed order is not safe.

Do not classify by HTTP status alone. 403, 429 and even 200 carry different meanings across these venues.

FAQ

Does HTTP 429 mean the same thing on every exchange?

No. On Binance, 429 means you broke the rate limit and should back off before it becomes a 418 IP ban. On Bybit, 429 is system-level protection under server load, while its IP limit returns 403. OKX’s 50011 can arrive with HTTP 200 or 429. Read the venue’s error code, not just the status.

Do separate API keys get separate rate limits?

It depends on the venue. Binance meters request weight per IP, so keys on the same host share one budget. Bybit meters per UID and endpoint, OKX private endpoints meter per User ID, and Hyperliquid meters actions per address, with sub-accounts counted separately on both OKX and Hyperliquid.

Why does a new Hyperliquid account hit rate limits so quickly?

Because Hyperliquid’s address-based allowance is earned through cumulative trading volume, on top of a fixed initial buffer. A new address has only the buffer, so an automated client doing frequent actions can exhaust it before trading much. Cancels have a higher ceiling and keep working.

Where do I find the current rate-limit quotas?

On each venue’s own documentation: Binance’s endpoint tables and rateLimits in exchangeInfo, Bybit’s rate-limit page, the per-endpoint “Rate Limit” line in OKX’s V5 docs, and Hyperliquid’s rate-limits page. On Alpaca, the X-RateLimit-Limit header reports the current figure.