What actually happens when Cloud World Model simulates a cloud decision?

Say you stop a workload. Does the cloud bill stop too?

Compute costs disappear — but load balancers, databases, and networking resources keep charging. You're paying for infrastructure you're no longer using, and it can be hard to know which resources are safe to remove versus which ones still have something depending on them.

Cloud World Model simulates that transition before you touch anything in production. You describe your starting state, apply the action, and see the resulting state — costs, risks, utilization — without making the change to real infrastructure.

Five things happen in every simulation step

Every simulation step follows the same structure, regardless of the scenario:

That five-step loop — state, action, next state, metrics, recommendation — is what every simulation does. The scenario changes. The structure doesn't.

Why simulate instead of just stopping things?

Cloud environments have dependencies that aren't visible in a diagram. Some resources look idle but still have something depending on them. Removing the wrong thing causes an outage that costs more to recover from than the infrastructure was costing to run.

Simulation lets you see the consequence before it's real. If the simulated next state shows an error rate spike, or a cost component that doesn't go away when expected, or a resource that goes critical after you remove something else — you find that out before the change, not after.

Other tools look at what your environment is.
Cloud World Model models what it becomes.

For engineers: what happens inside the step

This section covers the internal mechanics for engineers integrating with the API. Non-technical readers can stop here — the section above covers everything you need to understand what Cloud World Model does and why it matters.

Each tick of the simulation runs through six stages in order:

Traffic & Current State
         ↓
   Rule Engine (step 1)
  computes metrics & resources
         ↓
   ML Model (step 2)
  called with rule step output
         ↓
  Referee / Blend
  → hybridDecision.hybridMetrics
         ↓
  Active Failure Effects
  (mutate metrics post-blend)
         ↓
   Autoscaling
  (post-failure resource list)
         ↓
 Final Metrics
 (costPerHour & cpuUsage
  recalculated from final nodes)

Traffic patterns are evaluated first. Patterns are declarative — a ramp specifies a start and end RPS and the engine interpolates where in that window the simulation currently sits. Multiple patterns compose toward their declared targets, preventing runaway RPS accumulation across long runs.

The core step runs sequentially. First the rule engine runs a complete deterministic step: it computes per-resource CPU from the traffic and capacity, derives latency percentiles from a formula combining base latency, load pressure, and warm-up penalties for recently-added nodes, and sums cost from provider pricing tables. Then the ML model is called with the rule step's output — its updated resource states and computed metrics — and produces its own predictions for those same fields, modelling non-linear degradation patterns and provider-specific behaviour the deterministic formulas can only approximate.

A referee then blends the two outputs. The blended result is saved in hybridDecision.hybridMetrics as a pre-failure snapshot — the pure output of the blend before anything else modifies it.

Active failures are applied after blending. A network latency injection adds a flat millisecond penalty directly to the aggregate latency percentiles (P50 gets the full amount; P95 gets 1.2×; P99 gets 1.5×). An AZ outage marks all resources in the affected zone as critical and degrades the aggregate error rate and latency proportional to the fraction of total resources that were in that zone. These effects land on the top-level response metrics after the blended snapshot is already saved — which is why metrics.latencyP95 and hybridDecision.hybridMetrics.latencyP95 can differ when failures are active.

Autoscaling runs last, on the post-failure resource list. When a compute group's CPU crosses the scale-out threshold, new instances are cloned in and begin absorbing traffic gradually. Scale-in fires symmetrically when load drops and the cooldown window expires. After any scale events, costPerHour and cpuUsage are recalculated from the final node list — so those two fields in the response always reflect the actual post-scale state, not the pre-scale blend. The simulated clock then advances by one tick.

The response contains three objects. metrics is the final observable state after all stages. hybridDecision is the referee's full record: pre-failure blended snapshot, per-field comparisons between rule engine and ML model, and a human-readable explanation of whether blending applied or the model was overridden. hybridResult is the running history — one decision appended per API call regardless of how many sub-steps were batched, with a summary of confidence averages, bottleneck counts, and fallback counts across the full run.

POST /api/simulations/:id/step-hybrid

{
  "steps": 1,
  "config": {
    "blendingWeights": { "rules": 0.5, "ml": 0.5 },
    "confidenceThreshold": 0.7,
    "safetyBounds": {
      "maxLatencyDeviation": 50,
      "maxCostDeviation": 0.2,
      "maxErrorRateDeviation": 5
    },
    "fallbackToRules": true
  }
}

Don't just inspect a cloud architecture. Change it.

Cloud World Model includes 16 pre-built scenarios you can step through without provisioning any infrastructure. Introduce a failure, change traffic, trigger scaling, or stop a workload — and watch the simulated environment respond tick by tick. API key access and x402 micropayment access both work.

API docs and endpoint reference →Getting started guide →Full API reference for LLM context →