Molar Clones
Molar Clones are stateful, local stand-ins for third-party vendors. Instead of hitting Stripe, Twilio, your email provider, Clerk, or S3 in a test — which is slow, flaky, and can cause real charges, sends, or data loss — Molar runs a vendor-faithful digital twin that behaves like the real API but is fully hermetic, resettable, and controllable.
| Surface | URL |
|---|---|
| Product landing | clones.molar.it |
| Operator dashboard | app.molar.it/dashboard/clones |
Why Clones exist
Vendor sandboxes break serious CI and agent-driven testing:
| Vendor | Sandbox limitation |
|---|---|
| Stripe | Lower rate limits than live; test clocks rate-limit under load; stripe-mock is stateless |
| Twilio | Test credentials do not fire status callbacks |
| Resend has no sandbox; SendGrid sandbox drops delivery | |
| Auth (Clerk) | Dev instances cap SMS (20/mo) and email (100/mo) |
| S3 | No AWS test mode; misconfigured deletes are irreversible |
Clones add cross-service world snapshots, a virtual clock, deterministic IDs, and destructive-call refusal when your app still points at a live vendor URL.
Two clone tiers
Deep clones (tier 1)
Stateful simulations with virtual clock, snapshot/restore, and chaos injection: stripe, twilio, email, auth, s3.
Fixture clones (tier 2)
Request/response fixtures for 23 vendors — GitHub, Slack, Linear, Jira, HubSpot, and more. See Supported vendors.
Deployment modes
| Mode | Best for |
|---|---|
| Library | Local dev — SDK spawns Go binary |
| Service / BYOC | Shared fleet via MOLAR_CLONE_*_URL |
| Hosted cloud | app.molar.it/dashboard/clones |
| On-prem Helm | Air-gapped enterprise |
How Clones fit in Molar
- Guard spawns fresh clones per PR and links failures to the Clones session workspace.
- Trace captures clone state per step for deterministic replay.
- Scenarios declare clone kinds in
.molar.md; the Molar runtime callsmolar.clones.start([...]).
Agents use MCP tools (molar_clone_spawn, molar_clone_world, …). See the capability manifest.