I have a chatbot that is now in several channels and am concerned about the rate limit. The rate limit for a known bot is stated as 50 messages per 30 seconds. My bot has a self limit of 1 message per 6 seconds per channel, but if 10 or more channels happen to hit that then the bot would get timed out for 30 minutes.
Channels could give the bot mod, increasing the limit to 100 per 30 seconds, but how is that calculated if not all channels mod it? Also I prefer not to have the bot modded because in my opinion that violates the principle of least privilege. There is no reason for my bot to be modded other than the increased rate limit. (some streamers like it modded for the visibility that the mod tag brings though.)
The next tier up is 7500! That’s a bit overkill for my bot, and am a bit surprised that there isn’t another in-between tier.
Keep in mind this rate limit is per channel so if I say hey 50 times in
#modesttim I can still say hey 50 times in
#dallas for example
Edit: I’m wrong
when was that changed @modesttim ? I actually thought its an overall limit?
IIRC it’s channel because it’s a channel specific command (PRIVMSG), Things like JOIN or PART would be global commands but I could be wrong.
Edit: I just tested 5 different channels 50 messages each at the same time (Mod in 2 of the channels) and all messages went through fine with the connection staying open still able to send messages after
Edit Again: My test was flawed do to poor pre-coffee code see @3ventic’s reply under this for a real answer.
They’re global limits, unless I’m severely out of the loop. 50 messages in 30 seconds in a single channel is already overkill, unless you count timeout waves in large channels.
@modesttim I only see 24 messages from your 5-channel test; not modded there’s also a separate cap of one message every 1.5 seconds, which prevents going above 20/30 in that channel.
This is a prime example on why I shouldn’t try to contribute to forums first thing out of bed and then proceed to write poor tests. My apologies.
Looking back at the code I see where my test went wrong and didn’t catch the error, I was counting the wrong number I had two vars called the same thing.
Sent was the message I was sending and
sent was the new message from the twitch channel I should of been counting
sent rather than
You say they are global, but then say 50 messages per 30seconds in a channel is overkill. I find that confusing. Global makes me think that I can only send 50 per 30 seconds total, i.e. 10 in channel a, 10 in channel b, and so on.
If it were 50/30 in a single channel I would agree that’s overkill, and with the limit I have placed on my bot it would never reach it. (short of an unforseen bug in the code.)
Could you clarify which you meant?
It’s global: a known bot can send a total of 50 messages across all channels within any 30-second window.
So how would it be calculated if the bot was modded in some channels and not in others?
well and thats where the fun beginns. if you send 50 msgs in channels where your bot is a mod and then the 51th is in a channel were your bot is no mod you are basically ******
It’s easiest to just assume you’re not a mod and limit your bots output around that, so in a situation where for whatever reason your bot is not a mod and says something that could potentially hit the limit, your bot just would drop/queue the message rather than send it.
Think of it like a bucket of 100 for every 30 seconds. The first 50 messages in the bucket can be sent to any of the channels, 51-100 can only be sent to the channels where the bot has mod status.
You must trust the broadcasters in order to use the 51-100. If the bot gets unmodded between messages 51 and 52, for example, there is no way for the bot to detect this in time and the 52nd message will exceed the rate limit. Multichannel bots should always stick to the known/verified bot limit for this reason.
Ok I think I’m clear on the rate limits, but now let’s look at it form a user (chatter) side. If the bot has hit the rate limit and someone sends a command, the bot can either queue the response or drop the response, either way the user who sent the command is left wondering if the bot is somehow broken due to the sluggish or missing response.
With a per channel rate limit they can easily see that the bot recently sent a command, and is on cool down. However, They have no way to know if the bot has hit the global limit, this creates confusion. Did they type the command right? Is the bot broken? Etc…
I want to avoid anything that would appear as erratic behavior.
I’m 100% with you.
- Let’s say my bot is connected to 150 chats and it’s modded in all of them. In a window of 30 seconds, at least 1 user in each chat decided to trigger a command on the bot by pure free will. Bot’s now global’d. So you come here and ask how to deal with this and you get told to queue your messages. Right… so a user would trigger a command and see the response delayed by seconds or even minutes. EIther that or discard the response and make the user think the bot’s broken.
- Timers though. Bots connected to 2000 channels offering commands and timers. Just with timers alone the chances of getting global’d are so high.
- I’m supposed to believe that popular bots connected to hundreds, if not thousands, of chats over the years (even before known or verified status) have been working under these limits with no problems? Without circumventing them in any way?
- Again, even before known/verified, If all of this is true, why don’t I see Nightbot getting global’d all the time? Why don’t I see it respond to commands with a delay due to a queue? Why don’t I see it drop responses? I’ve only seen Nightbot down no more than 5 times.
If someone from staff would tell me “honestly, I’m not 100% sure about it” or “those bots use proxies to send messages to chat from different IPs” I would believe it. Either I don’t understand maths at all or there’s a lot of bullshit going around. This is all I got the last time I asked. https://discuss.dev.twitch.com/t/trying-to-understand-chats-rate-limit/11693
Current situation is that those large bots you speak of all work within the verified bot limits. 7500 is a lot.
Ok, “current” I can understand. But what about before verified was a thing? Is Twitch gonna be more flexible in the future regarding who’s worthy of having a verified bot?
Before verified status was added the rate limits were per connection so you could open up as many as needed to distribute your messages to keep them under the limit.
But eventually it was abused so limits needed to be added.
7500 is a lot, 50 is not quite enough, and as 3ventic pointed out the modded 100/30 limit isn’t really practical because you have to be mod and trust that mod won’t be removed (as well as my point earlier that middling a bot simply for rate limits gives unnecessary other privileges).
My bot is currently in about 15 channels, it doesn’t need 7500, it doesn’t need moderator privileges, heck it’s still unlikely to hit the 50/30 limit, but it’s possible, and may still get added to more channels.
Can I get my bot added to verified status? Could twitch add another tier of rate limits? Maybe the answer is to increase the limit for known bots?
I view this as a potential stability issue that I need to iron out before my bot gets to the 50/30 point…
If you need a higher limit I’m sure it would be helpful to Twitch if you could provide evidence to support that. One of the reasons to the limits are what they are is to prevent abuse, so rightfully so Twitch aren’t going to raise a bots limit when there’s no sufficient need to. So what you may want to do is log usage statistics, how close you are getting to your limit on average, at peak times, and how frequent those peaks are, you may find you don’t actually need higher limits.
Higher limits would always be nice, and personally I’d like something similar to Helix rate limits but for chat so we could simply email for a rate limit increase and provide the use case and justification for the limit increase.
In the google form there is an application for higher chat limits too. In the same form that you use for helix rate limits or webhook/pubsub connection limits.