Короче, задача была простая на словах и подлая на деле: надо было обогатить почти девять тысяч крипто-каналов метаданными из Telegram API, а потом ещё докинуть к ним кластеры до общей очереди в 40902 канала. Один аккаунт упёрся бы в лимит Telegram за час и стоял бы потом сутки, поэтому мы с Claude Code собрали параллельную инфру — десять аккаунтов, десять прокси, десять контейнеров, крон на ежедневный запуск и прогресс-файл на каждого. За шесть дней обработали около 9900 каналов, база разрослась до тех самых 40902, осталось примерно семнадцать дней при темпе под 1900 в день. И по дороге мы четыре раза упали, каждый раз по-разному, и каждый раз вытащили из этого правило. Вот про это я и расскажу, потому что вся соль ведь не в том что «получилось», а в том как именно ломалось.
Зачем вообще 10 аккаунтов, а не один с паузами
Когда у вас один источник и надо собрать данные по тысячам каналов, первая мысль обычно такая — давай аккуратно, один аккаунт, большие паузы между запросами, никуда не торопимся. Звучит безопасно, но это растягивается на недели и всё равно ловит лимит, просто медленнее. Вторая мысль — несколько аккаунтов, но через один IP, и вот тут уже пахнет горелым, потому что Telegram прекрасно видит, что десять «разных» аккаунтов сидят с одного адреса и синхронно долбят API. Третий вариант, на котором мы и остановились — десять аккаунтов, и каждому свой SOCKS5-прокси, свой контейнер, свой кусок очереди.
Распределение каналов Claude предложил по-честному простое: round-robin по остатку от деления, то есть канал с индексом i уходит на аккаунт `index % 10`. Никаких хитрых балансировок, просто десять равных потоков, каждый знает свой набор и пишет свой прогресс. В этом и весь смысл затеи — параллель даёт примерно десятикратную скорость, но риск на каждый отдельный аккаунт при этом не растёт, потому что каждый работает в своём темпе и со своего адреса. Код тут целиком писал AI, я только принёс файлы аккаунтов и прокси и сказал «параллель, агентами, до конца». Конвертацию сессий в рабочий формат тоже делал Claude.
Грабля первая: засветил аккаунты с собственного IP
И вот тут случилось то, что я люблю в работе с AI больше всего — он сам себя поймал. Все десять аккаунтов сконвертировались минут за пятьдесят, всё зелёное, можно радоваться, и тут Claude буквально пишет: конвертация через текущую сессию коннектилась к Telegram по обычному IP, без прокси. То есть аккаунты, которые мы аккуратно прогревали на новых адресах, только что засветились с моего домашнего IP. Дословно от него прилетело: «Ты прав, я обосрался — нужно было сначала настроить прокси и только потом коннектиться. Весь смысл прогрева на новых IP частично обнулён».
Знаете, в чём кайф этого момента? Не в том что он ошибся — ошибаются все, и кожаные разработчики тоже, не смешите меня. Кайф в том, что он не стал заметать это под ковёр и выдавать «всё хорошо, продолжаем». Записали это в память как урок и решили не дёргаться: подождать день, пусть прогрев на правильных адресах затрёт этот локальный след, и только потом запускать боевую сессию. Иногда лучшее, что можно сделать после фейла — вообще ничего не делать сутки.
Грабля вторая: 250 в день — это не сутки, а скользящее окно
На следующее утро запустили по-настоящему. И первый день прошёл почти неприлично гладко: за час все десять дошли до 175 запросов из плановых 250, ни одного FloodWait, к обеду финишировали на 222-223 каждый, ноль банов. День первый — около 2200 каналов в копилку. Я выдохнул и решил, что мы поняли как оно работает. Зря.
Вечером я попросил перезапустить через force-recreate, чтобы подхватить правку, и сделал это, по сути, среди ночи, не подумав про окно. Claude потом сам же и сформулировал: «Блять, ты прав, я поспешил. Запустил force-recreate среди ночи — все 10 аккаунтов сразу словили FloodWait 12 часов на первом же запросе». И вот тут до нас дошло главное про лимиты Telegram, чего нигде толком не написано: 250 в день — это не «250 за календарные сутки, в полночь обнулилось». Это скользящее окно примерно в 24 часа. То есть если вчера вечером вы выбрали свой лимит, то сегодня вечером вы всё ещё внутри того же окна, и любой запрос мгновенно ловит флуд. Календарь тут вообще ни при чём, считается откат на сутки назад от текущего момента.
Грабля третья: реальный потолок не 250, а 200
Дальше мы аккуратно нащупывали границу. На второй день снова прилетел FloodWait, но уже не из-за окна, а просто потому что упёрлись где-то на 200 каналах на аккаунт. Стало ясно, что красивая цифра 250 из документации это теория, а живой потолок — около 200 запросов в сутки на аккаунт, и подходить к нему вплотную глупо. Я сказал: «Поставь 190, с запасом до бана». Десять каналов запаса звучит как мелочь, но именно эти десять и отделяют чистый выход от словленного флуда.
Заодно поменяли поведение на сам FloodWait — сделали гибрид по порогу. Если флуд короткий, меньше шести часов, контейнер просто ждёт внутри и потом досасывает свой кусок, потому что рестартовать ради короткой паузы дороже. А если флуд длинный, больше шести часов, контейнер выходит и ждёт следующего крона, потому что держать его живым полдня впустую смысла нет. Логика тупая, но именно она и убрала весь хаос. На третий день с лимитом 190 все десять отработали начисто: ноль FloodWait, около 1850 каналов за 67-70 минут. Вот это уже был тот стабильный режим, ради которого всё и затевалось — примерно 1900 в день и спишь спокойно.
Грабля четвёртая: одна строчка `if not has_comments`
Казалось бы, всё, инфра поехала, можно расширять очередь. Я принёс ещё кластеры каналов — сначала пачку на 7403, потом большой атлас на сотни тысяч, из которого в очередь ушло столько, что общая сумма дошла до 40902. Переработали скрипт обогащения под несколько входных файлов с пометкой источника у каждого канала, чтобы не путать кластеры между собой, и крон поехал дальше. К концу недели было 9923 из 40902, это 24 процента, и первый крипто-кластер закрыт полностью.
А потом я заметил, что 3747 каналов почему-то остались без метаданных, хотя крон по ним точно проходил. Claude полез искать и нашёл — там была одна строка вида `if not has_comments: return result`. Логика была такая: если у канала нет комментариев, дальше считать нечего, выходим. Но это была ошибка по сути, потому что вместе с комментариями она выкидывала и просмотры, и вовлечённость, и частоту постинга — а это есть у любого канала, хоть с комментами, хоть без. То есть из-за одной невнимательной проверки почти четыре тысячи каналов недополучили половину данных. Починили, пересчёт занял пару дней. Вот вам и вся романтика — три дня воюешь с rate limit Telegram, а половину базы тихо обесценивает одна строчка, которую никто не перечитал.
Кто что тут делал на самом деле
Раз уж я про это пишу честно — давайте честно и про роли. Весь код тут писала нейросеть: и скрипт обогащения, и docker-compose на десять контейнеров, и крон-обёртки, и мелкие helper-ы для статуса. Архитектуру с round-robin по `index % 10` тоже предложил AI, и root cause каждого FloodWait находил он же, и баг с `if not has_comments` выкопал он. Я тут не «закодил руками» — я код писать не умею и не делаю вид что умею, я оркестрировал. Моя работа была другой и, как по мне, не менее важной: я приносил аккаунты и прокси, я принимал стратегические решения вроде «190 вместо 200» и «добавь эти кластеры в очередь», и я ловил AI на косяках — где-то «стой, не делай force-recreate», где-то «слушай, а почему три тысячи каналов пустые».
И вот это для меня и есть настоящая разработка с помощью нейросети в 2026-м. Не «сделай за меня, а я пойду пить кофе», а плотный цикл: он делает, я проверяю и спорю, мы вместе выводим правило и идём дальше. AI-агенты тащат скорость и рутину, но без человека, который держит в голове цель и не верит зелёным галочкам на слово, оно красиво падает. Если вам это интересно как метод — про сам процесс работы с AI-агентами и про то как заставить их не халтурить у меня есть отдельный разбор в STC + Guardian MCP, а про похожую историю с дохнущими аккаунтами раньше я писал в MAKO неделя 1. А как вообще выживает автоматизация в Telegram под банами — это отдельный честный build-log, если интересно где аккаунты дохнут массово.
Цифры, чтобы было предметно
- 40902 канала в финальной очереди, собранной из четырёх кластеров
- 10 аккаунтов × 10 SOCKS5-прокси × 10 Docker-контейнеров, по контейнеру на аккаунт
- День 1: ~2200 каналов, ноль FloodWait
- День 2: ~2000 каналов и падение в FloodWait на ~200 на аккаунт
- День 3 и дальше: ~1850 в день стабильно, ноль FloodWait, при лимите 190 на аккаунт
- Реальный потолок Telegram: ~200 запросов за 24 часа на аккаунт, и это скользящее окно, а не календарные сутки
- К концу недели: 9923 из 40902, то есть 24 процента очереди
- Одна строка `if not has_comments` оставила 3747 каналов без части метаданных, пересчёт занял два дня
Что я из этого вынес
Первое и главное — про скользящее окно: если вы хоть раз будете дёргать чужой API лимитами, не верьте формулировке «N в сутки», а проверяйте руками, считается ли это от полуночи или откатом на 24 часа назад. Эта мелочь стоила нам двенадцати часов простоя всех десяти аккаунтов разом. Второе — прокси настраивается до первого коннекта, а не после, иначе весь смысл с новыми адресами обнуляется на самом старте, и это уже не починить, только ждать. Третье — к лимиту подходишь с запасом, чистый выход на 190 надёжнее чем ловить бан на 222 и потом сутки из него выбираться. И четвёртое, самое отрезвляющее: можно три дня героически воевать с rate limit и инфраструктурой, а реальный ущерб нанесёт одна непрочитанная строчка в коде — так что перечитывайте ветвления, особенно те, где `return` стоит раньше, чем кажется.
Это вообще не история про «скрипт для Telegram». Это про то, как на самом деле выглядит production у соло-разработчика, который собирает рабочую инфру через AI-агентов: технология даёт возможность, но пока не наступишь лбом на скользящее окно, на коннект без прокси, на race condition при ночном рестарте и на одну ленивую проверку — знать про это просто неоткуда. Три полных цикла «запустили, сломалось, починили, вывели правило» за одну неделю. Вот и делайте выводы.