Phase 6 — Go live

Before enabling the feature flag in production, verify everything works in a staging or preview environment.

If your app supports percentage-based rollout (e.g. via LaunchDarkly, Vercel Edge Config, Cloudflare Workers, or a simple random check), start with a small percentage of traffic using Restormel.

const RESTORMEL_ROLLOUT_PERCENT = parseInt(
  process.env.RESTORMEL_ROLLOUT_PERCENT ?? '0',
  10
);

export const USE_RESTORMEL_KEYS =
  process.env.USE_RESTORMEL_KEYS === 'true' ||
  (RESTORMEL_ROLLOUT_PERCENT > 0 && Math.random() * 100 < RESTORMEL_ROLLOUT_PERCENT);

Rollout sequence:

If you don't have percentage-based rollout, use the boolean flag: USE_RESTORMEL_KEYS=true for the full cutover (Step 6.3).

You'll see

A mix of requests going through Restormel (your app logs include providerType / modelId from resolve) and legacy. The ratio roughly matches your rollout percentage.

How to test

Check your application logs. Requests that went through Restormel log the resolved provider and source. Requests that went through legacy log the legacy provider. Both succeed without user-facing errors.

When you're confident from the parallel run, enable Restormel for all traffic:

# In your production environment variables
USE_RESTORMEL_KEYS=true
RESTORMEL_ROLLOUT_PERCENT=100  # if using percentage-based rollout

Deploy the env change. Monitor for 15–30 minutes.

You'll see

All AI requests resolve through Restormel. Your logs show the resolved providerType / modelId for every request. The dashboard shows request volume in the project's usage section.

How to test

Verify no requests are going through legacy (e.g. grep -c '"source":"legacy"' /path/to/your/app.log — expected 0). Check the dashboard: Projects → your project → Usage. Request counts match your expected traffic.

Run a comprehensive check within the first hour after cutover.

CLI checks:

npx @restormel/doctor
npx @restormel/validate

Dashboard checks: Usage (request count non-zero and growing, no error spikes); Routes (traffic against configured routes); Policies (no unexpected violations); Provider credentials (all show "valid").

Application checks: Make a request through each major code path; confirm correct provider and model. Test fallback (temporarily remove a provider credential, confirm next step is used, restore). Test a policy block (request a model not on the allowlist). Check latency; resolve adds a network round-trip (typically <100ms).

Smoke test script: Create a script that (1) calls the resolve endpoint and prints provider, model, explanation; (2) calls the policy evaluate endpoint for an allowed model; (3) runs keys doctor. Use RESTORMEL_GATEWAY_KEY from the environment; never hardcode secrets.

Implementors: See “Agent prompts for this phase” below for a ready-to-run smoke-test prompt.

Once you're confident Restormel is handling all traffic correctly (at least one full release cycle with the flag at 100%), clean up:

1. Remove the feature flag. The Restormel path is now the only path.
2. Remove the legacy resolve function. The legacy fallback in your resolve module is no longer needed.
3. Remove the inventory items marked "REMOVE" in Phase 0. Custom router, hardcoded model lists, custom fallback chains, custom model picker UI.
4. Remove unused env vars. Any DEFAULT_MODEL, AI_PROVIDER, or provider-specific routing env vars that Restormel replaces.
5. Keep the error fallback to a sensible default. Your resolve wrapper should still handle Restormel errors gracefully (e.g. return a hardcoded default or a user-facing error).

Implementors: See “Agent prompts for this phase” below for a post-burn-in cleanup prompt.