Ce qui change
La migration comporte quatre étapes :
- Conserver la structure du corps de la requête.
- Remplacer l’URL de base et la source de la clé API.
- Vérifier les identifiants de modèles et les en-têtes propres à OpenRouter.
- Augmenter le trafic progressivement en comparant latence, sorties et coûts.
Avant de commencer
- Accès au code d’intégration OpenRouter actuel et à la configuration de déploiement.
PHASEO_API_KEYdisponible en développement, en test et en production.- Une courte liste d’identifiants de modèles de production et de prompts représentatifs.
1) Inventoriez l’utilisation actuelle d’OpenRouter
Repérez toutes les références à OpenRouter : URL, clés, identifiants de modèles et en-têtes propres au fournisseur.- Recherchez les endpoints
openrouter.ai. - Recherchez
OPENROUTER_API_KEYdans le code, la CI et les variables d’environnement d’hébergement. - Repérez les en-têtes propres à OpenRouter, comme
HTTP-RefereretX-Title. - Documentez les identifiants de modèles actifs et la logique de repli.
- Identifiez les valeurs réutilisables de prompts, fournisseurs ou paramètres à déplacer vers des préréglages Gateway au lieu de les dupliquer dans le code.
2) Remplacez l’URL de base et les identifiants
Conservez d’abord la structure de la requête, puis vérifiez la parité avant toute optimisation.3) Validez les identifiants de modèles et adaptez les fonctions propres à OpenRouter
Ne partez pas du principe que tous les anciens alias sont valides. Consultez/v1/models et vérifiez chaque modèle de production. Par défaut, la réponse ne contient que les modèles actuellement accessibles au routage public ; utilisez availability=all uniquement pour examiner les modèles inactifs ou à venir.
- Conservez le format
Authorization: Bearer. - Gardez
HTTP-RefereretX-Titles’ils identifient l’application appelante. Phaseo accepte aussi les équivalents en minusculeshttp-refereretx-title. - Si des appelants dépendent de champs de réponse propres à OpenRouter, adaptez-les dans une seule couche de compatibilité.
- Si votre configuration utilise des listes de fournisseurs autorisés ou interdits et des règles de routage, déplacez-les vers Préréglages et Routage et solutions de repli.
Faites correspondre les contrôles de fournisseurs
Phaseo prend aussi en charge
provider.required_execution_region et provider.required_data_region si une charge de travail exige des contraintes régionales. Consultez Épingler ou exclure des fournisseurs et Routage vers l’UE ou des fournisseurs compatibles ZDR uniquement pour voir des requêtes complètes.
4) Liste de contrôle de parité avec OpenRouter
Avant de déplacer une part importante du trafic, vérifiez que :- L’URL de base est
https://api.phaseo.app/v1. OPENROUTER_API_KEYa été remplacée parPHASEO_API_KEYdans tous les environnements.- Tous les identifiants de modèles de production ont été vérifiés avec
/v1/models. - Une requête sans streaming fonctionne via
/v1/chat/completionsou/v1/responses. - Une requête avec streaming fonctionne via le même parcours d’intégration applicatif qu’en production.
- Les recherches
GET /v1/generations?id=<request_id>ont été revérifiées pour rejouer les échecs depuisreplay_requestlorsquereplay_supported=true. - Les appels d’outils et les sorties structurées ont été revérifiés avec de vrais prompts.
- Les erreurs de clé et de modèle invalides ont été vérifiées en environnement de test.
- Les en-têtes et champs de réponse propres à OpenRouter ont été supprimés ou explicitement normalisés.
- Les valeurs partagées de prompts et de routage ont été déplacées vers des préréglages si nécessaire.
Liste de migration pour un agent
Confiez à l’agent cette séquence précise :- Recherchez
openrouter.ai,OPENROUTER_API_KEY,sk-or-v1,HTTP-RefereretX-Titledans le code et la configuration de déploiement. - Passez à
https://api.phaseo.app/v1etPHASEO_API_KEYsans enregistrer de secret dans le dépôt. - Consultez
GET /v1/modelset consignez chaque correspondance entre anciens et nouveaux modèles. - Adaptez les options de routage ou champs de réponse propres à OpenRouter dans un seul module de compatibilité.
- Effectuez les vérifications de santé, modèles, requêtes sans streaming, streaming et erreurs ci-dessous.
- Signalez les fichiers modifiés, changements de noms de secrets, correspondances, preuves de test, écarts de parité et mécanisme de retour arrière.
5) Déployez sans risque
Procédez par étapes : développement, petite part de la production, puis tout le trafic une fois les métriques stables.- Commencez uniquement avec le trafic interne.
- Passez à 5–10 % du trafic de production et comparez qualité, latence et coûts.
- Passez à 100 % après confirmation de la parité.
- Gardez le retour arrière limité à un changement d’URL et de clé jusqu’à stabilisation.
Commandes de validation
- Exécutez une requête avec streaming via le test d’intégration applicatif.
- Effectuez un test négatif avec une clé ou un modèle invalide.
- Rejouez un petit jeu de prompts de référence et comparez les sorties.