# Как Binance считает лимиты API на IP-адрес > Spot API Binance даёт каждому IP-адресу 6 000 веса запросов в минуту — а не 1 200, которые до сих пор цитируют многие библиотеки. Лимиты на ордера считаются отдельно, по аккаунту. Разбираем, как работает весовая математика и что вызывает 429 и 418. - Источник: https://papaproxy.net/ru/blog/binance-api-rate-limits.php - Опубликовано: 2026-07-31 (обновлено 2026-08-06) - Автор: Alex Young - Рубрика: Лимиты и производительность · Блог PapaProxy.net --- ## Ключевые выводы - Бюджет Spot API — 6 000 веса запросов в минуту на IP; поднят с 1 200 ещё 25 августа 2023-го, но библиотеки вроде python-binance до сих пор цитируют старое число. - Binance считает вес, а не запросы, и сразу в нескольких фиксированных интервалах: короткое окно может сброситься, пока длинное исчерпано, — следите за всеми лимитами из `exchangeInfo`. - Вес трекается на IP, ордерные лимиты — на аккаунт: у 429 два прочтения, а дневной потолок считает только неисполненные ордера. - Публичные данные сначала уводите на официальные пути разгрузки: стримы веса не тратят, а `data-api.binance.vision` — рекомендованный Binance хост для сервисов только с рыночными данными. - Не хардкодьте лимиты: сверяйтесь с заголовками `X-MBX-USED-WEIGHT-*` и обновляйте потолки из `/api/v3/exchangeInfo` в рантайме. - Воркерам за одним IP нужен центральный лимитер — атомарный резерв веса в общем хранилище до каждого запроса; локальный троттлер вроде ccxt соседей не видит. - Наш стенд подтвердил бюджет на практике: 94% от 6 000 веса/мин на 16 соединениях без единой ошибки, первый 429 — на 24 соединениях; три адреса параллельно дали 17 066 веса/мин без 429 — бюджеты адресов независимы и складываются линейно. ## Как вес запросов считается на IP Binance считает не запросы, а их вес. У каждого эндпоинта есть своя цена, и весовая система складывает эти цены в общий бакет, привязанный к вашему IP-адресу. Лёгкий вызов — например, цена одного тикера — стоит 1–2 веса. Тяжёлый вызов, который возвращает данные по всем символам биржи сразу, может стоить в десятки раз дороже. Минутный лимит веса действует именно на этот общий бакет, а значит, все скрипты, боты и соединения на вашем адресе расходуют один и тот же бюджет. Из этого следует, что троттлинг нужно строить иначе, чем привыкло большинство. Считать «запросы в минуту» бессмысленно, потому что сотня тяжёлых вызовов исчерпает бюджет, который три тысячи лёгких почти не тронули бы. По той же причине не помогают дополнительные API-ключи: лимит привязан к IP, а не к ключу, и все ключи на одном сервере пьют из одного бакета. Вслепую лететь при этом не приходится: каждый ответ содержит заголовок `X-MBX-USED-WEIGHT-1M` с расходом текущего окна. Одна важная оговорка о том, как это окно устроено. Binance применяет несколько фиксированных интервалов лимитов одновременно: счётчик переключается на границе интервала, а не скользит непрерывно, и короткое окно может сброситься, пока длинное остаётся исчерпанным. Поэтому следите за всеми лимитами, которые возвращает ваш API, а не только за заголовком `1M`. Бот, который сверяет троттлинг с этими значениями, существенно снижает шансы поймать 429 на ровной нагрузке; бот, который сверяет собственный счётчик с числом из туториала, обычно эти 429 и коллекционирует. ## Почему цифра «1 200 веса в минуту» устарела Короткий ответ: Binance поднял лимит ещё несколько лет назад, а половина интернета этого не заметила. 25 августа 2023 года бюджет на IP в Spot API вырос впятеро — со старого значения до 6 000 веса в минуту. Это не было тихим изменением: Binance объявил о нём официально, и актуальное число сегодня подтверждается везде, где это имеет значение. Сэмплы `exchangeInfo` в официальной документации показывают 6 000, и даже текст ошибки `-1003` теперь гласит: «current limit is 6000 request weight per 1 MINUTE». Почему же старое число продолжает всплывать? Потому что оно живёт ровно там, где разработчики реально читают. Документация python-binance до сих пор указывает старое минутное значение на обзорной странице, а обсуждения лимитов на GitHub, которые хорошо ранжируются в поиске, писались против потолка образца до 2023 года. Цена доверия к ним вполне конкретная: троттлер, настроенный на старое число, не использует 80% реального бюджета, а туториал, который учит паниковать на 1 100 веса, учит вас правилам 2023 года. Надёжное лечение — не заменить одну зашитую константу на другую, а перестать зашивать её вовсе. Запрашивайте `/api/v3/exchangeInfo` при старте бота: массив `rateLimits` в ответе — это живой источник истины, и именно его Binance обновит первым, когда лимиты изменятся в следующий раз. ## Вес запросов и счётчик ордеров — два разных лимита Упереться в один из этих лимитов — ещё ничего не узнать о втором, потому что считаются они по разным осям. Весовой минутный лимит привязан к IP-адресу и покрывает всё, что вы отправляете. Ордерные лимиты устроены иначе: они считаются по аккаунту. Текущий сэмпл `exchangeInfo` в документации показывает, что это значит в числах: окно в 50 ордеров за 10 секунд, а поверх него — дневной потолок в 160 000. В дневном потолке есть тонкость, на которой спотыкаются торговые боты, — и работает она в вашу пользу. Счётчик учитывает только *неисполненные* ордера, о чём Binance пишет прямо: если ваши ордера стабильно исполняются сделками, размещать их через API можно без ограничений. Иными словами, потолок существует, чтобы наказывать ордер-спам, который никогда не торгуется, а не активные стратегии, которые торгуются. Следить за своим положением можно в реальном времени: каждый успешный ордер возвращает заголовок `X-MBX-ORDER-COUNT-*`, а `GET /api/v3/rateLimit/order` показывает те же числа по запросу. Вывод для отладки простой. Поймав 429, сначала выясните, какой именно из двух бакетов вы осушили: троттлинг опроса маркет-данных ничем не поможет, если исчерпано было ордерное окно. ## Какие эндпоинты стоят дороже всего Общее правило прямо из официальной документации по лимитам: дороже те эндпоинты, что выполняют операции сразу над несколькими символами. Публичные эндпоинты маркет-данных добавляют к этому вторую закономерность: их цена растёт вместе с объёмом данных, который вы просите в одном вызове. Как это работает, видно на примере стакана. Один и тот же эндпоинт стоит 5 веса, когда вы запрашиваете до 100 уровней, 25 веса — до 500 уровней и 50 веса — на полной тысяче; это числа из разобранного примера самой Binance Academy. Та же логика делает классическим убийцей бюджета вызов тикеров без параметра `symbol`: вы просите один запрос ответить за всю биржу сразу. Свечи находятся на противоположном конце этой шкалы. Эндпоинт свечных данных стоит плоские 2 веса за вызов по актуальной таблице эндпоинтов — независимо от таймфрейма. Этот разрыв в цене объясняет закономерность из реальных проектов: стратегии на свечах при типовых нагрузках упираются в потолок редко, а краулеры стаканов — постоянно. Мы измерили это на своём стенде: вес свечного запроса не зависит и от размера страницы, поэтому запрашивайте всегда `limit=1000` — списание то же, данных в тысячу раз больше (подробности в [разделе с тестом](#ip_2) ниже). Для экономии веса на публичных данных существуют два официальных рычага, и оба должны стоять в архитектуре ДО любых разговоров о масштабировании адресами. Первый: маркет-стримы WebSocket не расходуют вес вовсе — текст ошибки 429 у Binance сам советует перейти с опроса на WebSocket. Только не путайте при сравнении лимитов REST и WebSocket: бесплатны именно *стримы*; request-response WebSocket API расходует тот же весовой пул, что и REST (одно открытие соединения стоит 2 веса), а подключения ограничены 300 за 5 минут на IP. Второй рычаг: для сервисов, работающих только с публичными рыночными данными, Binance прямо рекомендует специальный базовый эндпоинт `data-api.binance.vision` — те же пути, без аккаунтных эндпоинтов. Направляйте публичные пайплайны туда, а не на основной хост API. ## Чем отличаются лимиты спота и фьючерсов Спот и фьючерсы — раздельные системы с раздельными бюджетами, поэтому исчерпание одного никак не задевает другой. Spot REST даёт каждому IP 6 000 веса в минуту на `api.binance.com`. Фьючерсный API живёт на другом хосте, `fapi.binance.com`, и ведёт собственную бухгалтерию: для контрактов USDⓈ-M лимит составляет 2 400 веса в минуту на IP, согласно фьючерсной документации. Бакет меньше, но и рассчитан он на API, где большинство вызовов данных легче своих спотовых аналогов. Для бота, который торгует оба рынка с одного сервера, это палка о двух концах. С одной стороны, у вас два независимых бюджета — это удобно. С другой — два независимых способа сжечь один и тот же IP-адрес, потому что бан 418 действует на уровне адреса и не разбирается, какой из API его заработал. И правило «не хардкодить» здесь работает с двойной силой: каждый фьючерсный вкус (USDⓈ-M и COIN-M) публикует собственный `exchangeInfo`, и их числа никогда не менялись синхронно со спотом. Запрашивайте лимиты того API, на котором реально торгуете. ## Как жить в лимитах, когда крутится бот На практике правила лимитов для трейдинга сводятся к четырём привычкам, и ни одна из них не требует запоминать числа. Первая привычка — читать заголовки, а не документацию. Ведите троттлинг от значения `X-MBX-USED-WEIGHT-1M` в живых ответах, а потолки обновляйте из `exchangeInfo` при старте. Боты, собранные по этому принципу, пережили смену лимитов 2023 года без единой правки — просто потому, что изначально не доверяли константам. Обе проверки занимают пару строк. Актуальные потолки достаются без всякого API-ключа: BashКопировать код ```bash curl -s "https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT" | jq '.rateLimits' ``` В выводе ищите объекты, где `rateLimitType` равен `REQUEST_WEIGHT` и `ORDERS`. Поле `limit` рядом с каждым `interval` — то число, которому должен доверять троттлер; обратите внимание, что интервалов на один тип может быть несколько. Следить за расходом в реальном времени так же коротко: PythonКопировать код ```python import requests r = requests.get("https://api.binance.com/api/v3/ticker/price", params={"symbol": "BTCUSDT"}) print(r.headers["X-MBX-USED-WEIGHT-1M"]) # вес, потраченный в текущем окне ``` Проверку уровня «пересекли 90% — спим» считайте демонстрацией, а не production-лимитером. Настоящий расчёт бюджета выглядит ближе к этому: КодКопировать код ``` effective_remaining = configured_limit - observed_used_weight - reserved_weight_for_inflight_requests - safety_margin ``` Что за этим стоит при нескольких воркерах — отдельная тема, ей посвящён следующий раздел. Вторая привычка — воспринимать 429 как жёсткий стоп, а не как рекомендацию. Ответ несёт заголовок `Retry-After` со временем ожидания в секундах, и уважать его важно: продавливание сквозь повторные 429 — документированная дорога к 418, а IP-баны для рецидивистов растут от 2 минут до 3 дней. Третья — сначала увести публичные данные на официальные пути разгрузки: стримы и `data-api.binance.vision`, о которых выше. Всё, что бот опрашивает по таймеру, должно жить там; REST-бюджет основного хоста берегите для того, чему он действительно нужен, — ордеров и состояния аккаунта. Четвёртая привычка — архитектурная: точно знать, какие процессы делят исходящий IP. Бюджет в 6 000 принадлежит адресу, и его делит всё, что за этим адресом стоит. Именно поэтому лимиты торговых ботов так часто выглядят мистикой: три процесса на одном сервере пьют из одного бакета, и «случайные» 429 — это просто соседи, конкурирующие за общий бюджет. По той же причине здесь могут подвести фреймворки: у ccxt есть встроенный троттлер, но общий IP незаметно ломает его математику, ведь библиотека видит только собственный трафик и ничего не знает о соседях. Отсюда два честных варианта: скоординировать воркеров за одним адресом или развести их по отдельным адресам. Следующие два раздела разбирают оба по очереди. ## Как скоординировать несколько воркеров за одним IP Если воркеры обязаны делить адрес, лечение — центральный лимитер: один хранитель бюджета, к которому каждый процесс обращается перед отправкой. Паттерн описывается коротко: счётчик живёт в общем хранилище (обычно Redis), вес эндпоинта резервируется *атомарно до* отправки запроса, а локальное состояние сверяется с заголовками `X-MBX-USED-WEIGHT-*` из ответов — потому что число сервера истина, а ваше лишь оценка. Production-ориентированный набросок: PythonКопировать код ```python # Набросок, не библиотека: центральный лимитер веса для воркеров за одним IP import time, random, logging, redis, requests r = redis.Redis() BASE = "https://api.binance.com" SAFETY = 0.10 # консервативно для парка воркеров; одиночный сборщик может снизить до 0.05 SPANS = {"SECOND": 1, "MINUTE": 60, "DAY": 86400} WEIGHTS = {"/api/v3/klines": 2, "/api/v3/depth": 50} # 50 — худший случай (1 000 уровней); до 100 уровней вес 5, до 500 — 25 def load_limits(): info = requests.get(f"{BASE}/api/v3/exchangeInfo", params={"symbol": "BTCUSDT"}).json() limits = {} for l in info["rateLimits"]: if l["rateLimitType"] != "REQUEST_WEIGHT": continue if l["interval"] not in SPANS: # новый тип интервала — не падаем в горячем пути logging.warning("неизвестный интервал %s — пропущен", l["interval"]) continue limits[(l["interval"], l["intervalNum"])] = l["limit"] return limits LIMITS = load_limits() def window_key(interval, num): span = SPANS[interval] * num return f"w:{interval}{num}:{int(time.time()) // span}", span def reserve(weight): acquired = [] for (interval, num), limit in LIMITS.items(): # каждый интервал, не только 1M key, span = window_key(interval, num) used = r.incrby(key, weight) # атомарный резерв ДО отправки r.expire(key, span) acquired.append(key) if used > limit * (1 - SAFETY): for k in acquired: # откат по ВСЕМ занятым интервалам r.decrby(k, weight) return False return True def call(path, params): weight = WEIGHTS[path] while not reserve(weight): time.sleep(0.2 + random.random()) # джиттер против одновременного старта resp = requests.get(BASE + path, params=params) used = resp.headers.get("X-MBX-USED-WEIGHT-1M") if used: # сверка: правда за сервером key, span = window_key("MINUTE", 1) r.set(key, max(int(used), int(r.get(key) or 0)), ex=span) # ex — не снимать TTL с ключа окна if resp.status_code == 429: time.sleep(int(resp.headers.get("Retry-After", "1"))) elif resp.status_code == 418: raise RuntimeError("IP забанен: остановить весь парк, не ретраить") return resp ``` На что смотреть при запуске. Цикл в `reserve` обходит *все* интервалы из `exchangeInfo` — именно это спасает, когда короткое окно сбросилось, а длинное всё ещё исчерпано, — а при отказе откатывает резерв по всем уже занятым интервалам, а не только по последнему: иначе каждая неудачная попытка накручивала бы короткое окно, и лимитер начал бы блокировать сам себя при нулевой реальной нагрузке. Шаг сверки подтягивает счётчик в Redis до серверного заголовка при любом расхождении — обязательно с `ex=span`, потому что голый `SET` снимает TTL и оставляет ключи окон в Redis навсегда. Порог `SAFETY` согласуйте с задачей: 10% останавливают резерв на 5 400 веса из 6 000 — разумный запас для парка воркеров, но одиночный сборщик, который метит в 90–94% бюджета из нашего теста ниже, может снизить его до 5%. И честно о том, чего реальному деплою ещё не хватает поверх наброска: circuit breaker, который ставит парк на паузу после серии 429; освобождение резерва для запросов, упавших до Binance; цикл обновления таблицы `WEIGHTS` — в идеале с весом стакана как функцией запрошенной глубины, а не константой худшего случая; и один неймспейс Redis *на исходящий IP* — все ключи и воркеры за одним адресом обязаны делить одного хранителя бюджета. Координации нужны и глаза. Минимальный набор метрик, после которого «случайное» поведение лимитов перестаёт выглядеть случайным: КодКопировать код ``` binance_used_weight_ratio binance_order_count_ratio binance_http_429_total binance_http_418_total binance_retry_after_seconds binance_request_weight_by_endpoint binance_websocket_reconnect_total ``` Если `used_weight_ratio` подскочил, а `request_weight_by_endpoint` вашего воркера ничего нового не показывает — бюджет тратит кто-то ещё за тем же адресом. Чистое лечение — развести нагрузки по отдельным адресам, а насколько независимы их бюджеты на самом деле, мы измерили в следующем разделе. ## Наш тест: где на самом деле заканчивается бюджет одного IP **Что проверяли.** Выше статья утверждает, что Binance выдаёт каждому исходящему IP независимый бюджет 6 000 REQUEST_WEIGHT в минуту. Мы потратили двое суток и проверили это на собственной инфраструктуре: выделенные HTTP-прокси PapaProxy.net с egress в Германии, публичный эндпоинт `GET /api/v3/klines` на `api.binance.com`, пара BTCUSDT, интервал 1m. **Сначала — сколько стоит запрос.** Прямым соединением, по 8 замеров на каждое значение, мы считывали приращение заголовка `X-MBX-USED-WEIGHT-1M`: | `limit` | Вес запроса | Свечей в ответе | Размер ответа | | --- | --- | --- | --- | | 1 | 2 | 1 | 167 Б | | 100 | 2 | 100 | 16,9 КБ | | 500 | 2 | 500 | 84,8 КБ | | 1000 | 2 | 1000 | 169,1 КБ | Вес не зависит от размера страницы. Практический вывод простой: **всегда запрашивайте `limit=1000`** — списание одинаковое, а данных в тысячу раз больше. Запрос за одной свечой стоит ровно столько же, сколько запрос за тысячей. **Лестница по одновременным соединениям.** Один выделенный адрес, `limit=1000`, ступени по 120 секунд, без искусственных пауз между запросами: Интерактивный тест ### Где параллелизм упирается в лимит Binance Переключайте показатели и наведите курсор или фокус на точку, чтобы увидеть замер. Таблица ниже остаётся полным источником данных. Вес/мин Запросы/с Мбит/с *Тест параллелизма Binance.* Один выделенный HTTP-прокси в Германии · BTCUSDT, свечи 1m · limit=1000 · 120 секунд на ступень. | Соединений | Запросов/с | вес/мин | % от бюджета 6 000 | Мбит/с | HTTP 429 | | --- | --- | --- | --- | --- | --- | | 1 | 3,09 | 370 | 6,2% | 4,2 | нет | | 2 | 5,65 | 678 | 11,3% | 7,6 | нет | | 4 | 11,44 | 1 373 | 22,9% | 15,4 | нет | | 6 | 17,22 | 2 067 | 34,4% | 23,2 | нет | | 8 | 23,62 | 2 834 | 47,2% | 31,9 | нет | | 12 | 35,27 | 4 233 | 70,6% | 47,6 | нет | | 16 | 47,02 | 5 642 | 94,0% | 63,4 | нет | | 24 | 71,19 | 8 543 | 142,4% | 95,6 | **да** | Первый 429 пришёл на 24 соединениях, на запросе №4910, с заголовком `Retry-After`. **Что это значит.** Бюджет 6 000 веса в минуту — реальный и достижимый. Чтобы выбрать его при `limit=1000`, адрес должен отдавать 50 запросов в секунду по 169 КБ, то есть держать около 68 Мбит/с. Наш адрес выдал 95,6 Мбит/с — то есть **ограничением становится бюджет Binance, а не канал прокси**. И эту скорость каждый адрес пула держит независимо: при параллельной работе десятков или сотен IP узким местом станет канал вашего сервера или ноутбука, а не прокси. На 16 соединениях мы получили 94% бюджета без единой ошибки; между 16 и 24 соединениями проходит граница. Рабочая точка, которую мы рекомендуем: **14–16 одновременных соединений на адрес**. Это 90–94% бюджета с запасом на неровности. Идти к 100% смысла нет: первая же задержка на стороне API сдвинет окно и даст 429. **Независимы ли бюджеты у разных адресов.** Три выделенных адреса, работающих одновременно по 14 соединений каждый, 120 секунд: | Адрес | Максимум `X-MBX-USED-WEIGHT-1M` | | --- | --- | | адрес 1 | 5 666 | | адрес 2 | 5 654 | | адрес 3 | 5 746 | | **Сумма** | **17 066** | Суммарно 17 066 веса в минуту — почти втрое больше бюджета одного адреса, и ни одного 429. Если бы адреса делили общий egress, лимит сработал бы почти сразу. **Бюджеты независимы**, и параллельные адреса складываются линейно: каждый следующий IP добавляет к общему потолку ещё 6 000 веса в минуту. **Надёжность пула на длинной дистанции.** Отдельно, до основной серии, мы прогнали продолжительный тест на общем пуле из 1 000 адресов: равномерный round-robin по всему пулу, публичный эндпоинт свечей, суммарно около четырёх с половиной часов работы. | Показатель | Значение | | --- | --- | | Адресов задействовано | 1 000 | | Запросов всего | 197 527 | | Ответов с валидным содержимым | 197 204 (99,84%) | | Ошибок установки соединения | 323 (0,16%) | Важная деталь про методику: тот загрузчик открывал новое соединение на каждый запрос, а не переиспользовал сессии. То есть 0,16% — это доля неудачных *установок* соединения из 197,5 тысячи попыток, а не доля сбоев внутри пары сотен долгоживущих сессий. Для оценки надёжности пула это более строгий сценарий. Этот прогон шёл с низкой нагрузкой на каждый отдельный адрес и *не является* проверкой лимитов Binance — из него нельзя делать выводов о 429. Он отвечает только на вопрос, насколько стабильно пул держит соединения при длительной равномерной работе. **Проверка на втором адресе.** Границу 6 000 веса в минуту мы получили дважды и независимо: на выделенном адресе в основной серии и, ранее, на другом адресе общего пула — там 429 пришёл на 16 соединениях при `limit=1`. Совпадение границы на двух разных адресах и двух разных размерах страницы говорит, что лимит считается по исходящему IP, а не по маршруту или типу трафика. **Геолокация имеет значение.** Выделенные адреса в США на `api.binance.com` возвращали HTTP 451, немецкие — 200. Это не сбой, а граница между двумя разными компаниями: Binance.US — отдельная организация со своими эндпоинтами (`api.binance.us`), поэтому для работы с американской биржей нужны именно американские адреса. Для эндпоинтов глобальной Binance подходят адреса любой обслуживаемой страны — кроме США. Страну egress выбирайте до начала работы, иначе тест упрётся не в лимиты, а в блокировку. **Практические следствия для сбора истории.** Вся минутная история BTCUSDT — примерно 4,7 млн свечей, то есть около 4 710 страниц по 1000. Это **9 420 единиц веса, около полутора минут бюджета одного адреса** и примерно 796 МБ трафика. Иными словами, лимиты Binance полный бэкфилл одной пары не ограничивают вообще — ограничивает передача данных. Два числа ниже получены пересчётом из таблицы выше, а не отдельным замером: - последовательный обход в одно соединение (3,09 запроса/с) — около **25 минут**; - 16 соединений на одном адресе (47,02 запроса/с) — около **100 секунд**. Разница здесь целиком про конкурентность, а не про прокси. Если ваш загрузчик ходит по страницам последовательно, добавление адресов не поможет — сначала нужно распараллелить обход по диапазонам времени. **Условия теста.** Выделенные HTTP-прокси PapaProxy.net, egress DE, авторизация по белому списку IP. Цель — публичный `api.binance.com`, без ключей и подписи. Ступени по 120 секунд, пауза 65 секунд между ступенями для сброса минутного окна. Лестница останавливается на первом 429 и выше не поднимается. Прогон от 5 августа 2026 года. Практический итог для планирования: рабочая точка — 14–16 соединений на адрес, бюджеты адресов складываются линейно, а дальше — чистая арифметика вашего объёма. Наши клиенты решают эту задачу двумя схемами, и выбор зависит только от объёма: пакеты в 5 000–10 000 адресов из общего пула под массовый сбор данных — или выделенные адреса, когда IP должен принадлежать только вам. Обе схемы рабочие, обе прошли через этот тест с разных сторон, и обе доступны на странице [прокси для Binance](/target/binance-proxy-server/): выделенные адреса от одного IP, пакеты из общего пула, доступ по белому списку IP, а на каждом адресе — HTTP, HTTPS, SOCKS4 и SOCKS5. ## FAQ **Есть ли у Binance API бесплатный тариф?** Платных тарифов нет вовсе — API бесплатен для любого верифицированного аккаунта. Лимиты, в которые вы упираетесь, технические, а не коммерческие: 6 000 веса в минуту на IP и ордерные потолки на аккаунт одинаковы для всех, и никакая оплата их не поднимает. Масштабируются эффективным расходом веса и добавлением IP-адресов, а не апгрейдом плана. **Какие лимиты у бесплатного использования на практике?** Те же, что у всех: 6 000 веса в минуту на каждый IP-адрес и ордерные лимиты на аккаунт — 50 ордеров за 10 секунд и 160 000 неисполненных в день по текущему сэмплу `exchangeInfo` в официальной документации. Исполненные ордера дневной счётчик не душат. Живые значения проверяйте через `/api/v3/exchangeInfo` — Binance обновляет их там первыми.