DEV Community: charlie-morrison

Telegram editMessageText: Your Keyboard Vanishes (Tested)

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.

The setup

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.

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

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.

The keyboard you did not mention is the keyboard you deleted

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.

Removing a keyboard on purpose

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.

The method is fixed by how the message was sent

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.

The boundaries on an edit are the boundaries on a send

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.

What survives an edit

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.

Deleting twice is an error

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.

What I did not measure

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.

What to change in your code

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.

Telegram in Production

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

FAQ

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, and the measurements are reproducible with the script above.

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

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.

The setup

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 ceiling is 100, and it refuses rather than truncates

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 charset is enforced, not cleaned up

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.

Telegram in Production

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

Two rewrites that happen on the way in

Everything above announces itself. These two do not.

The leading slash is stripped

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.

Duplicate names are deduplicated, last one wins

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.

The description field

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.

Scopes shadow, they do not replace

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.

What to do with this

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.

FAQ

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.

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

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.

The setup, and why it needed almost no chat

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.

One occurrence: the docs are exactly right

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.

Two occurrences: fourteen still fail, four disappear

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.

Where this actually bites

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.

The migration trap: legacy Markdown to MarkdownV2

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.

Inside code spans and links, the rules genuinely are narrower

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.

HTML mode has one fatal character instead of eighteen

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.

What I do now

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)

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 ``

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.

Telegram in Production

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 probe

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.

FAQ

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.

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

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.

The setup

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.

Layer one: parse errors, no chat required

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.

Layer two: limits, chat first

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.

The one size limit the server actually enforces

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.

The empty label is the one I would guard against

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.

Telegram in Production -- the parts that bite you

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.

What I would do with this

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.

Limits of this measurement

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.

FAQ

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.

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

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.

How I tested it

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.

The download cap is exactly 20 MiB

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 cap counts your HTTP headers

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.

An over-limit upload does not return an error

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.

The asymmetry is the actual problem

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.

What to do about it

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.

Building on Telegram for something lighter?

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.

What I did not test

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.

The short version

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.

Telegram in Production -- the parts that bite you

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.

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

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.

How I tested it

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.

The number is 4096. The unit is code points.

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.

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

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.

Visible characters are not the unit either

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: same rule, different number, different error string

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.

What this means in code

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.

Building on Telegram for something lighter?

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.

What I did not test

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 short version

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.

Questions I had before I measured

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.

Telegram in Production -- the parts that bite you

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.

Telegram Poll Limits: What I Measured Against the Live Bot API

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

A game night in a group chat lives or dies on polls. They are the only mechanic Telegram gives you where twelve people can answer at once without the first reply telling everyone else what to think. Every round I have ever run -- who is lying, which answer is right, who gets the dare -- ends in a poll.

So it is worth knowing exactly where a poll stops working. Not the theory: the point where the API says no, and the more annoying point where it says yes and quietly does something else. I spent an evening sending deliberately-broken polls at Telegram until it complained, then read every poll back a second way to see what a person in the chat would actually get.

Some of it matches the official sendPoll reference. Three things do not, and one of those three has silently ruined a round for me before I understood it.

Unedited output from the three probe scripts, 3 August 2026. Every number in this post comes from these runs.

How I tested it

Three passes, because one was not enough to catch my own mistakes.

The first pass sends polls at the boundary of every documented limit -- a 300-character question and a 301-character one, twelve options and thirteen, and so on -- and records the exact accept or reject. The second pass re-sends the interesting cases and reads what Telegram echoes back in the response, because "accepted" and "sent as I asked" turn out to be different things. The third pass reads the same polls back over the client protocol with a normal user account, which is the closest I can get to seeing what a member of the group sees without asking anyone to look over my shoulder.

That third pass exists because of a habit I had to learn the hard way: an exit code of zero tells you the request left the building, not that the thing arrived intact.

The hard walls

These are the limits that produce a clean, immediate error. You will never hit them by accident with a short question, and you will hit all of them the moment you paste in something you wrote in a document.

What	Limit	What happens past it
Question	300 characters	poll question length must not exceed 300
Options per poll	12	poll can't have more than 12 options
Text per option	100 characters	poll options length must not exceed 100
Quiz explanation	200 characters	message is too long
Empty option	not allowed	text must be non-empty
Two identical options	allowed	accepted without complaint

Twelve is the number that shapes a game night more than any other. A round where everybody votes for a person -- who is most likely to lose their phone, who is bluffing -- caps out at a group of twelve, because each player needs their own option. Past that you are splitting the room into two polls and reconciling the counts by hand, which is exactly as fun as it sounds. If your group runs bigger than twelve, design the round as a vote on answers , not on people.

One hundred characters per option sounds generous until you write a Would You Rather. "Always have to say everything on your mind out loud, even in meetings" is 70. The version with the funny qualifier on the end is 118, and it is refused. The workaround is not to shorten the joke -- it is to put the full text in the message above the poll and keep the options to the two short labels people are choosing between.

The character cap counts characters, not bytes

This one I expected to go the other way. An option of 100 dice emoji is 400 bytes on the wire, and it is accepted. One hundred and one of them is refused with the same error as 101 letters.

So the cap is counted in characters as a person would count them, not in the storage a string takes up. That matters for anyone writing prompts with emoji in them, and doubly for anyone writing them in a language whose characters are multi-byte by default -- a Ukrainian or Greek option gets the same 100 characters as an English one, not half as many. The Unicode consortium's own FAQ is the reference for why those two counts differ so much in the first place.

Timers get rounded, not refused

Here is the behaviour that costs you a round. A poll can carry a countdown -- open_period -- and the allowed range is 5 seconds to 2,628,000 seconds, which is 30 days.

Send something outside that range and Telegram does not reject it. It silently rounds it into range and tells you nothing :

Ask for a 4-second timer, get 5 seconds.
Ask for 2,628,001 seconds, get 2,628,000.

The response comes back ok: true with the corrected number sitting in it, which is easy to miss if you are only checking that the call succeeded. And the corrected timer is real: I sent a poll asking for 4 seconds, waited nine, and tried to close it manually. Telegram refused -- poll can't be stopped -- because it had already closed itself on schedule.

The same forgiving-to-a-fault behaviour shows up in a second place. The documentation says open_period and close_date cannot be used together. Send both anyway and the request is accepted; the open_period wins and the close_date you specified is overwritten. I asked for a 60-second timer and a close time ten minutes out, and got a poll that closed in 60 seconds.

Why this bites in practice. Timed rounds are where hosts reach for these values, usually by computing them from something -- "close this when the round ends", "give them a third of the remaining time". Arithmetic that lands on 3 or 4 seconds silently becomes 5, and arithmetic that produces both a period and a date silently drops one of them. Nothing errors, nothing logs, and the round just runs on a timer you did not choose. Print the value Telegram echoes back, not the one you sent.

There is no bold, no italics and no spoiler inside a poll

