Ограничения, ожидания и фоновые задания
Разберитесь в темпе запросов 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). Из ответа MAXmaxне знает, сколько ждать, поэтому сам не ждёт и не повторяет запрос.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-idMAX узнаёт и второго сообщения не создаёт (проверено на повторе через 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.