Phase 0 — Inventory your routing

Search your codebase for the code that currently decides which AI provider and model to use for a given request.

Look for:

• Shared resolver helpers — e.g. getReasoningModelRoute, resolveModel, vertex.ts, ai-router. Grep SDK imports alone often misses routing; trace callers of those helpers.
• Direct provider SDK imports (openai, @anthropic-ai/sdk, @google/generative-ai) — where are they called, and what decides which one to call?
• Environment variables like DEFAULT_MODEL, AI_PROVIDER, OPENAI_API_KEY, ANTHROPIC_API_KEY — who reads them and how do they affect routing?
• Custom router/gateway modules — any file named router, provider, gateway, ai-client, model-selector, or similar.
• Fallback logic — try/catch blocks that retry with a different provider on failure.
• Model selection UI — any dropdown, radio group, or settings page where users pick a model.
• BYOK settings — any UI or API where users paste their own provider API keys.

Multi-entrypoint apps: Include verification, extraction, learning, eval, and batch jobs — not only main chat — so policies stay consistent.

You'll see

A list of files and modules. Organise them into three categories:

How to test

There's nothing to test yet — this is an audit. Confirm you can answer: "If I grep for every place my app decides which AI provider to call, these are the files."

For each item in your inventory, decide its fate:

You'll see

An annotated version of your inventory. For example:

REMOVE  src/lib/server/ai-router.ts        — custom fallback chain, replaced by Restormel routes
REMOVE  src/lib/server/model-allowlist.ts   — hardcoded model list, replaced by Restormel policies
KEEP    src/lib/server/billing/wallet.ts    — billing logic, not routing
WRAP    src/lib/server/ingestion/worker.ts — replace ai-router call with Restormel Resolve
REMOVE  src/components/ModelPicker.svelte  — custom model UI, replaced by Restormel ModelSelector
WRAP    src/components/KeySettings.tsx     — BYOK UI, may replace with Restormel KeyManager or keep as wrapper

How to test

Review your annotations with a second pair of eyes (or a coding agent). Confirm: every "REMOVE" item has a Restormel equivalent identified in the phases ahead. Every "KEEP" item genuinely has no routing responsibility.

Before you change anything, record how your app currently calls AI providers. This becomes your regression baseline.

Write down (or have a coding agent extract):

1. Entry points: Which functions/routes initiate an AI provider call? (e.g. POST /api/chat, ingestion worker, background job)
2. Selection logic: For each entry point, how is provider + model chosen today? (e.g. env var, user preference, hardcoded, fallback chain)
3. Credential source: Where does the API key come from? (e.g. env var, user BYOK from database, config file)
4. Error handling: What happens when a provider call fails? (e.g. retry same provider, fallback to different provider, return error to user)
5. Observability: Are provider calls logged? Do you track which provider/model was used, latency, cost?

You'll see

A short document or code comment block that captures the current state. This is your "before" snapshot.

How to test

Pick one entry point. Trace the request from "user action" to "provider API call" and back. Confirm your documentation matches reality.

Implementors: See “Agent prompts for this phase” below for an audit-only prompt you can paste into a coding agent.

Based on your inventory, plan which walkthrough phases address which items:

How to test

Walk through each row and confirm: "When Phase N is complete, this inventory item will be retired." If any item has no corresponding phase, it either belongs in "KEEP" or you need to identify which phase handles it.

If your app supports feature flags, create one now: USE_RESTORMEL_KEYS (or equivalent). This lets you run old and new routing in parallel during Phases 2–6 and roll back instantly if something breaks.

Larger apps: Gate inside a shared resolver so verify/learn/extract paths use the same branch — avoid sprinkling the flag only on chat.

// src/lib/feature-flags.ts
export const USE_RESTORMEL_KEYS = process.env.USE_RESTORMEL_KEYS === 'true';

Example — branch once in shared routing code:

// src/lib/server/resolve-provider.ts
import { USE_RESTORMEL_KEYS } from '../feature-flags';

export async function resolveProvider(request: AIRequest) {
  if (USE_RESTORMEL_KEYS) {
    return await restormelResolve(request);
  }
  return await legacyRouter.resolve(request);
}

You'll wire restormelResolve in Phase 2. For now, the flag just exists.

You'll see

A feature flag that defaults to false. Your app behaves identically to before.

How to test

# Confirm the flag defaults to off
echo $USE_RESTORMEL_KEYS  # should be empty or unset

# Confirm your app starts normally
pnpm dev  # or your start command

Implementors: See “Agent prompts for this phase” below for a ready-to-run prompt for adding the flag safely.