Poll options carry no formatting at all. Not "limited formatting" -- none. I sent three options containing a spoiler tag, a bold marker and an HTML bold tag, then read the poll back over the client protocol. All three came back as literal text, with an empty entity list on every one of them.

The question field is only slightly better: it accepts a parse mode, but the reference restricts it to custom emoji entities. I sent a question as MarkdownV2 bold; the asterisks were consumed and the text arrived plain, with no bold and no entities. Not an error -- just quietly unformatted.

For a game night this rules out the trick everyone reaches for first: hiding the answer behind a spoiler tag inside the poll. ||like this|| in an option is displayed exactly as those characters, answer and all. What works instead is a two-part round -- the hidden text goes in a normal message, where spoiler formatting is fully supported, and the poll below it carries only the plain-text choices. It is one extra message and it is the difference between a reveal and a leak.

Quiz mode: one correct answer, whatever the field name suggests

Quiz polls -- the mode Telegram introduced with Polls 2.0 -- mark one option right and can show an explanation when someone picks wrong. The parameter is now named in the plural, correct_option_ids, which reads like an invitation to mark two answers correct.

It is not. Passing two ids is refused with QUIZ_CORRECT_ANSWERS_TOO_MUCH. The older singular parameter still works and comes back echoed in both the singular and plural fields, so nothing you already wrote is broken -- but a quiz round with two acceptable answers has to be built as two separate questions.

Two smaller findings from the same pass. A quiz without a correct answer is refused outright (correct quiz option list must be non-empty), so you cannot use quiz mode purely for its nicer layout. And the explanation is documented as allowing at most two line breaks -- I sent three and it was accepted, which is the one place the API turned out to be more permissive than its own description rather than less.

Four switches worth knowing before your next round

While checking the limits I went through the full parameter list, and a few of the newer ones solve group-chat problems I had been solving by hand:

hide_results_until_closes -- nobody sees the tally until the poll closes. This is the native fix for the single biggest problem with voting in a group: the first three votes anchor everyone who comes later.
shuffle_options -- each person sees the options in a different order, which kills "the answer is always the long one" pattern-matching in a quiz.
allows_revoting -- on by default for regular polls, off by default for quizzes. If your round is scored, turn it off explicitly and stop arguing about who changed their vote.
allow_adding_options -- lets players add their own answers, which is a genuinely good "make up a lie" round. It refuses to work on an anonymous poll: pair it with public voting or you get ANONYMOUS_OPEN_INVALID.

An honest caveat on the first two: Telegram accepts both flags, but neither appears in the poll object it sends back, and neither showed up when I read the poll over the client protocol either. So I can confirm they are accepted -- I cannot confirm from the response alone that they took effect. Set them, then look at the poll in the chat before you build a round around them.

Want the run sheet instead of the API?

The free Telegram Game Night Planner builds a timed game night as paste-ready blocks -- rounds, host lines, and poll questions with the options already separated so you can send them straight into a group chat. No signup, runs in your browser.

Build a game night -> Everything above is baked into the blocks it gives you -- short options, plain text, no spoiler tags where they will not render.

What I actually changed after this

Four rules, all of them the direct consequence of a probe above:

Options stay short and plain. The long version of the prompt goes in the message; the poll gets the two or three word labels. This sidesteps the 100-character wall entirely and reads better on a phone.
Nothing hidden ever goes in an option. Spoilers live in a normal message above the poll, because inside one they are just punctuation.
Twelve is the room size for person-voting rounds. Bigger group, different round design -- vote on the answer, not the player.
Read back the timer. If a round is timed, use the number Telegram returns, not the one that was sent. It is the only way to notice a clamp.

None of this is exotic. It is the difference between a round that lands and a round where somebody says "wait, I can see the answer" -- which, in a group chat, is the whole game.

Running a whole night, not a single round?

The Telegram Party Pack is the hosted version of everything above: 255 prompts across six games, a host guide for a 60-minute night in a group chat, and the poll, spoiler and threading mechanics laid out per round so nothing leaks and nothing anchors. Copy-paste blocks, PDF included.

Get the pack -- $9.99 The planner above stays free. See what is in the pack before you buy.

FAQ

How many options can a Telegram poll have?

Twelve. The thirteenth is refused with "poll can't have more than 12 options". A single-option poll is also accepted, which is occasionally useful as a one-button prompt. For any round where each player needs their own option, twelve is your real group-size cap.

How long can a poll option be?

100 characters per option, 300 for the question, 200 for a quiz explanation. The count is per character, not per byte -- 100 emoji weigh 400 bytes and still pass, while 101 of anything fails.

Can I use bold or a spoiler in a poll?

No. Options carry no formatting entities at all, so markup appears verbatim. The question accepts a parse mode but only for custom emoji -- bold sent as MarkdownV2 arrives stripped. Put hidden text in a regular message and use the poll only for the vote.

How long can a poll stay open?

From 5 seconds to 30 days. Anything outside that is rounded into range without an error, so a 4-second timer quietly becomes 5. Sending an open_period and a close_date together is also accepted despite the documentation, and the open_period is the one that wins.

13 Telegram Bots on One 1GB VPS: The Real RAM Numbers

charlie-morrison — Mon, 03 Aug 2026 20:25:21 +0000

Every thread about hosting a Telegram bot answers the same question with the same shrug. How much server do I need? -- "not much", "a small VPS is fine", "1 GB is plenty". Nobody posts numbers. So people either overbuy a 4 GB instance for a bot that answers six commands, or they pick the cheapest box on the market and spend a weekend wondering whether it will fall over.

I have thirteen Telegram bots running right now on a single 1 GB, 1 vCPU VPS that costs $4.17 a month. Some are mine, some are client work, one is a staging copy. Instead of guessing, I measured every one of them. Here is what a Telegram bot actually costs in memory, what the real ceiling turned out to be, and the thing on my box that quietly used more RAM than all thirteen bots combined.

Live readings from the box, 1 August 2026. Client bot names replaced with generic labels; every number is unedited.

What is actually on the machine

The host is a 1 vCPU / 1 GB / 24 GB NVMe instance. Linux reports 961 MB usable after firmware reservations, which is the number worth planning against -- not the 1024 you paid for. Thirteen tg-* systemd services are active: a media-downloader bot, seven demo and sales bots for a Telegram SaaS product, four client bots, and one staging duplicate.

All of them are Python, all use long polling rather than webhooks, and each one is a separate systemd unit with its own token and its own process. That last detail matters more than it sounds like it should, and I will come back to it.

What a Telegram bot really costs in RAM

Reading resident set size straight out of /proc/<pid>/status for each service's main PID:

Bot	Resident memory	What it does
Media downloader	21.0 MB	Fetches and returns media files
SaaS demo ×5	16.6-17.8 MB	Full menu, database, payments
Sales / signup bots	16.5 MB	Forms, notifications
Client bot A	16.2 MB	Team workflows
Client bot B	10.1 MB	Command-driven
Client bot C	9.9 MB	Command-driven
Client bot D	7.4 MB	File uploads
Client D staging	3.2 MB	Idle duplicate

