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 fallback de 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 avec model: "<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.