Skip to main content
Phaseo est une alternative à OpenRouter compatible avec OpenAI. Si votre application utilise déjà OpenRouter via le SDK OpenAI ou des appels HTTP directs, la migration se limite généralement à la frontière du client, sans réécrire les prompts ni la logique applicative.

Ce qui change

La migration comporte quatre étapes :
  1. Conserver la structure du corps de la requête.
  2. Remplacer l’URL de base et la source de la clé API.
  3. Vérifier les identifiants de modèles et les en-têtes propres à OpenRouter.
  4. 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_KEY disponible 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_KEY dans le code, la CI et les variables d’environnement d’hébergement.
  • Repérez les en-têtes propres à OpenRouter, comme HTTP-Referer et X-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-Referer et X-Title s’ils identifient l’application appelante. Phaseo accepte aussi les équivalents en minuscules http-referer et x-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.
Ne copiez pas les préférences de fournisseurs ni les champs de réponse propres à OpenRouter dans chaque appel. Centralisez ces différences dans un adaptateur pour qu’un retour arrière ne nécessite qu’un changement d’URL et d’identifiants.

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_KEY a été remplacée par PHASEO_API_KEY dans 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/completions ou /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 depuis replay_request lorsque replay_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 :
  1. Recherchez openrouter.ai, OPENROUTER_API_KEY, sk-or-v1, HTTP-Referer et X-Title dans le code et la configuration de déploiement.
  2. Passez à https://api.phaseo.app/v1 et PHASEO_API_KEY sans enregistrer de secret dans le dépôt.
  3. Consultez GET /v1/models et consignez chaque correspondance entre anciens et nouveaux modèles.
  4. Adaptez les options de routage ou champs de réponse propres à OpenRouter dans un seul module de compatibilité.
  5. Effectuez les vérifications de santé, modèles, requêtes sans streaming, streaming et erreurs ci-dessous.
  6. Signalez les fichiers modifiés, changements de noms de secrets, correspondances, preuves de test, écarts de parité et mécanisme de retour arrière.
Pour un flux réutilisable, consultez le guide de migration d’OpenRouter vers Phaseo, qui regroupe l’inventaire, les correspondances, la validation, le rapport et le 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.
  1. Commencez uniquement avec le trafic interne.
  2. Passez à 5–10 % du trafic de production et comparez qualité, latence et coûts.
  3. Passez à 100 % après confirmation de la parité.
  4. Gardez le retour arrière limité à un changement d’URL et de clé jusqu’à stabilisation.

Commandes de validation

Testez le streaming séparément avec le même endpoint :
Vérifiez aussi que l’application gère un modèle invalide sans exposer les identifiants :
Ensuite :
  • 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.

Étapes suivantes

Dernière modification le 2 octobre 2026