Telegram Scripts on GitHub: What the Free Repo Costs

Search for a Telegram automation tool and you will find a repository before you find a price. It is free, the code is right there, and somebody has already written the thing you were about to pay for. That is a reasonable place to start, and this article is not an argument against starting there. It is an account of what the repository does not tell you, checked against the platform's own documentation and against the two libraries that nearly every one of those repositories imports.

The short version, and every part of it is checkable in a browser: the two Python libraries that almost all of this code depends on are archived on GitHub. The package one of them installs from has not had a release since 2023. The newest release of the other one broke our production this month and we had to pin backwards. The api_id baked into a public repository is poisoned by design, and Telegram says so on its own page. And the account you log in with is placed under observation the moment an unofficial client touches it, which is also Telegram's own wording, not ours.

None of that makes the free script useless. It changes what the word free is measuring. Below, every platform claim is quoted from Telegram's documentation or read from GitHub and PyPI on the day of writing. Where a number is ours, measured on accounts we run, the text says so.

The two libraries under almost every free script are archived

Open a handful of Telegram automation repositories and the import list converges fast. Either telethon or pyrogram is at the top of the file. These are the two libraries that speak Telegram's user protocol from Python, and between them they carry the overwhelming majority of the community's automation code. Everything else in a typical repository is a thin wrapper: a loop, a text file of targets, a sleep call.

Both are archived.

What archived means on GitHub

An archived repository is read only. Nobody can open an issue, nobody can submit a pull request, and the maintainers have signalled that they are not accepting work. The code stays visible and clonable forever, which is exactly why it keeps turning up in search results long after it stopped being maintained. Archiving is not deletion. It is a public statement that the project has stopped, printed in a banner most people scroll past.

The numbers, read from GitHub on the day of writing

Pyrogram is archived. Its last push was on 23 December 2024. It carries 4,621 stars and 279 open issues, all of them now frozen in place, because an archived repository cannot accept a fix for any of them.

Telethon is archived. Its last push was on 21 February 2026. It carries 12,064 stars. Its open issue count is one, which reads like health until you notice that the number is one because the tracker is closed rather than because the problems were solved.

Twelve thousand stars is the number a person sees. Archived is the word they do not read. Both facts sit on the same page.

Why this is not the usual open source scare story

Plenty of good software is finished software, and an archived repository can still be perfectly serviceable for a year or five. The problem here is specific. These libraries do not implement a stable file format or a mathematical function. They implement a private, undocumented, moving protocol belonging to a company that changes it without consulting anybody. A parser for that protocol is not a thing that can be finished. It is a thing that decays at exactly the rate the other side chooses.

The package you install is not the repository you read

There is a second gap, and it is the one that catches people who did check the repository. Reading the code on GitHub and installing the package from PyPI are two different acts, and the two artefacts can be years apart.

Pyrogram's last release predates its own archiving by nearly two years

The version of pyrogram published on PyPI is 2.0.106, uploaded on 30 April 2023. The repository was archived on 23 December 2024. So there is a stretch of roughly twenty months during which the project was still technically alive, still receiving commits, and still shipping nothing. Anyone who ran the install command in that window got 2023 code regardless of what the repository showed them.

At the time of writing, that release is over three years old and it is still what the plain install command gives you.

The community moved, and it moved sideways

What actually happened is what usually happens: people forked. Two forks have real activity. One publishes as pyrofork, most recently on 10 December 2025. Another publishes as kurigram, most recently on 11 July 2026. Both keep the original import name, which is the practical detail. Your code still says import pyrogram, but the package supplying that name is now maintained by a different group under a different name on the index.

This is a sensible community response and it is also a trap for anyone copying a repository. The script you cloned lists pyrogram in its requirements. Installed literally, that gets you the frozen 2023 release. Installed the way the fork's readers do it, you get code from a project the original author never reviewed. Neither is wrong. They are just not the same thing, and the repository you copied says nothing about which one it wants.

Telethon still ships, and that is where our own story starts

Telethon is the healthier of the two on paper. Its latest release is 1.44.0, published on 15 June 2026, three and a half months after the repository was archived. Releases continuing past an archive is unusual and it is worth knowing about, because it means the archive banner alone is a bad signal in both directions.

Our own measurement: the newest release broke us

This is our number, from our accounts, on the day of writing.

