429 Too Many Requests: rate limit exceeded on a cloud VM

This page as markdown: https://aluvia.io/unblock/rate-limit.md

429 Too Many Requests is often counted against the IP. When Rate limit exceeded hits a cloud agent, a residential IP sometimes starts a fresh count because neighbours on the same cloud range already spent the budget.

Fix

npx aluvia-cli setup
aluvia proxy-on

Reload the page. If the limit follows the agent, aluvia rotate-ip gets a different exit IP and the count starts again.

What the page says

Any of these is a string the page showed:

429 Too Many Requests
Rate limit exceeded
Slow down
You are being rate limited
Error 1015

Why it happens

Rate limits are usually keyed on the client IP. On a cloud VM that IP is shared with other tenants, so Grok Bot can see 429 Too Many Requests before it has spent a budget of its own.

Backing off helps only if the agent is the one spending the budget. When Rate limit exceeded is the shared range, a residential IP is the retry that sometimes starts a fresh count. It is not a promise the next exit is clean; aluvia rotate-ip gets another one if the first is still limited. A limit tied to the browser's fingerprint will still follow the session.

What those commands do

npx aluvia-cli setup aims the existing Chrome at a local proxy. aluvia proxy-on sends every tab through a residential or mobile IP. Neither command restarts the browser after that first setup.

The rate limit is often counted while the client is the VM's datacenter IP, before origin HTML, which is why these commands exist.

If it is still blocked

One exit IP can be blocked on its own. Get a different one and reload again.

aluvia rotate-ip

When this is the wrong tool

If the quota is on the account, rotating the IP will not reset it. Use this when the limit is on the client address, including a shared cloud range.