HTTP 429 responses from Gitter's message-streaming API under concurrent connections

Gitter's API signals rate-limit exhaustion with HTTP 429 responses, and the standard X-RateLimit-* response headers expose remaining quota and reset time. When latency or dropped events appear only while multiple rooms or clients are active simultaneously, the message-streaming endpoint becomes the suspect component, since it maintains long-lived connections per room rather than handling isolated requests.

The unresolved behavior is whether the rate-limit budget is accounted per access token or per connection. Two clients sharing a single token may exhaust a shared quota while separate tokens do not, but it is undocumented how streaming connections are charged against the same budget as ordinary REST calls.

Concurrency-only latency can also originate outside Gitter. SSE-aware proxies, corporate middleboxes, or client-side parsing may buffer or delay events, so a slowdown without any 429 does not by itself implicate the service. Under current GitLab operation, the API surface remains subject to change, so any observed limit reflects a live snapshot rather than a stable contract.

Is the rate-limit budget for Gitter's message-streaming endpoint counted per access token or per connection? How are long-lived streaming connections charged against the same quota as REST calls? What is the current documented behavior for X-RateLimit-Remaining decrements when multiple rooms share one token?