> ## Documentation Index > Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt > Use this file to discover all available pages before exploring further. # Rate limiting > How Metabind protects projects from runaway calls and how to plan for high-traffic deployments Rate limiting protects your project (and the platform) from runaway tool-call traffic — accidental or otherwise. Two layers apply today: a per-project ceiling on Data Tool execution, and a per-IP ceiling on anonymous traffic to public MCP projects. ## Default limits | Scope | Limit | Where it applies | | --------------------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Data Tool execution per project, per minute** | 60 calls | Every Data Tool handler invocation across both production and draft endpoints, regardless of caller identity. Sum across all callers on the project. | | **Public anonymous MCP traffic per IP, per hour** | 60 calls (default), burst 10 | Public-visibility MCP projects only. Authenticated requests (API key or JWT) are not subject to this limit. | | **Public anonymous MCP traffic — configurable max** | up to 600 / hour, burst 60 | Per-project override. Set `settings.mcp.publicRateLimit.requestsPerHour` and `.burst`. The platform refuses values higher than the published max to keep "public" from meaning "uncapped." | Limits apply at the host edge. Once you're rate-limited, additional calls return `429 Too Many Requests` until the window rolls over. The audit log captures rejections for diagnosis. ## What gets rate-limited The per-project Data Tool minute cap counts every Data Tool execution, regardless of where it came from: * AI-initiated calls from MCP hosts (Claude Desktop, ChatGPT, and any custom host). * Calls from the Assistant SDK in your iOS, Android, or React app. * Test-panel runs in MCP App Studio (yes, even your own testing). * Programmatic calls via the REST API. What doesn't count toward the Data Tool minute cap: * `tools/list` calls — host capability discovery is uncapped under normal usage. * Interactive Tool renders — the tool-execution rate limiter is scoped to the Data Tool sandbox. * MCP App Studio editor operations. * Audit log queries. The per-IP public limit applies only to anonymous traffic against public-visibility MCP projects. As soon as a request authenticates with an API key or JWT, the per-IP limit is not consulted. ## Per-project public rate-limit configuration For a public-visibility project, override the default in **Settings → MCP → Public rate limit** or via the API: ```json theme={null} { "settings": { "mcp": { "visibility": "public", "publicRateLimit": { "requestsPerHour": 300, "burst": 30 } } } } ``` The platform clamps `requestsPerHour` to `[1, 600]` and `burst` to `[1, 60]`. Higher values require a support conversation — the published max is enforced in code, not policy. For private projects, the per-IP public limit is irrelevant — every request is authenticated. ## Authenticated traffic There is no documented per-token or per-user rate limit on authenticated calls today. Authenticated traffic is bounded only by: * The per-project Data Tool minute cap (60/min) when a tool execution is involved. * Underlying infrastructure protections (timeouts, sandbox concurrency, AWS-side throttling). If you're planning a high-throughput deployment that you expect to exceed the per-project minute cap, contact support early — capacity-planning conversations with concrete QPS numbers move faster than runtime escalations. ## Rate-limit responses When a call is rejected, the response is HTTP `429` with a structured body: ```json theme={null} { "error": { "code": "rate_limit_exceeded", "message": "Rate limit exceeded", "retry_after_seconds": 12 } } ``` `retry_after_seconds` is the wait time until the bucket has capacity again. Hosts and clients should respect it — retrying immediately just spins on the rejection. ## What the AI does on rate limit Most AIs handle `429` responses gracefully: * Anthropic's Claude pauses and retries after the indicated delay. * OpenAI's GPT models log the error and may surface it to the user if retries fail. * Custom hosts: implement retry-with-backoff yourself. The AI sees a structured error, so it can also explain the situation to the user: "I'm being rate-limited; let me wait a moment and try again." Whether the user sees this depends on the host's UX. ## Long-running operations A Data Tool that runs near the 60-second sandbox limit consumes one call's budget while running. It does not keep counting against the minute cap second by second — but it does take an execution slot until it returns. For long-running flows, design with task support so the client polls without burning the rate budget on retries. See [Sandboxed execution: task support](/guides/building/sandboxed-execution#task-support-long-running-operations). ## Client-side throttling Even with server-side limits, throttle on the client for hosts you control: * **Assistant SDK.** Already queues over-limit calls rather than failing. * **Custom MCP clients.** Implement a token bucket sized to match the server limit — for the Data Tool cap, that's 60/minute project-wide. * **Batch when possible.** A Data Tool that takes a list of IDs costs one call; one call per ID costs N. ## Monitoring The audit log captures every `429`. Key signals: * **A spike of `429`s against one project.** Either traffic outgrew the per-project cap, or a misbehaving caller is hammering one tool. * **Public-anonymous `429`s.** A public project is hot; either the default is too tight for the use case, or someone's running a script. Inspect the IP distribution in the audit log before raising. * **Sustained `429`s.** Plan capacity with support; the per-project Data Tool cap is the limit you'll need to discuss raising. ## Related Where rate-limit rejections are recorded. Public projects, the kill-switch, and the per-IP limit. Concurrency and time limits inside the sandbox. Server-side gates on tool calls.