Thirteen bots, 185.0 MB total, averaging 14.2 MB each. The whole fleet fits in under a fifth of a 1 GB machine.

The spread is the interesting part. The lightest bot uses 3.2 MB and the heaviest uses 21.0 MB -- a 6.5× range -- and that gap has almost nothing to do with how many users each one serves. The staging bot at 3.2 MB and the client bot at 7.4 MB run the same framework as the 17 MB SaaS bots. What separates them is what they import.

A bot that only parses text commands loads the Telegram library and little else. A bot that pulls in an HTTP client, a database driver, an image library and a payments SDK pays for every one of those at startup, whether a user ever triggers that code path or not. Python's memory floor is set at import time, not at request time. If you want a cheaper bot, the lever is your dependency list, not your user count.

One honest caveat about these numbers. RSS counts shared memory pages once per process. Thirteen Python processes on the same host share a lot -- the interpreter itself, libc, and any identical library versions -- so summing RSS overstates the true combined footprint. The real figure is somewhat below 185 MB. I am quoting the pessimistic number deliberately: if you plan against it you will not be surprised, and it is the number you can reproduce yourself in one command. The kernel's proc documentation spells out what each field does and does not include.

The biggest memory consumer was not a bot

This is the part that changed how I think about small hosts. Sorting every process on the box by memory, the top entry is not a Telegram bot at all:

Process	Resident memory
warp-svc (networking daemon)	162.8 MB
node	74.6 MB
systemd-journal	49.0 MB
All 13 Telegram bots combined	185.0 MB

A single networking daemon I installed once and forgot about uses 162.8 MB -- roughly 88% of what all thirteen bots use together , and about eleven average bots' worth of memory. Add node and the journal and the non-bot overhead comfortably exceeds the entire fleet.

So the mental model most people bring to this is backwards. When someone asks "can my 1 GB VPS handle another bot?", the honest answer is that one more bot costs about 14 MB and is almost never the problem. The thing to audit is everything on the box that is not a bot: the monitoring agent, the VPN client, the container runtime, the log daemon with no retention limit. That is where a 1 GB machine actually goes.

The real ceiling is not memory

Here is the number I am not going to dress up. The box shows 687 MB of RAM in use and 1041 MB of swap in use. It is over-committed, and it has been for a while.

It has also been up for 45 days with a load average of 0.52, 0.17, 0.05, and the media bot has recorded zero restarts. Nothing is falling over. What that combination means is that a pile of memory has been paged out to disk and is simply never touched again -- idle bots holding startup allocations they will not read a second time. On NVMe, that is a reasonable trade rather than a crisis, and it is exactly the behaviour Linux is supposed to produce.

But it does define the actual limit. When the constraint arrives, it will show up as latency, not as an out-of-memory kill: a bot whose pages have been swapped out takes a beat longer to answer the first message after a quiet spell. On one vCPU, the thing to watch is several bots waking simultaneously -- a shared burst is a CPU and paging problem, never a headline RAM problem.

Two practical consequences I would apply to any small box:

Cap the journal. An uncapped systemd journal grows until it owns real memory and real disk. Setting a size limit is a one-line change and buys back more than a bot's worth.
Set per-service memory limits. systemd will do this for you with MemoryMax= in the unit file, so one leaking bot degrades itself instead of the twelve next to it. The options are documented in systemd's resource-control manual.

One process per bot, and why it is worth it

Thirteen separate services is not the most efficient arrangement available. I could run several bots in one process and share an interpreter, saving maybe 100 MB of the 185.

I do not, and the reason is that the 100 MB is not the scarce resource -- my attention is. When a client bot crashes on a bad update, it crashes alone. systemd restarts that one unit, the other twelve never notice, and the journal tells me exactly which one it was. Sharing a process to save memory I am not short of would trade a resource I have for a failure mode I would have to debug at two in the morning.

The same reasoning drives long polling over webhooks. Webhooks are more efficient at scale and need one HTTPS endpoint rather than thirteen open connections. But they also need a public certificate, a reverse proxy and a working DNS record before a single message is delivered -- and every one of those is a thing that can break independently. Long polling, described in the official Telegram Bot API documentation, needs none of it: the bot dials out, so it works behind any firewall and needs no inbound access at all. At my volume that trade is obvious. Past a few hundred messages a second it flips, and python-telegram-bot's documentation covers both modes if you need to switch.

Measure your own box in one command

Nothing above required special tooling. To get the same table for your own server:

systemctl list-units 'tg-*' --state=active --no-legend --plain gives you the running units; for each one, systemctl show -p MainPID --value <unit> gives the PID, and grep VmRSS /proc/<pid>/status gives the memory. Then run ps -eo rss,comm --sort=-rss | head -- that second command is the one that matters, because it is what showed me the 162.8 MB daemon I would never have suspected.

If you are sizing a box before you build anything: budget about 15 MB per bot, then add up everything else you intend to install, and let the second number drive the decision. On this evidence a 1 GB instance holds well over thirty typical bots on memory alone. It will run out of CPU, patience, or forgotten background daemons long before it runs out of RAM.

See a Mini App that needs no server at all

The cheapest bot to host is the one with no backend. My party game ships its logic inside the page Telegram opens -- 151 questions per language, English and Ukrainian, no signup, nothing to switch off.

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

Not here to run a server?

If you landed on this because you wanted a game night rather than a hosting bill, The Telegram Party Pack skips the infrastructure entirely: 255 prompts across six games, rewritten for a group chat, plus a host guide covering polls, spoiler reveals and keeping a round legible when replies arrive out of order. Files you own -- no server, no uptime, nothing to maintain.

Get the pack -- $9.99 The Mini App above stays free, no signup. See what's in the pack before you buy.

FAQ

How much RAM does a Telegram bot need?

On this server a long-polling Python bot settles between 3 MB and 21 MB resident, averaging 14.2 MB across 13 bots. The variation tracks what the bot imports rather than how many users it has -- an HTTP client, a database driver and a media library cost more at startup than any amount of traffic does at runtime.

Can I run multiple Telegram bots on one 1 GB VPS?

Yes. Thirteen bots here use 185 MB in total, under a fifth of the machine. Memory is rarely the binding constraint -- a single vCPU during simultaneous bursts, and non-bot daemons, both bite first.

Does each bot need its own server?

No. Each needs its own process and token, but one host handles many. A separate systemd service per bot on one machine gives you crash isolation without paying for separate servers.

Long polling or webhooks?

Long polling is cheaper and much simpler: no public endpoint, no certificate, no reverse proxy, and it works behind any firewall because the bot dials out. Webhooks win when you have high volume and already run a web server. At thirteen low-traffic bots, polling is not close to being the bottleneck.

I Sent 24 Requests to Telegram's Bot API to Find What Breaks a Group Game

