Cloud World Model
Pre-provision multi-cloud cost and latency simulation
Compare greenfield designs before launch or before changing existing infrastructure; check cost, latency evidence, and a valid CWM simulation API example.
Definition: evaluate before deploying
Pre-provision simulation is the greenfield case of evaluating infrastructure before deploying or changing it: define resources and traffic, advance the system model, then inspect estimated cost and performance before creating live infrastructure. The same workflow applies to proposed changes to existing systems, such as a scaling change or a pull request. “Multi-cloud” means considering deployment options across providers, not assuming that an instance on one cloud has an identical price or latency on another. Model output answers a planning question, not what your future invoice or p95 will definitely be.
How this differs from chaos tools, FinOps calculators, and monitoring
Chaos and fault-injection tools affect real systems; CWM uses simulated chaos and recommends later production-capable validation such as AWS FIS or Gremlin. FinOps calculators estimate prices from SKUs or IaC diffs; CWM also models latency, errors, and resilience under traffic and failure, but its outputs are estimates, not invoices. Monitoring observes live telemetry after deployment; CWM is a pre-deployment and pre-change world model, not an observability or operations console.
Start from evidence, not a universal accuracy score
For an example of what CWM has actually validated, the owned AWS benchmark documents its three-tier reference workload (load balancer, application servers and database), comparison method and metric-specific limitations. It is an AWS reference, not proof of equivalent accuracy for every provider or traffic shape. The accuracy page gives the currently published results and methodology; use your own provider invoice and telemetry to check a prospective migration.
The fidelity page identifies where behavior comes from assumptions rather than a measured workload. Before ranking providers, fix the region, traffic profile, required services, pricing assumptions and latency objective; document any unmapped services.
Worked API example: create a virtual baseline
This request defines one fixed virtual AWS VM: location.regionKey selects the region, characteristics.size selects the catalogued t3.large SKU, and characteristics.instanceCount explicitly requests one instance. No additional fleet capacity or redundancy is implied. Replace CWM_API_KEY with an authorized key, run the create request, then set SIM_ID to the returned id before stepping. Compare different clouds using their own supported SKU labels rather than carrying an AWS instance type across providers. Creation and simulation are virtual: no EC2 instance is provisioned.
curl -sS -X POST https://www.cloudworldmodel.ai/api/simulations \-H "Authorization: Bearer $CWM_API_KEY" \-H "Content-Type: application/json" \-d '{"name": "Pre-provision single-VM baseline","traffic": 5000,"resources": [{"id": "web-1","name": "Web Server","type": "compute","provider": "aws","location": {"regionKey": "us-east-1"},"characteristics": {"size": "t3.large", "instanceCount": 1, "autoscaling": false}}]}'# Save the returned id as SIM_ID. This creates a virtual simulation, not an EC2 instance.curl -sS -X POST "https://www.cloudworldmodel.ai/api/simulations/$SIM_ID/step" \-H "Authorization: Bearer $CWM_API_KEY"
Compare strategies and check the result
For multi-cloud exploration, the API provides POST /api/multi-cloud/explore and asynchronous job results. Define a workload profile and optimization weights, then inspect the returned ranked strategies rather than assuming one architecture transfers unchanged to another provider. Reconcile costs against provider price lists and your bill, and verify latency with realistic regional tests.