Планировать инвайт в 2026 году по чужой «таблице на аккаунт в сутки» — самый быстрый способ сломать и сетку, и чат. Telegram не публикует единую официальную таблицу, где было бы написано: столько добавлений, столько ЛС, столько вступлений, и после этого можно спать спокойно. То, что кочует по чатам трафферов, почти всегда чужой замер на чужих номерах, чужом гео и чужой истории. Для оператора важнее другое: понимать типы ограничений, узнавать их в логах задачи и уметь проверить потолок *своих* аккаунтов на *своём* чате.
Ниже — практический взгляд без агентской обёртки. Речь про работу в софте (в том числе в Metagram): как читать отказы, как отделять лимит метода от приговора аккаунту и как не сжечь прогрев ради красивого отчёта за вечер.
Почему «официальной таблицы лимитов» нет и зачем это оператору
Telegram описывает антиспам и ограничения как систему сигналов, а не как прайс-лист. Публично известны отдельные *жёсткие* потолки структуры чата: обычная группа ограничена двумястами участниками, супергруппа — двумястами тысячами, гигагруппа после конвертации перестаёт принимать инвайт как механизм роста. Есть ошибки вида «слишком много админов», «пользователь уже в слишком большом числе сообществ», «нужны права администратора». Но это не то же самое, что «N инвайтов с аккаунта в день».
Поведенческие лимиты зависят от истории номера, возраста аккаунта, взаимности контактов, гео и ASN, скорости однотипных действий, доли отказов и жалоб, состояния чата, в который вы добавляете. Два аккаунта с одинаковой «настройкой задержки» могут жить неделю и сгореть за час. Поэтому оператор, который копирует чужие 40/80/200 «безопасных инвайтов», планирует фантазию, а не задачу.
Рабочая модель на 2026 год такая: считать лимитом не цифру из статьи, а *точку, после которой ваш конкретный аккаунт начинает отдавать устойчивый класс ошибок*. Эту точку измеряют тестом, а не верят форуму.
Связанные состояния — PEER_FLOOD, FloodWait, заморозка и спамблок — разобраны отдельно: про PEER_FLOOD при инвайте и рассылке, про FROZEN_METHOD_INVALID и про заморозку аккаунта. Если «отлетает» не аккаунт, а само сообщество, смотрите разбор причин отлёта чатов.
Четыре класса ограничений, которые путают в одном логе
На практике в задачу инвайта одновременно бьют несколько слоёв. Их нужно именовать по-разному, иначе вы «крутите задержку», когда проблема уже в чате, или «меняете прокси», когда аккаунт заморожен.
1. Лимит метода и FloodWait. Это ближайшее к классическому rate limit. Telegram отвечает, что действие сейчас нельзя повторить, и часто даёт ожидание в секундах (`FLOOD_WAIT_X`). Это не приговор сетке. Это сигнал «слишком часто / слишком плотно». Правильная реакция — ждать указанное время (а лучше чуть шире) и снизить плотность. Неправильная — ретраить тот же метод пачкой аккаунтов с той же скоростью.
2. PEER_FLOOD и ограничения на новые пиры. Это уже не таймер одного метода, а ограничение на массовые касания «холодных» пользователей: инвайт незнакомых, ЛС невзаимным контактам, однотипный outreach. Таймера «подожди 87 секунд» здесь обычно нет. Аккаунт для коммерческого инвайта становится полуживым: старые диалоги могут жить, новые пиры — нет. Подробности — в отдельном материале про PEER_FLOOD; здесь важно не смешивать его с FloodWait.
3. Заморозка и FROZEN_METHOD_INVALID. С 2025 года Telegram явно описывает frozen-аккаунты как read-only режим при серьёзных нарушениях ToS. Многие методы просто недоступны, клиент получает `FROZEN_METHOD_INVALID` (код 420). Это не «подкрутить троттлинг». Задача должна стопнуть аккаунт, апелляция идёт через официальный контур (`freeze_appeal_url` / Spam Info Bot), а не через повтор инвайта.
4. Ограничения чата и прав, а не аккаунта. Сюда относятся антиспам сообщества (резкий рост, выходы, жалобы, пустой чат), нехватка прав (`CHAT_ADMIN_REQUIRED`, необходимость права приглашать), переполнение слотов администраторов (`ADMINS_TOO_MUCH`), потолок участников (`USERS_TOO_MUCH`), приватность цели (`USER_PRIVACY_RESTRICTED`), лимит сообществ у самого пользователя (`USER_CHANNELS_TOO_MUCH`). Инвайт «через админку» упирается ещё и в то, сколько живых админов с правом add members вы реально можете держать, не превращая чат в кладбище технических учёток.
Отдельно стоят отказы цели, которые лимитом аккаунта не являются: пользователь запретил добавлять себя, нет взаимного контакта, цель уже в чате, username мёртвый. Это брак базы. Его надо фильтровать, а не лечить «ещё десятью аккаунтами».
Как эти классы выглядят в софте, а не в клиенте Telegram
Оператор видит не модалку официального приложения, а строку в логе задачи. Имеет смысл заранее договориться в команде, как вы эти строки классифицируете.
FloodWait в нормальном софте должен быть *событием паузы*, а не ошибкой аккаунта. Если кабинет кладёт FloodWait в ту же кучу, что и PEER_FLOOD, вы начнёте ротировать номера вместо того, чтобы подождать. Смотрите: есть ли в тексте/коде значение ожидания, повторяется ли оно на одном методе, снимается ли после паузы.
PEER_FLOOD обычно приходит как устойчивый отказ на добавление/сообщение новым пирам без таймера. Один эпизод на грязной базе ещё не значит, что аккаунт мёртв. Серия на разных целях при той же плотности — значит. В задаче это должен быть стоп аккаунта и вывод из пула инвайта, а не «ещё 500 из той же пачки».
FROZEN_METHOD_INVALID нужно ловить как отдельный критический код. После него любые ретраи инвайта бессмысленны и вредны: вы только подтверждаете автоматике, что сессия живая и продолжает нарушать. Параллельно проверьте, открывается ли аккаунт в официальном клиенте, есть ли экран заморозки, отвечает ли Spam Info Bot.
Ошибки чата и прав часто выглядят «как будто аккаунт сдох», хотя соседний аккаунт с правами проходит. Если падает вся пачка на одном сообществе — сначала чат: права, тип (не гигагруппа ли), антиспам, заполненность, не упёрлись ли в ADMINS_TOO_MUCH при раздаче админок. Если падает один номер на разных чатах — смотрите аккаунт.
Приватность и mutual contact дают высокий процент отказа при «зелёном» аккаунте. Это не лимит Telegram в смысле антиспама, это качество парса. Метрика «успешных инвайтов» без доли `USER_PRIVACY_RESTRICTED` врёт.
В облачном контуре вроде Metagram ценность не в том, что софт «обходит лимиты» — он этого не делает и не должен обещать. Ценность в том, что задача крутится по расписанию, логи не теряются вместе с VPS, аккаунты можно снимать с потока, не останавливая всю сетку, и вы видите *какой* отказ, а не просто красный счётчик.
Что можно опереть на публичные факты, а что нельзя
Можно опираться на документированные сущности:
· супергруппа до 200 000 участников; базовая группа до 200;
· гигагруппа: инвайт людей как механизм роста не предусмотрен;
· ошибки прав и структуры: админка, переполнение админов, переполнение чата, лимит сообществ у пользователя;
· FloodWait как ожидание перед повтором метода;
· frozen-аккаунт и `FROZEN_METHOD_INVALID`;
· спам-ограничения, которые Telegram описывает в Spam FAQ: жалобы, ограничения на сообщения незнакомым, контакт `@SpamBot`.
Нельзя выдавать за официальные правила:
· «40 инвайтов в день с нового, 80 с прогретого»;
· «один инвайт в 60–180 секунд как стандарт Telegram»;
· фиксированное число часов заморозки или PEER_FLOOD;
· «инвайт через админку снимает лимиты»;
· соотношение «1 к 5 ботов» как требование платформы (это практическая модель подготовки чата, не лимит API).
Если цифра не подписана самим Telegram как общее правило, для оператора она — гипотеза. Гипотезу проверяют тестом.
Как тестировать потолок, не сжигая сетку
Тест лимита — это не «залить 20 номеров и посмотреть, кто доживёт до утра». Это узкий эксперимент с одной переменной.
Возьмите 2–3 аккаунта одного класса: одинаковое гео, схожий возраст, похожий прогрев, один тип прокси. Не смешивайте в одном тесте свежие виртуальные номера и годовалые «живые» сессии. Иначе вы не узнаете, что измеряли.
Зафиксируйте чат. Тестовый чат должен быть уже оформлен и не пустой: иначе вы измеряете антиспам сообщества, а не потолок аккаунта. Про подготовку и выходы подробно в статье про отлёт чатов. Для теста прав админки заранее проверьте, что у учёток есть нужное право добавлять участников и что вы не упёрлись в потолок админских слотов.
База для теста — маленькая и чистая. Не гоните в первый заход самую холодную простыню. Нужна выборка, на которой вы отличаете брак (privacy, mutual) от антиспама. Если 70% отказов — приватность, вы не видите лимит аккаунта вообще.
Стартовая плотность должна быть заведомо консервативной относительно того, что вы *подозреваете* как потолок. Цель первого прогона — получить стабильные успехи и карту отказов, а не максимум головы. Смотрите не только «сколько добавилось», а:
· доля успехов;
· доля privacy / not mutual / already participant;
· появились ли FloodWait и как часто;
· появился ли PEER_FLOOD;
· не ушёл ли аккаунт в frozen;
· сколько людей вышло из чата в первые часы;
· не начал ли чат вести себя как ограниченный.
Масштабируйте одну ось. Либо чуть поднимаете объём на тех же аккаунтах, либо добавляете аккаунты при той же плотности. Не оба сразу. Если после шага вылез PEER_FLOOD — это и есть ваш текущий потолок *для этого класса номеров на этой базе*. Записывайте его как внутренний SOP, не как истину платформы.
Отдельно тестируйте «утро / ночь / прайм» только если гео базы это требует. Часто «ночной инвайт» даёт другую долю выходов, а не другой API-лимит. Не путайте реакцию людей с реакцией сервера.
Слоты админов и инвайт через админку как отдельный лимит
В 2026 инвайт через админку — рабочая схема, но она добавляет лимит, о котором забывают. Каждый технический аккаунт, которому вы выдали права, занимает админский слот. Когда слотов слишком много, Telegram отвечает ошибкой уровня `ADMINS_TOO_MUCH`. Точную «официальную цифру слотов» как универсальную константу в операторской документации лучше не высекать в камне: ориентир — ошибка и то, что вы видите в карточке чата, а не скрин из чужого гайда 2022 года.
Следствия для задачи:
· нельзя раздавать админку всей ферме «на всякий случай»;
· админов с правом add members должно быть столько, сколько реально работает в смене;
· после сжигания номера админку надо снимать, иначе слот висит мёртвым;
· путаница прав (есть в админах, но нет invite users) выглядит как массовый отказ «аккаунты не инвайтят».
Антиспам чата при этом не исчезает. Админка не индульгенция. Резкий рост + пустой контент + выходы бьют по сообществу независимо от того, кто жал «добавить». Лимит аккаунта и лимит чата живут параллельно.
Как отличить лимит аккаунта от антиспама чата во время боя
Признак чата: несколько независимых аккаунтов, которые вчера инвайтили нормально в другой проект, синхронно начинают сыпаться *только* на этом сообществе. Параллельно растут выходы, жалобы, «странное» поведение инвайт-ссылок, ограничения на посты. Тогда крутить пейсинг на номерах — вторично. Сначала останавливаете набор, смотрите упаковку, базу, гео, контент.
Признак аккаунта: тот же чат принимает добавления с соседних номеров, а конкретная сессия стабильно отдаёт PEER_FLOOD / freeze / спамблок во всех задачах. Тогда номер выводится из инвайта. Не лечите его сменой чата.
Признак базы: высокий отказ privacy/mutual при живых аккаунтах и живом чате. Тогда парсер и фильтр, а не «ещё лимитов».
Признак инфраструктуры: массовые обрывы сессий, AUTH_KEY_DUPLICATED, внезапные логины, одинаковый ASN на всю пачку. Это не лимит инвайта, это ферма. Пока это не починено, любой тест лимитов бессмыслен.
Рабочий контур контроля в задаче
Соберите в софте и в таблице смены минимум такой контур:
1. Классификация ошибок, не один счётчик fail.
2. Стоп-условия на аккаунт: первый PEER_FLOOD — пауза и разбор; freeze — немедленный вывод; серия FloodWait на одном методе — снижение плотности, а не игнор.
3. Стоп-условия на чат: аномальный процент выходов, жалобы, синхронный отказ нескольких здоровых номеров.
4. Стоп-условия на базу: доля privacy выше порога, который вы сами задали на тесте.
5. Журнал «класс аккаунта → наблюдаемый потолок → дата». Это ваш единственный честный лимит на 2026 год.
6. Разделение пулов: прогрев, инвайт, рассылка. Номер из-под холодной рассылки не должен без карантина идти в инвайт.
Облачный запуск удобен тем, что задача не умрёт вместе с ноутбуком оператора, а логи можно разобрать утром. Попробовать контур без установки десктопного комбайна можно в Metagram: бесплатный режим с ежедневными кредитами подходит именно для теста классификации ошибок, а не для «закрыть план любой ценой».
Типичные самообманы при планировании объёма
«Мы поставим задержку 90 секунд — значит, уложимся в лимит». Задержка без учёта параллелизма по аккаунтам, ретраев и других задач на той же сессии ничего не гарантирует. Две задачи на одном номере удваивают плотность, даже если в каждой стоит «безопасный» интервал.
«Официальный клиент добавляет быстрее софта, значит софт виноват». Клиент тоже ловит те же классы ошибок, просто оператор не видит код. Софт делает их видимыми. Это плюс, если вы умеете читать.
«Прогретый аккаунт = безлимит». Прогрев снижает чувствительность, не отменяет жалобы и холодную базу.
«Если чат большой, лимиты выше». Большой пустой чат с ботами может быть токсичнее маленького живого. Антиспам смотрит на динамику и жалобы, не на круглую цифру участников.
«Сменим IP — снимутся лимиты». FloodWait иногда связан с частотой метода, PEER_FLOOD и freeze — с аккаунтом и поведением. Смена IP на замороженном номере не является лечением и часто ухудшает картину сессий.
Что писать в SOP на 2026 год вместо таблицы
Внутренний регламент полезнее любой инфографики:
· классы ошибок и реакция смены;
· запрет ретраить freeze и PEER_FLOOD как FloodWait;
· правило одного теста — одной переменной;
· требование чистого лога перед масштабированием;
· разделение лимита аккаунта, чата и базы;
· ссылки на рабочие разборы: PEER_FLOOD, заморозка, FROZEN_METHOD_INVALID, отлёт чата.
Цифры в SOP — только ваши замеры по классам номеров, с датой и пометкой «не официальный лимит Telegram».
Коротко
В 2026 лимиты инвайта — это набор разных механизмов: таймер метода, ограничение на холодные пиры, заморозка, антиспам чата, права и слоты админов, приватность целей. Официальной сводной таблицы нет, и это не пробел в вашей подборке, а устройство платформы. Оператор выигрывает не тем, что знает «магическое N», а тем, что задача умеет остановиться на правильном классе отказа и что потолок измерен на своей сетке.
Дальше по кластеру: как вести себя задаче при FROZEN_METHOD_INVALID, чем заморозка отличается от спамблока, и что менять в пейсинге при PEER_FLOOD. Контур запуска удобно отладить в Metagram.
Перенесите сценарий в Metagram
Парсинг аудитории, инвайтинг, рассылки, планировщик и управление Telegram-аккаунтами — в одном облачном кабинете.
Начать бесплатно