charlie-morrison — Wed, 29 Jul 2026 20:19:19 +0000

Every article about Telegram games answers the same question: which games. Truth or Dare, Never Have I Ever, Would You Rather, Most Likely To. Fine: that part is easy, and I've written one of those lists myself.

Nobody writes about the part that actually decides whether your game night survives past round three: the chat mechanics. A group chat is not a living room. Nobody takes turns. The person who types fastest answers first and quietly sets the answer everyone else copies. Half the group is reading on a phone under a table. The host, meaning you, is trying to run a game in a medium that has no concept of "whose turn it is".

Telegram has real tools for this: polls, quiz polls, spoiler text, pinned messages, self-closing rounds. Most of what's written about them is copied from other articles, and a fair amount of it is simply out of date. So rather than trust it, I sent 24 live requests to Telegram's own API : real polls, real spoilers, real pins, and I wrote down exactly what came back.

Seven of the 24 failed. Two of them "succeeded" while doing something other than what I asked, which is worse, because those are the two you ship to your friends without noticing.

How I tested it

I run a party game on Telegram, so the questions weren't hypothetical: I wanted to know which of these mechanics I could rely on when a group of eight people is mid-round and impatient.

The method was deliberately boring. Each mechanic became one request to Telegram's Bot API, using sendPoll, sendMessage and pinChatMessage, with one variable changed at a time: a poll question at 300 characters and then at 301, an option at 100 and then at 101, a quiz with a correct answer and then without one. Whatever the API returned, success or error, went straight into a results file. The screenshot below is generated from that file, not typed by hand.

All 24 requests. Green rows were accepted; red rows carry Telegram's own error text. The two red rows with code 200 are the dangerous ones.

One thing I could not test, and won't pretend otherwise: the per-group rate limit. My test account is restricted from creating new groups, so the requests went to a one-to-one chat with my bot, where 22 back-to-back messages went through in 6.1 seconds without a single block. That number does not transfer to a group. Telegram's own bot FAQ puts the guidance at roughly 20 messages per minute in the same group, and everything I say about pacing below follows their figure, not mine.

The five things that break a round

1. The 100-character option cap hits the exact game you most want to poll

A poll question can be 300 characters. Each option can only be 100. I got poll options length must not exceed 100 at 101 characters, and success at exactly 100.

That sounds generous until you look at what you're actually pasting. I ran all 255 prompts from my own game pack through those two limits. Zero exceeded the question cap. Twenty exceeded the option cap, and 19 of those 20 were Would You Rather.

Which makes sense once you see it. A Would You Rather line is already a question plus its two answers glued together: "Would you rather have unlimited money but no free time, or unlimited free time but just enough money?" runs to 138 characters. Paste that whole line as an option and Telegram rejects it. Would You Rather is the game that maps most naturally onto a poll, and it's the one whose text most reliably breaks the poll.

The fix is a split, not an edit. The dilemma goes in the poll question (300 characters, so it always fits; my longest was 101). The two halves become the two options: "Money, no time" / "Time, no money". When I re-ran the same 30 Would You Rather prompts that way, all 30 fit , without cutting a single word.

Host shortcut: if a prompt is too long to be an option, it was never an option. It was a question with the answers written into it. Split it, don't trim it.

2. The option limit is 12, not the 10 you'll read everywhere

Twelve options were accepted and created normally. Thirteen came back poll can't have more than 12 options. A lot of current advice still says ten, which was true of an earlier version of the API and quietly stopped being true.

This matters for exactly one thing, and it's the most popular game in the genre: Most Likely To. You want one option per player, so the group can vote for each other. Twelve options means a group of up to twelve fits in a single poll. At thirteen people you either split the vote across two polls, which fractures it, or drop the poll and take answers as replies.

3. Quiz mode demands a right answer, so it's wrong for opinion games

A quiz poll without a designated correct option is rejected: correct quiz option list must be non-empty. With one, it works, and you can attach an explanation that pops up after the vote.

So quiz mode is for trivia, where there genuinely is a correct answer, and the explanation slot is the best feature nobody uses: it lets the poll teach instead of just scoring. For anything with no right answer (Would You Rather, Most Likely To, Never Have I Ever) you want a regular poll. Reach for quiz mode there and Telegram forces you to declare one of your friends' opinions officially correct.

4. Polls are anonymous by default, which silently kills Most Likely To

Anonymity is the default, and that default is exactly backwards for half these games.

Never Have I Ever wants anonymity. People answer honestly precisely because nobody sees who tapped "I have". Most Likely To wants the opposite: the accusation is the game. "Most likely to reply at 3am: Ann, Bo, Cy" is only funny if you can see that four people voted for Bo. Run it anonymously and you get a bar chart, which nobody laughs at.

Turning anonymity off is one toggle when you create the poll, and it's the single highest-value decision in the whole session. My rule: confessions anonymous, accusations public.

5. Two requests that succeed while doing the wrong thing

These are the two red rows carrying code 200, and they're the reason I ran this test at all. An outright rejection you notice immediately, a silent substitution you ship.

Spoiler formatting is ignored inside a poll question. Telegram introduced spoiler text in 2021, and it's the mechanic that finally makes hidden-answer games work in a chat: the answer sits there covered until someone taps it. Write a poll question as Guess: ||Bo|| expecting the name to be hidden, and the API returns success, then delivers the question with the pipes visible as ordinary characters. The answer isn't hidden. It's printed, in a slightly uglier font, to everyone.

Spoilers only work in ordinary messages. So the pattern is two messages, not one: poll first, reveal second, spoiler applied to the reveal.

Bots cannot schedule anything. I sent a message with a scheduling timestamp one hour in the future. The API said success and delivered it instantly. My "scheduled" message arrived 3,599 seconds before its own schedule. There is no scheduling parameter for bots; the API just ignores what it doesn't recognise instead of telling you.

Scheduling does exist, in the Telegram app, on your side: compose the message, hold the send button, pick a time. That's how you have the rules card land in the group at 20:00 without being awake for it. It is not something you can automate through a bot, and if a tool promises you that, it is doing something else.

Two mechanics worth adding on purpose

Self-closing rounds. A poll can carry an open period. I set 30 seconds and it was created with a 30-second life. This is the closest Telegram gets to a turn timer. It ends the round for you, so the game doesn't die of one person "answering later", and it applies pressure that makes answers funnier.

Pin the rules, then edit the pin. Pinning worked, and so did editing the text of an already-sent message. Together those are a live scoreboard: pin one message at the start, edit it as the night goes, and anyone arriving late reads the current state instead of scrolling. Editing a pin doesn't re-notify the group, so it's cheap to update often.

One thing the API will not do is protect you from a broken round. A poll with a single option was accepted without complaint: a poll nobody can meaningfully vote in, delivered with a cheerful success code. Telegram checks lengths and counts. It does not check whether your game makes sense.

The host protocol this adds up to

