What We Learned from Launching Cloud World Model on Product Hunt

We finished #5 Product of the Day. Here's what three days of 60+ comments actually taught us.

We launched Cloud World Model on Product Hunt last week. The pitch: simulate AWS, GCP, Azure, OCI, and DigitalOcean infrastructure without provisioning real resources. You describe an architecture compute, databases, load balancers, serverless functions and the simulator models latency curves, CPU saturation, autoscaling behavior, failure propagation, and cost. No cloud bill.

We expected interest from learners. The comments told a different story.

What actually surprised us

The forgotten resource problem is more universal than we thought.

Mustafa Arian @thenameisarian opened with a direct question and a direct story: "I blew $400 on an RDS instance I spun up for testing and forgot about for 11 days. Nobody warned me." Jimmy Xu @jimmy_benhsu followed: their team's staging AWS bill had hit $400/month because someone left a NAT Gateway running, no error thrown, just wrong behavior discovered later on a bill.

These weren't edge cases. They were the comments with the most upvotes.

The use case pattern that emerged from these threads: simulate before you spin up, not just before you go to production. One user articulated a workflow we hadn't fully named, "simulate again on every architecture change" and described it as something Terraform can't give you: Terraform tells you what's changing, not what it will cost.

Terraform and Pulumi export requests came fast.

Two people asked within the first hour. We hadn't planned for it. The way we'd framed the product: the simulation validates architecture decisions. The agent that drives the simulation knows the customer's actual environment and writes the IaC from what it learns. That's the right division of labor. But the demand for tighter IaC integration is real, and the community articulated why: Ahmad's @blah_mad framing was precise — before deploying an agent-generated IaC change, he wants a "handoff receipt": source sim run, changed resources, blast radius, rollback path. The episode history and final config are stable today. Blast radius as a named field is on the roadmap.

The CI integration pattern came from the community, not from us.

Jimmy Xu @jimmy_benhsu synthesized it: use Cloud World Model for the bulk of integration tests to catch resource saturation and cost surprises, then gate merges with a lightweight real-cloud canary that just checks "does the thing actually boot and serve traffic." The canary handles the "does it work" question. The simulator handles the "will it saturate or surprise you on the bill" question.

We hadn't published this pattern. The engineers talking in the comments arrived at it themselves and it's cleaner than anything we'd written.

RL agent training opened a serious technical thread.

We built a reinforcement learning API into the simulator, agents can run episodes, collect observations, train policies, and iterate. We expected this to be interesting. We didn't expect a 3-day thread involving Valeria @hi_i_am_mimo , Dipankar Sarkar @dipankar_sarkar , and Syed Noor @syed_noor4 that got into reward shaping, unmodeled dimensions, and train/test reward splits at the level of an ML paper review.

The sharpest point came from Dipankar @dipankar_sarkar: unmodeled costs don't stay neutral in a reward function, they become free reward. An agent trained on a simulator that doesn't model egress will drift toward chatty cross-AZ topologies precisely because egress looks free. The policy that emerges looks optimal in the sim and ships expensive in production.

His solution, a separate eval environment with the "free" dimensions switched on, used only for evaluation not training, like a train/test split applied to the reward, is the right approach. We're implementing a per-step warning when a policy wanders into unmodeled territory, plus a soft penalty to keep the agent from exploiting blind spots. The train/test reward split is the proper structural solution and we're working on exposing an eval environment configuration.

The use cases we discovered

The ones we expected: simulation for learners, architecture validation, cost estimation.

The ones the community surfaced:

Architecture reviews before anyone writes an infrastructure ticket. Omri Ben-Shoham @omri_ben_shoham1 : "Being able to say 'here's what we're planning to build' and actually simulate the traffic/cost without provisioning anything is huge." The value here is frontloading the signal, you get behavioral data before the architecture document is even finished.

CI pipelines as a first-class use case. Resource saturation and cost surprises caught before staging. Lambda cold-start cascades. Overprovisioned RDS instances. NAT Gateway billing accidents. These are exactly what the simulator surfaces, and they're exactly the things that don't show up until a bill arrives or a load test reveals them.

Chaos engineering with resilience scoring. Inject a database crash. Get a resilience score back. Know which architectures are brittle before touching real infra. Sanjay Kumar @i_sanjay_gautam called this out specifically, and it's the kind of test that's prohibitively expensive to run on real infrastructure, especially for small teams without a real staging environment.

Migration transition cost, not just steady-state comparison. Kévin Monteiro @keirodev made the point that's hardest to address: egress costs are asymmetric. They punish multi-region and migration paths specifically, which are exactly the architectures someone opens a simulator to stress-test. The moment we can say "this design looks cheaper until you price the cross-AZ chatter, then it isn't", that's the day it tells people something they couldn't already guess. Egress and cross-AZ cost modeling is now moving up the roadmap.

What's next

• x402 protocol. We're implementing native payable API support, so AI agents can use the simulation API without human-in-the-loop billing setup. The agent describes an architecture, pays for the simulation run directly, and gets back a structured result it can act on.

• Chrome extension - Cloud Console Overlay. We're releasing an extension that surfaces simulation context directly inside the AWS, GCP, and Azure consoles. You're looking at your real infrastructure. The overlay shows what the simulator predicted for that architecture, cost, saturation, failure behavior, right next to what you're actually provisioning.

Closing the egress gap. The community was direct about this. Egress is the hidden cost that changes the decision. We're modeling it.

To everyone who commented, asked hard questions, and pushed back on the accuracy methodology, the RL reward function, the IaC integration gap: thank you. The roadmap is sharper because of it.

cloudworldmodel.ai