We run long lived sessions against the user protocol. Earlier this month our workers began raising a constructor parse failure roughly every five seconds. The library was receiving an object from Telegram's servers that it did not recognise and could not decode, and because the failure landed in the connection path, everything downstream of it stopped: the pollers stopped polling, the accounts sat connected but deaf. From the outside the service looked fine. The health endpoint answered. Nothing was being processed.

The version in production was 1.44.0, the newest release. We installed 1.43.0 locally against the same accounts and the same server objects and it decoded them without complaint. We pinned production backwards to 1.43.0 and the error count went to zero.

What that episode is actually evidence of

It is not evidence that the library is bad. Telethon is a serious piece of engineering and twelve thousand people did not star it by accident. It is evidence of something narrower and more useful: on a moving private protocol, the newest release is not automatically the working one, and the project that would normally have absorbed a report like ours is closed to reports. We could not open an issue. There was nowhere to send the payload that failed. The only available action was to pin backwards and write down what we saw.

A free script does not come with that reflex. It comes with an unpinned requirements file, which means it installs whatever is newest on the day you run it, which means it will one day install the version that does not work with your accounts and you will have no idea why the loop went quiet.

The cheapest lesson in this whole article

Pin your versions. If a repository's requirements file lists bare package names with no version numbers, that file is a statement that nobody is testing this against a specific build. Add the numbers yourself, write down the date you tested them, and treat a version bump as a change that needs verifying rather than a chore.

The api_id in a public repository is poisoned by design

Every user protocol client needs an api_id and an api_hash. You get them by filling in a form at Telegram's own developer page while logged into your account. This is where the free repository has a problem it cannot solve, and Telegram spells it out.

Telegram's wording, quoted

On the page describing how to obtain those credentials, Telegram states plainly: "For the moment each number can only have one api_id connected to it." One phone number, one credential pair. There is no bulk issuance and no way to mint a fresh pair per project.

The same page describes what happens to shared credentials. Applications built on open source code that ship with the sample api_id run into an error named API_ID_PUBLISHED_FLOOD, and developers are told to obtain their own api_id before releasing anything publicly.

What that means when you clone somebody's script

If a repository ships with working credentials in it, those credentials are public. Public credentials get used by everybody who cloned the repository, which means they accumulate the flood behaviour of every one of those people. By the time you arrive, the pair may already be carrying months of other people's mistakes. The error name exists precisely because this happens often enough to deserve one.

And if the repository does the responsible thing and leaves the credentials blank, then the first thing you must do is register your own, tied to a real phone number, which is one more real thing you have put on the table before the free script sends a single message.

Logging in with an unofficial client puts the account under observation

This is the sentence most people never read, and it is on the same page as the credentials form. Telegram writes: "All accounts that log in using unofficial Telegram API clients are automatically put under observation to avoid violations of the Terms of Service."

Read that carefully, because it is more specific than the folklore. It does not say that unofficial clients are banned. It says that using one changes your account's status from ordinary to watched, automatically, from the first login. Nothing has to go wrong for this to happen. It is the default condition of every account any of these scripts touches, including yours, including ours.

Why the distinction matters for what you build

If observation is the baseline, then the interesting question is never whether you are being looked at. You are. The question is what the thing looking at you sees: a pace that resembles a person, or a pace that resembles a loop. Almost everything that matters in this field follows from that reframing, and none of it is in the free script, because a loop is precisely what the free script is.

The published penalty is not a warning, it is a permanent ban

Telegram's wording again, verbatim from the same page: "If you use the Telegram API for flooding, spamming, faking subscriber and view counters of channels, you will be banned forever."

There is no graduated language in that sentence. No suspension, no cooling off period, no appeal described in the same breath. Elsewhere the documentation does mention that an account banned despite good faith use can write to a recovery address with an explanation of the intended use, so the door is not literally welded shut. But the stated default is permanent, and a recovery request is a letter you write after your account is already gone.

The part people misread

Notice what the sentence lists. Flooding, spamming, and faking counters. It does not list automation. Telegram publishes the protocol, hands out credentials through a form, and maintains a client library of its own. The prohibited thing is a pattern of behaviour, not the act of writing code. That distinction is the entire margin anybody operates in, and it is worth being precise about rather than pretending the rule says something softer than it does.

The error the free script never handles

Open a free automation script and search it for the string FLOOD. In most of them you will find nothing, or you will find a bare try block that swallows every exception and continues the loop. This is the single most consequential omission in the category.

