Depuis Portkey
BYOK + smart routing, sans les guardrails ni la prompt library de Portkey.
Ce guide couvre la migration d'un déploiement Portkey vers HiWay2LLM. Les deux sont des couches de routage OpenAI-compatible, donc le diff de code est minimal. Les vraies décisions sont autour des concepts Portkey-specific (virtual keys, guardrails, prompt library) — certains mappent 1-to-1, d'autres n'existent pas sur HiWay. Lis la section gotchas avant de flipper le switch. De bout en bout : 10-15 minutes en comptant la re-saisie des clés provider.
Prérequis
Un compte HiWay et au moins une clé provider configurée dans Tableau de bord → Paramètres → Fournisseurs. Contrairement aux virtual keys Portkey, tu entres la clé provider brute directement — HiWay la chiffre en AES-256-GCM et appelle l'upstream en ton nom.
Étape 1 : récupère ta clé API HiWay
Ouvre Tableau de bord → Clés et clique sur Nouvelle clé. Ta clé hw_live_ remplace le x-portkey-api-key de Portkey.
Étape 2 : change ta config
Sur Portkey tu utilisais la base URL https://api.portkey.ai/v1 avec un header x-portkey-api-key et généralement un header x-portkey-virtual-key pointant vers un credential provider stocké. Sur HiWay tu utilises https://app.hiway2llm.com/v1 avec un header standard Authorization: Bearer hw_live_... — le provider upstream est résolu depuis ta liste de providers activés dans le dashboard, pas de headers supplémentaires.
from openai import OpenAI
client = OpenAI(
base_url="https://app.hiway2llm.com/v1",
api_key="hw_live_VOTRE_CLE",
)
response = client.chat.completions.create(
model="auto", # ou "openai/gpt-4o", "anthropic/claude-sonnet-4-5", ...
messages=[{"role": "user", "content": "Rédige un email de relance"}],
)
print(response.choices[0].message.content)Étape 3 : vérifie
Envoie une requête, confirme X-HiWay-Routed-Model sur la réponse, et va voir la timeline dans Tableau de bord → Usage. Si tu dépendais de la vue traces de Portkey, l'équivalent HiWay est Tableau de bord → Analytics plus l'objet métadonnées _hiway sur chaque réponse.
Gotchas spécifiques à Portkey
- Virtual keys → clés provider HiWay : l'abstraction virtual key de Portkey devient tes entrées dans Paramètres → Fournisseurs. Même posture de chiffrement au repos, modèle mental plus simple — pas de header séparé à envoyer sur chaque requête.
- Les guardrails sont hors scope : Portkey embarque une couche modération / content-filter inline. HiWay n'en a pas — utilise l'API Moderation d'OpenAI, les features de sécurité prompt-level d'Anthropic, ou un service dédié comme Lakera. Apporte ta propre modération si c'était load-bearing.
- La prompt library n'existe pas sur HiWay : Portkey permet de versionner les prompts côté serveur et de les référencer par id. HiWay n'a pas d'équivalent — gère les prompts dans ton propre code, ou utilise une lib comme LangChain / le templating prompt de Vercel AI SDK.
- Config fallback → fallback same-tier automatique : le bloc
fallbackde Portkey est remplacé par le comportement par défaut HiWay (retry sur le modèle le moins cher du même tier sur erreurs upstream, max 2 retries). Si tu avais des chaînes de fallback ordonnées sur des modèles spécifiques, épingle avecmodel: "<provider>/<id>"et gère les retries côté client. - Budget et alerting bougent aussi : les limites de budget Portkey deviennent Tableau de bord → Budget Control (plafond mensuel avec verdicts BLOCK / DOWNGRADE / LIGHT_ONLY), et l'alerting devient des webhooks Slack / email sur déclenchements Guardian et transitions budget.
C'est fini
10-15 minutes, surtout pour re-saisir les clés provider dans le dashboard. Contacte support@hiway2llm.com si tu bloques.