Why the numbers disagree
Your editor counts characters. The networks do not, and each one is wrong in a different direction. X replaces every link with a t.co URL and charges 23 for it no matter how long the original was, so a post with a long link is shorter than it looks. Bluesky counts grapheme clusters, so an emoji with a skin-tone modifier is one character rather than four. X weights CJK and emoji at two, which caps a Japanese post nearer 140 than 280.
The counts above model those published rules, and the card tells you when its number disagrees with your editor’s. Link weighting and CJK weighting follow the rules exactly. Emoji are the one place the answer can drift: X recognises them through twemoji, and this page has no runtime dependencies, so it matches them with Unicode properties instead. A sequence it misses costs the sum of its parts, never less, so the error runs toward cutting early rather than letting a post through that X would reject.
The red line is the API’s hard cap, exact except where the card says otherwise: Mastodon’s 500 is what a stock instance ships with and an operator can raise it, so that card says so. The amber line is where the feed collapses your post behind a “see more”, which is a client behaviour that moves with viewport and browser, so it is labelled as the estimate it is.
The second panel
It marks the mechanical tells that make writing read as machine-written: em dashes, “delve”, “seamless”, “not just X but Y”, trailing clauses that add nothing. It reports a count, never a percentage and never a verdict on who wrote something, because only the count is a claim you can check by looking.
Merge & Tell writes the post. This tells you whether it fits.
You were going to merge the PR anyway.