What Telegram actually sends you

Telegram's error documentation defines error code 420 as the flood class, described as the maximum allowed number of attempts to invoke a given method with given parameters having been exceeded. The specific error is FLOOD_WAIT_X, documented as "A wait of X seconds is required (where X is a number)".

That is not a failure. It is an instruction. The server has told you exactly how long to stop for, in seconds, in a machine readable field. A client that reads the number and honours it is behaving the way the protocol expects. A client that catches the exception and retries immediately is telling the observation system that it did not understand a clear instruction, repeatedly, which is a very legible signal.

A newer variant worth knowing about

The same documentation now also describes FLOOD_PREMIUM_WAIT variants, where a Telegram Premium subscription waives the limitation. That is a real and current detail with an obvious implication: some of the limits people describe as fixed platform physics are actually tied to account status, and a script written before that existed will treat every wait as identical when they are not.

What handling it properly looks like

Read the seconds from the error. Sleep for that long plus a margin. Do not retry the same call in a tight loop. Track how often a given account is receiving waits at all, because a rising rate is the early signal that something upstream is wrong, and treat that rate as a first class metric rather than a log line nobody reads. None of this is difficult. All of it is missing from the typical repository, because the person who wrote the repository was demonstrating that the protocol can be spoken, not operating anything.

The session is not a file you can copy

Here is a mistake with a distinctive fingerprint, and we have paid for it ourselves.

What the documentation says

Telegram's error reference lists AUTH_KEY_DUPLICATED under the 406 class, and explains that it is emitted when an authorised session sends requests in parallel from multiple TCP connections. In plain terms: the same authorisation, used from two places at once, invalidates itself.

What that looks like in practice

An authorised session is stored as a file, or as a string, and it looks exactly like a thing you can back up and copy. So people do. They copy it to a second machine to run the script from two places, or they hand a copy to somebody else to test with, or they restore an old backup alongside a running instance. The result is not a warning. The authorisation dies, and the account behind it needs a fresh login it may not survive.

We have watched this happen to an account we owned. A set of session files was shared with an outside team for a trial. A read only check of the active authorisations afterwards showed two of the three accounts holding only our own session, and the third returning a duplicated authorisation key error: the same session live from two addresses at once, which is to say dead. That account was not recoverable in any useful sense, and no error in the script that was using it ever said the word session.

The rule that follows

One session, one running process, one place. If you need a second worker, you need a second authorisation, which means a second number, which means a second real cost. This is one of the clearest examples of the pattern this whole article is about: the free script hides a constraint that is not technical but economic, and you meet it the first time you try to scale past one machine.

Bot protocol or user protocol: which one the repository is using

Telegram has two entirely different programmable surfaces, and a repository rarely announces which one it sits on. Everything about your risk depends on the answer.

The bot protocol

A bot is a separate account with a username ending in bot, created through Telegram's own bot registration flow, and it speaks a documented HTTP interface. It is fully sanctioned. It also cannot start a conversation with anybody: a person has to write to it first. That single rule is why bot based tools are safe and why they cannot do outreach.

The user protocol

The user protocol is the one real clients speak. Code that logs in as a person can do the things a person can do, which is why every outreach script in the category lives here. It is also the surface the observation sentence applies to, the surface the permanent ban sentence applies to, and the surface where both archived libraries operate.

How to tell in ten seconds

Look at the imports and the credentials. If the script wants a token that looks like a long colon separated string handed out by a registration bot, it is on the bot protocol and its reach is limited to people who contacted it. If it wants an api_id, an api_hash and a phone number, it is logging in as a human being and everything in this article applies. Repositories that describe themselves as a bot while asking for a phone number are on the user protocol, whatever the readme calls them.

The one that is not archived

There is a third option and it deserves a mention in fairness, because the picture is not uniformly bleak. Telegram maintains its own client library. Its repository is not archived, it was pushed to on 17 July 2026, and it carries 9,006 stars. It is written in a compiled language rather than Python, which is why the casual scripting community mostly ignored it, and it is the reference implementation from the party that controls the protocol.

Wrappers exist to make it usable from Python, and one of them published as recently as 29 June 2026. If you are choosing a foundation today rather than inheriting one, the difference between a library the platform maintains and a library the platform's community abandoned is the most important variable on the table, and it is worth the extra difficulty.

What the repository does not ship

This is the honest inventory. None of these are exotic. All of them are the difference between a demonstration and something that runs.