Strip out the API detail and what's left is a short list of things a host does, all of which exist because the medium has no turns:

Name one host per session. Not a rotation, not a democracy. One person sends the prompts and closes the rounds, because otherwise two people post round four simultaneously and the thread splits.
Pin the rules, including the pace. "One round every ten minutes, replies by reply-thread." Half the failures aren't disagreement, they're people guessing at the tempo.
Poll first, talk second. A poll captures everyone's answer before the loudest voice anchors it. In an open-text round the first reply becomes the template for every reply after it.
Two passes each, then the round closes. The single rule that keeps quiet people in the game. It caps the extroverts without singling anyone out.
Space the sends. Around 20 messages per minute to one group, per Telegram's guidance. Twelve prompts fired back to back is also just unreadable.
Spoiler the reveals. Separate message, spoiler applied there, never in the poll question.

None of this is clever. It's just the set of things that turn out to be load-bearing once you stop assuming a group chat behaves like a room.

Try the free game first

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

Want the rounds already built for polls?

The Telegram Party Pack is the version of this with the work done: 255 prompts across six games, each written to fit inside Telegram's limits, plus poll-ready files where the Would You Rather dilemmas are already split into question and options, the exact split this test says you need. Includes the host guide: pinned rules, pacing, spoiler reveals and keeping a round legible when replies arrive out of order.

Get the pack — $9.99 The game above stays free, no signup.

FAQ

How many options can a Telegram poll have?

Twelve. Tested directly: 12 options were created normally, 13 came back poll can't have more than 12 options. Plenty of guides still say ten, which was true of an older API version. The question is capped at 300 characters and each option at 100.

Why can't I see who voted in my Telegram poll?

Because polls are anonymous unless you say otherwise, and most people never change it. For accusation games like Most Likely To that's fatal, because seeing who picked whom is the game. Turn anonymity off for those, leave it on for confession-style rounds where hiding the vote is what makes people honest.

Can I schedule game-night messages from a bot?

No. The Bot API has no scheduling parameter and doesn't complain if you invent one. My message with a timestamp an hour ahead was delivered immediately with a success code. Scheduling lives in the Telegram apps: compose, hold send, pick a time.

Do spoiler tags work inside a poll question?

No. Formatting is ignored in poll questions, so ||spoiler|| arrives with the pipes visible and nothing hidden. Send the poll, then reveal the answer in a separate message with the spoiler applied there.

Which games work best as polls, and which as plain messages?

Polls suit anything with fixed choices: Would You Rather (split into question and options), Most Likely To (one option per player, up to twelve), Never Have I Ever (two options, kept anonymous). Plain messages suit anything open-ended, such as Truth or Dare, Story Chain and Paranoia, where the answer is written, not chosen, and the spoiler reveal does the work.

I Messaged 18 'Best' Telegram Game Bots. 7 Never Replied

charlie-morrison — Mon, 27 Jul 2026 22:21:54 +0000

Search for something like "best Telegram games" and you'll get a dozen confident listicles. Each one hands you a set of @handles: Hangman, 2048, Werewolf, Poker, Snake. What none of them tell you is which of those bots is still running.

That's not a nitpick. I run a Telegram game myself, and in May 2026 I switched off the chat-command backend behind it. The bot account stayed. Its profile page kept loading. My own article kept telling readers to add it to a group and type /play — into total silence, for weeks, before I noticed. Nobody complained, because a dead bot doesn't produce a complaint. It produces nothing.

So I stopped guessing and measured it. I took every bot recommended by three "best Telegram games" articles currently ranking on Google, sent each one a real /start from a real Telegram account, and waited to see what came back.

Eleven answered. Seven said nothing at all.

How the test worked

I wanted this to be boring and reproducible rather than clever, so the method is exactly what a person would do by hand — just automated so all 18 got identical treatment.

The sample is the union of the bots recommended by three articles ranking for "best Telegram game bots" in July 2026: a 16-game roundup on LightXtremeVPN, MakeUseOf's "8 Fun Telegram Game Bots You Should Try", and Membertel's "5 best Telegram Game Bots". Deduplicated, that's 18 distinct handles. I didn't hand-pick them and I didn't drop any.
The probe is one message: /start, the command every Telegram bot is expected to handle, sent from my own account (@charliemorrison) rather than a fresh burner, so nothing could be blamed on an unusual account.
The wait is 15 seconds. That is extremely generous — a live bot replies in well under a second, because the reply is a program responding, not a person typing.
The verdict is based on new inbound messages only. I record the newest message ID in the chat before sending, then count only replies newer than that. Otherwise an old message from a previous visit would make a dead bot look alive — which, on two of these chats, it would have.
Pacing: 6–11 seconds of randomised delay between bots, so the run looks like a person poking around rather than a flood.

Here is the actual run:

The real output. 15 seconds of patience per bot, 18 bots, no cherry-picking.

The seven that said nothing

Bot	Listed as	Result
@PlayGame2048Bot	2048 Puzzle	Silent
@Snakeslite_official_bot	SnakeLite	Silent
@HangBot	Hangman	Silent
@dreamersbot	Dreamers	Silent
@ArenaGameTelegramBot	Arena Game RPG	Silent
@chessybot	Chessy	Silent
@LumberjackBot	Lumberjack	Silent

Every one of those handles resolves. Open any of them in Telegram and you get a normal-looking bot profile with a name and a Start button. Press Start and the chat stays empty. There is no error, no "this bot is no longer available", no hint that you're talking to a switched-off machine. The most common reaction to that is to assume you did something wrong.

Worth flagging: Lumberjack is a special case that shows exactly how these lists rot. The standalone @LumberjackBot is silent — but LumberJack the game is still perfectly playable, because it lives inside @gamebot, which answered immediately. One article recommends the working route, another recommends a handle that leads nowhere, and both describe the same game. If you followed the second one you'd conclude the game is gone. It isn't.

The eleven that answered

These replied within the window, most of them instantly: @gamebot, @ChessBot, @xoBot, @unobot, @QuizariumBot, @wordibot, @RatherGameBot, @werewolfbot, @chat_against_humanity_bot, @PokerBot and @Gamee.

Two details are worth having before you pick one:

Several are group-only, and that surprises people. Quizarium's reply to a private /start is: "Yes, it's my command, but you can use it only within a group chat." Chat Against Humanity says the same in different words — you need a group and a couple of friends before anything happens. Not broken, just not a solo experience, which most roundups fail to mention.
@unobot's own first message points somewhere else: "Also check out @UnoDemoBot, a newer version of this bot with exclusive modes and features." The bot itself is telling you the recommendation is a version behind.

One caveat I'd rather state than hide: this is a snapshot taken on 28 July 2026. A bot that answered today can go quiet next month — that is the entire point of the exercise. Treat the list as a demonstration of the method, not as a permanent verdict.

Why bots die quietly

The reason is structural, and once you see it you can predict which recommendations will rot.

