Rate limits and bans

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

How do Binance weight-based rate limits work?

Binance meters requests by 'weight', not count: each endpoint costs a documented weight (cheap lookups = 1, `exchangeInfo` is heavy, 10+). Limits are defined per interval in the `rateLimits` array of `GET /api/v3/exchangeInfo` — historically 1200 weight per minute per IP on spot (verify live values as of early 2026; Binance has been moving some limits to per-UID). Track usage from response headers like `X-MBX-USED-WEIGHT-1M` and throttle client-side around 80% of the cap. Placing an order costs weight AND, on futures, also counts against separate order-count limits (also listed in exchangeInfo). Cache exchangeInfo instead of re-fetching it per call — that alone saves most bots hundreds of weight per minute.

What is the difference between HTTP 429 and 418 on Binance?

HTTP 429 means you violated a rate limit: back off immediately and respect the `Retry-After` header if present. If you keep hammering after 429s, Binance escalates to HTTP 418 — an IP ban whose duration grows with repeat offenses, from minutes up to multiple days. A ban blocks ALL API traffic from that IP, so one runaway loop can take down every strategy on the box. Rules: never retry a 429/418 instantly; use exponential backoff with jitter; route all requests through one throttled client so concurrent strategies share the budget; and treat a 418 as a circuit breaker that halts trading until the ban lifts. The same 429/418 semantics apply on futures and the WebSocket API.

How do I read Bybit v5 per-endpoint rate limit headers?

Bybit v5 enforces per-endpoint, per-UID (and per-IP) limits, and trade endpoints report them in response headers: `X-Bapi-Limit` (bucket size), `X-Bapi-Limit-Status` (remaining), and `X-Bapi-Limit-Reset-Timestamp` (ms when the bucket refills). Order placement endpoints such as `/v5/order/create` have their own buckets, and the sizes vary by account/VIP tier — so do not hardcode numbers you found in a blog post; read the headers at runtime and adapt. When exceeded you get HTTP 403 with retCode 10006; wait until the reset timestamp, do not spin. If headers show you are chronically near the cap, use batch endpoints (`/v5/order/create-batch`) or apply for a limit raise rather than shaving margins ever thinner.

What are OKX rate limits and how do I stay under them?

OKX expresses limits per endpoint as 'N requests per 2 seconds' — e.g. 20 req/2s is typical for public endpoints, with private endpoints having their own values in the docs. There is no weight header system like Binance, so throttle client-side per endpoint path. Exceeding a limit returns error code 50011 ('Request too frequent'); back off rather than retrying instantly, since persistent abuse can throttle the sub-account or IP further. Batch endpoints are your friend: `/api/v5/trade/batch-orders` places up to 20 orders in one request, and batch amend/cancel endpoints similarly amortize cost — grid and market-making bots should batch by default. Note that limits for the same endpoint can differ between live and demo (`x-simulated-trading`) environments.

Do WebSocket connections have rate limits too?

Yes, on connection count, message rate, and stream count. Binance spot WS limits connection attempts (historically 300 per 5 minutes per IP) and caps streams per connection (1024), so combine streams into one `stream?streams=a/b/c` connection instead of opening one socket per symbol. Inbound messages (subscribe frames, WS API calls) are also rate-limited per connection. The Binance WebSocket API (`wss://ws-api.binance...`) lets you place orders over WS: each call is signed per-request (HMAC or Ed25519) and consumes the same weight budget as REST, but with lower overhead — useful for latency-sensitive order paths. Bybit v5 and OKX similarly limit subscribe messages and require periodic app-level pings. Verify exact numbers in current docs; they drift.

How do I read remaining rate-limit quota on Bybit v5 and OKX?

Bybit v5 returns quota in response headers: X-Bapi-Limit (the per-endpoint cap), X-Bapi-Limit-Status (remaining in the current window), X-Bapi-Limit-Reset-Timestamp (window reset, unix ms). Limits are per-endpoint per-UID and vary by account tier, so read the headers live instead of hardcoding numbers — log them when you approach the cap. OKX documents limits per endpoint as 'N requests per 2 seconds' (order endpoints are typically 60/2s for placement as of early 2026, but verify per endpoint and tier in the docs) and returns error code 50011 when breached; OKX does not give a uniform X-RateLimit-* header family across REST endpoints, so track client-side: a token bucket per endpoint group keyed to the documented window. On both exchanges, back off on the first breach — repeated hammering after 50011/10006 escalates from throttling to temporary bans.

Do WebSocket connections have rate limits, or are they unlimited?

They have limits, on two layers. Connection layer: Binance caps new WS connections per IP (5 per minute historically — verify current), and streams drop after 24 hours by design, so reconnect logic is mandatory; invalid frames or too many subscription messages per connection get the socket closed. Order layer: the Binance WebSocket API (placing orders over WS) carries its own order rate limit — 10 orders per second per connection, plus the same per-account order limits as REST; exceeding returns an error frame, and abuse closes the connection. Bybit v5 WS enforces per-endpoint and per-connection message limits with its own retCodes; OKX applies account-level limits to WS order channels too. Design rule: one WS connection multiplexed for streams, REST for burst order flow, and never assume a socket that accepted your message executed it — confirm via the execution report or a REST order query.

Give your agent this brain