Per account network identity

A script with one machine and ten authorisations puts ten identities behind one address. Whatever else that pattern resembles, it does not resemble ten people. Solving it means a network path per account, which means a recurring bill and a configuration surface, and it is essentially never in the repository.

Pacing that is not a sleep call

A fixed delay between actions is the signature of a loop, because people are not periodic. Real pacing varies, respects the server's own wait instructions, backs off when a particular account starts receiving them, and differs across accounts rather than moving them in lockstep.

State that survives a restart

Free scripts hold their progress in memory. Restart the process and it either repeats work or loses it. We have made this exact mistake in our own code and it is not theoretical: a polling loop that keeps what it has seen only in memory will, after a restart, treat the newest message already sitting at the top of a conversation as brand new and answer something that was answered days ago. Persist what you have done, and make the first pass after a start observe rather than act.

Duplicate protection when there are two paths in

The moment you have a live update stream and a polling fallback, you have two roads to the same event, and both will one day arrive. If nothing marks an event as handled by account, chat and identifier, the same message gets processed twice. We shipped that bug and a real person received the same greeting twice before we caught it. A backup path is not free; it brings duplication with it and duplication has to be designed for.

Anything at all to look at

The most expensive gap is the smallest one. When a free script goes quiet you have no counters, no per account state, no error taxonomy, nothing to look at. We spent an hour hunting a fault in the wrong layer once, when the answer was one line in the service log the whole time. Logs are what a running thing has that a demonstration does not.

The maintenance bill nobody quotes

Add up what is actually being asked of you when you adopt a free script on this protocol.

You inherit two archived dependencies whose upstreams cannot accept a fix. You inherit an unpinned requirements file that will silently install a version that does not work. You take on registering credentials against a real number, one pair per number. You take on the network layer per account. You take on pacing, persistence, duplicate protection and error handling, all of which are absent. And you take on the diagnosis of every failure yourself, with no issue tracker to report to and no release cadence to wait for.

That is not a criticism of the people who published the code. They published a demonstration, honestly labelled as one, usually as a weekend project, and they owe nobody a maintenance commitment. The distortion happens later, when a search result presents that demonstration as an alternative to a product.

When the free script is the right answer

There is a real answer here and it is not always buy something.

If you want to understand the protocol, clone the repository. Reading working code that speaks a private protocol is genuinely the fastest way to learn it, and no article substitutes for that. If you have a one time job with a fixed end, on one account you can afford to lose, and you will be watching the terminal while it runs, the free script is exactly the right size of tool. If you are a developer who is going to own the code anyway, starting from a fork with an active maintainer and pinning it is a perfectly sound decision.

The free script is the wrong answer in one specific case: when it is being used as an unattended production system by somebody who cannot debug it. That is the case where all of the hidden costs above arrive at once, usually on the day something changes on the other side, and usually with no logs to explain it.

How to read a repository before you run it

A short and entirely mechanical checklist. All of it can be done in a browser in about five minutes.

Check whether the repository is archived

The banner is at the top of the page. If it is there, the project accepts no fixes. Check the parent library it imports as well, because that is where the archive that matters usually is.

Check the last commit date, not the star count

Stars measure how many people liked the idea, and they never go down. The date of the last push measures whether anybody is still there.

Check what the package index actually serves

Look up each dependency on the index and read the upload date of the current version. If the newest release is years older than the newest commit, the code you read and the code you install are different code.

Check whether versions are pinned

Bare names in a requirements file mean whatever is newest on the day you install, tested by nobody.

Search the source for the flood error

If the string does not appear, the script does not read the server's own wait instruction. That is the fastest single test of whether the author operated the thing or only demonstrated it.

Search for hard coded credentials

If an api_id is committed in the source, it is public, shared, and already carrying strangers' behaviour.

Read the issue tracker before the readme

If it is open, the last few issues will tell you what breaks in practice far more honestly than the feature list. If it is closed, that is your answer.

What we do differently, plainly

We are not neutral, so here is the disclosure in one paragraph rather than smuggled through the article. We sell Telegram software. That is why we run these accounts, and it is why we had a production incident with a library version this month and had to fix it rather than shrug.

The parts of our answer that are actually relevant to a reader are the ones this article has been describing all along. Versions are pinned, and a bump is a change we verify rather than absorb. There is a network path per account. Progress is written down rather than held in memory, and the first pass after a restart observes instead of acting. Events are marked handled so two intake paths cannot double process. The server's wait instruction is read and obeyed. And there are counters and logs, so that when something does go quiet, the answer is a line we can read rather than an hour of guessing.

