Rate limits

Marble 2 beta rate limits protect shared model capacity. This page is the placeholder rate card for the beta; final per-task quotas and commercial throughput tiers have not been published yet.

Do not use the provisional values from Marble 4 or older World API docs for a Marble 2 capacity plan.

Beta rate card

Limits apply to the project or account associated with the API key, depending on the enforcing tier. Multiple keys do not create independent capacity pools. Available throughput can also vary with model capacity and request complexity.

Task submission rates and concurrency limits are shared between the web app, Developer API, and API playground. Submitting through another surface does not create a separate budget: each task type uses the same per-account limits and service-wide capacity across all three.

Design for limits now

Even before final numbers are published:

• queue task submissions instead of starting unbounded parallel requests;
• cap concurrency per project;
• persist accepted operation IDs;
• poll existing operations instead of resubmitting work;
• add jitter to every retry schedule;
• make throughput and backoff settings configurable.

Task completion time is not a request-rate limit. A long operation should stay in your polling queue; do not replace it because another task completed sooner.

Concurrency limits

Each task type also caps how many of its tasks may be open at once, counted both per account and across the whole service. A task is open from the moment it is accepted until its operation reaches a terminal state or passes its deadline. A submission past the cap is refused rather than queued.

The caps are not published. They move with available model capacity, so a number printed here would be wrong within a release. Treat the refusal as the signal instead: hold new submissions for that task type until an operation you already hold finishes.

Handle 429 responses

429 Too Many Requests means the request was not accepted under the current limit. The code field in the response body says which limit refused it.

1. Honor Retry-After when the response provides it.
2. Pause new submissions for that project.
3. Retry with capped exponential backoff and jitter.
4. Resume gradually instead of releasing the entire queue at once.
5. Reduce concurrency if 429s continue.

Reuse the same Idempotency-Key when retrying an uncertain task submission. For a definite 429, the task was not accepted, but keeping the key stable still makes the retry safe.

Request higher throughput

Enterprise customers can contact their World Labs account representative with the task methods, expected requests per minute and hour, peak concurrency, input sizes, regions, and whether traffic is bursty or sustained. Agreed limits should be load-tested with a representative workload before launch.