DEV Community: charlie-morrison

Dead Telegram Bots Still Look Alive: How I Sorted 9 of Them

I Probed 15 Telegram Game Bots via MTProto: Only 2 Actually Play

I Tested 9 Telegram Anonymous Chat Bots: Only 1 Connected Me to Anyone

I Tested 6 Telegram Download Bots: Only 2 Actually Sent a File

Telegram Games for 2: Only 4 of 11 Bots Work Without a Group

I Rolled Telegram's Emoji Dice 900 Times: Here Is What Each One Actually Returns

Telegram editMessageText: Your Keyboard Vanishes (Tested)

Telegram Bot Commands: 100 Max, and Two Rewrites That Don't Tell You

Telegram MarkdownV2: 14 of 18 Reserved Characters Error, 4 Delete Themselves

sent: Anna_Marie (dev) v2.0-beta! 50% off #1

raw: 400 Character '(' is reserved and must be escaped

escaped: ACCEPTED -> Anna_Marie (dev) v2.0-beta! 50% off #1 ``

Half of Telegram's Bot API Errors Arrive Before It Checks Your Chat Exists

Telegram's 50 MB Bot Upload Limit: I Measured Every Boundary

Telegram's 4096-character limit isn't characters. I measured it

DEV Community: charlie-morrison

Dead Telegram Bots Still Look Alive: How I Sorted 9 of Them

I Probed 15 Telegram Game Bots via MTProto: Only 2 Actually Play

I Tested 9 Telegram Anonymous Chat Bots: Only 1 Connected Me to Anyone

I Tested 6 Telegram Download Bots: Only 2 Actually Sent a File

Telegram Games for 2: Only 4 of 11 Bots Work Without a Group

I Rolled Telegram's Emoji Dice 900 Times: Here Is What Each One Actually Returns

Telegram editMessageText: Your Keyboard Vanishes (Tested)

Where the nine came from

What I could test, and what I could not

Result 1: three are almost certainly switched off

Result 2: three more never reply, and I cannot prove why

Result 3: two actually play, and they are not the same game

The one that only works in groups

The privacy question no directory mentions

How I would pick one tonight

Why the lists keep getting this wrong

Why I asked Telegram instead of a directory

Never Have I Ever: three names, no game

Would You Rather is the opposite: two that work

"Silent" and "switched off" are different verdicts

What the account flags say before you add anything to your group

How to run Never Have I Ever with no bot at all

What I could not test, said plainly

The set, and why it is not a cherry-pick

What I measured, and the line I did not cross

Result 1: one bot works, and it works in four seconds

Result 2: the bot search engines send you to never gets past its own first question

Result 3: two bots that resolve, accept your message, and are not there

Result 4: the wall that `/start` cannot see

Result 5: three of the nine entries are really one service

The thing I expected to find, and did not

So what does "anonymous" actually mean here?

All nine, in one table

If you just want one that works

The pattern underneath all of this

The set, and why it is not a cherry-pick

Result 1: the most-recommended bot is not there

Result 2: the failure mode nobody warns you about is silence

Result 3: one bot sells the file back to you as an audience

Result 4: two of them genuinely work

Two things I got wrong, and how the run caught them

Why the working bots offer you 360p

If you just want the thing to work

The pattern underneath all of this

How I tested it

The first pass answered six of eleven with "I don't know"

Two things my own script got wrong, and how I caught them

All eleven, and what each one does to a pair of friends

The four that work all work the same way, and it is not commands

The two workarounds worth knowing

What this means for the lists

There are six of them, not one

Why the fairness question is worth asking

How I threw 900 of them

The results: nothing is rigged

The slot machine is three reels wearing one number

What this means at an actual game night

What I could not verify, and will not pretend I did

Running this yourself

The setup

The no-op edit is an error, and it compares more than the text

The keyboard you did not mention is the keyboard you deleted

The method is fixed by how the message was sent

The boundaries on an edit are the boundaries on a send

What survives an edit

Deleting twice is an error

What I did not measure

What to change in your code

FAQ

The setup

The ceiling is 100, and it refuses rather than truncates

The charset is enforced, not cleaned up

Two rewrites that happen on the way in

The description field

Scopes shadow, they do not replace

What to do with this

FAQ

The setup, and why it needed almost no chat

One occurrence: the docs are exactly right

Two occurrences: fourteen still fail, four disappear

Where this actually bites

The migration trap: legacy Markdown to MarkdownV2

Inside code spans and links, the rules genuinely are narrower

HTML mode has one fatal character instead of eighteen

What I do now

The probe

FAQ

The setup

Layer one: parse errors, no chat required

Layer two: limits, chat first

The one size limit the server actually enforces

The empty label is the one I would guard against

What I would do with this

Limits of this measurement

FAQ

How I tested it

The download cap is exactly 20 MiB

The upload cap counts your HTTP headers

An over-limit upload does not return an error

The asymmetry is the actual problem

What to do about it

What I did not test

The short version

How I tested it

The number is 4096. The unit is code points.

But the UTF-16 rule is real -- for offsets

Visible characters are not the unit either

Captions: same rule, different number, different error string

What this means in code

What I did not test

The short version

Questions I had before I measured

Where the nine came from

What I could test, and what I could not

Result 1: three are almost certainly switched off

Result 2: three more never reply, and I cannot prove why

Result 3: two actually play, and they are not the same game

The one that only works in groups

The privacy question no directory mentions

How I would pick one tonight

Why the lists keep getting this wrong

Why I asked Telegram instead of a directory

Never Have I Ever: three names, no game

Would You Rather is the opposite: two that work

"Silent" and "switched off" are different verdicts

What the account flags say before you add anything to your group

How to run Never Have I Ever with no bot at all

What I could not test, said plainly

The set, and why it is not a cherry-pick

What I measured, and the line I did not cross

Result 1: one bot works, and it works in four seconds

Result 2: the bot search engines send you to never gets past its own first question

Result 3: two bots that resolve, accept your message, and are not there

Result 4: the wall that /start cannot see

Result 5: three of the nine entries are really one service

The thing I expected to find, and did not

So what does "anonymous" actually mean here?

All nine, in one table

If you just want one that works

The pattern underneath all of this

The set, and why it is not a cherry-pick

Result 1: the most-recommended bot is not there

Result 2: the failure mode nobody warns you about is silence

Result 3: one bot sells the file back to you as an audience

Result 4: two of them genuinely work

Two things I got wrong, and how the run caught them

Why the working bots offer you 360p

If you just want the thing to work

The pattern underneath all of this

How I tested it

The first pass answered six of eleven with "I don't know"

Two things my own script got wrong, and how I caught them

All eleven, and what each one does to a pair of friends

The four that work all work the same way, and it is not commands

The two workarounds worth knowing

What this means for the lists

There are six of them, not one

Why the fairness question is worth asking

How I threw 900 of them

The results: nothing is rigged

The slot machine is three reels wearing one number

What this means at an actual game night

What I could not verify, and will not pretend I did

Running this yourself

The setup

The no-op edit is an error, and it compares more than the text

The keyboard you did not mention is the keyboard you deleted

The method is fixed by how the message was sent

The boundaries on an edit are the boundaries on a send

What survives an edit

Deleting twice is an error

What I did not measure

Result 4: the wall that `/start` cannot see

Want Truth or Dare that cannot go offline?

Try the free game first

Skip the writing: 255 prompts, ready to poll

Want a group chat that cannot go silent on you?

The first test link was a live stream

My own classifier mislabelled a bot, twice over

Tired of Telegram things that go silent?

How to actually use it, in three steps

Want more than four games for the two of you?

Want the run sheet instead of the maths?

Running the night in a group chat?

Removing a keyboard on purpose

Telegram in Production

Telegram in Production

The leading slash is stripped

Duplicate names are deduplicated, last one wins

Telegram in Production

Telegram in Production -- the parts that bite you

Building on Telegram for something lighter?

Telegram in Production -- the parts that bite you

Building on Telegram for something lighter?

Telegram in Production -- the parts that bite you

Want Truth or Dare that cannot go offline?

Try the free game first

Skip the writing: 255 prompts, ready to poll

Want a group chat that cannot go silent on you?

The first test link was a live stream

My own classifier mislabelled a bot, twice over

Tired of Telegram things that go silent?

How to actually use it, in three steps

Want more than four games for the two of you?

Want the run sheet instead of the maths?

Running the night in a group chat?

Removing a keyboard on purpose

charlie-morrison — Tue, 15 Sep 2026 20:48:32 +0000

Every directory page for a Telegram Truth or Dare bot says some version of the same thing: " Compatible with groups!" A few add that it will spice up your chat. None of them say whether the bot still answers.

That is the only question that matters at nine in the evening with six people in a group chat waiting for someone to go first. So on 11 September 2026 I took every Truth or Dare handle that three web searches turned up that night and sent each one a message.

Three of the nine answered. The handle listed by the most directories never said a word.

The whole run. Every verdict comes from the objects Telegram returned. Nothing here was typed in from a bot's description.

Picking nine bots I expected to fail would prove nothing, so I fixed the set before measuring anything and wrote down where each handle came from:

Bot directories: @todgame_bot (listed on three of them), @truthordarerobot, @truth_dare_bot, @randomtdbot, @truthordaregroupbot.
Bare Telegram links that came up in search: @truthordaregamebot, @truthanddaregamebot.
Open source: @conversationGamesBot, named in the README of its own GitHub repository.
A search engine 's own summary of "party game bots": @YetAnotherTruthOrDareBot.

All nine resolve. None of the usernames is empty, which is already better than the download bots I tested last week, where the most-recommended handle no longer existed.

Truth or Dare is a group game, and the honest thing is to say up front that I did not play it in a group. My test account is restricted from creating group chats, and I was not going to drop nine strangers' bots into somebody else's group to find out. So this is not a review of what a round feels like with friends.

What I could do turned out to be enough to sort the nine, because a bot whose server is switched off is switched off everywhere. Four checks:

Private chat. /start, then the bot's own game command taken from the list it registered with Telegram, never guessed. Silence at 12 seconds got a second try at 40 seconds before it counted.
Inline query. Telegram passes an inline query straight to the bot's server and waits. A running server answers. A dead one times out.
The bot 's account flags. Telegram publishes two per bot on the user object: whether it can be added to groups, and whether it "can see all messages in groups".
Source code , where it is public.

@truthordaregamebot and @YetAnotherTruthOrDareBot both registered inline mode, which gave me a second test. I sent each an empty inline query and one for "truth". Both timed out, at 10 seconds and again at 20. Telegram forwarded the question and nobody answered it. Neither replied in private chat either, at 12 seconds or at 40. Together that is strong evidence, not proof: on 16 September four working Crocodile bots answered private messages instantly and still timed out on the same inline test.

@conversationGamesBot is open source, which settles it a different way. Its entry file registers a handler with bot.start(showStart) and no check on chat type, so the program answers /start in any chat it can see, private included. I got nothing at 40 seconds, and nothing for its own /question command. The code says it would reply if it were running. The repository's last commit is from May 2025.

That is the failure nobody warns you about. A switched-off bot keeps its name, its profile picture and its command menu, and Telegram delivers your message to it with the usual ticks. From the chat window it looks exactly like a bot that is thinking.

@todgame_bot, @randomtdbot and @truth_dare_bot said nothing at 12 seconds, nothing at 40, and nothing to their own /tod or /truth commands. None of them has inline mode or public code, so I have no second test that could separate "switched off" from "ignores private chats on purpose". I am calling them silent, not dead.

Two details are worth knowing anyway.

@todgame_bot is the one listed on three directories, with the cheerful "Compatible with groups!" description. It is also the one I would bet on being gone, because a group bot that does not answer /start in private is unusual. Even the one bot in this set that refuses private chats still says so when you message it.

@truth_dare_bot describes itself like this, spelling included:

"I Will Ask You To Answer Me Truthfully Or Do Some Works And Share It With Me. I Will Share Yur Answers In Twitter And Also In Channel: Telegram.Me/Truth_Or_Dare !"

So the pitch is that your truths get published. The channel it names does not exist any more: Telegram answers "Nobody is using this username". It is hard to know which is worse, a bot that posts your answers or one that promises to and cannot.

@truthordarerobot is the one I would use. /start gets a short greeting and an "Add me to a group" button. Its help screen lists four commands, /truth, /dare, /mode [classic|hot] and /lang [en|it], and they work in private too:

✅ TRUTH ✅ What is the strangest rumor you've heard about yourself?

❗️ DARE ❗️ Let someone tickle you for one minute.

Each prompt comes with an "Another One" button. The default mode is party-safe, the hot mode is opt-in, and the bot has a privacy screen that says what it keeps: your user ID, the group ID, your language, the mode you picked and when you last changed a setting. That is about the minimum a group bot can store and still work, and it is the only bot of the nine that told me.

@truthanddaregamebot also works, but read the small print. It is built on Manybot, a bot builder, and its first message is followed by " Want to create your own bot? Go to @Manybot" and " Use /off to pause your subscription". Starting it subscribes you to its broadcasts. After /startgame and /go it returned two prompts:

What is the most adventurous thing you'd want someone to do to you?

What would you do if you and your partner were stuck in a room for 24 hours with no lights?

Both were truths, both came with no truth-or-dare choice, and both are couples-flavoured. That is fine if it is what you want, but it is not what you want to fire off in a group that includes your cousin.

@truthordaregroupbot answered /start and its own /startgame with the same line: " Hello I only work in groups so please add me in one", plus a button that opens Telegram's add-to-group screen. It is alive, and its command list is the most complete of the nine: /joingame, /nextquest, /leavegame, /endgame, even /add_dare for your own dares. I could not test a round, for the reason above, so I am not going to guess how good it is. What I can say is that its description ends with a "business inquiries" link into a different bot, which tells you how the operator pays for the server.

Handle	Verdict	What actually happened
`@truthordarerobot`	Plays	Real truth and dare on request, classic and hot modes, a plain privacy policy.
`@truthanddaregamebot`	Plays, with a catch	Two couples-flavoured truths, no dares. Subscribes you to broadcasts.
`@truthordaregroupbot`	Groups only	"I only work in groups." Alive, not played.
`@todgame_bot`	Silent	Listed by three directories. Nothing at 40 s, nothing to `/tod`.
`@randomtdbot`	Silent	Nothing to `/start` or `/truth`. Privacy mode off.
`@truth_dare_bot`	Silent	Promises to publish your answers to a channel that no longer exists.
`@truthordaregamebot`	Switched off	Inline query times out at 10 s and 20 s. Silent in private.
`@YetAnotherTruthOrDareBot`	Switched off	Inline query times out at 10 s and 20 s. Silent in private.
`@conversationGamesBot`	Switched off	Its public code answers `/start` in any chat. Got nothing.

A Truth or Dare round is a group of friends typing things they would not type anywhere else. So it is worth knowing what a bot can read once you add it.

By default, very little. Telegram bots run in privacy mode, where in a group they only receive commands meant for them, replies to their own messages and a few service events. Telegram's documentation is explicit that privacy mode is "enabled by default for all bots, except bots that were added to a group as admins", and that admin bots "always receive all messages".