You can build all of that yourself on top of a fork. Plenty of people should. The point of the list is that it is the actual scope of the work, and none of it is what you were comparing when you compared a price to zero.

The honest summary

Free, on this protocol, means the code costs nothing and the operating costs are unlisted. The libraries are archived, the packages lag the repositories, the credentials are single issue and per number, the account is observed from the first login, the published penalty is permanent, and the errors that keep you inside the lines are the ones the script does not read.

Start with the repository if you want to learn. Take the checklist above before you run anything against an account you care about. And when you compare a paid tool to a free one, compare the two lists of work rather than the two prices, because that is the comparison that turns out to be true a month later.

The five repositories you will actually find

Search results in this category are not varied. Five archetypes cover almost everything, and each one fails in a way specific to what it is trying to do. Knowing which one you are looking at tells you where to look for the hole.

The member adder

Reads a list of usernames and invites them into a group. It fails on a rule that is not in the code: the people who can be added are the people whose privacy settings permit it, and that is a minority of any list. The script does not distinguish between a person who declined the invitation and a person the platform refused to invite, so its success counter is measuring two different things and reporting one number. Add the refusal reasons to the output and the same script becomes twice as informative, which tells you how little was there.

The scraper

Pulls a member list out of a chat. The hole here is a hard boundary rather than a bug. A channel's subscriber list is not visible to members, so it cannot be read, and a script pointed at a channel returns an administrator privileges error rather than a list. Groups with open participant lists are readable. A large number of repositories in this family do not explain that difference anywhere, and the reader concludes their setup is broken when the answer is that they aimed at the wrong object type.

The mass sender

The archetype this whole article is really about. Reads a list, sends the same text to everybody, sleeps a fixed number of seconds. Every hidden cost above lands on this one at once: identical text, periodic timing, one network path, no wait handling, no state. It is also the archetype most likely to be run unattended by somebody who cannot debug it, which is the exact combination that produces a dead account and no explanation.

The auto forwarder

Mirrors posts from one place into another. Usually works, and usually keeps working, because it is reactive rather than initiating. The problems are content problems rather than platform problems: the source protects its content and copying is blocked, or the copy carries a link the destination should not be publishing. Of the five, this is the one where a free script most often is genuinely sufficient.

The userbot

A general purpose command layer bolted onto a personal account, usually with dozens of plugins. The hazard is breadth. A single project holds a large surface of half tested modules, any one of which can act on your account, and it is running on the protocol where the observation sentence applies. People install these for one feature and inherit forty.

What changed in 2026, and why older repositories are wrong about it

Two things moved this year that quietly invalidate advice written before them, and repositories are the slowest medium to update because nobody rewrites a readme they stopped maintaining.

Automation on a personal account is no longer forbidden by architecture

For years the honest answer to "can my own account reply automatically" was no, and the workaround was the user protocol, with all of the exposure that implies. In May 2026 Telegram shipped a setting that connects a bot to a personal profile and lets it answer on the account's behalf, inside limits the platform publishes. That does not replace outreach tooling, because a connected bot still cannot start conversations. It does mean that a whole class of things people used to reach for the user protocol to accomplish now have a sanctioned route, and any repository whose readme says your own account cannot be automated is describing the world before that date.

Some limits are now tied to account status rather than being fixed

The appearance of premium specific wait variants in the error documentation is small in print and large in consequence. It means the wait a given account receives is not purely a property of the action; it is partly a property of the account. A script written before that change treats every wait as the same object, and a person reading its comments will form a mental model of fixed platform physics that is no longer accurate.

Comparing the two lists rather than the two prices

The comparison people make is a price against zero. The comparison that turns out to be true is a list against a list.

What the free path actually asks for

Registering credentials against a real number, one pair per number. A network path per account, which is a recurring bill. Writing pacing, persistence, duplicate protection and wait handling, none of which the repository contains. Pinning and testing versions of two archived libraries. Diagnosing every failure with no upstream to ask. And keeping all of that current against a protocol that changes when the other side decides it does, not when you have time.

What it is worth being honest about

