Given the constraint you've shared I see two possibilities:
- assume worst case scenario, as you suggested. The questions to consider are:
- what is the byte limit in the API anyway and what is the most typical length of the message, i.e. how likely are the users to hit the limit?
- how many users will be affected by this? I.e. if most of your users are typing in e.g. Japanese, Chinese, Cyrillic or other "byte-hungry" character set, the assumption is correct
- how often do the characters with more bytes encoding appear, i.e. how much of the precious storage space will be lost
In this scenario the users meet with a no-brainer counter that decreases each time they type one character. They may be, however, disappointed by the insufficient length of the message.
- make the counter dynamic, i.e. the counter presents the amount of bytes available and decreases according to the entered character, which is by one to four units at a time. The questions to consider are:
- how aware are your users of using variable width encoding and how many of them are there, i.e. who will see the counter decreasing at double, triple or quadruple speed while typing?
- how likely the more-byte-characters are to appear causing the counter to jump by couple of units while entering just one character
In this scenario you benefit from using variable width encoding, however the users face the consequences. If your users are forgiving you may put some explanation next to the counter, e.g. in the form of a pop-up message that will appear each time a more-byte-character is entered (and allow the users to dismiss it once they are aware).
The advantage of either solution is that users can complain in any case (message limit too strict or counter jumping). Should the complaints be frequent you can use them as a reason for API change request.
You can also combine both of the solutions and the proposed bar/pie display in the following way (your limit is 400 bytes which is something between 100 and 400 characters, depending on what kind of characters the users are typing):
- show a bar/pie titled space left and decrease it by 0.25% each time the user enters a byte (i.e. one-byte character => 0.25% decrease, four-byte character => 1% decrease)
- when the bar is between 100% and 25% make it green
- when the bar is between 25% and 10% make it orange/yellow
- when the bar is less than 10% (40 bytes, 10 to 40 characters) here is where the worst-case scenario begins - decrease the bar/pie by 1% regardless of the character-byte length and show the message X characters left.
This way you waste not more than 30 bytes space (7.5%, I hope you can afford it).
The users are shown the approximate space left when there is still plenty of it and an exact value left when they reach the limit.
The jumping of the approximate counter will not be noticeable and the jumping of the accurate counter (sub-10%) does not occur.
You can play with the percentage ranges to achieve eye pleasing result.