Skip to main content
A World starts one Simulation for each Simulator ID you give it and starts, stops, and deletes those Simulations together. Use a World when an agent needs several systems, such as billing and support, in one scenario. Use a single Simulation when one system is enough.

​
Lifecycle

A World starts in pending, becomes building when a slot is free, and then becomes ready. Start moves it to running. Stop moves it to stopped. A build that cannot create or verify starting data ends in failed with a safe reason. A canceled build ends in canceled with error code world_build_canceled. A first start that cannot create or start its Simulations ends in failed with error code world_create_failed or world_start_failed. A later start from stopped that cannot restart every member stops the members that did start, returns an error, and leaves the World stopped. The build creates no Simulations. The first start creates one Simulation per Simulator. Stop saves each member’s state. Later starts restore the members from saved state. Each idle member of a running World pauses on its own, like any Simulation. Inactivity never stops the World or its members.

​
Build a World

Provide one or more ready Simulator IDs. Add instructions to describe the starting records, relationships, dates, and situations that your agent needs. Continuous generates synthetic data across the selected Simulators and checks that the data can be read through their APIs. The selected model builds and reviews the data, and can test and repair its plan before submission. The generated build endpoint lists model choices. See Quotas and limits for the shared build budget and queue policy. The generated build endpoint owns request options and defaults. Use curl 7.82 or later with CONTINUOUS_API_KEY set, or run continuous auth login for the CLI. Replace the example IDs with your ready Simulator IDs.
The World becomes Ready after the build completes. Open its detail page to review starting record counts, checked relationships, and assumptions. During the build, the page shows the selected model, tool calls, and plan submissions. Start is a separate action; the build creates no user Simulations. The build checks each requested condition across every generated record of its type through API reads, including records that do not match. A description or an unrelated identifier is not evidence for a requested condition. Without instructions, the World uses each Simulator’s default starting data. With instructions, generated record types replace the corresponding default records. Other record types keep their defaults. All retained references must still be valid. A populated World supports up to eight selected Simulators and 1,000 total starting records. The data plan is limited to 1 MiB. Relative dates use the Simulator’s fixed reference time, January 1, 2024, at 00:00 UTC. Explicit dates do not change Simulator time. The summary records inferred choices. Cancellation stops the active agent and releases temporary resources. Retries use the shared build budget. REST and SOAP Simulators can participate when their declared schemas and read operations support the requested records. A build fails with a safe reason when it cannot create or verify the requested data. History records, ambiguous references, or missing population schemas can prevent a build. A failed or canceled build cannot be started. Condition checks support exact scalar equality and counts. The read API must expose the declared record key and condition fields under matching field names. Hidden keys, field aliases, null values, range predicates, and ambiguous repeated SOAP elements have unsupported proof shapes. The full record census must fit the 64-read limit; one list read can check several records. The response is 202 with status pending. An unknown Simulator ID answers 400 simulator_unknown; a Simulator that is not ready answers 409 simulator_not_ready. Start a Ready World to create its Simulations from the saved starting states. This does not generate data again. Each member starts with an empty request history. Stop saves the current data; a later Start restores it, including changes your agent made. The saved World data does not change the original Simulators.

​
Advance time together

The first Start accepts optional start_time. Every member uses that runtime clock; omission keeps January 1, 2024, at 00:00 UTC. This choice does not change the concrete business dates saved during Build. Later starts preserve the clock and pending events from runtime state. Send POST /v1/worlds/{id}/advance-time with an absolute to timestamp and an Idempotency-Key header. The response identifies a durable operation with member progress. Poll GET /v1/worlds/{id}/advances/{advance_id} to follow it. Repeating the same key and target returns the same operation. Advance a member through its World; direct member advancement returns 409 simulation_world_owned. The World tries each running member independently and skips paused or stopped members without waking them. Each member commits its own events as one local step. Successful advances remain committed even if another member fails. Events do not cross member boundaries. The operation reports completed, failed, or skipped members. A failed or unconfirmed member does not prevent attempts on later members. The World clock records the last settled request target; individual member clocks can differ. Repeating the same key returns the same result; use a new key to retry failed members. Start and stop return a conflict while the advance is active. Deletion drains the advance before member cleanup.

​
Control a World

  • POST /v1/worlds/{id}/start starts a ready or stopped World. Every member needs a free Simulation slot at once; otherwise the call answers 429 simulation_quota_exceeded and starts nothing.
  • POST /v1/worlds/{id}/stop stops a running World and saves each member’s state.
  • POST /v1/worlds/{id}/cancel cancels an active build. If the build has already finished, the call returns the current World.
  • DELETE /v1/worlds/{id} deletes the World, its Simulations, and their saved states.
Start, stop, or a membership change in any other state answers 409 world_conflict. Starting a running World or stopping a stopped one returns the World unchanged.

​
Change members

A ready, running, or stopped World can gain or lose members without a rebuild. Each change is a durable operation: the call returns 202 with the change, and GET /v1/worlds/{id}/changes/{change_id} reports its status until it is completed or failed. Both calls need an Idempotency-Key header; repeating the same key and body returns the same change. A World runs one change at a time; another change answers 409 world_change_active, and a clock advance answers 409 clock_conflict while a change runs. active_change_id on the World names the change in flight.
  • POST /v1/worlds/{id}/simulations adds a ready Simulator as a new member, last in member order. A running World starts the member at the World’s current time; a stopped World creates it at its next start; a ready World creates it at its first start. Adding to a running World needs one free Simulation slot, otherwise the call answers 429 simulation_quota_exceeded. The new member starts from its Simulator’s default data.
  • POST /v1/worlds/{id}/simulations/{simulation_id}/remove removes a member of a running or stopped World. By default the member is detached: it leaves the World and becomes a standalone Simulation that keeps its ID, endpoint, token, clock, and data, and you then start, stop, advance, and delete it directly. A detached member of a stopped World stays stopped. Send "delete": true to delete the member and its saved state instead. A World keeps at least one member; removing the last one answers 409 world_conflict, so delete the World instead.
Other members keep their data, clocks, tokens, and endpoints through every change.

​
Work with member Simulations

GET /v1/worlds/{id} returns the World. While it is running or stopped, simulations lists each member’s id and simulator_id in simulators order. A member is a normal Simulation for reads and requests. Call GET /v1/simulations/{id} for its endpoint. Each member has its own token. Retrieve it with GET /v1/simulations/{id}/token and send it in X-Continuous-Simulation-Token. It does not expire, and World stop and start keep it. Regenerate it with POST /v1/simulations/{id}/token/regenerate. You can also fork a member. An idle member pauses like any Simulation, as described in Lifecycle. Stop, start, and delete members through the World. Those calls on a member directly answer 409 simulation_world_owned. To manage a member on its own, detach it. Use the API reference for exact World routes and schemas.

Understand Simulators

Each World member runs one ready Simulator.

Understand Simulations

Stop, start, and fork a single Simulation.