# Request budget How the browser tools stay within Hyperliquid's rate limits, using half of your IP's allowance. :::note[Planned] Defined in `web/live/src/budget.ts`, part of the live data module that is being built. ::: The browser tools call Hyperliquid from **your** browser, so they spend **your** IP's allowance. They are built to leave most of it to your own tools. ## Hyperliquid's limit 1,200 request weight per minute per IP for REST ([Hyperliquid docs, "Rate limits and user limits"](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/rate-limits-and-user-limits), checked 6 Oct 2026). The weights the tools use: | Request | Weight | |---|---| | `clearinghouseState` | 2 | | `frontendOpenOrders`, `portfolio`, `meta` | 20 | | `userFillsByTime`, `userFunding`, `historicalOrders` | 20, plus 1 per 20 items returned | ## The page's share: 600 a minute A token bucket: up to 120 can be spent at once, and it refills at 480 a minute. In any 60 seconds the page spends at most 120 + 480 = 600, half the limit. - A request whose weight depends on the answer reserves its worst case first and is refunded the difference. - After a `429` (too many requests), the page spends nothing until the bucket has refilled from zero, and retries with exponential backoff and jitter (at least a quarter of the current ceiling, so retries never stampede). **Example.** A Backtest of an address with 6,000 fills needs three pages of fills. Each costs 20 + 2,000 / 20 = 120. Three pages are 360, which the bucket spreads over about 30 seconds after the first burst. ## WebSocket Watch and the live market subscribe over Hyperliquid's WebSocket, which has its own limits. A user-data subscription counts as one of the **10 unique users** an IP may subscribe to. Watch uses one. ## If you run your own tools too If your bot polls Hyperliquid from the same IP, the page and the bot share the 1,200. The page keeps to 600; keep your bot under the other 600, or close the tab while it runs.