A developer can switch privacy mode off, and when they do, Telegram marks the account. I read that flag for all nine. Eight keep privacy mode on.@randomtdbot has it off, which means that if it were running and you added it to your group, it would receive every message sent there, including all the answers. It is also one of the three that never replied to me, so the practical risk today is low. The broader point holds, though, and it is the one I wrote about in what "anonymous" bots can see: what a bot receives is decided by flags you can check, not by its description.

Two things to do before adding any game bot to a group. Do not make it an admin unless a feature needs it, because an admin bot receives everything whatever its privacy setting says. And if a round is going to get personal, remember that the bot's operator is a stranger who can log every command sent to it, including the one that says whose turn it is.

Message it in private first. If /start gets nothing within about fifteen seconds, move on. Six of the nine failed right there, and none of them was thinking.
Ask for one prompt before you add it. /truth in private tells you what tone the default mode has. That is how I found out one bot defaults to couples' questions.
Read the first message for a subscription. "Use /off to pause your subscription" means you have joined a broadcast list.
Do not make it an admin. Privacy mode only protects you while it is not one.
Have a fallback that needs no bot. A group that expected Truth or Dare at nine does not want to watch someone troubleshoot a server at five past.

The Telegram Party Pack is 255 group-chat prompts, Truth or Dare and Never Have I Ever among them, with ready-made polls. No bot to add, no stranger reading the answers, nothing that can go quiet halfway through a round.

Get the pack -- $9.99 Or start with the free party games list.

This is the fourth time I have run the same exercise in this corner of Telegram, after quiz bots, download bots and anonymous chat bots. The shape has not changed: a set of confidently listed handles, a minority that do what they say, and a long tail that looks alive and is not.

Truth or Dare makes it especially easy to miss. A directory entry is a name, a picture and a description, and all three outlive the server by years. A dead bot keeps its command menu, so /truth still autocompletes as you type it. Nothing in the chat window tells you there is no program at the other end until your message goes unanswered.

If you are planning the evening rather than picking a bot, the game night guide covers the chat mechanics that break first. Fifteen seconds of sending /start beats any directory, this page included, and the date at the top is there because some of these verdicts will be out of date by spring.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Mon, 14 Sep 2026 20:05:07 +0000

Never Have I Ever needs no explanation, no board and no app. Somebody says a thing they have never done, everyone who has done it admits it, and the evening takes care of itself. It is the easiest game in the world to put in a group chat -- which is why I expected Telegram to have five bots for it.

It has none.

On 13 September 2026 I asked Telegram itself, not a directory, which bots exist for this game. Three accounts carry the name. Not one of them plays. One answers with a "confirm you are human" button that leads somewhere else entirely, one signs you up to a broadcast list, and one -- the only account that is actually about the game -- never replies at all. Meanwhile the neighbouring game, Would You Rather, has two bots that work fine.

The whole run: what Telegram's own account search returned per query, then what each bot did when messaged. Every verdict comes from the objects Telegram sent back, not from a bot's description.

The last three times I did this -- quiz bots, download bots, Truth or Dare bots -- the handle list came from web directories. That method has a built-in flaw: a directory entry outlives the bot's server by years. Nobody goes back to delete the listing when the program stops running, so the list you are reading is a record of bots that once existed.

So this time the list came from the platform. The MTProto method behind the Telegram search box is contacts.search, documented as returning "users found by username substring" (core.telegram.org). It only returns accounts that exist right now. I fixed seven queries before measuring anything -- the phrasings a player would actually type, plus the two acronyms -- and took every bot account each one returned:

never have i ever -> 1 account, 1 bot
neverhaveiever -> 2 accounts, 1 bot
nhie -> 3 accounts, 3 bots
would you rather -> 6 accounts, 6 bots
wouldyourather -> 4 accounts, 3 bots
wyr game -> 2 accounts, 2 bots
party game -> 2 accounts, 2 bots

That is 18 distinct bot accounts. Three of them matched only as a substring and are plainly something else -- two Vietnamese ad-watching earners that matched nhie inside nhiem vu , and a casino link farm that matched wyr -- so they are recorded with that reason and not probed. The remaining 15 each got the same three reads: a direct message with /start, then the bot's own first game command taken from the list it registered with BotFather rather than one I guessed, then an inline query as a liveness control.

Notice what the first line of that list already tells you. The most natural search a person can type for this game returns one account in the whole of Telegram.

Here is what the three accounts carrying the name actually do.

@never_have_i_ever_adult_bot is the only one whose description is about the game: an 18+ Russian version where whoever has done the thing takes a drink. It registered /start and /help with BotFather, so at some point there was a program behind it. It did not answer /start. It has inline mode switched off, so I have no second test, and I am calling it silent rather than dead -- that distinction matters and I will come back to it.

@NHIEBot is the shortest, most valuable handle of the set, and it has been repurposed. Its display name is a redirect notice pointing at an unrelated channel, and its answer to /start is a human-verification screen: "Confirm that you are human -- press the button below for access to the bot." I did not press it. Whatever is behind that button, it is not Never Have I Ever.

@Neverhaveiever_bot is the one I would have clicked first, and it is a mailing list. Its display name is "Hacker". Two messages came back in twelve seconds:

Congratulations! You subscribed to Hacker.

Use /off to pause your subscription.

Want to create your own bot?

Go to @Manybot

That second line is the tell. Manybot is a builder that turns a Telegram bot into a broadcast channel with no code at all, and somebody used it to park a game name on a subscriber list. The exact same pattern showed up on the Would You Rather side: @WouldyouratherBot answers with "Congratulations! You subscribed to Would you rather" and the same Manybot footer. Two good game handles, two mailing lists.

So the score for the game the whole post is named after: three accounts, zero games.

Nine handles came up for Would You Rather, and two of them play properly -- which is worth knowing, because it is the closest game to Never Have I Ever in shape. Both are a prompt plus a binary choice.

@RatherGameBot is the better one for a group. Its welcome message explains single-player use (/next, /nsfw), then group use (/next@RatherGameBot), then inline. /next returned a real question immediately -- " Be an average person in the present" against " Be a king of a large country 2500 years ago" -- with two buttons to vote with. Its inline query answered with two results, "Get Question" and "Get Question (18+)", so it works in a chat you have not added it to. Two caveats: the 18+ set is one command away from the family-friendly one, and its privacy mode is off, which I get to below.

@pickle_picker_bot is the richer single-player experience: a question feed, categories, curated collections, AI-generated questions and a suggestion box. It sent a question with A/B buttons and a Next arrow straight after /start. It has no inline mode and does not document group commands, so it reads as a bot to scroll on your own rather than one to run an evening with.

The other seven are the usual long tail. @BetterRatherGameBot is inline-only by design -- its display name literally starts with "(inline)" -- and its inline query timed out, which for an inline-only bot means there is nothing left of it. @RatherGamesBot has the fullest command list of the whole set (/set_category, /askme) and answered nothing at all. @Would_You_Ratherbot is not a game: its description is a wall of links to pirated 1080p films. @gamepartyevening_bot replied exactly once, with "Hello, this is Gamepartyevening_bot.", and had nothing else to say.

Truth or Dare, Never Have I Ever and Would You Rather, with 151 questions per language, English and Ukrainian, no signup and no backend that can be switched off. Open it in the chat and start a round.

Open the Party Game No Telegram? It runs in a browser too: charliemorrison.dev/party-game

A bot that ignores you looks identical to a bot that no longer exists. The username, the profile picture and the command menu all survive the server being turned off, so /next still autocompletes as you type it into a chat where nothing is listening.

There is one test that separates the two, and it is why the census has an inline column. Telegram forwards an inline query to the bot's own server and waits for the answer, so a running server replies with results and a stopped one produces a timeout. Four bots timed out: @BetterRatherGameBot, @RatherGamesBot, @WouldYouRather_bot and @wyrgamebot. All four were also silent in private, so I call them very likely switched off. For the inline-only @BetterRatherGameBot that is as close to certain as the outside gets. (Correction, 16 September: a timeout on its own is not proof. Four working Crocodile bots answered private messages instantly and still timed out on the same inline test.)

Five others -- including the 18+ Never Have I Ever one -- never enabled inline mode, so Telegram refuses the query before it goes anywhere. That is no signal , not proof. They stay silent, cause unknown. A bot can also be built to answer only in groups and ignore private chats entirely, which is a design choice, not a fault, and the group test that would tell them apart is the one test I could not run.

There is one more number Telegram publishes that almost nobody looks at. The bot account object carries a field described in the API schema as "Monthly Active Users (MAU) of this bot (may be absent for small bots)" (core.telegram.org/constructor/user). Of these 15 bots, exactly one exposes it: @RatherGamesBot, with 3 monthly active users -- and it is one of the four that answered nothing. For the other 14 the field is absent, and per that same sentence absence means small, not zero. Either way, nothing in this set is a busy product.

Two flags on the same object are worth checking on any bot you are about to put in a chat with friends, and both are readable without messaging it:

" Can the bot see all messages in groups?" -- this is privacy mode, and when it is off the bot receives every message in every group it is in, not just the commands addressed to it. Four of the 15 have it off, @RatherGameBot among them. For a game bot that is usually a convenience choice, so it can watch for answers. It still means a stranger's server reads the whole room.
" Can the bot be added to groups?" -- @WouldYouRather_bot is flagged as barred from groups entirely. A party game that cannot join a party is worth knowing about before you try.

Since the bots do not exist, here is the thing I actually do, and it is better than a bot for a reason that has nothing to do with uptime: nobody has to admit anything out loud.

Each round is a two-option anonymous poll. The question is the prompt ("Never have I ever missed a flight"), the options are I have and I have never. Anonymous results turn the game from a confession into a headcount, which is where the laughing actually starts -- five of six people voting "I have" is funnier than any single answer. Any member can create a poll, no admin rights and no third party added to the chat.

Three mechanics matter. The two character limits I measured myself on this account when I wrote up Telegram's poll limits; the pacing figure is Telegram's own guidance, not mine, and I say which is which:

Pace the rounds. Telegram's bot FAQ puts the safe rate at roughly 20 messages a minute into one group. One poll every 15-20 seconds is a comfortable evening; firing ten at once is how you get throttled mid-game.
Keep the prompt short. A poll question holds 300 characters and each option 100 -- measured, not documented -- which is plenty. But a long prompt on a phone pushes the buttons off-screen, and people vote on what they can see.
Close the poll before the next one. Two open polls on the same wall means half the group votes in the old one. The game night guide has the rest of the chat mechanics that break first.

The prompts are the actual work. A search for a list will get you the same twenty mild questions everyone has already answered, and the ones that make an evening are specific, plausible and survivable. That is a writing problem, not a software problem, which is also why no bot fixes it.

The Telegram Party Pack is 255 group-chat prompts across six games -- 45 Never Have I Ever statements in warm-up and spicy tiers, 30 Would You Rather dilemmas with both options pre-written, 110 Truth or Dare -- as copy-paste text and ready-made poll blocks. No bot to add, no stranger's server reading the room, nothing that can go quiet halfway through a round.

Get the pack -- $9.99 Or start with the free party games list.

Three limits, because a census that hides them is just a list with confidence.

No group pass. These are group games and the right test is a real group chat. The account I test from is spam-reported and Telegram refuses to let it create chats at all -- a permanent restriction since May -- and I do not borrow strangers' groups to experiment in. So group behaviour here is read from the typed flags and from what each bot documents about itself, and a bot that only talks in groups would show up as "silent" in my table. That is the weakest part of the method and it is the same gap I had on Truth or Dare.

Username substring, not semantics. contacts.search matches names and usernames. A bot that plays Never Have I Ever under a name like "PartyPal" would never appear in my results, which is exactly why the two Vietnamese earners did. So the honest claim is not "no such bot exists anywhere". It is that a person searching Telegram for this game by its name finds nothing that plays it -- which for anyone at nine in the evening is the same thing.

Twelve seconds, one attempt. Each bot got a twelve-second window per message. A server that woke up on the thirteenth second reads as silent here. Verdicts have a date on them for that reason, and if you are reading this months later, the fifteen-second test is /start yourself.

For a game this simple, the result is oddly consistent with the last three of these I ran: the gap between what the listings promise and what answers a message is not a Never Have I Ever problem. It is what a bot ecosystem looks like when the cost of abandoning a username is zero.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

charlie-morrison — Wed, 09 Sep 2026 20:42:10 +0000

An anonymous chat bot makes a very simple promise: press start, and in a moment you will be talking to a stranger who does not know who you are.

It is a promise that is unusually easy to check, and unusually rarely checked. Every "best anonymous chat bots" list I could find on 9 September 2026 describes what each bot is for. Not one of them shows what happens when you actually press start.

So I pressed start on all nine of them.

One connected me to a person. The other eight failed in eight genuinely different ways, and the differences turned out to be more interesting than the number.

The full run. Every verdict is computed from the message objects the bots returned, not from their bios. The "phone?" column is read from the button type, not from the button text.

Choosing nine bots that fail is easy and worthless. So the set was fixed before anything was measured, taken from other people's recommendations, and every handle was copied exactly as written by its source:

Seven handles from a "top Telegram bots for chatting" list published for 2026: @AnonyMeetBot, @hidden_chat_bot, @chatbot, @smartychatt_bot, @RandomChatssBot, @TalkMe_chat_bot, @anonimechatbot.
One handle from a general Telegram bot directory -- @anonxbot.
One handle from a 2026 random-chat round-up -- @chatty_random_bot.

That "exactly as written" matters more than it sounds. Several lists name a brand and link to a website rather than giving a Telegram handle, and it is very tempting to infer the handle from the brand. I refused to. A handle I guessed wrong would come back as this bot does not exist , and I would have published a live service as dead. Every name below is one a source actually printed.

These bots connect you to a real human being. That puts a hard limit on what an automated test is allowed to do, and the limit shaped the whole design.

I measured the onboarding path only : does the handle resolve, what does the bot demand before it will do anything, and does it actually place you in a matching queue. Wherever a match could occur I sent /stop immediately. No conversation was held with anybody. Twice a stranger got a word in before my /stop landed. One opened with "M", one with "Hey", and both times I disconnected without replying, which is a slightly rude thing to do to a person and the only defensible thing to do in a test.

So this article cannot tell you whether the people on the other side are pleasant, or whether a bot has an active user base at 3am. It can tell you, precisely, what stands between you and that first hello.

@chatbot, plainly named "Anonymous Chat", is the only one of the nine that did what all nine advertise. The entire interaction:

Looking for a partner…

Partner found 😺

/next -- find a new partner

/stop -- stop this chat

About four seconds, start to stranger. No gender question, no age question, no profile, no channel to join, no phone number. I ran it a second time to be sure a single match was not luck, and it matched again just as fast, with the other person opening first.

That speed is worth sitting with, because it reframes every other result on this page. The eight failures are not evidence that anonymous matching is hard to build. It is evidently not hard: one working service does it instantly, for free, with no questions. The failures are evidence that the lists are not checked.

@AnonyMeetBot is the one I most expected to work. It has a polished welcome, its own launch page, and it is the handle people search for by name.

It opens by asking your gender -- three buttons, Male, Female, Non-Binary. Fair enough; plenty of matching services want that.

Then you press one, and nothing happens.

No confirmation. No next question. No error. Not even the little grey toast Telegram shows when a bot acknowledges a button press. I pressed Male and waited eight seconds, then repeated the whole flow with a deliberately generous 30-second window in case the server was merely slow. Same result: the bot re-sent its welcome and asked my gender again.

