update

Production Foundation

Three months of focused work turned WonderTwin into a production platform — Stripe, Slack, GitHub, and the rest of the catalog running locally on your laptop, CI that fails closed on missing entitlements, agents that get real answers via MCP, and the production posture to put it all on the critical path.

Four months ago we had an idea, and a month later we shipped a first version to see if the world cared. It was early, and rough, but the enthusiastic response encouraged us to turn WonderTwin into a product that people, agents, and companies can build on. This release marks a major milestone and the result of three months of focused effort. You can now install a Stripe twin on your laptop and develop against it with no live account, no rate limits, no fixture-resetting between scenarios — backed by a platform that’s now production-grade. Drop a one-line GitHub Action into your CI that fails closed when a teammate’s commit reaches for a twin your org hasn’t paid for. Have an agent reach for any twin via wt mcp and get a structured response — the install if the org permits it, a queue if it needs approval, a trial offer for Day-Zero users, a plan-change URL when an upgrade is required. The agent never has to stop because the request fell into a black box.

Stripe runs locally

The Stripe twin is in the WonderTwin community catalog. Install it, run it, develop against it the same way you’d hit Stripe’s live sandbox — except locally, with no rate limits and no shared state between your test runs.

Install and run:

Terminal window
wt install stripe@latest
wt up

Every request your SDK makes is captured. You can replay it deterministically, inspect the twin’s internal state at any point, and reset it between scenarios without coordinating with anyone else on your team.

The same pattern works for every community twin in the catalog — Slack, GitHub, HubSpot, Twilio, Resend, Linear, PostHog, and the rest. Browse with wt catalog and pick the ones your project actually depends on.

CI as the conversion event

wt verify is the new CI-time entitlement gate. It reads your project’s wondertwin.lock and a single-line .wondertwin/project.json that names the org the project belongs to, then asks the WonderTwin entitlements API whether your org actually has every twin the lock file references.

Add to your CI in one line via the action wrapper:

- uses: wondertwin-ai/verify-action@v1

If a teammate’s commit depends on a twin your org hasn’t paid for, the action fails with exit code 1 and surfaces a setup URL pointing at the right next step — a trial start, a plan upgrade, an admin approval. The friction lands at the right moment: the developer can explore freely on their personal license, and the conversation about adding the twin to the org happens when their work tries to ship.

Local development stays unconstrained on purpose. The gate is CI, not your laptop.

Agents always get a real answer

wt mcp exposes WonderTwin to AI agents through the MCP protocol. This release adds three new tools to the surface — and reshapes one — so the agent’s contract with the platform is consistent across every commercial-twin scenario.

wt_install — the agent calls this when it needs a commercial twin. The platform evaluates the org’s policy and returns one of: installed, queue (human approval needed), setup_required (account not yet ready), upgrade_required (org needs a different plan), trial_started_and_installed, or policy_error. Every outcome carries a client_facing_message the agent surfaces to you verbatim, plus the URLs to act on next.

wt_trial — the agent calls this when the user is brand new. Day-Zero users get a signup URL that activates their one-trial-per-account at signup. Authenticated users get routed to plan management, where the platform decides eligibility server-side.

wt_license_refresh — forces a sync between the agent’s local license file and the platform’s current view. Normally the runtime calls this automatically when it detects a stale license; the explicit tool lets the agent (or you) force the sync when needed.

wt_subscribe reshape (breaking). wt_subscribe used to be the per-twin verb ({twin_name: "stripe"} → subscribe to stripe). It’s now the plan-relationship verb — trial → paid, paid → larger plan. The twin_name parameter is gone. If your agent client was calling wt_subscribe with a twin name, switch to wt_install with the same name.

The shape of every response is structured JSON. The agent doesn’t have to interpret prose, recover from a 500, or guess what to tell you. Stop conditions are explicit.

What we hardened

The headline story for this release isn’t a new feature — it’s the work that makes the rest of the post credible.

  • Backups are verified, not assumed. Litestream replicates the platform’s SQLite to S3 continuously. A restore drill runs against a recent snapshot every day and reports the result.
  • Production images are pinned by digest. No latest-tag drift. The exact image that ran in staging is the exact image that runs in production.
  • Graceful shutdown is real. Background workers — webhook ingest, telemetry emitters, twin admin endpoints — drain through a tracked WaitGroup before the database closes.
  • /health exercises every dependency. Database, blob storage, per-twin reachability. No fail-fast — the response shape tells you which sub-check failed if any did.
  • License lifecycle is testable end-to-end. A standing test scaffold covers TTL caps, expiry boundaries, mid-request expiry, re-issue scheduling, clock skew, and goroutine-leak verification.

What’s not done yet

We’re OSS-honest about what’s deferred. Pre-1.0 means “community-validated”, not “feature-complete” — and the version number is intentionally conservative.

  • Automated billing is a v0.2.2 release. Early customers are bespoke / direct-invoice for now. The end-to-end self-serve checkout lands next.
  • The MCP install endpoint returns setup_required against production today. The platform-side signing key is intentionally unset until the MCP-auth design lands. The protocol contract is live, and you’ll see the bundle flow the moment the key lifts. Community twin install via wt install <twin>@<version> is unaffected.
  • Approval-workflow UI and policy-management UI in the portal are pending. The underlying APIs work today; the admin pages are next.
  • Per-twin release pages and the engineering firehose at /docs/twins/[vendor]/releases are coming in the next platform cycle. Twin releases are tracked in the registry today.

→ Technical changelogs: Platform v0.2.0 · Platform v0.2.1 · wt CLI v0.3.0