A Telegram bot is not a self-contained thing living on Telegram's servers. It's the Telegram-facing half of somebody's software. The platform's own documentation is blunt about the other half: "In order for a bot to work, set up a bot account with @BotFather, then connect it to your backend server via our API." That backend is a machine someone rents, maintains and pays for every month.

When the developer moves on — new job, lost interest, hosting bill no longer worth it — they stop paying for the server. They almost never delete the bot account, because deleting it takes deliberate effort and produces no benefit. So the account outlives the product. Telegram keeps rendering the profile from its own records, and your Start button keeps sending commands into a machine that is no longer there.

This isn't unique to Telegram, it's just unusually invisible there. Pew Research Center's 2024 study on digital decay found that "a quarter of all webpages that existed at one point between 2013 and 2023 are no longer accessible", and that 38% of pages from 2013 are gone. On the web, decay at least announces itself with a 404. A dead bot has no 404. It has an empty chat.

Which means 39% silent in this sample isn't a scandal — it's roughly what a decade of link rot looks like when it's applied to software that nobody can see rotting. The scandal is that lists keep recommending them without ever pressing Start.

The bug in my own test that nearly produced a fake result

I'll include this because it's the most useful thing I learned, and because the first version of this article would have been wrong.

My first run died four bots in. Everything after @ChessBot came back with the same error — TypeNotFoundError: Could not find a matching Constructor ID — and the naive reading was that 12 bots were unreachable. That would have been a much more dramatic headline and completely false.

What actually happened: my client library (Telethon 1.43.2) was receiving live account updates in the background, including an unrelated spam broadcast that used a newer Telegram data type than the library knows about. One unparseable object killed the connection's receive loop, and every later call inherited the corpse. The bots were fine. My tooling was lying to me.

The fix was one argument — receive_updates=False, so the server never pushes those updates to this client at all — and re-running gave clean results for 15 of 18. The last three still errored, so I re-probed those with a fresh connection each. All three came back conclusive: @Gamee alive, @chessybot and @LumberjackBot genuinely silent.

The transferable lesson: when a tool reports a wall of identical failures, suspect the tool before you believe the finding. A real-world result is usually messy — some pass, some fail. Perfectly uniform failure, starting at an arbitrary point in the run, is the signature of something breaking in your code, not of the world suddenly agreeing to be broken.

The 15-second check you can do yourself

You don't need any of my scripts. Before you trust a bot from any list, including mine:

Open the bot and press Start.
Count to fifteen.
If nothing arrived, the backend is off. Move on — there is nothing to fix on your end.
If it's a group game, add it to a group and run its start command there before inviting people. Several of these only wake up in groups.

The one thing that proves nothing is the bot's profile loading. Every dead bot in this test has a perfectly healthy profile page. Telegram serves that from its own database; it has no idea whether the developer's server is still switched on.

What this changed about the game I run

Watching my own bot go silent, then measuring how normal that is, is why my party game no longer depends on a backend at all. It's a Mini App: the questions and the game logic ship inside the page Telegram opens, so there is no server left to switch off. It also opens in a normal browser, which means it survives even if I lose interest entirely — the failure mode that killed seven bots above simply doesn't exist for it.

That's not a claim you should take on faith after an article about not taking claims on faith. Press Start and count to fifteen.

Test it yourself — it should answer instantly

Truth or Dare, Never Have I Ever and Would You Rather. 151 questions per language, English and Ukrainian, no signup, no backend to die.

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

FAQ

Why does a Telegram bot stop replying?

Because a bot is only the Telegram-facing half of the product. Telegram's documentation tells developers to connect a bot account to their backend server. When that server is switched off, unpaid for or abandoned, the bot account still exists and its profile still loads — but nothing answers your commands.

How do I tell if a bot is dead before trusting a recommendation?

Open it, press Start, wait about 15 seconds. A working bot answers almost instantly because the reply is automated. If nothing arrives, the backend isn't running. A profile page that loads normally proves nothing.

Do dead Telegram bots show an error message?

No, and that's what makes them hard to spot. No error, no warning, no retirement notice — you press Start and the chat stays empty, which most people read as their own mistake.

Which recommended game bots still work?

In this test, 11 of 18: GameBot, ChessBot, xoBot, unobot, QuizariumBot, wordibot, RatherGameBot, werewolfbot, chat_against_humanity_bot, PokerBot and Gamee. The seven silent ones were PlayGame2048Bot, Snakeslite_official_bot, HangBot, dreamersbot, ArenaGameTelegramBot, chessybot and LumberjackBot. Snapshot from 28 July 2026 — re-check before you rely on it.

I Generated a Month of Social Posts With One Free Tool — Here's the Mix That Held Up

charlie-morrison — Tue, 21 Jul 2026 19:59:38 +0000

Here is how most small accounts actually plan their social media: they don't. They open the app in the morning, remember they have a thing to sell, and post about the thing. The next day they feel guilty for being salesy, so they post nothing. Three days later a competitor does something and they fire off a reactive post. That is not a strategy, it is a mood, and the algorithm can smell the difference. The accounts that grow are boring in exactly one way: they show up with a plan , and the plan is mostly not about them.

I wanted to see what that plan looks like when you take the human indecision out of it. So instead of writing about content-calendar theory, I ran a real niche through a free content calendar generator I put on this site, read every post it planned, and checked whether the balance it produced matches what the people who study this for a living recommend. This is that experiment: one frozen input, the raw output, and an honest account of what a machine gets right and wrong about a month of posting.

The input I froze

I gave it a deliberately unglamorous, real-world case -- the kind of account that actually struggles with this: a small fitness coaching business on Instagram , posting 5 times a week for 4 weeks. Twenty posts. No brand voice tuning, no cherry-picking; I took whatever the first generation handed me and read it top to bottom.

The first thing I noticed was what it refused to do. I never told it "go easy on the selling." It decided that on its own. Out of twenty planned posts, only three were straight promotion. The other seventeen were teaching, asking, showing behind-the-scenes, or proving results -- the stuff that earns the right to sell in the first place.

The generated calendar for a fitness coach on Instagram -- each card carries a pillar badge, a hook, a CTA, and a best-time suggestion. Note how few of them are "Promote."

