104,729 messages in ~21 hours: how I automated promo in Telegram chat bots

The idea

Telegram has dozens of popular anonymous chat bots: you tap "Find a partner", and the bot connects you with a random stranger. The audience is big. In the November 3–4 run alone, the accounts found 99,180 chat partners in 14 bots.

The client sells a product through Telegram and wanted those people to hear about it in a conversation. By hand that's an endless loop: enter a bot, sign up, solve a captcha, subscribe to its sponsor channels, wait for a partner, say hello, mention the product, next. Anon Outreach runs the same loop on hundreds of accounts in parallel, day and night.

To be straight about what this is: automated promotional messaging to strangers in third-party bots. The greetings and the message are sent by software from the client's accounts, so the people on the other side are chatting with a program, and nobody asks for their consent. This kind of promotion can break the rules of individual bots and of Telegram, and accounts do get banned: some bots ban an account after one or two messages. The software records every ban, and from then on that account skips that bot.

The client wanted maximum reach at minimum cost with no paid ads, a program that runs unattended for days, easy adaptation to bots that all differ and keep changing, no wasted accounts, and honest numbers: where the messages actually went, not just how many went out.

What it does

Every account in the pool works through its list of bots one by one. In each bot it first enters: starts the bot, checks it isn't banned, signs up and subscribes to the sponsor channels the bot requires. That happens once. Then come the dialogs: find a partner, a short greeting, the client's message, the next partner. After a set number of messages the account moves to the next bot, and after the last one it goes to the back of the queue while the next account takes its slot.

What the software handles on its own:

• Sign-ups by buttons or typed text: gender, age, country, city, "room" or location, including bots that ask one question at a time.
• Sponsor subscriptions: public and private channels, join requests, chat folders and referral bots. A sponsor on an external website marks the bot unusable (the client's rule).
• The client's own accounts: if the partner turns out to be another of the client's accounts, the software recognizes it and doesn't spend a message on it.
• Cooldowns: when a bot says "you can't search right now", the account moves on to the next bot at once.

The live board

While a run is going, the console redraws a board every five seconds: what each account is doing and in which bot, plus the totals for messages sent, messages to the client's own accounts, cancelled ones, "reached people" and the running costs.

How it's used day to day

• Starting: the operator answers a few questions (which bots, what message, how many messages per bot, how many cycles, with 0 meaning endless) and can save the answers, so a run starts with one command.
• Scaling: how many accounts work at once is one number in the settings file, 70 in the November 3–4 run.
• Adding a bot: the operator fills in a file with that bot's rules and runs the onboarding check, which tests the bot automatically and returns a verdict. For step types the software already supports, that takes minutes and no code changes; a new kind of step means development.

The numbers

These numbers describe message volume and how the software runs, not sales. They don't show how many subscriptions the messages produced; that data isn't part of this case.

What it costs to run. Captcha-recognition services are the only thing the software pays for itself: the November 3–4 run came to about $0.47, and with headroom it stays at about $1 a day. The accounts and network infrastructure come from the client, who treats them as consumables, and the machine is his too — none of that is in the dollar.

Before tuning, recognition was expensive: $10–15 flew out in two days😅 After optimization those costs dropped 10–30×. When a service's balance runs out, the software stops calling it and moves the accounts to other bots instead of spinning in place.

For scale: by my rough estimate, a person doing this by hand gets through 40–60 partners an hour, while the software sent about 3,300 messages an hour at a steady pace. That's a throughput comparison, not a measured staffing saving.

Sent isn't reached

Counting messages sent is easy, and the number flatters. In smaller bots, the client's accounts sometimes land on each other, and a message to one of your own accounts reaches nobody.

So the board subtracts those meetings: messages that went to another of the client's accounts (12,330 in the November 3–4 run) and own-account meetings the software caught in advance and cancelled (15,440). The arithmetic is right there on the board: 72,862 − 12,330 − 15,440 = 45,092, or 62%. The client watches that share during the run instead of finding out afterwards.

The board calls those 45,092 "reached people", but it's an operational counter: it shows that a message went to a partner who isn't one of the client's accounts. It doesn't show whether anyone read the message or how many different people got one.

The logs give per-bot numbers too: in the November 3–4 run, five of the 14 bots carried about 80% of the messages, while bots that often ban accounts for advertising produced far fewer. So adding or dropping a bot is a decision based on data. By the way, delivery was checked as well: in a September test pass, 17 accounts sent 540 messages in 14 bots over 1 hour 20 minutes, and the logs showed all 540 delivered.

Tuned on real runs

The software got to production quality through 24-hour runs, not by eye. The test runs of September 2–4 checked 34 bots: 17 worked cleanly, 4 banned an account after one or two messages, and 4 were unusable. The first 24-hour run, on September 4–5 with 1,019 accounts, 22 bots and 49,443 messages, turned up 14 defects.

After each run I went through all the logs (up to 1,019 files and 374 MB per run), read sampled accounts line by line and re-checked the findings live in the bots. Every fix from a live run got a regression test to lower the risk of the same bug coming back. Over the autumn that added up to more than 60 fixes, and the test suite grew from 354 to 429.

Three things the loop caught:

• A false ban. A Telegram Premium promo message was read as a ban, which cost about 1,550 sessions in one run.
• A silent outage. The whole proxy pool went down, and the software kept churning through the queue without noticing. Now it raises an alert and backs off with growing pauses.
• A slow greeting. It took 36.8 seconds from "partner found" to the message, and tens of thousands of partners left before it arrived. A shorter greeting brought that down to about 12 seconds.

Who this is for

• Products sold through Telegram that want an automated channel for their message and want to see where the messages actually went.
• Teams already doing multi-account Telegram work by hand or with fragile scripts, who need it to run unattended for days and report honestly.
• Scenarios that span many third-party bots that differ and keep changing, where a new bot or step should be a setting, not a code change.

The same foundation can be adapted to other long-running Telegram scenarios — large test runs against your own bots, for example.

Engineering details

Engineering details

A new bot is a file, not code

Each bot is described by a YAML profile: trigger phrases, sign-up steps, captchas, and the commands to search and to leave a dialog. Common phrases live in one defaults file, and a profile adds only what's specific to its bot. A sign-up is a list of steps: when the bot says this, press this button or send this text.

In plain terms, the routine is the same everywhere, and each bot's quirks live on a separate card that the software reads. When a bot changes its wording, adds a sign-up question or switches sponsors, the fix is usually an edit to its profile. A new bot is a new file plus an automatic test run that ends with a verdict. There are 38 profiles today, loaded into typed Pydantic models, so a malformed profile is caught at load time.

A rolling pool, one guard and an event bus

All the accounts in the pool work concurrently on asyncio. The orchestrator keeps a fixed number of slots on a semaphore (70 in the November 3–4 run), and when an account finishes its bot list, the next account in the queue takes its slot right away. No batch waits for its slowest member.

A chat bot can throw a captcha, a ban notice or "you're already in the queue" at almost any moment. The old version called the checks for captchas, bans, sign-up and the queue three or four times each, in different places of the scenario. In 4.0, one guard (middleware) sits in front of every important step and handles each case in one place, and a failure in one check doesn't break the others.

Services publish events on an event bus (status changed, message sent, banned in a bot, two of the client's accounts met), and the live board, the journals and the ban database subscribe; a web dashboard would simply be one more subscriber. Accounts, proxies and profiles sit behind repository interfaces, ready to move from files to a database.

Reliability and tests

• Account health: fatal states (blocked, frozen, a dead session, a revoked token) each lead to their own action instead of endless retries. Accounts blocked by Telegram move to a separate ban/ folder, and bans.db stores which account is banned in which bot.
• Budget guard: captcha service balances are on the board, and a service whose balance runs out stops being called.
• 429 automated tests (pytest): about 7,700 lines of tests for about 9,000 lines of code, linted with ruff, with a regression test for every fix from a live run and 24-hour production-scale runs as the final check.

Data and privacy

• Accounts, proxies, bot profiles and the message belong to the client and load from local files. The greetings and the message are prepared in advance; no AI writes them, and outside services receive only the captchas themselves.
• Journals also contain incoming messages from bots and partners; none of that text appears in this case. bans.db holds only which account is banned in which bot.
• In every image here, bot names are hidden, account numbers and proxy addresses are masked, and message texts aren't shown.

Tech stack

Layer	Technology
Runtime	Python 3.11, asyncio
Telegram	Telethon (MTProto)
Models and configuration	Pydantic v2; YAML: app.yaml plus 38 bot profiles over shared defaults
Storage	Files behind repository protocols; SQLite for ban tracking
Network and images	aiohttp, Pillow
Captchas	External recognition services; the cost of every captcha is logged, and balances show on the board
Quality	pytest (429 tests), ruff
Interface	A console launcher and an ASCII live board

About 9,000 lines of code, 7,700 lines of tests and 38 YAML bot profiles.