So the bot is not dead -- it answers /start instantly and renders a working keyboard. It simply never processes the answer to its own only question. A user hits a polite, well-designed, completely closed door, and would reasonably conclude they did something wrong.

@RandomChatssBot and @chatty_random_bot both open normally. They have names ("Random Chatss bot", "Anonymous Chat -- chatbot") and profiles, and they accept /start without complaint.

Neither has ever said a word to me. Not at a 12-second wait, and not at the 40-second re-test I ran specifically because "silent" is a claim that deserves a second chance. Silence at 12 seconds might be a slow server; silence at 40 is a switched-off one.

This is the failure mode that looks healthiest from the outside, and it is structural rather than accidental: a bot username stays registered with Telegram long after the program behind it stops running. Telegram will resolve the handle, show you a normal profile, and deliver your message into nothing. Every list that has ever recommended these two still recommends them, because from a list-writer's desk they look fine.

Note the second name, though: " Anonymous Chat -- chatbot". That is the display name of a dead bot echoing the one bot on this page that works.

This is the finding that changed how I will run every test like this in future.

@anonimechatbot greets you in Italian with an unusually confident privacy pitch: 100% anonymous chat with other anonymous users, we do not keep your data or your conversations, we have existed since 2018 and we take confidentiality very seriously.

My first pass scored it clean. Its /start reply is clean: a welcome, a rulebook link, a menu. Nothing to object to.

Then I pressed the button that actually starts a chat:

📣 Devi entrare nel canale sottostante per poter continuare ad usare il bot!

(You must join the channel below to continue using the bot.)

A forced channel subscription -- the thing you join so somebody's promotional channel gains a member, sitting one click behind a privacy promise, and completely invisible to any test that stops at the greeting. My own first classifier had marked this bot as unremarkable for exactly that reason.

The rule I took away, and the reason this section exists: test the action, not the greeting. A bot's welcome message is marketing copy it wrote about itself. The demand it makes when you finally ask it to do its job is the only part that describes the product.

Line up the results and something odd appears. @anonxbot, listed in a bot directory as a working anonymous chat service, replies only with this:

🌎 Anonymous Chat has moved here: @chatbot

It is a forwarding sign. And @chatty_random_bot, as noted, is a silent bot whose display name is "Anonymous Chat -- chatbot".

So of nine recommended entries, three point at, or imitate, a single underlying service , the one that works. The apparent variety of the anonymous-chat bot market is partly an illusion produced by lists copying each other. If you had tried the first three names you found and all three had been these, you would have concluded the category was broken, when in fact you had been handed one address written three ways.

And one entry, @smartychatt_bot, is not an address at all. Telegram's answer is UsernameInvalidError: nobody is using this username. A 2026 list is recommending a handle you cannot even open.

I built this test around a suspicion. I assumed at least one "anonymous" bot would ask for a phone number, because that is the sharpest possible contradiction and I wanted to catch it.

Telegram makes such a demand precisely detectable. The Bot API defines a keyboard button field request_contact, documented as: " If True, the user's phone number will be sent as a contact when the button is pressed. Available in private chats only." (official Bot API reference). Its sibling request_location does the same for your position. Because those are typed API fields rather than words in a message, a bot cannot disguise the request, and it cannot take either silently, since both require a deliberate tap.

My classifier watched for both. Zero of the nine used either. Not one asked for a phone number. Not one asked for a location.

I am reporting that as prominently as the failures, because a test that only publishes the results it hoped for is not a test. On the specific axis I was most suspicious about, this category came out clean. The anonymity problem here is not data harvesting through the front door. It is that eight of nine bots never work at all, and one of them quietly bills your channel membership as the price of entry.

It means anonymous to the stranger , and that is a real and useful thing. The person you are matched with sees a relayed message and nothing else.

It does not mean anonymous to the operator. Telegram's own Bot Platform Developer Terms are explicit about the arrangement: these third-party applications "are hosted on their developers' own servers, and are third-party services that Telegram allows to have a presence in Telegram apps." Telegram is providing the doorway, not vouching for the room. Whoever runs the bot receives every message you send through it, on hardware you know nothing about, under a privacy policy you have not read. And in one case here, a policy asserting "we do not keep your data" sat one click in front of a demand that you join a marketing channel.

So what can the operator see about you , as opposed to what your chat partner sees? I measured that separately, and the answer surprised me: anonymous Telegram bots can see your username, whatever the bot chooses to show the other side.

The Telegram Party Pack is 255 group-chat game prompts that run on nothing but the chat you already have. No bot to add, no handle to verify, nothing that can quietly stop existing next spring.

Get the pack -- $9.99 Or start with the free party games list.

Handle	Result	What actually happens
`@chatbot`	Connects	Matched in ~4 seconds on both attempts. No profile, no gender, no channel, no phone.
`@AnonyMeetBot`	Dead-end gate	Asks your gender; pressing an answer produces no reply, no toast and no state change, even after 30 seconds.
`@anonimechatbot`	Channel wall	Clean greeting, then demands you join a channel the moment you ask for a chat. Italian only.
`@RandomChatssBot`	Silent	Resolves and accepts `/start`. No reply at 12 seconds or at 40.
`@chatty_random_bot`	Silent	Same, and its display name imitates `@chatbot`.
`@smartychatt_bot`	Does not exist	`UsernameInvalidError` -- the handle cannot be opened at all.
`@TalkMe_chat_bot`	Profile first	Opens with "Fill out your profile information" plus language and gender selectors before anything else.
`@anonxbot`	Redirect	Replies only that Anonymous Chat "has moved here: @chatbot".
`@hidden_chat_bot`	Different product	Mints an anonymous inbox link to share (`/mylink`). It does not match strangers -- the list mis-filed it.

On that last row: @hidden_chat_bot is not broken and I am not criticising it. It does its own job fine. It is simply the anonymous message link model, where people send you messages, rather than the random-stranger model. A list recommended it for "talking to strangers", which is a category error, and it is the second-most common way these round-ups mislead you after recommending dead handles.

Use @chatbot, and know three things going in.

Check the handle character by character. The single most valuable habit in this category. One dead bot on this page is already wearing a display name that mimics this one, and imitation handles are the cheapest attack in the entire Telegram ecosystem.
Assume the operator logs everything. Not because this particular bot has done anything wrong, but because it runs on somebody's private server and that is simply how the platform works. Send nothing through a relay you would mind seeing attached to your account.
Never join a channel to unlock a "free" bot. The join demand tells you the bot's real business is audience-building, and the chat is the bait. There is at least one service doing the same job with no wall at all.

This is the fourth time I have run this exercise in the same corner of Telegram, after anonymous message apps, quiz bots and download bots. The shape of the result has never once changed: a set of confidently recommended handles, a small minority that do the advertised thing, and at least one entry that no longer exists in any form.

The cause is structural rather than dishonest. Naming a Telegram bot costs nothing; keeping one running costs money and attention every month. Lists get written once and republished forever, and the recommendation outlives the service by years. Nobody who profits from the list has any reason to go back and press start.

Which is the whole argument for doing it yourself, and it takes about ninety seconds. Open the handle. If it does not answer, it is dead. Wait a full minute before believing it is merely slow. If it answers, ask it to actually do the thing before you decide it works, because the greeting is the one part guaranteed to be pleasant.

Tested 9 September 2026. Every verdict here was computed from the message objects Telegram returned, and the raw replies were kept so the verdicts could be recomputed without messaging anybody a second time, which is exactly what happened when my first pass filed three quite different failures under one careless label.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Tue, 08 Sep 2026 20:19:02 +0000

Every list of Telegram download bots I can find ends with the same sentence, in slightly different words: " Telegram bans and renames bots constantly, so confirm a bot still responds before you rely on it."

It is good advice. It is also a confession. The list is telling you it has not checked, and quietly handing you the job.

So on 7 September 2026 I did the checking. Six handles, taken from two independent live lists on the day. One public-domain link sent to each. I read the message objects Telegram returned rather than the screenshots or the bios. Whether a file arrived is a property of the reply, not a matter of opinion.

Two of the six sent a file. The handle that leads almost every list does not exist at all.

The full run. Every verdict is computed from the objects the bots returned. The file sizes are the real byte counts of the mp4s that arrived.

Picking six bots that fail is easy and worthless. So the set was fixed before anything was measured, and it came from other people's recommendations, not mine:

Four handles -- @SaveVideoBot, @TGDownloaderBot, @allsaverbot, @SaveViBot, named by the "best Telegram video downloader / download bot for 2026" listicles that currently rank for the query.
Two handles -- @Free_download_tiktok_bot, @Kyreth_hq_bot, named in the download category of a general Telegram bot directory.

That split turned out to matter more than I expected, so hold on to it.

The test link was a NASA upload: Perseverance Rover 's Descent and Touchdown on Mars (Official NASA Video). NASA material is generally not copyrighted, per NASA's own images and media guidelines, which makes it the one video I can hand to six strangers' servers while testing whether the machinery works and nothing else.

@SaveVideoBot is the name at the top of the lists, the one described as handling "most formats and sizes up to 2 GB". Resolving it returns:

No user has "savevideobot" as username

Not banned, not broken, not rate-limited. The username is unoccupied. Whatever that bot was, it is gone, and the lists recommending it in 2026 are copying each other rather than opening Telegram.

There is a second-order effect here worth naming. @SaveViBot, a different handle one character short of the famous one, presents itself as " Save Video Bot". When the well-known name empties out, the traffic still arrives, and something will be waiting at the near-miss spelling to collect it.

@TGDownloaderBot and @SaveViBot both resolve. Both have plausible display names: TG Downloader and Save Video Bot. Both accept /start. Both accept the link. Neither ever replies to anything.

This is worse than a dead handle, because a dead handle tells you immediately. A silent bot looks completely normal: it has a profile, the message ticks show as delivered, and you sit there assuming it is working on your video. A bot username survives the server behind it being switched off, so "the account exists" carries no information about whether any program is listening.

Practical consequence: if nothing comes back within about fifteen seconds, nothing is coming back. The working bots in this test answered in well under that, and re-sending does not help.

@Free_download_tiktok_bot opens confidently. Its /start message promises "No watermark", "Fast download", "Smart cache system" and, in its own words, " Totally free 🎁".

Send it a link and the tone changes:

"⚠️ To download videos, you must first join our channel. 📢 Join @Dirgrama_Directorio and enjoy exclusive content. After joining, send your link again."

A button labelled 🔗 Join channel comes attached. This is the forced-subscription pattern: the download is not the product, you are. Each person who wants a video is converted into a subscriber for a promotional channel, and the file is the bait. "Totally free" is technically true and completely misleading, which is a fairly precise description of the whole category.

@Kyreth_hq_bot asked for a language, took the link, said ⬇️ Downloading YouTube... and returned a 7,223,157-byte mp4. One step, no wall, no upsell. It came from the bot directory, not from any "best of 2026" list.

@allsaverbot works too, in two steps: it returns the video's title with a thumbnail and a row of quality buttons (360p, 480p, 720p, 1080p, Audio) and sends the file once you choose. It is ad-supported, and says so plainly ("Turn off the ads /subscription"), which is a more honest business model than the channel wall even though it is the less pleasant experience.

Handle	Verdict	What actually happened
`@SaveVideoBot`	Gone	Username not occupied. The most-recommended handle on the lists.
`@TGDownloaderBot`	Silent	Resolves as "TG Downloader", accepts everything, never answers.
`@SaveViBot`	Silent	Resolves as "Save Video Bot". Same near-miss name, same silence.
`@Free_download_tiktok_bot`	Channel wall	Says "Totally free", then demands you join @Dirgrama_Directorio.
`@allsaverbot`	Works, ad-supported	Thumbnail + quality buttons, then a 6,696,461-byte mp4 on 360p.
`@Kyreth_hq_bot`	Works	One step, 7,223,157-byte mp4, no wall and no upsell.

Now the split from earlier. Of the four handles the curated "best of 2026" lists named, exactly one delivered a file. Of the two the plain directory named, one delivered and one walled. The editorial lists performed worse than an unedited category page. That makes sense once you accept that the lists were never testing anything, only recopying each other while the underlying bots quietly rotted.

I would rather publish the corrections than pretend the first pass was clean, because both mistakes are the kind that turn into a confident wrong article.

My original test URL resolved to " NASA Live: Official Stream of NASA TV". A live stream is the hardest possible input, because there is no finite file to fetch, so every failure would have been ambiguous, and I would have reported bots as broken when they were merely being asked something unreasonable. I noticed when @allsaverbot came back with " The download failed. Try again later". Re-ran the entire census against a finite upload instead. The verdicts came back identical for five of six -- and the sixth is the next mistake.

The census first scored @allsaverbot as a forced subscription wall. It is not one. My rule fired on the bare substring "subscription", which appears in its ad-removal upsell: "Turn off the ads /subscription". That is a paid option, not a gate. I split the rule in two: a wall now requires an explicit demand ("must first join", "not subscribed") or a join hint carrying an actual channel button, and the upsell gets its own label. @Free_download_tiktok_bot stays a wall on that stricter test; @allsaverbot does not.

Then the same bot got scored as not delivering a file, because its first reply carries a thumbnail and buttons rather than a video. That is a two-step flow, and scoring it as failure is the measurement's fault, not the bot's. So I ran a separate pass that clicks the 360p button and records what arrives. A 6,696,461-byte mp4 arrives. The follow-through overturned my own verdict, and moved the headline from "1 of 6" to "2 of 6".

The general lesson is the one I keep relearning: a script's exit code is a hypothesis. If a result would make a good headline, that is exactly when it needs a control run.

Those quality buttons are not a courtesy, they are a workaround for a hard ceiling. Through the standard Bot API a bot can send you a file of at most 50 MB , and can fetch one of at most 20 MB from Telegram. Both limits are stated in the official Bot API documentation, and I measured both to the byte in a separate test of the file size limits.

So for anything longer than a few minutes, 1080p simply cannot reach you through an ordinary bot. When a bot offers 360p first and greys out the higher options, it is telling you the truth about its own ceiling. A bot promising 2 GB downloads is either using infrastructure well beyond the standard API, or repeating a number from a listicle.

One thing worth being clear about. These bots are anonymous third-party servers. Every link you send is logged by someone you cannot identify, one of the six wants you in a promotional channel first, and whether you have the right to download a given video is entirely your responsibility, not the bot's and not mine. I tested with public-domain NASA footage for exactly that reason.

Check the handle exists before trusting any list. Open it in Telegram. If the profile does not load, the list is stale -- and it is stale about everything else too.
Give it fifteen seconds. A working download bot answers fast. Silence is not processing, it is a switched-off server.
Walk away from channel walls. "Join our channel to download" means the file was never the product.
Expect 360p on anything long , and treat a promise of large high-definition files as a tell.
For Telegram 's own videos, you often need no bot. If the sender has not restricted saving, the built-in download in the message menu is the whole solution, and it does not involve handing your link to a stranger.

The Telegram Party Pack is 255 group-chat game prompts that run on nothing but the chat you already have. No bot to add, no handle to check, nothing that can quietly stop existing next spring.

Get the pack -- $9.99 Or start with the free party games list.