The mix it enforced (and why it's right)

When I tallied the pillar badges across the twenty posts, the shape was clear. Educational content was the backbone, engagement posts came second, and promotion was deliberately a minority slice. Roughly:

Pillar	Share of the month	What it looked like
Educate	~35%	"3 mobility drills before you squat," "why your scale lies to you"
Engage	~20%	"What's the one exercise you avoid? Be honest." polls, this-or-that
Behind-the-scenes	~15%	"My actual 6am prep," a client session setup
Inspire / proof	~15%	a transformation, a client win, a mindset reframe
Promote	~15%	the coaching offer, a spot opening, a free consult

If that ratio feels familiar, it should. It is a near-exact match for the frameworks marketers have converged on for years. The classic social media rule of thirds splits your feed into roughly one-third promotion, one-third curated industry value, and one-third personal, relationship-building content. The even more common 80/20 rule is blunter: 80% of your posts should inform, educate, or entertain, and only 20% should sell. The generator landed at about 15% promotion without being told either rule -- it just bakes the principle in so you can't drift back to selling every day.

That drift is the entire problem the tool solves. Nobody plans to be a walking advertisement. It happens because promotion is the only post type that feels "productive" in the moment, so when you improvise, you over-index on it. A calendar quietly removes the improvisation. You are no longer deciding whether today is a sales day; the plan already decided, and it said no most of the time.

The cost of getting this wrong is invisible until it isn't. An account that sells in half its posts doesn't get a warning; it just slowly trains its audience that opening a notification means being pitched. People mute before they unfollow, so you never see the moment they check out -- you only see reach quietly sliding down over months while you post the same amount. The value-first mix is not a feel-good nicety. It is the thing that keeps the audience willing to see the 15% of posts where you actually ask for the sale. You earn the promote posts with the seventeen that came before them.

What the generated posts actually contained

A pillar label is worthless if the post underneath it is filler, so I read the contents, not just the badges. Each card came with four things I would otherwise have to invent from scratch:

A specific idea , not a category. Not "post something educational" but "the three warm-up mistakes I see every new client make." The difference between a prompt and a blank page.
A hook written to survive the half-second thumb-scroll -- a question, a mild contradiction, or a number. Hooks are where most amateur posts die, and it is the one line I am worst at writing under time pressure.
A platform-tuned CTA. Instagram got "save this for your next session" and "DM me the word START," not the LinkedIn-flavored "thoughts?" that reads as tone-deaf on IG.
A best-time-to-post nudge and format hint (reel vs carousel vs single image), so the calendar is a shooting schedule, not just a topic list.

Were they perfect, finished captions? No. They are strong first drafts -- the skeleton and the hook, with room for your real voice and your real client stories. But going from "I have no idea what to post for four weeks" to "I have twenty specific, balanced ideas with hooks" in about ten seconds is the entire value. The blank page is the tax; the tool pays it for you.

What it can't do

I would be lying if I sold this as a full content team. Three honest limits:

It doesn't know your voice or your stories. The ideas are sound and the structure is right, but the thing that makes a fitness post yours is the client who cried after their first pull-up, and the tool has never met her. You still have to pour the specifics in. It gives you the mold; you supply the metal.

It doesn't watch what works. A real calendar is a loop: post, read the analytics, do more of what landed. A generator gives you a strong month one. It cannot tell you that your carousels crush and your talking-head reels flop, because it never sees your numbers. After the first cycle, you are the one who has to prune and double down.

It doesn't replace consistency. This is the quiet punchline of every content-mix framework, and the marketers who study it say it plainly: the ratio only works if you actually apply it week after week. A perfect calendar you post from for nine days and then abandon loses to a mediocre one you keep for six months. The tool removes the planning excuse. It cannot remove the showing-up part.

The honest verdict

For anyone staring at an empty content calendar -- a solo founder, a freelancer, a small brand with no social hire -- generating a balanced month in one click is genuinely useful. It solves the blank-page problem, it enforces a value-first mix you would not hold to on your own, and every post lands with a hook and a CTA already attached. What it can't do is know your voice, read your analytics, or post for you. Treat it as the frame of the month, then fill it with real stories and adjust from your own numbers. The generator gets you a plan; you turn the plan into a following.

Skip the blank calendar entirely

The 2026 Social Media Content Calendar bundles a full year of balanced post ideas plus 110 caption templates -- the same value-first mix, pre-written, so you spend your time filming instead of staring at a grid.

Get the 2026 Content Calendar -- $17

FAQ

How much of my social content should actually be promotional?

The two most-cited frameworks agree it's a minority. The 80/20 rule caps direct promotion at about 20% of posts; the rule of thirds puts it around one-third, with the rest split between industry value and relationship-building. In practice, aiming for 15-20% promotion and putting the rest into teaching, engaging, and proof keeps you from training your audience to scroll past you.

Is a generated content calendar just generic filler?

The topics are a starting frame, not a finished caption. A good generator gives you a specific idea, a hook, and a CTA per post -- which solves the blank-page problem -- but you still add your own voice, client stories, and real examples. Think first draft from a sharp assistant, not a done-for-you feed.

How often should a small account post?

Consistency beats volume. Three to five well-planned posts a week that you can sustain for months will outperform daily posting that burns you out in three weeks. Pick a cadence you can actually keep, plan it in advance so you're not deciding daily, and protect that schedule.

Related reading: I also ran the numbers on the AI content-creation tools worth using in 2026, and the free social media AI helper here drafts captions and hooks once you know what you're posting. All of it follows the same rule as this post: plan the mix first, sell second.

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.

I Ran 4 Salary Negotiation Tones Through an AI Detector

charlie-morrison — Mon, 20 Jul 2026 20:04:51 +0000

Half the salary advice online now ends the same way: paste your role into some generator, pick a tone, copy the script it spits out, send it. I have nothing against that. A script beats freezing up when a recruiter asks what number you had in mind. But there is a quieter problem nobody mentions. Hiring managers read a lot of email, and in 2026 a growing share of them can smell a machine-written message from the subject line. If your carefully generated counter-offer reads like it came out of a chatbot, the number is not the thing that sinks you. The voice is.

So I stopped guessing and measured it. I took one free salary negotiation script tool, gave it a single scenario (countering a lowball offer) and generated the exact same negotiation in all four of its tones. Then I fed each result into an AI-text detector and wrote down the score. Same facts, same numbers, same person. Only the tone changed. The spread surprised me, and the tone I expected to sound the most robotic came out the most human.

The test: one offer, four tones, one detector

I kept every input frozen so the only moving part was tone. The scenario was "countering a lowball offer." The role was Senior Backend Engineer in tech, eight years of experience, a current offer of $120,000, and a target of $150,000. For the three achievement bullets I used real, specific wins: cut cloud spend 34% by re-architecting the billing pipeline, shipped a fraud-detection service now screening four million events a day, mentored three juniors with two promoted inside a year. Concrete numbers, because vague bullets are their own separate problem.

Then I generated the script four times, switching only the tone selector: Confident & Direct, Collaborative & Warm, Data-Driven & Analytical, and Humble but Firm. Each run produced two script versions plus a short tips block. I ran the raw script text of each tone through the same AI-writing detector I use on my own drafts before anything ships. It returns a 0-to-100 score where higher means more machine-like. Here is the data-driven run mid-generation, so you can see the tool and the inputs I am describing:

The free salary script tool generating the "Data-Driven" counter-offer, using the same frozen inputs, one of four tone runs.

The scores

Lower is better here. A low score means the text reads like a person wrote it.

Tone	AI-likeness (0-100)	Reads as…
Data-Driven & Analytical	2	Clearly human
Humble but Firm	23	Mostly human
Collaborative & Warm	28	Borderline
Confident & Direct	35	Most machine-like

I had it backwards going in. If you had asked me to guess, I would have said the "Data-Driven" tone, with its percentiles, market bands, and the word benchmarked , would read the most like a spreadsheet wrote it. It read the most human of the four, by a wide margin. And "Confident & Direct," the tone that is supposed to sound like a real person putting their foot down, scored the highest on the robot scale. The reason turns out to be simple once you read the two side by side.

Why "Confident" read like a bot

Here is the confident version, lightly trimmed:

Thank you for the offer of $120,000. I want to be straightforward: that's significantly below what I'm seeing for Senior Backend Engineer positions in tech… I need to be at $150,000 to accept. I'm not trying to negotiate for the sake of it -- that number reflects my market value and the results I'll deliver. Is there flexibility on your end?

Read it out loud and the tells stack up. " I want to be straightforward." "I have to be honest." "I'm not trying to negotiate for the sake of it." These are announcements of a posture rather than the posture itself, the verbal equivalent of a header that says TONE: CONFIDENT. Real confident people rarely narrate that they are being direct; they are just direct. Then it closes on a soft rhetorical question, " Is there flexibility on your end?", which is the exact hedge-after-a-bold-claim rhythm that AI detectors are tuned to notice. The message is trying to perform confidence, and performance is what reads as synthetic.

Why "Data-Driven" read human

Now the same offer in the data tone:

I'd like to discuss the offer of $120,000. Here's my analysis: market rate for Senior Backend Engineer in tech sits in the $150,000 range… The offer sits below the 25th percentile for someone with eight years of experience… My counter: $150,000, which is in line with the median. I'd rather we both start with a number grounded in data. Does this align with your internal bands?

There is almost no throat-clearing. It states a fact, attaches a number to it, and moves on to " below the 25th percentile," "in line with the median," "your internal bands." Concrete nouns crowd out the filler phrases, and the closing question is a genuine ask about the company's pay bands, not a rhetorical softener. Detectors key on generic connective tissue, the "I want to be honest with you" padding, and this version simply has less of it. The lesson is not "always pick the data tone." It is that specificity is what makes writing sound human , and the data tone happened to force the most of it.

What this actually means for your next email

You do not need to abandon script tools. You need to edit their output like a human would before it leaves your outbox. Three moves cover most of it:

Delete the posture announcements. Cut every "I want to be honest," "let me be straightforward," "I'm not trying to be difficult." If the sentence describes your tone instead of doing the work, it goes.
Replace one vague clause with a number. "Below market" becomes "below the 25th percentile for eight years' experience." Specificity reads as human and, separately, it is more persuasive. Harvard Business Review's long-standing negotiation guidance is that you justify the ask with evidence, not adjectives (HBR's 15 rules for negotiating an offer).
Kill the rhetorical closer. "Is there flexibility on your end?" is filler. "Can you match $150,000, or should we talk about the equity side?" is a real question that forces a real answer. Indeed's script guidance makes the same point: state the counter and the reason clearly and stop (Indeed's salary negotiation scripts).

