Frequently asked questions.

WonderTwins are adaptive software twins of the external services your code and your agents reach for — Stripe, Plaid, Shopify, and more. A twin is a local, stateful, behavioral model of the real service: it runs on your machine and responds the way the service would. The adaptive part — staying aligned as the real service changes — is what the Pro twins do; the open-source twins are fixed snapshots of the service at release.

Whatever shape a service exposes, the twin matches it — the twin API behaves like the real software’s API, we build to the official SDKs where they exist, and we match the published OpenAPI spec. “API,” “SDK,” “OpenAPI spec” are just the shapes a piece of software exposes; a WonderTwin twins the software, so whichever shape you build against, the twin answers with the fidelity of the real thing.

A mock returns a shape — a canned response you wrote, identical every time, with no memory of the calls before it. A WonderTwin runs a model: it holds the service’s state and enforces its rules, so each response is computed from what you’ve actually done, not looked up from a fixture. That’s what makes it stateful (a transfer moves the balance, and the next read reflects it), distribution-faithful (it counts your calls and enforces the real rate limits and latencies), and failure-accurate (it runs the service’s validation, so a bad idempotency key fails the way production would).

So a mock tells you whether the call shape was right; a WonderTwin tells you whether your code actually works when the service behaves like itself — with no mocks to maintain and no vendor sandboxes to stitch together.

The catalog covers 30+ services and is growing, split between an open-source tier and a Pro tier. Open-source twins include the workhorse developer services (Stripe, Twilio, GitHub, Sentry, SendGrid, Mailgun, Resend, PostHog, Supabase, Algolia, Cloudflare, Logo.dev, and more). Pro adds higher-stakes commercial services — Plaid, Shopify, HubSpot, Slack, Linear, Chargebee, Ramp, Rippling, Modern Treasury, NetSuite — plus Pro versions of the open-source twins.

New twins ship regularly. See the full catalog for the current state.

Browse the catalog →

A WonderTwin reproduces the external service’s behavior, not just its API shape. We measure behavior against your actual workflow: how completely the WonderTwin substitutes for the service you’re developing against. Your agent can ask the MCP the same question — does this twin handle what I need? — and get a definitive answer before building against it.

We verify fidelity in four layers: shape (does the response schema match the SDK?), state (do transitions hold across a call sequence?), behavioral (do rate limits, latencies, and error patterns match production?), and coverage (how much of the real service’s surface is handled — reported per service in each twin’s README).

Yes. Your agent talks to the MCP and can discover and call any twin in the catalog as it works — it doesn’t have to be wired up ahead of time.

Open-source twins are free. When your agent calls a Pro twin, that twin is added to your subscription, billed per organization (not per seat). Each Pro twin is its own line — including each version you keep running. If you’re holding a twin on v3.1 after the service has moved to v3.2, that’s two Pro twins. You’re billed for the Pro twins you actually run.

Current pricing →

Build your own. WonderTwin includes a twin-building skill that walks you (or your agent) through modeling a new service against the same fidelity layers our catalog twins are held to. If it’s a service others would use, contribute it back to the registry — community twins are how the catalog grows fastest.

We also partner directly with companies to build twins, whether for external dependencies you rely on or internal systems you want a local model of. Reach out → hello@wondertwin.ai

When your agent describes what it needs to the MCP and an existing twin doesn’t handle it, that gap is captured automatically. We prioritize capability improvements based on real demand from real agents. Once the gap closes, your agent picks up the new behavior through the MCP without any wiring on your end.

Two commands:

$ npx wondertwin init stripe plaid
✓  Stripe twin v3.2 ready on localhost:4111
✓  Plaid twin v2.0 ready on localhost:4112

$ wt status
2 twins running · drift-aligned · 0 errors

That’s it — the twins run locally as one binary. Point your existing SDK at the local port and your calls work, offline and unlimited.

Two ways. Your application code points its existing SDK at the twin’s localhost port — no code changes beyond the base URL. Or your agents talk to the MCP, which exposes the running twins and lets the agent discover, call, and request twins.

Either way, your agent’s full dev loop closes locally against WonderTwins instead of production.

WonderTwin is infrastructure that sits alongside your agent, not inside it. Any agent that can reach an HTTP endpoint or speak MCP can use it — which in practice is every coding agent on the market. The twins expose standard HTTP on a local port, and the MCP server lets agents discover, install, start, and inspect twins programmatically. No framework-specific adapters, no SDK lock-in.

If your agent calls APIs, it can call a WonderTwin. That’s the whole integration story.

The runtime and open-source twins make zero outbound calls during operation — no telemetry, no install pings. They run on your machine and stay there.

The MCP and Pro twins do send telemetry. The MCP carries it because it has to know which twins exist and what’s being requested in order to serve them. Pro twins carry it because adaptive behavior needs operational signal — that’s what keeps them aligned with the real service.

Full privacy policy →

Open source (MIT, free forever): the twin catalog’s open-source tier, the wt CLI, the MCP server, and the local runtime. Open-source twins ship as frozen snapshots — they model the service as of their release.

Pro (paid, per-twin subscription): adaptive twins that stay aligned as the real service changes, version pinning, drift detection, and the Pro-only services in the catalog.

The difference in one line: open-source twins are frozen; Pro twins stay current.

Pro twins are adaptive: they stay aligned with the real service as it changes. The signal comes from three sources — usage patterns across customers running the twin, open-source intelligence (changelogs, SDK releases, public docs), and direct communication from the software companies themselves. When something shifts, we update the twin’s model and push it to running Pro twins via the WonderTwin platform API — no hand-edited fixtures, no waiting for the next release cycle.

Twin versions are pinned, so you control when to adopt new behavior. Drift detection surfaces what’s changed; you decide when to move.

Open-source twins don’t have this. They’re frozen snapshots of the service at the moment the twin was released — accurate at the time, but they can’t adapt. If the real service evolves, the OSS twin doesn’t follow. Adaptivity is what you’re paying for in Pro.

Yes, both — and they’re different things.

Edge cases and failure modes. The runtime ships with chaos testing built in. You can force errors, inject latency, hold a target failure rate, or otherwise put a twin into adverse conditions to test how your code handles them. It’s a runtime capability, available to anyone running WonderTwin — no Pro relationship needed.

Improving the twin itself. Open-source twins live in public repos. If you find a gap or a fidelity issue, open a PR — contributions get reviewed and merged into the catalog so everyone benefits.

Pro twins are a per-twin subscription, billed per organization (not per seat). Open-source twins are free.

Current per-twin pricing →

One local binary with three parts: the Registry (which twins exist, open-source and Pro), the Runtime (composes the twins you pull into one local environment), and the Twins themselves (the behavioral models).

SOC 2 readiness is on the roadmap. If you have a near-term compliance need, reach out — hello@wondertwin.ai