Telegram Member Adder Tools Compared on Ban Rate and Retention

You have found four tools that all claim to add members to your Telegram group. Their landing pages compare features: scraping speed, proxy support, multi-account, GUI. None of them publish the two numbers you would actually use to choose.

Those numbers are how many of the added members are still there after 30 days, and how many of your operator accounts get spam-limited getting them there. Everything else is packaging.

The two metrics, defined precisely

30-day retention. Count the group on the day the run finishes. Count it again 30 days later, subtracting any organic joins in between. Divide. Anything above 80% is genuinely good; 50-70% is the realistic middle; below 40% means you paid for account churn.

Burn rate. Operator accounts permanently spam-limited per 1,000 successful adds. This is the number that decides whether self-serve is cheaper than done-for-you, because every burned account is a phone number, a warm-up period, and a proxy you have to replace. A tool running at 12 burned accounts per 1,000 adds turns a 10,000-add campaign into 120 replacement numbers, on top of whatever you needed to run it in the first place.

You cannot get either number from a sales page. You can get both from a 500-add pilot, which is the entire recommendation of this article.

Why the Bot API cannot do this at all

Worth settling before you evaluate anything, because it explains the shape of the whole tool market.

Telegram's Bot API has no method for adding a user to a chat. A bot can create invite links, ban and unban, and approve join requests - but it cannot reach into a user's account and place them in your group. That is deliberate.

So every member adder is built on the MTProto client API instead, driving real user accounts. That single fact produces all the risk in this category: you are operating logged-in user sessions at machine speed, and Telegram's anti-abuse systems are built to notice exactly that. Any tool marketed as a "bot" that adds members is a user-account driver with a friendlier name.

The tool categories, and what each actually costs

Category	Examples	Typical 30-day retention	Operator burn per 1,000 adds	Real cost driver
MTProto libraries, self-coded	Telethon, Pyrogram, GramJS, TDLib	55 - 80%	0.5 - 3 accounts	Your time + accounts + proxies
Desktop adder software	Windows GUI tools sold on forums	30 - 60%	3 - 12 accounts	Licence + heavy account churn
SMM panel reseller APIs	Generic "Telegram members" endpoints	15 - 40%	0 (theirs, not yours)	Retention loss
Managed delivery service	Done-for-you, per-order	75 - 90%	0	Per-1,000 price

Retention ranges are wide because they depend far more on where the members came from than on which tool moved them. A perfectly written Telethon script pulling from a dead group full of recycled accounts will underperform a mediocre GUI tool pulling from an active, topical one.

MTProto libraries: the honest option

Telethon and Pyrogram in Python, GramJS in Node, TDLib if you want the official C++ client library. All free, all well documented, all give you exact control over pacing - which is the single biggest lever on both metrics.

What you get: you decide the delay between adds, you handle FLOOD_WAIT_X by sleeping the full requested duration instead of retrying, you back off immediately on PEER_FLOOD rather than grinding the account into a limit, and you skip USER_PRIVACY_RESTRICTED targets without treating them as failures to retry.

What you also get: the entire account supply problem. You need aged accounts on real numbers, one residential proxy per account, a warm-up routine so a fresh session does not start by adding forty strangers, and somewhere to store session files safely. That is the actual project. The script is an afternoon.

Desktop adders: paying for someone else's pacing decisions

These sell on convenience - load your session files, paste a source group, click start. The problem is that their defaults are tuned to make the demo look fast, and fast is what burns accounts. Several popular ones retry PEER_FLOOD immediately, which converts a temporary throttle into a permanent limit.

If you use one, the first thing to check is whether you can set the inter-add delay and the daily per-account cap yourself. If those are hard-coded or hidden, the tool is choosing your burn rate for you.

SMM panels: cheap because retention is not their problem

You send an order over an API, members appear, you have no visibility into source or method. Retention in this tier is the worst in the market for a structural reason: the accounts are shared across many buyers' orders and frequently recycled out to fill the next one. The "refill" feature that panels advertise exists because drops are expected.

Worked example: 10,000 members, self-serve versus managed