Run whichever tone fits the relationship, then spend two minutes stripping it of the four or five phrases that scream "generated." That two minutes is the difference between a message a hiring manager reads as a candidate who did their homework and one they read as a candidate who pasted a template.

Generate the script, then make it sound like you.

The Job Search AI Toolkit is 100+ prompts for the whole offer stage: counter-offer language that avoids the robotic tells, the follow-up note after you send it, and the "what's your range" answer that comes before any of it. Built for editing, not blind pasting.

Get the Job Search AI Toolkit -- $12

One caveat about the number itself

An AI detector measures how machine-like the prose is, not whether the negotiation is any good. A perfectly human-sounding email that asks for a number with no justification behind it will still lose to a slightly stiff one backed by real market data. The tone test is about clearing a threshold, so you avoid tripping the "this is a bot" reflex. It is not about winning the negotiation on style. Get the message past the human filter first, then let the evidence do the arguing. If the underlying number is wrong, the smoothest wording in the world will not save it, which is a separate exercise in answering the salary-expectation question before you ever get to the counter.

FAQ

Do salary negotiation scripts really sound like AI to hiring managers?

Some tones do. In my test, the "Confident & Direct" script scored 35 out of 100 on an AI detector while the "Data-Driven" version scored 2, from the exact same inputs. The difference was filler phrases like "I want to be straightforward" and a rhetorical closing question, both patterns detectors flag. A hiring manager who reads a lot of email notices the same rhythm.

Which tone should I use for a counter-offer?

Match the relationship, but bias toward specificity. The data-driven framing read the most human in my test because it swapped vague adjectives for concrete numbers: percentiles, medians, your role's pay band. You can use any tone and get the same effect by editing out the posture announcements and adding one hard number to justify the ask.

How do I make a generated negotiation email sound less robotic?

Delete the phrases that describe your tone instead of showing it ("let me be honest," "I want to be direct"), replace one vague clause with a specific number, and turn any rhetorical closing question into a real one that forces a decision. Those three edits removed most of the AI-likeness in the scripts I tested.

Is it a bad idea to use a salary script tool at all?

No. A script is a good starting point, especially if negotiating makes you freeze. The mistake is pasting the output unedited. Generate the structure, then spend two minutes stripping the four or five generic phrases that make it read as machine-written before you send it.

Does an AI detector score tell me if my negotiation will succeed?

No. It only measures how human the prose reads, not whether the ask is justified. A human-sounding email with no evidence behind the number still loses to a stiff one backed by market data. Use the tone check to clear the "this is a bot" filter, then let concrete numbers carry the actual argument.

Related reading: I generated 30 salary negotiation scripts to see which openings recruiters actually respond to, and what happened across 38 counter-offer negotiations. Both use the same "test the advice, don't repeat it" approach as this post.

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.

DEV Community: charlie-morrison

Telegram editMessageText: Your Keyboard Vanishes (Tested)

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

Removing a keyboard on purpose

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

Telegram in Production

FAQ

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

The setup

The ceiling is 100, and it refuses rather than truncates

The charset is enforced, not cleaned up

Telegram in Production

Two rewrites that happen on the way in

The leading slash is stripped

Duplicate names are deduplicated, last one wins

The description field

Scopes shadow, they do not replace

What to do with this

FAQ

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

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

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 ``

Telegram in Production

The probe

FAQ

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

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

Telegram in Production -- the parts that bite you

What I would do with this

Limits of this measurement

FAQ

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

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

Building on Telegram for something lighter?

What I did not test

The short version

Telegram in Production -- the parts that bite you

More from the Telegram build log

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

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

Building on Telegram for something lighter?

What I did not test

The short version

Questions I had before I measured

Telegram in Production -- the parts that bite you

More from the Telegram build log

Telegram Poll Limits: What I Measured Against the Live Bot API

How I tested it

The hard walls

The character cap counts characters, not bytes