MAX

Ограничения, ожидания и фоновые задания

Разберитесь в темпе запросов CLI для MAX, общих лимитах профиля, отправках и влиянии ожиданий сервера на параллельные команды.

MAX ограничивает, как часто один аккаунт может к нему обращаться, и свои пределы не публикует. Если спрашивать слишком часто, MAX отказывает, а частые входы подряд он и вовсе блокирует на время. max держит каждый профиль в одном темпе, останавливается на отказе MAX и не повторяет запрос сам. Здесь всё это собрано в одном месте.

Темп: один на профиль

Каждый запрос, который max делает от имени профиля, — из команды, max mcp, max serve или фонового задания — ждёт своей очереди в одном темпе этого профиля:

  • первые 10 запросов идут сразу, поэтому обычные команды не ждут;
  • дальше — 20 запросов в минуту, один примерно раз в 3 секунды, пока запас не восстановится.

Две команды одновременно делят один темп. Очередь хранится в файле в папке состояния (pace/<профиль>.json), поэтому два терминала, несколько store fetch --background и max serve встают друг за другом, а не идут каждый на полной скорости. Пять скачиваний параллельно идут не быстрее, чем по очереди, — и не рискованнее. У разных профилей (разных аккаунтов MAX) темп свой.

Команда, которой ждать своей очереди дольше 5 секунд, пишет об этом в stderr:

waiting 12 s to keep this profile's pace with MAX

Поменять темп можно в файле настроек или для одного окружения переменной:

{ "defaults": { "requestsPerMinute": 10 } }
MAX_REQUESTS_PER_MINUTE=10 max store fetch Друзья

0 выключает темп. Делайте это только для профиля, которым не жалко рискнуть.

Когда MAX отказывает

  • «Слишком много запросов». Команда останавливается с кодом 8 (rate_limited). Из ответа MAX max не знает, сколько ждать, поэтому сам не ждёт и не повторяет запрос. store fetch сохраняет уже скачанное, и следующий запуск продолжает с того же места. Подождите несколько минут.
  • Слишком частые входы. MAX отказывает во входе, и max сам не входит до конца паузы — ни одна команда, ни max session start, ни фоновый сервер. Пауза растёт с каждым отказом подряд: 1 минута, 5 минут, 30 минут, час, 6 часов, дальше сутки; удачный вход её сбрасывает. Подробно — в troubleshooting.md.
  • Если MAX всё же назовёт время ожидания, это ожидание держит весь профиль: следующий запрос любого процесса ждёт его конца, а тот, кому ждать больше 5 минут, сразу получает код 8, ничего не отправив. max doctor показывает удерживаемое в разделе flood; max flood clear снимает раньше срока, если вы знаете, что ограничение снято.

Один вход на всё

max serve держит одно соединение с MAX, и команды, max mcp и max watch идут через него, а не входят каждый сам. Поэтому параллельные команды не добавляют входов. Если сервер не работает, команда запускает его в фоне (настройка serve). После разрыва сервер подключается снова с растущей паузой — от секунды до минуты.

Отправка

  • 30 отправок в час на профиль по умолчанию (sendsPerHour), во всех процессах вместе; сверх — отказ с кодом 8. См. security.md.
  • Отправку, которая могла дойти, а могла и нет, max не повторяет сам: повтор с тем же --send-id MAX узнаёт и второго сообщения не создаёт (проверено на повторе через 15 минут).

Скачивание истории

  • store fetch листает по 30 сообщений, с паузой 5–10 секунд между страницами (--pause), не больше 1200 сообщений за запуск (--limit). Подробно — в archive.md.
  • messages download --all делает запрос на каждую страницу и каждый файл; файлы тоже идут в темпе.
  • Списки участников и ремонт пропусков в архиве идут в том же темпе.

Фоновые задания

store fetch --background и store gaps repair --background запускают задание, которое переживает команду: по одному заданию на чат, каждое в своём процессе, все — в одном темпе профиля. max store jobs list показывает их, max store jobs cancel <id> останавливает после текущей страницы.

Боты

У бота свои ограничения Bot API, отдельные от аккаунта. На ответ 429 с retry-after чтение повторяется один раз после паузы, которую просит MAX; отправка не повторяется. См. bot.md.