A group at 1,500 members wants 10,000 more, sourced from four topical public groups.

Self-serve with Telethon. Assume 0.6 accounts burned per 1,000 adds - the good end of the library row, and deliberately generous to the DIY case.

• Adds attempted: you will not land 10,000 from 10,000 attempts. Expect roughly 35% of targets to fail on privacy settings, already-a-member, or the 500-group ceiling. So ~15,400 attempts.
• Operator accounts burned: 15,400 attempts at 0.6 per 1,000 is about 9 accounts gone. Concurrency costs more than the burn does - 15,400 attempts across five weeks is 440 a day, and at a conservative 25 adds per account per day that needs 18 accounts live at any moment. Add the losses and you are sourcing 27 over the campaign.
• Account cost: aged accounts on real numbers vary a lot by market. Take a mid-range assumption of $4 each, clearly an assumption - $108.
• Residential proxies: one per account, roughly $2-4 per month per IP at small volume, over a campaign that runs into a second billing month - call it $95.
• Your time: writing the runner, handling flood waits, warm-up, monitoring, restarts. 15-25 hours honestly, plus the days you notice the run stopped six hours ago.
• Retention at 70%: 7,000 members kept.

Cash out of pocket: about $205. Effective cost per kept thousand: $29. Genuinely cheap - if your time is free and you enjoy this.

Managed delivery. Ten thousand members clears the volume step at 10,000, so the rate is $56 per 1,000: $560 for 10,000 delivered, paced across five weeks, sourced from the same four groups. At 85% retention that is 8,500 kept, $65.90 per kept thousand, and zero accounts of yours at risk because none of your accounts are involved.

The self-serve route is not quite 3× cheaper in cash and costs you 20 hours plus an account-sourcing pipeline you now have to maintain. That is a real trade and the answer depends entirely on how you value the 20 hours. If this is one campaign, buy it. If it is your ongoing job across a portfolio of groups, build it.

Where the trade stops being close is targeting quality and scale. Above about 25,000 members the concurrency requirement pushes you into managing 40+ live accounts, and account management becomes a job rather than a task.

Where the middle ground actually is

If you want the sourcing control of the DIY route without the account pipeline, the model that fits is naming the source groups and letting someone else run the sessions. That is what TeleReach does - you list up to ten public groups your audience already sits in, or take our US online-shopper audience if picking sources is the part you don't want, and delivery is paced across a schedule rather than dumped. $60 per 1,000, $56 at 10,000, $52 at 50,000. You keep the targeting decision; you skip the proxy bill and the burned accounts.

What usually goes wrong

Retrying on PEER_FLOOD. This is the number one cause of permanent limits. PEER_FLOOD means stop, not slow down. Any tool or script that treats it as retryable will destroy your account pool in a day.

Ignoring the sleep duration in FLOOD_WAIT_X. The error tells you exactly how many seconds to wait. Sleeping less and trying again is read as evasion.

Scraping a source group that is already saturated. If you have run three campaigns against the same group, most of its members are already in yours. Your attempt-to-success ratio collapses and every failed add still counts against the operator account.

Running fresh accounts. An account registered an hour ago that immediately adds thirty strangers is the clearest possible signal. Warm-up is boring and it is most of the difference between burning one account per 1,000 adds and burning eight.

One proxy for ten accounts. Session origin correlation is cheap for Telegram to compute and expensive for you to fix afterwards. One IP per account, residential, stable.

Measuring success on the day the run ends. The run always looks successful on day zero. Snapshot and re-count at day 30 or you are grading your own homework.

Assuming a working setup stays working. Anti-abuse thresholds move without announcement. A configuration that ran clean for three months can start burning accounts in a week, and the only way you find out is by watching burn rate per batch.

Next step

Before committing to either route, run a 500-add pilot with whatever tool you are considering and record two numbers: successful adds, and operator accounts limited. Re-count the group on day 30. Those three data points give you a real cost-per-kept-member for your specific niche and source groups, which no comparison table - including this one - can give you. If the pilot tells you the account pipeline is not worth building, place a paced order with your source groups named and put the 20 hours somewhere else.