Who actually reaches the message limits, and what they see

The assistant stops answering after several messages in quick succession, and starts working again a minute or so later.

In rough order of how often each one turns out to be the answer. Work down rather than across: each carries a way to tell whether it is yours before you change anything.

• 1

  The per minute cap, reached by a burst

  Why

  Chat is limited to 10 messages a minute for each visitor. Somebody typing questions does not get near that. Somebody clicking every suggested question in turn, or holding down send, does.

  How to confirm it is this one

  In the network tab the chat request comes back as 429 with no stream at all, and the response body names the exhausted counter as the visitor minute one, along with the number of seconds to wait.

  Fix

  Wait. The window is fixed rather than rolling, so it clears on its own and there is nothing to reset from the dashboard.

• 2

  The per hour cap, reached over a longer sitting

  Why

  The second counter allows 60 messages an hour for each visitor. An afternoon of testing reaches it easily, and it is the one that catches people out, because it can refuse a message when the last minute has been perfectly quiet.

  How to confirm it is this one

  Same place, same status, different counter: the response body names the visitor hour counter rather than the minute one, and the seconds to wait are a large number rather than a small one.

  Fix

  Wait it out, or carry on in a different browser profile or a private window, which gets a different visitor identifier and therefore a different counter. That is a testing convenience rather than a way around anything, because the limit per network address still applies.

• 3

  An automated test is driving the widget

  Why

  A test that opens the panel and sends messages in a loop is one visitor as far as the counters are concerned, because the identifier is kept in browser storage and reused on every page. A loop reaches the minute cap, then the hour cap, and then stays there for the rest of the run.

  How to confirm it is this one

  The refused requests all carry the same visitor identifier, and they begin at a predictable point in the run rather than at a random moment.

  Fix

  Put a delay between messages, or clear browser storage between cases so that each case is a new visitor. If what you are testing is behaviour under a limit, then the limit working is the pass condition rather than the failure.

• 4

  Several people are behind one network address

  Why

  There is a separate limit per network address, on messages and on starting sessions both, because a visitor identifier is generated in the browser and cannot be trusted on its own. An office, a school or a large corporate network presents one address for everybody behind it.

  How to confirm it is this one

  The refusals come from different visitors on the same site at the same moment. Where it is session creation rather than messaging that fails, it is the session request that returns 429, and the panel shows a line asking the visitor to wait rather than an answer.

  Fix

  Nothing to configure. The address limits are counted per minute, so they clear quickly, and the per visitor limits above are the ones a single determined person can actually reach.

• 5

  Retrying while blocked keeps the counters moving

  Why

  The counters are checked together, and a request refused by one still counts against the others. Retrying immediately never shortens the wait and can lengthen it, by spending the hourly allowance on attempts that were never going to be answered.

  How to confirm it is this one

  Retry a few times and watch the counter named in the response change from the minute one to the hour one. That is a short wait turning into a long one, and it is visible while it happens.

  Fix

  Stop retrying. Read the seconds to wait out of the response and wait that long once.

If every visitor is refused rather than one, this is probably not a rate limit at all. A workspace that has used up its monthly replies also stops answering, and it looks different in the network tab: the chat request succeeds and streams, and the stream carries an error naming the quota, with your configured offline message as the text the visitor sees. A rate limit never gets as far as a stream.

What does the visitor actually see?

The offline message you set in the appearance settings, not the limit wording. The panel shows that message whenever an answer does not come back, whatever the reason. Worth knowing when you write it: a sentence suggesting they try again shortly covers this case honestly, and covers a genuine outage too.

Can the limits be raised for my site?

They are not a per assistant setting. They are sized so that no real visitor meets them, and raising them for one site would weaken the protection on a key that anybody can read off the page it is installed on.

Does a refused message cost me anything?

No. A refused request stops before the assistant is asked anything, so it is not answered, not stored as a message, and not billed. That is also why the limits sit in front of the work rather than behind it.