World Labs Atlas API: Billing, Limits and Safe Retries

World Labs Atlas brings scene reconstruction and world-building tools into developer workflows, but an integration needs more than a successful generation request. The important questions are which project pays, whether a timed-out request started work, and what happens when capacity or spending limits stop the next job.

The Atlas product page describes image-based reconstruction, scene shaping and conversion from splats to meshes. This guide covers the Developer API's documented operating model, not the visual quality of those outputs. I have not run an Atlas generation or tested its billing behavior.

Use an API key, not your browser session

Atlas separates platform sign-in from software authentication. The authentication documentation requires a project-scoped key in the WLT-Api-Key header, not a browser session token or a key in the URL. The project is derived from that key; its assets and operations are not accessible through another project's key.

Scopes matter too. A valid key can still receive 403 if it lacks permission for the requested action. A worker that submits jobs needs tasks.create; reading their progress requires operations.read. That distinction is worth checking before repeatedly replacing a credential that already authenticates correctly.

For a small team, separate development and production projects before distributing keys. Otherwise a prototype and a customer-facing service become difficult to distinguish when an unexpected bill or failure appears.

A credit balance and a spend limit solve different problems

According to the billing guide, Developer API tasks consume account credits at 1,000 credits per US dollar. Task prices can change, so consult the platform's current rate card rather than treating a copied price as permanent.

Account-wide and project-specific monthly spending limits can both apply. When a relevant enabled limit reaches 100%, new API tasks pause, but existing work can finish. Usage reporting can also lag. A spending limit is not a precise real-time maximum charge.

An exhausted balance returns 402 with CREDITS_UNAVAILABLE; a reached limit uses SPEND_LIMIT_EXCEEDED. Check the account and project settings instead of repeatedly resubmitting. Automatic recharge replenishes credits using the configured payment method. It is not a replacement for a spending limit.

For example, a team could give experiments a smaller project allowance while keeping a separate account ceiling. Leave room for already-running jobs when choosing those amounts. This is a budgeting pattern, not a claim about how much any particular Atlas scene costs.

Save the operation before deciding to retry

Atlas tasks return asynchronous operations. The operations guide makes done the completion signal: a terminal result contains either a response or an error. A progress percentage is not proof that an output is ready.

Use a stable Idempotency-Key for one logical submission and preserve the request body. After an uncertain connection failure, retry that same body with the same key. Changing the body under that key returns 409; inventing a new key can create duplicate work.

For long tasks, avoid relying on submission with ?wait=true. Its HTTP connection can hit the load balancer's 60-second ceiling and return 504. Submit asynchronously, retain the operation ID, then wait or poll. Even the bounded wait endpoint can return before completion.

Consider a scene-building button that appears to hang after the user clicks it. Your application should show the existing job's state rather than make every click a new generation. Store the job identity durably enough that a page reload or worker restart does not erase it.

Do not borrow quotas from the older World API

Atlas's rate-limit page explicitly says its numerical quotas are not yet published and warns against using older World API values. Multiple keys do not provide independent capacity. The web app, playground and API share task capacity constraints.

A 429 can indicate request rate, concurrency or temporary task unavailability. Respect Retry-After, back off with jitter and reduce submissions while existing operations finish. A slower job should remain in the polling queue, not trigger a replacement job simply because another request completed sooner.

That leaves an important commercial question unanswered: how much work can your account reliably sustain? Before promising customers a completion time, establish capacity with World Labs and measure your own representative workload. A functioning demo proves that one request can succeed. It does not establish the throughput or spending behavior of a production queue.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn API behavior, product constraints and launch updates into clear stories developers can use.

Book a 30-minute call