Cooldowns are part of the viewer experience
A bot can be technically online and still make the stream worse. If ten viewers trigger the same command in a minute, the useful answer becomes noise. The right cooldown keeps commands helpful without making the bot feel broken.
Design cooldowns for the moment chat gets busy, not for the quiet test stream. The bot should behave well during a raid, a giveaway, a viral clip, a TTS pileup, or a sponsor segment when everyone is trying to use the same command.
A cooldown is not just a technical throttle. It is a pacing decision. It decides which messages deserve room, which viewers get feedback, and whether the streamer can still read the conversation.
Respect platform limits before you feel them
Twitch documents chat send limits for normal and privileged accounts, including per-channel behavior. Kick's chat API documents message posting, a 500-character content maximum, and 429 Too Many Requests responses. YouTube's live chat list API includes a polling interval that clients should respect between requests.
The streamer version: do not make your bot argue with the platform. Rate-limit your own commands first. If the platform has to reject your bot, you have already let the viewer experience get messy.
Platform limits are also not the only limit. Chat readability, moderator attention, stream audio, and overlay space all run out before the API does. A bot that stays below the official rate limit can still spam the room.
- Use one global cooldown for noisy commands like !tts or !song.
- Use per-user cooldowns for commands viewers may spam for attention.
- Keep bot replies under a few short sentences.
- Prefer one compact help command over many auto-replies.
- Treat platform 429 or rate-limit responses as a bug to fix, not normal behavior.
Use four cooldown layers
A single cooldown number is too blunt for real streams. Use four layers: global, per-command, per-user, and role-based. Together they prevent spam without blocking useful moderator actions.
Global cooldown protects the whole chat from bot floods. Per-command cooldown protects individual noisy commands. Per-user cooldown stops one viewer from hammering the same action. Role-based bypasses let moderators and the broadcaster act when viewers are restricted.
- Global cooldown: slows all public command replies when chat is busy.
- Per-command cooldown: limits noisy commands like !song, !tts, !clip, or !lurk.
- Per-user cooldown: stops one person from repeatedly triggering attention commands.
- Role bypass: lets moderators use operational commands during incidents.
- Emergency pause: stops nonessential bot replies while paid or safety issues are handled.
A practical cooldown recipe
Start stricter than you think. You can always loosen cooldowns after watching real chat. The first stream should prove that commands do not bury the host, alerts, or moderator messages.
Paid commands deserve special handling. If a viewer paid for TTS or an upload, do not let free commands flood the explanation or push the pending state out of chat.
Use cooldowns by command category instead of guessing per command forever. Help commands, monetization commands, fun commands, queue commands, and moderator commands all have different jobs.
- Help/rules commands: longer global cooldown.
- Monetization commands: medium cooldown, short reply, link-first copy.
- Moderator commands: no viewer cooldown, but restricted permissions.
- Fun commands: strict per-user cooldown and easy retirement.
- Queue-status commands: medium cooldown and one concise state reply.
Suggested starting values
Exact numbers depend on chat size, but starting values help. For small streams, a thirty-to-sixty-second global cooldown on help commands is usually enough. For fun commands, use a longer per-user cooldown so one regular cannot dominate. For TTS commands, keep the reply short and avoid repeating it every time someone asks.
For busy streams, increase global cooldowns before you increase reply length. A shorter answer less often is better than a longer answer constantly. If viewers still need information, pin it, put it on the overlay, or add it to the panel below the stream.
- Rules or help: 60 to 180 seconds global cooldown.
- Tip, TTS, or upload: 30 to 90 seconds global cooldown with a short reply.
- Fun commands: 120 to 300 seconds per user, plus a global cooldown if noisy.
- Song or queue status: 30 to 60 seconds, with one compact answer.
- Moderator commands: restricted by role, logged, and exempt from viewer cooldowns.
Protect paid interactions from free-command noise
A viewer who paid for TTS, an upload, or an alert should not have the status buried by free commands. When a paid queue is active, reduce nonessential bot chatter. Let the paid moment breathe.
This does not mean paid viewers can spam. Paid interactions need their own queue, cooldown, moderation status, and playback rules. The point is to make free commands quieter while the stream is handling money, not to remove guardrails from paid actions.
- Pause fun commands while a paid TTS message is pending approval.
- Show one queue status message instead of repeated reminders.
- Let moderators silence nonessential bot replies during disputes.
- Keep paid queue state visible in the dashboard, not only in chat.
- Log failed or skipped paid moments for support review.
Design quiet failure behavior
Bots fail. APIs return rate-limit responses, chat permissions expire, network calls time out, and browser sources disconnect. The failure mode should be quiet and understandable, not a new spam loop.
If a command is on cooldown, do not always reply with a cooldown warning. That warning can become spam too. For busy chats, silent cooldowns are often better. For paid actions, show status in the queue or dashboard where the moderator can see it.
- Use silent cooldowns for common fun commands.
- Use one polite cooldown reply for monetization commands, then silence repeats.
- Do not retry failed chat messages in a tight loop.
- Back off when a platform returns rate-limit errors.
- Alert moderators privately when the bot loses permission or queue access.
Give moderators operational controls
Moderators should not have to fight the bot in public chat. Give them commands or dashboard controls to pause public replies, clear queues, disable a specific command, and switch the bot into event mode during raids or sponsor segments.
Event mode is useful when chat spikes. It can reduce fun commands, keep monetization replies short, and prioritize safety messages. When the spike ends, moderators can return the bot to normal without editing every command one by one.
- Pause all nonessential commands.
- Disable one command that is being abused.
- Force the next help reply to include only the current paid action.
- Slow TTS or upload prompts during sensitive segments.
- Log moderator changes so the team can review them later.
Test cooldowns with a fake spike
Do not judge cooldowns from a quiet setup screen. Create a fake spike before launch. Have a few trusted people trigger help, TTS, rules, upload, and fun commands at the same time while a moderator approves and rejects test paid items.
Watch the recording back. If the bot talks over the streamer, buries paid status, repeats the same reply, or makes moderators ask viewers to stop using commands, tighten the cooldowns. If viewers cannot find the paid action at all, make that one reply clearer rather than making every command louder.
- Run the spike test with the real OBS browser source visible.
- Trigger one platform rate-limit safe backoff path.
- Confirm moderator-only commands still work.
- Check that public chat remains readable.
- Write down the cooldown defaults so future changes are deliberate.
Make the reply shorter before making the cooldown longer
Sometimes the cooldown is not the real problem. The command reply is too long. A twenty-word answer every minute can be easier to live with than a hundred-word answer every five minutes, especially on mobile chat.
Before adding harsher limits, trim the response to the action, status, and link. Move policy details to the landing page or overlay. The bot should point, not lecture.
- Put the action first.
- Put the link second.
- Move exceptions and policy details out of chat.
- Use the overlay for queue status when chat is too fast.
Quick answers
How long should a command cooldown be?
Use the shortest cooldown that keeps chat readable. For common help commands, start around one to three minutes. For monetization commands, keep the reply short and prevent repeated spam while the paid queue is active.
Do platform rate limits matter for small streamers?
Yes. Small streams can still create spam loops, and building around rate limits early prevents bad habits from becoming production issues later. Chat readability matters even before API limits are close.
Should every command have a cooldown?
Every viewer-triggered command should have some guardrail. Moderator-only commands are different because access is already restricted, but they should still be logged when they affect the show.
Should the bot tell viewers every time a command is on cooldown?
Usually no. Cooldown warnings can become spam. Use silent cooldowns for fun commands and one concise status reply for important monetization commands.
