Using Restormel with OpenRouter

If you already use OpenRouter, you don’t need to replace it. Treat OpenRouter as your provider access layer, and use Restormel Keys as the control layer for routing, policies, health checks, analytics, and progressive rollout.

What stays where

• OpenRouter owns: OpenRouter API key(s), provider selection behavior inside OpenRouter, OpenRouter-side analytics
• You own: Where the OpenRouter key lives (env/secrets manager), which endpoints your app calls
• Restormel owns: Routes/policies/health configuration, control-plane API keys, dashboard governance UX

Adoption path (low migration)

1. Keep your existing OpenRouter calls. Don’t touch credentials or request format yet.
2. Add Restormel control plane. Create a project, routes, and policies that describe the behavior you want.
3. Use Restormel Resolve for decisions. For a given request, ask Restormel which route/provider/model should apply, then execute via OpenRouter.
4. Progressively cut over. Start with a small traffic slice, verify logs/health, then expand.

When to keep OpenRouter vs go direct

If you rely on OpenRouter-specific models or routing features, keep OpenRouter as the execution layer. If you want direct provider relationships (OpenAI/Anthropic accounts, direct rate limits), you can migrate execution later while keeping the same Restormel routes/policies.