We have not measured the hours. Anybody who quotes you a precise figure for how long this takes is guessing, and we are not going to add another invented number to a field that already has too many. What we can say from our own operation is narrower and true: this month a single dependency version cost us a production outage that looked, from the outside, like nothing was wrong at all. That failure mode is the reason the list matters. The costs in it are not the ones you notice while you are deciding. They are the ones you notice on the day the loop goes quiet.

Frequently Asked Questions

Is it illegal to use a Telegram automation script from GitHub?

Legality and platform rules are different questions and only the second one is answerable here. Telegram publishes the protocol, hands out credentials through a form and maintains its own client library, so writing code against it is expressly provided for. What the documentation prohibits is a pattern: flooding, spamming and faking counters, for which the stated penalty is a permanent ban. Running a script is not the prohibited thing. Behaving like a flood is.

Why is Telethon archived if it still has releases?

Both facts are true at once and they are worth separating. The repository was archived, with its last push on 21 February 2026, and its latest package release is 1.44.0 from 15 June 2026. An archive closes the issue tracker and pull requests; it does not prevent a maintainer from publishing. The practical consequence is that you can still install new versions but you cannot report what they break, which is exactly the position we found ourselves in this month.

Should I use Pyrogram or one of its forks?

The original package on the index is version 2.0.106 from 30 April 2023 and the repository was archived on 23 December 2024. The active work is in forks that keep the same import name, published as pyrofork most recently on 10 December 2025 and kurigram most recently on 11 July 2026. If you inherit a script that lists the original, installing it literally gives you 2023 code. Decide deliberately which one you want and pin it, rather than letting the requirements file decide silently.

What is API_ID_PUBLISHED_FLOOD?

It is the error Telegram describes for applications that ship using a published sample api_id rather than their own. The documentation instructs developers to obtain their own credentials before releasing anything publicly. In practical terms it is what happens when a credential pair is shared by everybody who cloned the same repository, and it is the reason hard coded credentials in a public project are worthless the moment they work.

Can I use one api_id across several accounts?

Telegram's own page states that for the moment each number can only have one api_id connected to it. The credential is tied to the number you registered it with. This is one of the constraints that makes the free path more expensive than it looks, because scaling past one account is not a code change, it is a procurement problem.

Does logging in with a script get my account banned?

Not by itself, according to the documentation, but it does change your status. Telegram states that all accounts logging in through unofficial clients are automatically put under observation to avoid violations of the terms. That is the baseline condition rather than a punishment. What determines the outcome afterwards is the pattern of behaviour the observation sees.

What should a script do when it receives a flood wait?

Read the number of seconds out of the error and wait that long, with a margin, before trying anything else on that account. The documentation defines the error as requiring a wait of a stated number of seconds, so the instruction is explicit and machine readable. Catching the exception and retrying immediately is the worst available response, and it is the response most free scripts implement by accident through a broad exception handler.

Why did my session stop working after I copied it to another machine?

Because an authorisation used from two places at once invalidates itself. The error documentation lists a duplicated authorisation key case, emitted when an authorised session sends requests in parallel over multiple connections. Session files look copyable and are not. One session, one running process.

Can a free bot script send the first message to someone?

Not if it is a bot in Telegram's sense. A bot can only reply to people who have written to it first, which is a platform rule rather than a limitation of any particular script. Anything that opens conversations is logging in as a user account, whatever the project calls itself, and every consideration in this article applies to it.

Is there a maintained library I can build on?

Telegram maintains its own client library, and unlike the two Python libraries above its repository is not archived; it was pushed to on 17 July 2026. It is a compiled library rather than a Python package, which is why the casual scripting community mostly passed it over, and there are wrappers that expose it to Python, one of which published on 29 June 2026. If you are choosing a foundation rather than inheriting one, that is the difference between a maintainer who controls the protocol and one who has stopped.

How can I tell whether a repository was ever actually operated?

Search the source for the flood error string. A project that reads the server's own wait instruction was run against real accounts by somebody who got tired of being stopped. A project that has no reference to it was demonstrated rather than operated. That one test separates the two categories faster than reading the readme.

Is a paid tool automatically better than a free script?

No, and the comparison is not really tool against tool. It is one list of work against another. A paid tool is a claim that somebody else has already done the pacing, the network layer, the persistence, the duplicate protection, the wait handling and the version maintenance, and is still doing them next month. Whether a given vendor actually has is a fair question to ask them, in those words. If you are going to own the code yourself anyway, a maintained fork plus the checklist above is a legitimate answer.