I have now run this same exercise three times in this cluster: on anonymous message bots, on quiz bots, and now on download bots. The result has the same shape every time: a set of confidently recommended handles, a minority that actually do the advertised thing, and at least one entry that no longer exists in any form.

The reason is structural. A Telegram bot costs nothing to name and something real to keep running. Lists are written once and re-published forever. So the gap between what is recommended and what works widens quietly, month after month, and nobody who profits from the list has any reason to go and measure it.

Fifteen minutes of sending /start to things is worth more than any list, including this one. This article has a date on it for the same reason the others do. By next spring some of these verdicts will be wrong too, and the honest move is to say so rather than to keep collecting the traffic.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Tue, 01 Sep 2026 20:21:00 +0000

Every "best Telegram games" list answers the same question: is this game any good. None of them answer the question two people actually have, which is whether the thing will work for two people -- in the chat they are already in, without stopping to create a group, name it, and add a bot to it.

That gap is not cosmetic. I have now tested these bots twice, and the failure mode for a pair of friends is not a bad game, it is a lobby that says waiting for players and never fills. So on 1 September 2026 I ran a third pass over the eleven bots that were still alive when I retested them on 30 August, asking one thing of each: can exactly two people play you, right here, with no group?

Four can. Four refuse without a group. Three will happily play, but not with the person you wanted to play with.

Guessing commands would have measured my guesses, so the probe reads each bot's own declared command list -- the menu Telegram shows when you type / in a chat, which the bot registers with Telegram itself -- and picks the start-a-game command out of that. UNO declares /new, Werewolf declares /startgame, Chat Against Humanity declares /xyzzy_start. Nothing was invented; if a bot declared no such command, the probe recorded that instead of inventing one.

The other rule carried over from the August run: only messages newer than the ID already sitting in the chat count as a reply. Without that, an old greeting left over from a previous visit makes a switched-off bot look like it answered. Two of these chats would have produced exactly that false positive.

Both passes and the final verdicts. Every row is read from the run's JSON, not typed in -- including the two verdicts the first pass got wrong.

Five bots gave a clean answer immediately. Six came back unclear -- and that word is a fact about my probe, not about the bots. Every one of the six had stopped at a gate rather than at an answer: Arena Game, xoBot and PokerBot open with a language selector, GameBot opens with a button menu and no prose, and ChessBot answered " You have an active game. You can /stop it" -- leftover state from a visit weeks earlier.

A gate is not a result. So the second pass clicks through it the way a person would: press the English button, clear the stale game, then read what is behind it. That is where the actual answers were.

Before the table, the corrections -- because they are the reason I trust the rest of it.

Quizarium was classified as playable in a DM. It is the opposite. Its reply reads: " you can use it only within a group chat… If you want to play alone, you still should create a group chat with me and you in it." My classifier saw the phrase play alone , matched its solo pattern, and ranked it above the group pattern that fired on the same sentence. A mandatory group beats a solo affordance every time; ranking them the other way turned the strictest bot in the set into the friendliest one.

Werewolf was classified as unclear. It gave the clearest answer of all eleven: " You must run this command in a group." Seven words, unambiguous, and my patterns did not include that phrasing, so the one bot that said exactly what I was asking got filed as a mystery.

Both were caught by reading the raw replies next to the verdicts instead of accepting the verdict column, and both are now fixed -- verified by re-running the corrected rules over the same captured text , which moved precisely those two bots and nothing else. If a summary and the underlying evidence disagree, the summary is the thing that is wrong.

A third blind spot, worth knowing if you ever script Telegram. After clicking through xoBot's language menu, my reader saw no new message and recorded a blank. The menu was there the whole time -- xoBot edits its own message in place rather than sending a new one, so a reader that only counts new message IDs is structurally blind to it. The same discipline that stops dead bots looking alive creates a hole where in-place edits live. I only found the switch-inline button that decides xoBot's verdict by re-opening the chat and looking at the message itself.

Bot	Game	Two friends, no group?	What it actually said or did
@gamebot	Telegram Gaming Platform	Yes	Menu is a single Play with friends switch-inline button
@xoBot	Tic tac toe	Yes	Play with friend switch-inline button, behind an edited message
@wordibot	Word guessing	Yes	"You can play it in private chat with your friends" + switch-inline button
@RatherGameBot	Would You Rather	Yes	Names inline mode in `/start`: type the @username "to play against a friend"
@ChessBot	Chess	Vs the engine	`/start` deals a board immediately; only `/start` and `/stop` exist
@PokerBot	Texas Hold'em	Strangers	"play… with real players" -- matchmaking, not an invite
@ArenaGameTelegramBot	Arena RPG	Strangers	Solo grind plus an `/arena` queue against whoever is in it
@unobot	UNO	Group	"1. Add this bot to a group… after at least two players have joined"
@QuizariumBot	Quizarium	Group	"only within a group chat" -- and a group even to play alone
@werewolfbot	Werewolf	Group	"You must run this command in a group"
@chat_against_humanity_bot	Cards Against Humanity	Group	"add me to a group chat, and type /xyzzy_start"

The middle three deserve their own row rather than a yes or a no, because a list that calls PokerBot a two-player game is technically right and practically useless. You can play poker on it tonight. You cannot play poker on it with your friend , because there is no invite -- you are dropped into a table of strangers. Chess is the same shape in the other direction: a perfectly good game against the engine, no way to hand the other side of the board to a person.

This is the finding I did not expect. Every one of the four is playable by two people through inline mode -- Telegram's mechanism for summoning a bot into a conversation without that bot being a member of it. In the raw data it shows up as a button of type KeyboardButtonSwitchInline, which is the API's way of saying " put my @username in the user's chat box and let them pick". Three of the four expose it as a literal button labelled some variation of Play with a friend ; RatherGameBot describes it in words instead.

Not one of the four needs you to add anything to anything. And not one of the group-only four has that button at all -- they are lobby moderators, built to post into a room and track whose turn it is, which requires a room. That is a design decision from an earlier era of Telegram, and it is why inline mode exists: bots that work inside a conversation instead of joining it. Telegram introduced it back in 2016, and the surviving game bots split almost perfectly along the line of who adopted it.

Open the chat with the person you want to play. Not a group -- the normal one-to-one chat you already have.
Type the bot's username followed by a space: @xoBot. A popup appears above the keyboard.
Pick the game from the popup. It posts into your conversation, and both of you tap the board in the message.

If nothing pops up, that bot has no inline mode and no amount of retrying will produce one -- check the table above rather than assuming you mistyped. The one genuine annoyance is that inline results are cached, so a bot you tried a minute ago sometimes shows a stale menu; retyping the username usually clears it.

The honest answer above is that the bot ecosystem is thin for pairs -- four working options, and two of them are tic tac toe and word guessing. The Telegram Party Pack is the no-bot route: 255 prompts across six games as copy-paste blocks, plus the poll, spoiler-tag and threading mechanics that make a round work in a chat where nobody is in the same room. It scales down to two people and up to a full group, and nothing in it can be switched off by someone else's server. PDF included.

Get the pack -- $9.99 Every bot above stays free -- they are not mine to sell. See what's in the pack before you buy.

A group of two is a legal group. If you specifically want UNO or Cards Against Humanity with one other person, nothing stops you creating a group containing exactly the two of you and the bot. UNO explicitly says it starts "after at least two players have joined", so two is enough for it. Werewolf is the exception -- a social-deduction game needs a crowd to deduce against, and no amount of group-creating fixes a two-person Werewolf night.

Telegram 's own games need no bot at all. Send the dice, darts, basketball, football, bowling or slot-machine emoji into any chat, including a one-to-one, and Telegram animates a real random result. I threw each of them 900 times to check they were not weighted; every one is statistically indistinguishable from a fair draw. For two people that is the lowest-friction game on the platform: first to three bullseyes, highest roll picks the film, best of five at bowling. Nothing to add, nothing to configure, nothing that can be switched off next spring.

Three passes over these bots have now produced three different findings, and they stack into one point. In July, seven of eighteen recommended bots were already dead. In August the score held at eleven alive but the names underneath it moved , and none of the eleven had a Mini App. Tonight: of those eleven survivors, fewer than half work for the most common social configuration there is -- two people.

None of that is visible from a listicle, because a listicle records that a game exists and is fun. It does not record whether the server is still on, whether the bot has followed the platform for the last five years, or whether the game needs more people than you have. Those are the three things that decide whether your evening works, and all three take under a minute each to check yourself.

So the durable advice is the same as last time, with one addition. Send /start and wait fifteen seconds -- that catches the dead ones. Then type the bot's @username into your chat box -- if a popup appears, the two of you can play right here; if it does not, budget for a group. Both checks together cost less time than reading the article that recommended the bot.

More on running one of these with actual humans: how to run a Telegram game night, and the party games worth playing in 2026.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Mon, 31 Aug 2026 20:25:06 +0000

Almost everyone who uses Telegram has sent the die emoji at some point and watched it roll. Far fewer people know that there are six of these, that they work in any chat with no bot and no setup, and that the number is decided by Telegram's server before the animation even starts.

And as far as I can tell, nobody has bothered to check whether they are fair.

That is not an academic question. In practice these get used to decide things -- who pays the bill, who goes first, who does the forfeit. If you are settling a bill with a die emoji you are trusting a random number generator you have never seen, in an app that has every commercial reason to make its animations feel exciting rather than be flat.

So I threw 900 of them and counted every single result.

The short version: all six are statistically indistinguishable from a fair draw, there is no house edge and no streak-breaking, and the slot machine's mysterious 1-64 number turns out not to be a score at all. It is three reels packed into one integer -- which means the jackpot is 1 in 16, not 1 in 64 , and most people playing it have the odds wrong by a factor of four.

Here is the full set, with the range each one returns:

Emoji	Game	Returns	What a high value means
🎲	Die	1-6	The face shown, exactly like a real die
🎯	Darts	1-6	6 is the bullseye, 1 misses the board
🎳	Bowling	1-6	6 is a strike, 1 is a gutter ball
🏀	Basketball	1-5	4 and 5 go in, the rest miss
⚽	Football	1-5	3, 4 and 5 are goals
🎰	Slot machine	1-64	Three reels -- see below, it is not a score

The practical detail that most round-ups skip: the emoji has to be the entire message. Send 🎲 on its own and Telegram treats it as a throw, animates it, and everyone in the chat sees the same result. Type "let's roll 🎲" and it stays an ordinary emoji sitting in a sentence. That single rule is the difference between "this doesn't work on my phone" and a working game.

It works in a direct message, in a group, in a channel, and in your own Saved Messages. No bot is involved at any point.

Because the result is not generated on your phone. Telegram's own protocol documentation describes the dice as a media type where the server sends back a value field alongside the emoji -- the outcome arrives with the message. The animation you watch for two seconds is a replay of a decision that was already made.

That is the right design -- it is the only way everyone in a group sees the same roll -- but it does mean the number is entirely Telegram's to choose. Nothing about the interface lets you verify it. So the only way to find out is to throw a lot of them and count.

I used Telegram's client protocol to send throws automatically and record what came back. Three decisions shaped the test:

Everything went into Saved Messages. That is my own cloud storage -- no other human received a single one of the 900. Flooding somebody's DM with hundreds of dice to satisfy my curiosity was not on the table, and a throwaway group was not available either: my account has been spam-limited at the account level since late July, so Telegram refuses to let it create new groups or channels. Saved Messages sidesteps both problems, and afterwards the script deletes exactly the messages it sent, by ID.

Throws were paced half a second apart. Not for politeness -- for validity. Hammering the endpoint invites rate limiting, and a run that silently drops throws produces a distribution with holes in it that look like findings.

The value is read from the stored message, not from the send confirmation. This one I got wrong first and had to fix. My initial version read the result off the response to each send, and it crashed partway through the run: the library I was using could not parse one of the objects Telegram returned, because the server's schema has moved on since that library's last update. The throws themselves had landed perfectly -- 20 dice were sitting in the chat when I went to look. So I rebuilt the probe to fire the throws, tolerate the unparseable response, and then read the values back out of the chat history afterwards. Same authoritative field, via a path that works. Any throw whose message cannot be found afterwards is counted as lost rather than quietly folded into the tally; the final run lost zero of 900.

The actual run. 500 throws across five games, then 400 slot machine spins, then the fairness test.

Here is what 100 throws of each game produced.

Look at the football row and you will see why counting alone is not enough. A goal-scoring 5 came up 28 times out of 100, against an expected 20. That looks like a thumb on the scale -- the app flattering you with goals.

It is not. The question a statistician asks is not "did every outcome come up equally often", because with 100 throws it never will. The question is whether the gap between what you saw and what you expected is larger than random sampling would routinely produce. That is what a chi-squared goodness-of-fit test measures, and for football it returns 4.50 against a threshold of 9.488. Well inside noise.

All five passed, none of them close to the line. The full set of chi-squared values: die 3.32, darts 4.88, bowling 2.00, basketball 1.60, football 4.50 -- against a threshold of 11.07 for the six-sided games and 9.49 for the five-sided ones.

The slot machine got 400 spins instead of 100, because 64 possible outcomes need more data than six do. Every single value from 1 to 64 appeared at least once, and the distribution across all 64 came out at 50.24 against a threshold of 82.53. Also fair.

So: no house edge that a sample this size could detect, no outcome that never appears, no evidence of the app deciding anything. If you use 🎲 to pick who pays, it is picking honestly.

This is the part I did not expect to find, and it is the one thing here with real practical consequences.

The slot machine returns a number from 1 to 64, and if you have ever wondered what your 43 meant, the answer is that it is not a score and there is no "better" or "worse" 43. Subtract one, and read the result as a three-digit number in base 4. Each pair of bits is one reel; the four symbols are bar, berries, lemon and seven.

That is a claim, so I checked it two ways against the 400 spins.

Check one: if the decode is right, each reel independently must land on each of its four symbols about a quarter of the time. Decoded, reel one came out 26.0 / 25.8 / 23.8 / 24.5 per cent across the four symbols. Reels two and three landed in the same neighbourhood.

Check two, the one that settles it: the decode says exactly four of the 64 values are three-of-a-kind -- values 1, 22, 43 and 64. That predicts a jackpot rate of 4/64, which is 6.25 per cent. Over 400 spins I recorded 25 jackpots. That is 6.25 per cent, to the decimal.

Predicted 6.25 per cent, measured 6.25 per cent. The 1-64 value is three reels packed into one integer.

Two things follow, and both contradict what people assume:

The jackpot is 1 in 16, not 1 in 64. There are four winning combinations, not one. Spin the slot machine sixteen times and you should expect to see three-of-a-kind once.
Three sevens is not the rare one. Value 64 is seven-seven-seven and value 1 is bar-bar-bar, and they are exactly equally likely -- as are three lemons and three berries. In my run, berries actually came up most often (8 times against sevens' 7), which is noise, but noise that only makes sense once you know all four are equiprobable.

The free Telegram Game Night Planner turns all of this into a timed night you can paste straight into a group chat -- rounds, host lines and poll questions with the options already separated. No signup, runs in your browser.

Build a game night -> Or play the free Tech Quiz Mini App if you want something already built.

Four things I would now do differently:

Use the dice for real decisions without hedging. Who pays, who goes first, who picks the film. It is a fair draw, and unlike a physical die in a video call, everybody sees the same result at the same time with no argument about camera angles.

Rotate between 🎲, 🎯 and 🎳 freely. All three return 1-6 with the same flat distribution, so they are drop-in replacements for one another. Using a different one each round is pure variety at zero cost to fairness.

Do not use basketball or football for a 1 -6 decision. They only go up to 5. It sounds obvious written down, and it is exactly the kind of thing nobody notices until two people roll and someone insists there must have been a six.

The slot machine makes a decent jackpot round. At 1 in 16, a group of eight each taking one spin has roughly a 40 per cent chance that somebody hits three-of-a-kind -- frequent enough to be worth playing for, rare enough to feel like something.

Three honest limits on the above.

I measured numbers, not animations. The mapping in my first table -- darts 6 is a bullseye, bowling 6 is a strike, basketball 4 and 5 go in -- comes from Telegram's Bot API documentation, not from my run. What I can say from the data is that every value in every documented range does occur, so no outcome is unreachable. I did not sit and watch 900 animations to confirm which one draws which frame.

100 throws catches a gross bias, not a subtle one. If Telegram shaved two or three percentage points off some outcome, a sample this size would not reliably see it -- you would need thousands of throws per game. "Fair" here means "no detectable bias at this sample size", which is a real result but not a proof.

The schema is moving. Telegram's protocol definition for animated dice now carries a game_outcome field on the dice media object alongside value -- newer than the library I was throwing with, which is part of why my first run crashed. The outcome looks to be becoming something the server states explicitly rather than something clients infer from the number. Nothing in my results depends on that, but if you go and measure this yourself in a year, expect the shape to have changed.

One distinction worth carrying around. A bot can send a real 🎲 -- it is the same server draw, equally fair. But a bot that tells you the result in text ("You rolled a 5!") generated that number itself, and you have no way to check it. If it matters, look for the animated emoji rather than a sentence. Related: I messaged 18 recommended game bots and seven never replied -- a bot's fairness is moot if its backend is switched off.

You do not need my script. Open Saved Messages, send each of the six emoji on its own, and you have verified the mechanism in about fifteen seconds. To test fairness you need volume and a tally, which means automating it -- and if you do, throw into your own Saved Messages rather than a group, pace the sends, and read the values back out of the chat rather than trusting the send response.

The most useful thing you can do with fifteen seconds, though, is simply learn that there are six of these. Most people are still only using one.

Dice are the easy part. A group is a different problem: people answer forty minutes apart, and a round falls apart the moment two replies land at once. The Telegram Party Pack is built for that -- 255 prompts across six games, a host guide for a 60-minute night in a chat, and the poll, spoiler-tag and threading mechanics that keep a round readable when nobody is in the same room. Copy-paste blocks for every round, PDF included.

Get the pack -- $9.99 The emoji games above stay free forever -- they are Telegram's, not mine. See what's in the pack before you buy.

More on the games themselves: the party games worth playing on Telegram, and how to actually run a game night in a group chat.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

charlie-morrison — Wed, 26 Aug 2026 20:46:10 +0000

Most Bot API methods are interesting when they fail. Editing is the one where success is the problem.

A bot that edits its own messages -- a live scoreboard, a progress bar, a menu that changes as you click through it -- will at some point call editMessageText, get 200 OK, and quietly ship a message missing something the user was relying on. Nothing in the response says so.

So I measured the surface against a live throwaway bot: what an edit compares, what it replaces, which method applies to which message, the length boundaries, and what a delete does when you call it twice. Every verdict below was read back from the returned Message object rather than inferred from ok: true, and the finding this post is named after got an independent control run before I was willing to write it down.

A no-op edit is an error , and the thing it compares is the content and the reply markup as a pair -- not the text.
An edit that omitsreply_markup deletes the inline keyboard. 200 OK, buttons gone.
The edit method is fixed by how the message was sent , not by what it currently contains.
The length limits on an edit are the send limits -- 4096 for text, 1024 for a caption, and both refuse rather than truncate.
deleteMessage is not idempotent. The second call is a 400.

Verbatim verdicts from the run. The red lines are the failures you catch in testing. The yellow line is the one that reaches production.

One demo bot with nothing in production behind it, one private chat, and a standard-library probe. Each phase sends a fresh message, acts on it, and reads the resulting Message object; every message created is deleted at the end, in a finally block so a crash mid-run still cleans up.

Transport errors are retried, so a network timeout can never be recorded as an API verdict -- a timeout logged as a measurement is worse than no measurement at all. A Telegram-level error, meaning an HTTP 400 with a JSON body, is treated as data rather than as a failure. That distinction is the whole point of the exercise: the 400s are the documented, honest half of this API.

Send a message, then edit it to exactly the text it already has:

400 Bad Request: message is not modified: specified new message content
and reply markup are exactly the same as a current content and reply
markup of the message

The first half of that is widely known and widely worked around with a try/except that swallows it. The second half is the part worth reading, because the error string is unusually forthcoming: it names content and reply markup , together. That is the comparison.

Which predicts something testable. If Telegram compared the text alone, then re-sending the same text with a different keyboard would still be "not modified". It is not:

Edit	Result
Same text, same markup	400 `message is not modified`
Same text, new markup	200 OK -- markup stored
Changed text	200 OK

This matters for a very common bot shape: the message whose text is a fixed prompt and whose keyboard is the state -- a quiz that says "Pick one" above four options, a paginated list with a static header, a settings panel. All of those update the markup while the text stays put, and none of them will ever hit "not modified", as long as the keyboard genuinely differs.

The inverse is where it bites. A bot that re-sends the same keyboard on every tick -- a refresh loop, a poller that redraws unconditionally -- hits 400 on every tick where nothing changed. That is not a bug to suppress; it is the API telling you that you are making a network call to change nothing.

This is the finding the post is named after, and the only one here that will not show up in your tests.

Take a message that has an inline keyboard. Edit only its text, the way you would naturally write it -- chat id, message id, new text, done:

editMessageText(chat_id=..., message_id=..., text="updated")
-> 200 OK
-> reply_markup in the returned Message: absent

The buttons are gone. The call succeeded. Nothing warned you.

The mental model that produces this bug is that an edit is a patch -- you name the field you want changed and the rest is left alone. It is not. The editMessageText documentation lists reply_markup as an ordinary optional parameter, and an omitted optional parameter reads naturally as "leave it". What actually happens is that the edit replaces content and markup as a unit, and an absent keyboard is a keyboard set to nothing.

I did not want to publish that on the strength of one absent field in one response, because "the response object didn't include it" is weaker evidence than it looks -- APIs omit empty fields for all sorts of reasons. So I ran a discriminator.

After the markup-omitted edit, re-apply the same keyboard the message originally had. There are only two possible outcomes, and they disagree:

If the keyboard is still on the message, re-applying it changes nothing -> 400 message is not modified.
If the keyboard was removed, re-applying it is a change -> 200 OK.

Result: 200 OK. The keyboard was genuinely gone.

And because a discriminator that always returns OK would prove nothing at all, the same call went to a second message that had been left untouched -- same keyboard, never edited. That one returned 400 message is not modified, exactly as it must if the test is measuring what I claim. Both halves agree: the markup-omitted edit removed the keyboard.

The practical rule: if a message has an inline keyboard and you are editing its text, send the keyboard again in the same call. Not because the API is broken -- because "edit" here means "replace", and every field you leave out is a field you cleared.

The production failure is quiet and delayed. The user sees the new text arrive, correctly, and the buttons they were about to press are simply gone. There is no error in your logs to correlate it with, because there was no error -- the same class of problem as an oversized inline keyboard being silently truncated instead of rejected.

The deliberate version is editMessageReplyMarkup with an empty inline_keyboard. In my run it returned message is not modified -- because the previous phase had already removed the keyboard, so an empty markup was no change at all. That error is a consequence of the finding above, not a separate rule. On a message that still has its buttons, the same call clears them and returns 200.

A photo with a caption and a text message look similar in a chat and are not interchangeable to the API:

Call	Target	Result
`editMessageText`	photo message	400 `there is no text in the message to edit`
`editMessageCaption`	photo message	200 OK
`editMessageCaption`	text message	400 `there is no caption in the message to edit`

The symmetry is the useful part. Neither method degrades into the other, and the error text tells you precisely which assumption you got wrong. Whether a message carries text or a caption was decided at send time and an edit cannot change it.

Generic code is where this surfaces -- a helper handed a stored message_id that does not track whether the id came from sendMessage or sendPhoto. If you keep message ids in a database in order to edit them later, keep the message type next to the id. The API will not infer it for you.

No surprises here, which is itself worth recording -- an edit does not get a different budget:

Edit to	Result	Stored
Text, 4096 chars	200 OK	4096
Text, 4097 chars	400 `MESSAGE_TOO_LONG`	unchanged
Text, empty string	400 `message text is empty`	unchanged
Caption, 1024 chars	200 OK	1024
Caption, 1025 chars	400 `MEDIA_CAPTION_TOO_LONG`	unchanged

Every one refuses rather than truncating, and the previous content survives -- the same all-or-nothing behaviour the 4096-character limit shows on a send. A bot that grows a message by appending, such as a running log, therefore does not degrade at the ceiling: it stops updating, at full length, until someone notices.

One detail for anyone matching on error strings: the style is inconsistent. MESSAGE_TOO_LONG and MEDIA_CAPTION_TOO_LONG are uppercase constants, while message text is empty is lowercase prose. Both arrive in the same description field. Match the substring you actually saw; do not assume a house style exists.

The identity of the message is stable, which is the reassuring result of the set:

message_id is unchanged -- a stored reference stays valid across any number of edits.
The original date is preserved. An edit does not re-stamp the message as new.
An edit_date field appears on the returned object. That is what a client uses to show the "edited" marker, and it is a reliable way for your own code to tell an edited message from a fresh one.

deleteMessage returns true, and then:

Call	Result
Delete	200 OK, `result: true`
Delete the same message again	400 `message to delete not found`
Edit a deleted message	400 `message to edit not found`

So deletion is not idempotent, which is an awkward property for cleanup code. The realistic path to hitting it is a retry, not a double-click: your delete succeeds on Telegram's side, the response is lost to a timeout, the retry fires the same call, and the second attempt returns 400. A wrapper that treats any non-2xx as a failure will report a cleanup that worked as an error -- the retry manufactures a problem out of a success.

Treat message to delete not found as a synonym for "already gone" in cleanup paths. The deleteMessage reference is worth reading for its other constraints too -- the ones about message age and permissions, which is where the next section starts.

There is a widely repeated claim that a bot cannot edit or delete a message older than 48 hours. I cannot confirm or deny it from this run, and I am not going to repeat it as though I had.

The reason is structural rather than an oversight: a single run cannot produce a 48-hour-old message. Reaching backwards instead -- editing and deleting very low message ids in the same chat -- returns message to edit not found and message to delete not found, which is the absence error, not an age error. Those ids never existed there, so the test measured nothing about age.

What it does establish is that "not found" means "no such message" rather than "too old to touch". If you are handling the age rule, do not key on that string -- it answers a different question. The clean measurement needs a message left in place and re-probed two days later.

Re-sendreply_markup on every text edit of a message that has buttons. The single highest-value line in this post. Omitting it clears them, silently.
Store the message type alongside the message id if you plan to edit later. Text and caption are not interchangeable and the API will not guess.
Do not blanket-suppressmessage is not modified. It is a signal that a redraw path is firing when nothing changed -- on a rate-limited API, that is wasted budget. It is also harmless to hit deliberately, so it makes a cheap change-detector.
Treat "message to delete not found" as success in cleanup and retry paths.
Match error substrings, not error styles. Some are uppercase constants, some are prose.

If you work through a library rather than raw HTTP, the same rules apply underneath -- wrappers such as python-telegram-bot's Bot class pass reply_markup straight through, so an omitted argument is an omitted parameter on the wire, with exactly the effect above.

The measured limits, the failure modes and the boilerplate that survives them: escaping, rate limits, update queues and webhook handling, in one pack.

Get the pack -- $19

Why does Telegram say "message is not modified"?

An edit that changes nothing is an error rather than a no-op. The error text names both halves of the comparison -- content and reply markup -- and Telegram compares the pair. The same text with a different keyboard succeeds; the same text with the same keyboard is a 400.

Does editMessageText remove the inline keyboard?

Yes, if you omit reply_markup. An edit replaces content and markup together rather than patching the text, so an absent keyboard means no keyboard. The call returns 200 OK and the buttons are gone. Send the keyboard again with the edit to keep it.

Can I use editMessageText on a photo?

No -- it returns there is no text in the message to edit. Use editMessageCaption. The mirror holds as well: editMessageCaption on a plain text message is refused the same way. Which method applies is decided by how the message was sent.

What is the maximum length when editing a message?

The send limits, unchanged: 4096 characters of text (4097 gives MESSAGE_TOO_LONG) and 1024 characters of caption (1025 gives MEDIA_CAPTION_TOO_LONG). Both refuse rather than truncate, and an empty string is rejected outright.

Does editing change the message_id?

No. The message_id and the original date both survive; Telegram adds an edit_date field. Stored references remain valid across any number of edits.

Is deleteMessage idempotent?

No. The second delete returns message to delete not found. This is most often reached by a retry after a lost response, so cleanup code should treat that error as "already gone" rather than as a failure.

Can a bot edit a message older than 48 hours?

I did not measure it -- a single run cannot age a message two days. Editing a non-existent id returns message to edit not found, which is the absence error and says nothing about age. Do not key age handling on that string.

More measurements from the same bot: the inline keyboard caps that truncate instead of erroring, the command list that refuses 101 entries and silently rewrites two things, and which MarkdownV2 characters break a message and which delete it -- the last one matters here, because an edit re-parses your entities from scratch.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Mon, 24 Aug 2026 20:37:24 +0000

The command menu is the one part of a Telegram bot that users see before they type anything. It is also configured through an endpoint that answers true and moves on, which means the list you sent and the list your users get are two different objects that you have no particular reason to compare.

So I compared them. Every case below was set with setMyCommands and then read back with getMyCommands before anything was concluded about it, because a boolean return value is not evidence about state.

Four behaviours came out of it. Two are loud, well-documented 400s. Two are 200 OK with a menu you did not send.

The 100-command ceiling is a wall, not a truncation. 101 commands are rejected outright and your old menu survives untouched.
The charset is enforced, not normalised. Help is refused. It is not lowercased for you.
A leading slash is silently stripped. /help goes in, help comes out.
Duplicate names are silently deduplicated , and the last description wins.

Verbatim verdicts from the run. The red block is what the API tells you about; the yellow block is what it does without telling you.

One throwaway demo bot with nothing in production behind it, and a probe that is standard library only. Each phase sets a list, reads it back, records the pair, and clears the list before the next phase so that no phase inherits the previous one's state.

That last detail matters more than it sounds. The command list is bot-wide persistent server state, not a per-request parameter. A phase that forgets to clean up does not fail -- it silently contaminates the phase after it, and you get a result that is real but is about the wrong input.

The setMyCommands documentation states at most 100 commands, and that is exactly right. What it does not say is what happens on 101, and there are two plausible answers with very different consequences.

Commands sent	Response	Commands stored
1	200 OK	1
50	200 OK	50
100	200 OK	100
101	400 `BOT_COMMANDS_TOO_MUCH`	0 -- nothing changed
150	400 `BOT_COMMANDS_TOO_MUCH`	0 -- nothing changed

It refuses. The whole list is rejected as a unit, and the bot keeps whatever menu it already had.

This is worth dwelling on because it is the opposite of how the neighbouring endpoint behaves. An inline keyboard past its limit is truncated in silence -- 4000 buttons in a row return 200 OK with 12 stored. Same API, same kind of oversized array, and the failure modes are mirror images: the keyboard gives you a success and less data than you sent, the command list gives you an error and no change at all.

Refusing is by far the friendlier of the two, but it has a failure mode of its own, and it is a deployment-shaped one. A bot that generates its command list dynamically -- one entry per configured workflow, per tenant, per feature flag -- crosses 100 on a Tuesday, gets a 400 during startup, logs it at whatever level your framework picked, and carries on serving a menu that is now several releases stale. Nothing is broken. The menu is simply frozen at the last list small enough to fit, and every user sees a version of the bot that no longer exists.

The documented rule is lowercase English letters, digits and underscores, 1 to 32 characters. Every part of that is true and enforced, and the important word is enforced.

Command sent	Result
`help`, `top10`, `my_cmd`	accepted, stored verbatim
`1cmd`	accepted -- a digit may lead
`Help`, `HELP`	400 `BOT_COMMAND_INVALID`
`my-cmd`, `my.cmd`, `my cmd`	400 `BOT_COMMAND_INVALID`
Cyrillic, emoji	400 `BOT_COMMAND_INVALID`
`""`	400 command must be non-empty
33 characters	400 command length must not exceed 32

Uppercase is the one that catches people, because Telegram itself is case-insensitive when a user types a command -- sending /HELP in a chat reaches a bot that registered help. It is easy to generalise from that to "the API will lowercase my list for me". It will not. It rejects the entire call, which means one capital letter in one generated entry takes down the whole menu update, not just its own row.

If your command names come from anything user-editable or config-editable -- a tenant name, a workflow slug, a YAML file someone hand-writes -- normalise before you send: lowercase it, replace anything outside [a-z0-9_], truncate to 32, and drop entries that end up empty. The API's answer to a bad name is to discard the good ones next to it.

Non-English commands are simply not possible. The description field takes any Unicode you like, so a Ukrainian or Arabic bot can have a fully localised menu of descriptions hanging off ASCII command names, and that is the only shape available.

The measured limits, the failure modes and the boilerplate that survives them: escaping, rate limits, update queues and webhook handling, in one pack.

Get the pack -- $19

Everything above announces itself. These two do not.

Send {"command": "/help"} and the call succeeds. Read it back and the stored command is help. The slash is a display convention, not part of the name, and the API quietly normalises it away.

On its own this is harmless -- arguably it is the API being helpful. It stops being harmless the moment you write the obvious reconciliation check:

sent = [{"command": "/help", "description": "Show help"}]
bot.set_my_commands(sent)
live = bot.get_my_commands()
assert [c.command for c in live] == [c["command"] for c in sent]  # fails

The assertion fails on a bot that is configured perfectly correctly. Which way you resolve that matters: strip the slash in your own comparison, rather than "fixing" it by sending the slash-prefixed form everywhere, because the difference is only ever cosmetic and the check is the thing you actually want to keep.

This is the one I would not have gone looking for. Send three commands where two share a name:

[{"command": "same",  "description": "first"},
 {"command": "same",  "description": "second"},
 {"command": "other", "description": "third"}]

The response is 200 OK. The stored list has two entries: same with the description second , and other. The first occurrence is gone, and nothing in the response mentions that the list shrank.

Duplicates are not something anyone writes deliberately, which is exactly why this bites -- they arrive from merging. A base command set plus a per-tenant set, a default menu extended by a plugin, a list assembled by concatenating two config files. The merge produces a collision, the collision resolves to whichever entry was appended last, and the menu ends up describing a command differently from what the code that registered it first believed.

Order is otherwise preserved exactly. Sending zebra, alpha, middle stores zebra, alpha, middle -- no alphabetical sort, so the sequence in the menu is the sequence in your array and it is yours to control.

Less exciting, and it behaves exactly as advertised: 1 to 256 characters, both boundaries hard.

Description length	Result
0	400 command description must be non-empty
1	accepted
256	accepted
257	400 command description length must not exceed 256

An empty description is a 400 rather than a shrug, which is the right choice and worth knowing if you build descriptions from a translation catalogue: a missing key that resolves to "" takes down the entire setMyCommands call, not just its own entry. In practice 256 is far more room than the menu can display comfortably; the useful limit is closer to whatever fits on a phone.

Command scopes let you show different menus to different chats, and the mechanism is layered rather than destructive.

Action	Default scope	Chat scope
set default `[global1]`	`[global1]`	--
then set chat scope `[local1]`	`[global1]`	`[local1]`
then delete chat scope	`[global1]`	`[]`

Writing a chat-scoped list leaves the default completely intact, and deleting the chat scope leaves the default intact too -- that chat simply falls back to it at display time. So the scoped list is an override, and removing an override is safe.

One consequence to keep in mind when debugging: getMyCommands with no scope argument returns the default scope, not "the commands this user sees". If a tester reports the wrong menu, querying the bare endpoint will happily show you a correct-looking list while the chat-scoped override that is actually being displayed sits somewhere you did not ask about. Pass the same scope you are debugging.

For teardown, deleteMyCommands and setMyCommands with an empty array are equivalent -- both leave getMyCommands returning []. Use whichever reads better; there is no hidden difference between them.

Normalise command names before sending. Lowercase, strip to [a-z0-9_], cut to 32 characters, drop empties. One bad name rejects the whole list, so this is cheap insurance on any dynamically built menu.
Deduplicate your list yourself, and decide which one wins. The API's answer is "the last one", chosen for you and applied without comment. If you merge command sets from more than one source, collapse collisions where you can still see them.
Treat a failedsetMyCommands as a real error at startup. The call failing does not degrade the bot in any visible way -- it just freezes the menu. That makes it precisely the kind of failure that gets logged at warning and lives for months.
Read the list back once in your test suite. Compare with the slash stripped, and assert on the length too. Both silent rewrites on this page show up instantly in a round-trip and never show up in a return value.

That last habit is the one that keeps paying out across this whole API. Most libraries -- python-telegram-bot among them -- return the API's boolean straight through, so True is the most any wrapper can honestly give you. It means the request was accepted. Whether the menu now matches the array you built is a separate question, and there is exactly one way to answer it.

How many commands can a Telegram bot have?

One hundred. 101 returns BOT_COMMANDS_TOO_MUCH and the whole list is rejected, so the previous menu stays live. There is no truncation to 100 -- it is all or nothing.

Why does setMyCommands return BOT_COMMAND_INVALID?

A command name contains something outside lowercase ASCII letters, digits and underscores. Uppercase is the usual culprit and is refused rather than lowercased; hyphens, dots, spaces, Cyrillic and emoji fail the same way. A digit may lead, so 1cmd is fine.

Should I include the slash in setMyCommands?

You can -- /help is accepted and stored as help. The slash is stripped silently, so any code comparing sent against stored needs to strip it too or it will report a mismatch on a correctly configured bot.

What happens if two commands share a name?

The call succeeds and the list is deduplicated without warning. The description from the last occurrence survives. Watch for this when merging command sets from multiple sources.

How long can a command and its description be?

Command 1-32 characters, description 1-256. All four boundaries return a clear 400 when crossed, and empty values for either field are refused.

Does a chat-scoped command list delete the global one?

No. Scopes shadow rather than replace: the default scope keeps its own list, and deleting a chat scope leaves the default untouched so that chat falls back to it.

Can Telegram bot commands be non-English?

The names cannot -- they are ASCII only. Descriptions accept any Unicode, so a localised menu means English command names with translated descriptions.

Is deleteMyCommands different from sending an empty array?

No. Both leave getMyCommands returning an empty list, for the same scope.

More measurements from the same bot: the inline keyboard caps that truncate instead of erroring -- the mirror image of this endpoint -- plus which MarkdownV2 characters break a message and which delete it and which errors arrive before Telegram checks your chat exists.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Wed, 19 Aug 2026 20:21:25 +0000

The Bot API documentation has one sentence about MarkdownV2 that every bot developer has read and nobody has tested: eighteen characters "must be escaped with the preceding character \". It lists them, it moves on, and it treats all eighteen as the same kind of problem.

They are not the same kind of problem. I sent 126 live sendMessage calls at the API to find out where the differences are, and the split that came back is the one that actually decides whether a bug reaches your users:

Fourteen of the eighteen fail with a 400. Loud, logged, impossible to miss.
Four of them are accepted when the string contains two of the same character, and both characters are silently removed from the message that gets delivered.

A 400 is a bad afternoon. A message that sends successfully with pieces missing is a bug that survives your tests, your staging bot and your logs, and shows up as a support ticket six weeks later about a user whose name renders wrong.

Verbatim output from the probe. One occurrence of a reserved character always fails; two occurrences fail for fourteen of them and disappear for four.

Two days ago, while measuring inline keyboard limits, I found that the Bot API answers structural errors before it checks whether your chat exists. That turned out to apply to parse errors too, and it makes this kind of probing much cheaper than it sounds.

$ sendMessage chat_id=1 parse_mode=MarkdownV2 text="a.b"
   Bad Request: can't parse entities: Character '.' is reserved
                and must be escaped with the preceding character '\'

$ sendMessage chat_id=1 parse_mode=MarkdownV2 text="a\.b"
   Bad Request: chat not found

$ sendMessage chat_id=1                      text="a.b"
   Bad Request: chat not found

Chat 1 does not exist. Telegram parses the text first anyway, and only reaches for the chat once the markup is valid. So the second and third lines, both "chat not found", are the control: they prove the request got past the parser. Any string you want to check for parse validity can be checked with a bot token and no conversation at all.

The part I did need a real chat for is the interesting part. When a message is accepted, the API response contains the message object, and result.text holds the visible text with all formatting stripped out. Comparing that string to the string I meant to send is what exposes the silent cases. I used my own account as the target and deleted every accepted message immediately after reading it back.

First pass, one character at a time, in the middle of otherwise boring text: a_b, a*b, a.b, and so on through all eighteen.

All eighteen returned a 400. No exceptions, no partial credit. If you have been carrying a vague suspicion that half of that list is defensive over-documentation, drop it: _ * [ ] ( ) ~ ` > # + - = | { } . ! is a complete and accurate list of what breaks a MarkdownV2 message on its own.

Most of them come back with the same generic line, naming the character. Two do not, and the difference is a small gift when you are debugging:

a]b   Character ']' is reserved and must be escaped with the preceding character '\'
a[b   Can't find end of TextUrl entity at byte offset 1

An opening bracket does not report itself as reserved, because to the parser it is not junk. It is the start of a link that never got finished. The error names the entity it was building and gives you the byte offset where it started. That is the fastest debugging signal in the whole format, and it only appears for characters that open something.

The single-character test is the test everyone runs, and it is the test that hides the problem. Real strings do not contain one underscore. Usernames, filenames, package versions and search queries contain two, three, five.

Second pass, same eighteen characters, this time paired: a_b_c, a*b*c, a.b.c, and so on.

Fourteen of them behave exactly as they did alone, returning a 400 whether they appear once or twice: [ ] ( ) > # + - = | { } . !. The other four do not, and they are the finding:

Character	Paired and unescaped	What arrives
`_`	accepted	`abc` -- italic, underscores gone
`*`	accepted	`abc` -- bold, asterisks gone
`~`	accepted	`abc` -- strikethrough, tildes gone
`	accepted	`abc` -- code, backticks gone

The four are not a random subset. They are precisely the delimiters that have a closing form: italic, bold, strikethrough and inline code all open and close with the same character. Two of them in a row is not a mistake to the parser, it is a complete, well-formed entity. The API has nothing to complain about, so it does not complain -- it does what the markup says, consumes both delimiters, and delivers the remainder.

Everything else on the list is either structural (brackets and parentheses build links, and an unfinished link is an error) or purely reserved, a character with no entity behind it at all, which can only ever be a mistake, which is why the parser can reject it with confidence.

So the rule underneath the docs' flat list is this: a reserved character that can close itself will be obeyed rather than reported.

Nowhere in your own copy. You control your own strings, and you notice a missing asterisk in a template on the first run.

It bites at the join between your template and somebody else's data. A few real shapes:

anna_marie_k, a Telegram username with two underscores. Delivered as annamariek in italics. Now your bot has told a user their handle wrong, and if it also stored what it displayed, wrong in your database.
report_2026_final.pdf -- a filename echoed back in a confirmation. Two underscores, both eaten.
**important** -- a user who pasted Markdown into your bot. Renders bold, both pairs gone.
Search results, product titles, error strings pulled from another service -- anything you did not write yourself.

The failure mode is asymmetric in the worst direction. The fourteen loud characters are far more common in ordinary text than the four quiet ones (a full stop appears in almost every sentence), so the loud ones are what you hit first in development. You will fix it, conclude that unescaped text throws errors, and ship. The quiet four are rare enough to survive to production and common enough to get there eventually.

I ran the same eighteen characters through the deprecated Markdown parse mode for comparison, and the gap is bigger than "V2 is stricter" suggests.

Legacy Markdown rejected exactly four: _, *, [ and `. The other fourteen, including the full stop, the hyphen, the exclamation mark and the plus sign, passed straight through and rendered literally.

That is what makes the upgrade nastier than a version bump. Code that ran clean for years on legacy Markdown has fourteen new fatal characters the moment you change the string Markdown to MarkdownV2, and they are the ordinary ones. The first message with a date in it starts failing. Telegram's own formatting options reference flags V1 as deprecated, but the practical cost of moving is not in the docs: it is a bulk audit of every string you have ever passed to sendMessage.

The docs claim that inside code and pre blocks only the backtick and the backslash need escaping, and that inside a link's (...) only the closing parenthesis and the backslash do. Both claims held on every character I tested:

Code span and pre block. Seventeen of the eighteen were accepted and rendered verbatim. Only the backtick failed, which it must, since it terminates the span.
Link URL. Seventeen accepted, only ) failed. Full stops and hyphens inside a URL need nothing, which is a relief given what URLs look like.

One thing the docs mention that is worth seeing rather than reading: the backslash inside a code span is consumed, not displayed. `a\b` arrives as ab. If you are formatting Windows paths or regular expressions inside code spans, that is the fifth character on the silent list.

A smaller detail, offered because it contradicted my own guess: a lone trailing backslash, ab\, is not treated as an incomplete escape sequence. It is accepted and rendered literally as ab\. I had assumed an error, wrote the assumption into the test as the expected value, and the run told me I was wrong.

Telegram supports three parse modes, and the comparison is not close for untrusted input.

parse_mode=HTML   "if a < b then"      400  Unsupported start tag ""
parse_mode=HTML   "use <b> for bold"   400  Can't find end tag corresponding to...
parse_mode=HTML   "Tom & Jerry"        ACCEPTED  ->  "Tom & Jerry"

Only the less-than sign is genuinely fatal. The ampersand, which every HTML escaping guide treats as mandatory, was accepted and rendered literally because Telegram's parser only cares when it begins a recognised entity. Escaping it is still correct, since < in user text would otherwise decode into a literal <, but the blast radius is one character wide instead of eighteen.

And HTML mode has the advantage that matters more than the character count: your language already ships the escaper. Python's html.escape, Go's html.EscapeString, Java's StringEscapeUtils. All of them are older than your bot and none of them have a bug in them. For MarkdownV2 you are writing that function yourself, or trusting a helper such as python-telegram-bot's escape_markdown, which takes a version=2 argument that is easy to forget and defaults to the legacy list.

Three rules, in the order they save time:

Never interpolate untrusted text into a parse mode. If the string came from a user, an API or a filesystem, it goes out with no parse_mode at all, or escaped by a function. Never by hand, never "it's just a name".
Prefer HTML for anything with variables in it. One fatal character, and a standard-library escaper you did not write.
If you need MarkdownV2, escape all eighteen, always. Not the ones you think will appear. The failure of the selective approach is invisible, which is precisely why it is not worth the saved keystrokes.

The whole escaper is one line, and the test that proves it is one call:

`` RESERVED = r"_*[]()~`>#+-=|{}.!"

def esc(s):
return "".join("\" + c if c in RESERVED else c for c in s)

That test string has five of the loud characters and one of the quiet ones. Raw, it fails on the first parenthesis and never reaches the underscore. Escaped, every character survives. Verify by reading result.text back from the response rather than by eyeballing the chat. The response is the only witness that tells you what was actually stored, and it is the same discipline that catches the four silent characters in the first place.

If you run this yourself, use a chat you own. Every accepted case is a delivered message, and there were 126 of them. I sent them to my own account and deleted each one after reading the response. Keep the pace down as well: the burst allowance on a single chat is around a hundred operations before the rate limiter pushes back, and deletes spend from the same budget as sends.

The measured limits, the failure modes and the boilerplate that survives them: escaping, rate limits, update queues and webhook handling, in one pack.

Get the pack -- $19

The script is stdlib-only Python and takes a bot token and a chat ID. It runs the eighteen characters through seven contexts, then the paired pass, then the backslash cases, and prints the roll-up you see in the screenshot. Point it at a demo bot, not a production one.

`` python3 tg-markdownv2-escape-probe.py --chat <your own chat id>

UNESCAPED in plain MarkdownV2:
hard 400 error : 18 _~`>#+-=|{}.!
silently mangled: 0
PAIRED and unescaped in plain MarkdownV2:
hard 400 error : 14 >#+-=|{}.!
silently eaten : 4 _~`

Two numbers, one conclusion. Every reserved character will stop a message. Four of them will let it through with holes.

Which characters must be escaped in Telegram MarkdownV2?

All eighteen listed in the Bot API docs: _ * [ ] ( ) ~ ` > # + - = | { } . !. Tested one at a time, every single one returns a 400 when it appears unescaped in plain text. The documentation is accurate here.

Why does my Telegram message lose characters instead of returning an error?

Because four of the reserved characters open an entity that a second occurrence closes: underscore, asterisk, tilde and backtick. Two of the same character is valid markup, so the API accepts it and consumes both delimiters as formatting instead of delivering them as text.

Is HTML parse mode safer than MarkdownV2?

For untrusted text, yes. HTML mode had one fatal character in testing, the less-than sign, and an unescaped ampersand was accepted and rendered literally. MarkdownV2 has eighteen reserved characters, four of which fail silently. HTML also maps onto the escaper your standard library already ships.

What breaks when I migrate from Markdown to MarkdownV2?

Fourteen characters that were harmless become fatal. Legacy Markdown rejected only _, *, [ and ` in the same test; the other fourteen passed through. Those fourteen -- full stops, hyphens, exclamation marks -- are what starts returning 400 after the switch.

Can I test parse errors without a real chat?

Yes. Parse errors come back before Telegram resolves the chat, so sending to a chat ID that does not exist still returns the real parse error. A valid string sent to the same bogus chat returns "chat not found" instead, which is how you tell the two layers apart.

More measurements from the same bot: where the Bot API validates an inline keyboard, what the 4096-character limit counts, and what happens to an update queue after you switch the bot off.

Originally published on charliemorrison.dev.

This post was written with AI assistance. It links to a paid pack I sell, so I earn from it directly if you buy — nothing you read here is behind that link.

charlie-morrison — Tue, 18 Aug 2026 19:57:18 +0000

I found this by making a mistake. I was probing inline keyboard limits against the Bot API and I did not want to spam a real conversation while doing it, so I sent the first test to chat_id=1, a chat that does not exist, expecting Telegram to reject everything with the same useless line and force me to find a real chat.

That is what happened, for most of the cases. But two of them came back with a real answer:

button with no callback_data  ->  Bad Request: can't parse InlineKeyboardButton:
                                  Text buttons are unallowed in the inline keyboard
text=""                       ->  Bad Request: message text is empty
callback_data 65 bytes        ->  Bad Request: chat not found
1000 buttons in one row       ->  Bad Request: chat not found

Telegram had told me my keyboard was malformed without ever resolving the chat I claimed to be sending it to. So there are two validation layers in there, they run in a fixed order, and the boundary between them is worth knowing if you write bots, because one of those layers is testable from a machine with no chat and no test user.

I spent the evening mapping the boundary. Here is what the API actually does.

One throwaway bot (@cm_demo_order_bot, a demo, nothing in production), eight sendMessage calls, sent twice: once to chat_id=1, once to a real private chat. Anything that landed in the real chat was deleted straight after, so the comparison is clean. Then a bisection pass to find the exact numbers where the API flips from accept to reject.

The probe is about ninety lines and does not depend on anything beyond the standard library. Every verdict quoted below came out of one run of it on 17 August 2026.

The same eight cases, sent to a nonexistent chat and then to a real one.

Two of the eight cases answered before Telegram looked for the chat.

A button carrying neither callback_data nor url returns "can't parse InlineKeyboardButton: Text buttons are unallowed in the inline keyboard". An empty text returns "message text is empty". Both arrive against a chat ID that has never existed.

What these two have in common is that neither requires Telegram to know anything about the recipient. The request is structurally wrong on its face. A button with no action is not a button, an empty message is not a message, and the server can say so while parsing the request body.

That makes them cheap to assert against in a test suite. If your bot builds keyboards from data, and you want to know that the builder never emits a button without an action, you can ask Telegram itself instead of reimplementing its rules in a validator that drifts out of date. You need a bot token. You do not need a chat, a test user, or anyone's consent to receive junk messages.

The other six cases were invisible from chat_id=1. Oversized callback_data, a thousand buttons in one row, an empty button label, a message one character over the documented cap: all six came back as "chat not found" , which tells you nothing about the payload.

Send the identical six to a real chat and they separate immediately:

case	real chat
`callback_data` 64 bytes	accepted
`callback_data` 65 bytes	`BUTTON_DATA_INVALID`
1000 buttons in one row	accepted
2000 rows	accepted
button label `""`	accepted
`inline_keyboard: []`	accepted
text 4097 characters	message is too long

So the order is: parse the request, resolve the chat, then check sizes. If you were hoping to validate payload limits without touching a conversation, you cannot. That half needs a real chat, and if you are testing at any volume it needs to be a chat you own, because every accepted case is a message that gets delivered before you delete it.

There is a second tell in that table worth pointing at. BUTTON_DATA_INVALID is shouted in the uppercase constant style of the underlying MTProto layer, while the parse-layer errors are written as English sentences. Two error vocabularies, arriving in a fixed order, from what looks like two different pieces of code. The behaviour I measured is consistent with the shape of the error strings.

callback_data is documented as 1 to 64 bytes. I bisected it rather than trusting the number: 64 accepted, 65 rejected, and the rejection is that same BUTTON_DATA_INVALID. The documentation is exactly right, which is worth saying plainly because the next paragraph is about a number that is not in the documentation at all and is repeated everywhere anyway.

I then went looking for the ceiling on keyboard size and did not find one.

Thirty buttons in a row: accepted. A hundred: accepted. A thousand buttons in a single row: accepted. A hundred rows: accepted. Five hundred: accepted. Two thousand rows of one button each: accepted. An inline_keyboard of [], a keyboard with no buttons in it at all: accepted, and the message arrives with no markup attached.

If you have written Telegram bots you have probably read that the limit is eight buttons per row, or ten, or that you must keep the whole keyboard under some count. I have read it too. As an API rule it is not true. The server took every keyboard I built up to two thousand by one thousand without complaint.

The reason the folklore exists is that those keyboards are unusable, not invalid. Telegram's clients wrap and squeeze buttons to fit the width they have, so a row of twelve renders as a wall of unreadable stubs and a row of a thousand renders as something you scroll past forever. Eight per row is good advice about how phones display things. It has been repeated for long enough to become a rule people believe the API is enforcing, and it is not enforcing it.

That distinction matters when you are debugging. If your keyboard is not appearing, the API is not silently rejecting it for being too big. Look somewhere else: a parse error you are not logging, a chat not found you are treating as a network blip, or a client that is rendering exactly what you asked for.

Of everything in the results, the case I would actually put a check on before shipping is the button with an empty text.

Telegram accepts it. The message goes out. What arrives is a button that renders as a thin strip of nothing, still tappable, still firing its callback_data at your bot when someone hits it. Nothing in the response tells you anything is wrong, because from the API's point of view nothing is.

That is the shape of bug that gets past tests. A label built from user data, or a translation lookup that misses, or a truncation that trims to zero, and your keyboard ships with a hole in it that no error message will ever mention. It is exactly the class of thing I wrote about when a bot's update queue kept collecting messages months after I turned the service off: the API doing precisely what it was told, quietly, while the operator assumes silence means nothing happened.

Same for the empty keyboard. inline_keyboard: [] is accepted and produces a message with no buttons, so a builder that returns an empty list on a bad branch will never raise. It will just ship a message that does nothing, forever, until a human notices.

The five places a bot passes your tests and fails in front of real users: initData validation, poll payloads Telegram silently rewrites, systemd units that start and quietly do nothing, file-size limits, and the rate limit that stalls a round. Dependency-free Python and Node, 55 tests you can run from the zip, plus a 26-point pre-ship checklist.

Get the pack -- $19 What is in the pack, module by module. Every claim in it was measured first and published here.

Three practical things came out of the evening.

Assert the parse layer in CI, cheaply. Structural mistakes in keyboard construction can be checked against the live API with a token and no chat. It is a real network call, so it is not a unit test, but it is a very cheap contract test against the only authority that matters, and it will not drift when Telegram changes its mind.

Never test limits against a chat you do not own. Half the failure modes only surface after the chat resolves, and every passing case is a delivered message. Use your own account or a throwaway. Also keep the pace down: I measured the burst allowance on a single chat at roughly a hundred operations before the rate limiter starts pushing back, and edits spend from the same allowance as sends.

Validate button labels yourself, because Telegram will not. An empty label and an empty keyboard are both legal. If either is reachable from your code, the check has to live in your code.

One bot, one evening, one account, the public Bot API. I did not test a local Bot API server, which is documented to relax several limits and could plausibly differ here too. I did not find the ceiling on keyboard size, I found that it is above two thousand rows and above a thousand buttons per row, which is far past anything a sane interface would build. And behaviour like validation order is an implementation detail, not a documented contract. It could change on any Tuesday, without a changelog entry, precisely because it was never promised.

That is why the probe is a script and not a paragraph of notes. When something here stops being true, re-running it takes a minute and the answer comes from Telegram rather than from this post.

The documented parts are documented well, for what it is worth. The InlineKeyboardButton reference states the 64-byte callback_data bound and the rule that a button must carry exactly one optional action field, and both of those held exactly as written. The sendMessage reference gives the 4096-character text cap, and 4097 characters is where it broke. Everything in this post that surprised me lives in the space the documentation does not describe: the order the checks run in, and how much the server will accept when nobody wrote a number down.

What is the maximum number of buttons per row in a Telegram inline keyboard?

The Bot API does not enforce one. A row of 1000 buttons was accepted in testing, as were 2000 rows. The widely repeated limit of 8 buttons per row is a rendering convention for narrow screens, not a server rule.

What is the callback_data size limit?

64 bytes, and it is enforced exactly. Bisecting the boundary live, 64 bytes was accepted and 65 bytes was rejected with BUTTON_DATA_INVALID.

Why does Telegram return "chat not found" instead of telling me my keyboard is wrong?

Because size and length checks run after the chat is resolved. Only structural parse errors, such as a button with no action or an empty message text, are returned before Telegram looks for the chat.

Can I validate a Telegram inline keyboard without sending a message to anyone?

Partly. Structural errors can be checked by sending to a chat ID that does not exist, using a bot token and no chat. Size limits cannot, because those checks only run after the chat resolves.

Does Telegram accept a button with an empty label?

Yes. An empty button text is accepted and delivered. It renders as a thin strip and still fires its callback_data when tapped, so this check has to live in your own code.

More measurements from the same bot: what eighteen game bots actually reply, and what an "anonymous" bot operator receives when you press Start.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

charlie-morrison — Tue, 11 Aug 2026 20:21:54 +0000

The first time a Telegram bot of mine hit a file limit, the symptom made no sense. The bot could send a 40 MB video to a user without complaint. When the same user forwarded a 25 MB video back, the bot could see it, log its size, and read its file_id -- and then could not download it. Not slowly. Not with a retry. At all, permanently.

That is not a bug in anyone's code. It is the shape of the Bot API: the number governing what a bot may send and the number governing what it may fetch are different numbers, and the gap between them is where media bots go to die.

The official figures are 20 MB down and 50 MB up. What the docs do not say is which megabyte they mean, what the limit is actually measured against, or what happens at the boundary. I wanted all three, so I measured them against a live bot, one byte at a time.

Unedited output from the probe, 7 August 2026. Every number in this post comes from this run.

The probe generates files of a target size filled with os.urandom, so nothing on the path can compress them into a smaller request than I asked for. Each file goes up through sendDocument as multipart/form-data against a real bot token -- a throwaway bot, never one serving users -- and the response is recorded verbatim, including the HTTP status and any transport-level exception.

For anything that uploads successfully, the probe immediately calls getFile on the returned file_id to see whether the same bot can fetch back the thing it just sent. Every message the probe creates is deleted with deleteMessage at the end of the run, so the test leaves no residue in the chat.

Two deliberate choices are worth stating. I sized files in binary units rather than round decimal numbers, because the entire question is which unit Telegram means. And I tested the byte immediately either side of each candidate boundary, because a limit you have only bracketed to the nearest megabyte is a limit you have not actually found.

This one is clean, and it is exact:

File size	In words	getFile result
20,000,000 B	20 MB decimal	OK
20,971,520 B	20 MiB	OK
20,971,521 B	20 MiB + 1 byte	400 -- file is too big

The cutoff is 20,971,520 bytes, to the byte. The documented "20 MB" is binary. That gap matters more than it looks: a file of 20,000,000 bytes is genuinely 20 MB in the decimal sense and it downloads fine, so anyone who built their guard rail at size > 20_000_000 is rejecting almost a megabyte of files that would have worked.

The failure itself is well behaved. You get an ordinary JSON response, ok: false, error code 400, description Bad Request: file is too big. It is easy to detect and easy to branch on. Remember this, because the other limit does not extend you the same courtesy.

The upload side did not behave like a file-size limit at all, and working out why took the most interesting hour of the night.

A 49 MiB file (51,380,224 bytes) uploaded fine. A 50 MiB file failed. So far, so unremarkable. But then 50 MiB minus one byte also failed -- and a limit that rejects one byte under its own round number is not a limit on the file.

The obvious suspect was the multipart envelope. A multipart/form-data body is not just the file: it carries a boundary string, a content-disposition header per field, the chat_id, the trailing boundary. In my encoder that came to exactly 350 bytes. If Telegram caps the request body at 50 MiB rather than the file, then the largest file I can send is 52,428,800 − 350 = 52,428,450 bytes.

That is a falsifiable prediction with a one-byte resolution, so I ran it:

File size	Request body	Result
51,904,512 B	49.5 MiB + 350 B	OK
52,428,450 B	exactly 52,428,800 B	OK
52,428,451 B	52,428,801 B	connection dropped
52,428,800 B	52,429,150 B	connection dropped

Exactly as predicted, on the nose. The cap is 52,428,800 bytes of HTTP request body, not of file.

The practical consequence is mildly annoying: your real maximum file size depends on your HTTP client. A library with longer boundary strings, or one that sends extra form fields such as caption or reply_markup, eats further into the allowance. There is no single "maximum file size" you can hard-code and trust across libraries -- which is presumably why the docs round it to "50 MB" and leave it there.

If you want a number to actually use: stay under 52,400,000 bytes and you have roughly 28 KB of headroom for envelope overhead, which is more than any sane multipart encoder will spend.

This is the finding I would most want to know before shipping, and it is invisible from the documentation.

When the body exceeds 50 MiB, Telegram does not respond with 413, or a JSON error, or anything at all. It drops the TLS connection roughly 30 seconds into the upload. In Python that surfaces as:

URLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:2406)'))

It reproduced identically on all four over-limit attempts, at a consistent ~30 seconds, while a successful 49.5 MiB upload took 44.5 seconds. So this is not a timeout -- the server cuts the connection well before the point at which a legitimate, larger transfer would still have been happily in flight.

Why this specific failure mode is dangerous. Almost every HTTP retry policy treats 4xx as permanent and connection errors as transient. This failure is a connection error that is permanent. A bot with sensible retry logic will therefore re-upload an impossible file forever -- burning bandwidth on a 50 MiB body every attempt, with nothing in the logs but an intermittent-looking network exception. Guard on file size before you send; do not wait for the API to tell you, because it will not.

Put the two limits side by side and the design becomes clear:

Direction	Limit	At the boundary
Bot sends (multipart)	52,428,800 B of request body	TLS connection dropped
Bot sends (by URL)	20 MB, 5 MB for photos	400
Bot downloads	20,971,520 B	400 -- file is too big

A bot may hand out files two and a half times larger than it is allowed to pick up. For most bots this never surfaces, because they only ever send things they generated themselves. For anything that processes what users send it -- a converter, a downloader, a backup bot, an OCR bot -- it is the wall you hit in week one.

And it is a hard wall. When a user forwards a 30 MiB video, your bot receives a perfectly valid update. The file_id is real. file_size is populated and tells you exactly how big it is. Everything looks retrievable. getFile then returns 400, and no amount of retrying, re-requesting, or waiting changes that. The bytes exist on Telegram's servers and your bot simply has no method that will hand them over.

The one mercy: because file_size arrives in the update before you attempt anything, you can detect this instantly and tell the user something true. A bot that replies "that file is 30 MB and I can only fetch 20 MB" is infinitely better than one that says "processing" and then goes quiet.

Run a local Bot API server. Telegram publishes the server as open source at tdlib/telegram-bot-api, and it is the only real fix. It lifts uploads to 2000 MB and removes the download limit entirely; better still, it returns an absolute local file path in file_path, so for a bot on the same machine there is no download step at all. The cost is that you now run a stateful service that wants real disk and real memory -- which is a genuine consideration if, like me, you are running bots on a 1 GB VPS.

Checkfile_size before you do anything else. One comparison against 20,971,520, and a clear message to the user. This is the highest-value four lines in any media bot.

Do not build the guard at 20,000,000 or 50,000,000. Both are wrong in the same direction, and both quietly reject files that work.

Treat over-limit uploads as permanent, in code. Since the API will not classify them for you, your own size check has to. Otherwise your retry policy does the classifying, and it will get it wrong.

My free planner lays out a Telegram game night -- rounds, timings, poll structure -- in about a minute, no signup.

Build a game night -> Or read how to run one end to end.

Three honest gaps. I did not test a local Bot API server's 2000 MB ceiling -- that needs a server I would have to stand up and feed 2 GB through, and I am not going to claim a number I have not seen. I did not test the URL-upload path (sendDocument with an http:// URL instead of bytes), where the docs quote a lower 20 MB limit that I have taken on faith rather than measured. And every number here comes from one bot, on one network path, from Europe.

On that last point I am fairly relaxed, for one reason: the 350-byte overhead prediction landed exactly. A network artefact does not reproduce a byte-precise boundary you calculated in advance from the structure of your own request body. That the prediction held is much stronger evidence than the four failures on their own.

Download: 20,971,520 bytes, exactly. One more byte gives a clean 400 file is too big.
Upload: 52,428,800 bytes of request body , multipart headers included. Budget ~52,400,000 for the file.
Both are binary. 20,000,000 and 50,000,000 are both inside their respective limits.
Over-limit uploads drop the connection instead of erroring. Guard on size yourself.
You can send 2.5 × what you can fetch. Check file_size on arrival and say so plainly.

The size guard from this post, finished: the exact constants, a pre-send check that fails loudly instead of retrying forever, and the on-arrival file_size reply that saves your users a silent wait. Plus an initData validator with signature excluded and auth_date enforced, poll payloads Telegram will not silently rewrite, and a systemd unit linter for the two failure modes that cost me weeks. 55 tests you can run from the zip.

Get the pack -- $19 What is in the pack, module by module. Every claim in it was measured first and published here.

charlie-morrison — Mon, 10 Aug 2026 20:22:18 +0000

If you have ever asked how long a Telegram message can be, you have met the same answer twice: 4096 characters, and by the way Telegram counts UTF-16, so an emoji costs two. It is repeated in library issues, in Stack Overflow answers, and in the defensive splitters people paste into their bots, usually as a chunk size of 2000 or 4000 chosen with a shrug for safety.

I write a lot of bot code that emits long, emoji-heavy status blocks, and that folklore was costing me splits I did not think I needed. So I stopped guessing and asked the API directly: send messages one unit either side of the boundary, in four different alphabets, and see which measurement predicts what the server does.

The answer is that the number 4096 is real and exact, and that the unit almost everybody names is the wrong one. Worse, the UTF-16 rule is true, of a different field, in the same reply. A single Message object mixes two units, which is precisely why the folklore has survived so long: everyone is half right.

Unedited output from the probe, 10 August 2026. Every number in this post comes from this run.

The probe builds strings out of four deliberately different characters and sends each through sendMessage against a real bot token (a throwaway bot, never one serving users), recording the HTTP status and the exact description Telegram returns. Every message it manages to send is deleted with deleteMessage in the same breath, so the run leaves nothing behind in the chat.

The four characters are chosen so that the candidate units disagree with each other:

a -- 1 code point, 1 UTF-16 unit, 1 byte. All three units agree, so this only finds the number.
я -- 1 code point, 1 UTF-16 unit, 2 bytes. Separates bytes from the rest.
😀 (U+1F600) -- 1 code point, 2 UTF-16 units , 4 bytes. Separates code points from UTF-16.
e + combining acute (U+0301) -- 2 code points , 2 UTF-16 units, 3 bytes, and one thing you can see. Separates all of them from "visible characters".

Then the only discipline that matters: test the unit immediately either side of every candidate boundary. A limit you have bracketed to the nearest hundred is a limit you have not found.

ASCII gives the number straight away. 4,096 characters go through; 4,097 come back as a clean 400 Bad Request: message is too long. No truncation, no silent trim -- a real error you can catch.

Cyrillic kills the bytes hypothesis. 4,096 Cyrillic characters are 8,192 bytes of UTF-8, twice the ASCII payload, and Telegram accepts them; 4,097 fails. So whatever is being counted, it is not the size of what goes on the wire.

The emoji case is the one that surprised me. If the cap counted UTF-16 code units, 2,049 emoji -- 4,098 units -- would be rejected. It was accepted. So I pushed until it broke, and the boundary sits exactly where a code-point counter would put it:

emoji x4096   code pts 4096   UTF-16 8192   bytes 16384   -> OK
emoji x4097   code pts 4097   UTF-16 8194   bytes 16388   -> 400 message is too long

Read that again, because it is the whole post. A single Telegram message can carry 4,096 emoji, 16 KB of UTF-8 and 8,192 UTF-16 code units, and the server takes it. I echoed the accepted message back out of the API response and compared it to what I sent: identical, character for character. Nothing was truncated on the way through.

The mixed case pins it from the other side. a × 4,095 followed by one emoji is 4,096 code points and 4,097 UTF-16 units: accepted. Add one more a and it is 4,097 code points: rejected. Across every probe I ran, "code points ≤ 4096" predicted the outcome every single time. "UTF-16 units ≤ 4096" did not.

Here is why the folklore refuses to die. In the same JSON reply that just accepted 8,192 UTF-16 units, the formatting entities are indexed in UTF-16.

Send one emoji followed by bold text and read the entity Telegram hands back:

😀*bold*     ->  {"offset": 2, "length": 4, "type": "bold"}
😀😀😀*bold*  ->  {"offset": 6, "length": 4, "type": "bold"}

One emoji, and the bold run starts at offset 2. Three emoji, offset 6. If offsets were code points those numbers would be 1 and 3. Telegram documents this (entity offsets are specified in UTF-16 code units) and it is correct, and it has been quietly transplanted onto the length cap by a thousand summarised answers.

So both halves of the folklore are true of something. They are just true of different fields:

Field	Unit	Python equivalent
4096 text cap / 1024 caption cap	Unicode code points	`len(text)`
`entities[].offset` and `.length`	UTF-16 code units	`len(text.encode('utf-16-le')) // 2`

If you have ever sliced a message at an entity offset with plain Python indexing and watched the bold run land one character to the left for every emoji before it, that table is the bug.

The combining-mark probe closes the last escape route. e + U+0301 renders as a single é, but it is two code points. Send 2,048 of them, which is 2,048 things a human can see and 4,096 code points, and it is accepted. Send 2,049 and it fails at 4,098.

So a user can paste 2,049 visible characters into your bot and be told their message is too long, and they will be right and the error will also be right. If you show a live character counter in a Mini App, this is the case that makes it disagree with the server. Any counter built on grapheme clusters, or on String.length in JavaScript (which is UTF-16), will be wrong in one direction or the other for exactly these inputs.

Captions cap at 1,024 and behave identically. 1,024 emoji, or 2,048 UTF-16 units, are accepted; 1,025 are rejected. Worth noting for log-grepping: the error text is not the same one sendMessage returns.

sendMessage  -> 400 Bad Request: message is too long
sendPhoto    -> 400 Bad Request: message caption is too long

A pleasant contrast with the file limits. When I measured the file size boundaries, an over-limit upload got no error at all -- Telegram dropped the TLS connection ~30 seconds in and left the caller holding a transport exception. Text is the well-behaved case: you get a real 400, immediately, with a description worth logging.

In Python, the naive guard is the correct guard. len(text) <= 4096 matched every outcome I measured. This is the rare case where the obvious thing is right and the clever thing, re-encoding to UTF-16 to "be safe", is what makes you wrong.

In JavaScript, the naive guard is the wrong one. str.length is UTF-16 code units, so an emoji reads as 2 and your Mini App will refuse a message the server would have accepted. Count code points instead: [...str].length, which iterates by code point and gives 1 per emoji.

Stop halving your chunk size for emoji. If you split long output at 2,000 "to be safe with unicode", you are sending twice the messages you need to, at twice the flood-limit risk, for a hazard that does not exist. Split at 4,096 code points.

Never index a string by an entity offset directly. Convert first: encode to utf-16-le, slice by offset * 2 and length * 2, decode back. Anything else is correct only until someone types an emoji.

My free planner lays out a Telegram game night -- rounds, timings, poll structure -- in about a minute, no signup.

Build a game night -> Or read how to run one end to end.

Three honest gaps. I did not test whether the same code-point rule holds on the MTProto client APIs -- TDLib and the user-account layer are a different code path where the UTF-16 convention is far more visible, so I would not assume my result transfers. I did not test editMessageText, only sendMessage and sendPhoto; I would expect the same cap but I have not seen it. And I did not probe the entity-count limit, which is a separate ceiling that bites long formatted messages before the length cap does.

Everything here comes from one bot on one network path. I am comfortable with that for this particular claim, because the result is not a statistical trend -- it is a boundary that lands on an exact power of two from four directions at once, with a one-unit failure on the far side of each. Encoding a message differently changed its byte length fourfold and moved the boundary not at all.

The cap is 4,096 Unicode code points , exactly. 4,097 gives 400 message is too long.
Not bytes: 4,096 Cyrillic characters are 8,192 bytes and go through fine.
Not UTF-16: 4,096 emoji are 8,192 UTF-16 units and 16 KB, and go through fine.
Not visible characters: 2,049 combining-accent é's are 4,098 code points and are rejected.
Entity offsets are UTF-16. Two units in one Message. Convert before slicing.
Captions: same rule at 1,024 , with a distinct error string.

What unit is Telegram's 4096 message limit counted in?
Unicode code points. Measured against a live bot, 4,096 code points is accepted and 4,097 is rejected with 400 Bad Request: message is too long, regardless of how those code points encode. A message of 4,096 emoji is 8,192 UTF-16 code units and 16,384 bytes of UTF-8, and it sends without complaint.
Does an emoji count as two characters in a Telegram message?
Not against the length cap. A non-BMP emoji is one code point, and the cap counts code points, so it costs one. It does count as two in entity offsets, which are measured in UTF-16 code units. That is why the advice to budget two units per emoji is half right: it applies to formatting offsets, not to the 4096 limit.
Is len(text) a correct check for the Telegram message limit in Python?
Yes. Python's len returns the number of Unicode code points, which is exactly the unit the cap uses, so len(text) <= 4096 matched every measured outcome. Guards written against UTF-16 length or UTF-8 byte length both reject messages that Telegram accepts.
Does the same rule apply to the 1024 caption limit?
Yes. Captions cap at 1,024 code points and behave identically: 1,024 emoji is accepted at 2,048 UTF-16 units, and 1,025 is rejected with 400 Bad Request: message caption is too long. The error text differs from the sendMessage one, which is useful when you are reading logs.

The guards from this post, finished: a length check in the unit the server actually uses, an entity-offset slicer that survives emoji, and a splitter that stops halving your chunks for no reason. Plus the file-size guard that fails loudly instead of retrying forever, an initData validator with signature excluded and auth_date enforced, poll payloads Telegram will not silently rewrite, and a systemd unit linter for the two failure modes that cost me weeks. 55 tests you can run from the zip.

Get the pack -- $19 What is in the pack, module by module. Every claim in it was measured first and published here.

🏀 Basketball

⚽ Football