Migrer d’OpenRouter vers Brievio : un diff de deux lignes

Commençons par la part d’équité : OpenRouter est le leader de l’étendue. Une clé, une URL de base, et tu atteins 300+ modèles — y compris la longue traîne open source (Llama, Qwen, DeepSeek, Mistral, et des dizaines de fine-tunes communautaires) qu’aucune API first-party n’expose. Si ton boulot consiste à évaluer un large éventail, à contourner les pannes d’un fournisseur à l’autre, ou à atteindre un modèle open-weights de niche, ce catalogue est une force réelle et difficile à reproduire. Cet article n’est pas un réquisitoire.

C’est un guide du chacun-sa-place. Il existe une autre catégorie de besoins — ceux où tu veux le vrai modèle first-party flagship avec ses fonctionnalités natives intactes, une facturation que tu peux auditer token par token, l’image et la vidéo sur la même clé, et une remise par modèle assez modeste pour être crédible. C’est là que les équipes ajoutent une passerelle de calibre first-party comme Brievio à côté d’OpenRouter, ou y basculent entièrement le chemin de production. La migration elle-même se résume à un changement de base_url d’une ligne plus un renommage de slug de modèle. Voici la décision honnête et la mécanique.

Quand OpenRouter est le bon choix

Vois clair là-dessus avant de changer quoi que ce soit. OpenRouter est le meilleur choix quand :

• Tu as besoin de la longue traîne open source. Llama, Qwen, DeepSeek, Mistral et les fine-tunes communautaires ne sont sur aucune API first-party. Si ta feuille de route touche aux modèles open-weights, c’est ce catalogue qu’il te faut.
• Tu mènes une évaluation large. Comparer vingt modèles répartis sur cinq fournisseurs, c’est exactement ce pour quoi un agrégateur de 300 modèles est conçu. Une clé, un schéma, tous les modèles.
• Tu veux le basculement inter-fournisseurs comme fonctionnalité. OpenRouter sait se rabattre sur d’autres fournisseurs en amont pour un même modèle. Pour certains profils de disponibilité, c’est précisément cette étendue de routage qui compte.
• Tu compares les prix de l’hébergeur le moins cher d’un modèle ouvert donné. La marketplace expose plusieurs fournisseurs par modèle et te laisse trier par prix. C’est un vrai levier.

Rien de tout cela ne disparaît en ajoutant Brievio. Beaucoup d’équipes gardent OpenRouter pour exactement ces besoins et n’orientent ailleurs que le trafic de production first-party. Deux URLs de base, une seule base de code.

Quand une passerelle de calibre first-party convient mieux

L’argument du changement (ou du partage de trafic) est plus étroit et plus précis. Tourne-toi vers elle quand ces points comptent :

• Tu as besoin du vrai modèle first-party, avec ses fonctionnalités natives intactes. Pas un fine-tune ni un quasi-équivalent — le véritable Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 et Gemini 2.5 Pro / Flash, avec le tool use natif, la vision et le prompt caching qui fonctionnent comme le fournisseur les documente. Quand le comportement d’un flagship est ton produit, le « presque pareil » ne suffit pas.
• Tu veux une facturation au token honnête et auditable. Ton coût réel, c’est tarif × tokens, et le décompte de tokens est le chiffre le plus facile à gonfler. Brievio rapporte les décomptes de tokens first-party authentiques et les facture sans détour. Si tu n’as jamais vérifié, c’est un auto-test de vingt lignes.
• Tu veux l’image et la vidéo sur la même clé. Nano Banana et Nano Banana Pro, GPT-Image-2 et Veo 3 se trouvent derrière les mêmes identifiants et le même client à la forme OpenAI que tes modèles de chat — aucun second compte fournisseur, aucune surface de facturation séparée.
• Tu veux une remise assez modeste pour qu’on lui fasse confiance. Les modèles de chat tournent à environ 15 % sous le tarif officiel, l’image et la vidéo à peu près 37,5 % en dessous, publiés par modèle face au tarif de référence officiel pour que tu puisses auditer l’écart. Une remise modeste et explicable, c’est une marge sur le volume — pas une subvention qu’il faut récupérer ailleurs, là où tu ne vois rien.
• Les appels échoués sont gratuits. Les réponses 4xx et 5xx ne sont pas facturées, donc une mauvaise journée d’un fournisseur en amont ne se transforme pas discrètement en ligne sur ta facture.

La migration : un base_url, une clé

Comme les deux passerelles implémentent l’API OpenAI Chat Completions, le changement est le plus petit diff de ta base de code. Tu pointes le SDK vers un nouvel hôte et tu remplaces la clé. Le streaming, le function calling, le mode JSON et la forme de tes requêtes restent intacts :

# Quitter OpenRouter, c'est un diff de deux lignes : change le base_url et la clé.
# Tout le reste — le SDK OpenAI, la forme de tes requêtes, le streaming, les tools —
# reste rigoureusement identique, car les deux parlent l'API OpenAI Chat Completions.

from openai import OpenAI

# --- Avant : OpenRouter ---
client = OpenAI(
    api_key="sk-or-...",
    base_url="https://openrouter.ai/api/v1",
)

# --- Après : Brievio ---
client = OpenAI(
    api_key="sk-brievio-...",
    base_url="https://api.brievio.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",                 # voir la correspondance des noms ci-dessous
    messages=[{"role": "user", "content": "Summarize this contract clause…"}],
)

Si tu es venu à OpenRouter depuis le SDK officiel d’OpenAI au départ, cela te semblera familier — c’est le même geste que notre migration depuis OpenAI en dix minutes, avec simplement une origine différente. Pas de nouveau SDK, pas de réécriture de tes points d’appel.

La seule chose que tu changes : les slugs de modèles

Voici l’unique différence de comportement qui mérite quelques minutes de soin. OpenRouter préfixe chaque modèle en vendor/model — anthropic/claude-sonnet-4.6, google/gemini-2.5-flash — parce qu’avec 300+ modèles répartis sur de nombreux fournisseurs, le préfixe évite les collisions. Brievio sert un ensemble first-party trié sur le volet, donc les slugs sont nus : claude-sonnet-4-6, gemini-2.5-flash. Sans préfixe vendor/.

# La seule chose que tu touches VRAIMENT : les slugs de modèles.
# OpenRouter préfixe chaque modèle en "vendor/model" pour que 300+ modèles issus
# de nombreux fournisseurs n'entrent jamais en collision. Brievio sert un ensemble
# first-party trié sur le volet, donc les slugs sont nus — sans préfixe "vendor/".

MODEL_MAP = {
    # slug OpenRouter                 ->  slug Brievio
    "anthropic/claude-opus-4.7":         "claude-opus-4-7",
    "anthropic/claude-sonnet-4.6":       "claude-sonnet-4-6",
    "anthropic/claude-haiku-4.5":        "claude-haiku-4-5",
    "google/gemini-2.5-pro":             "gemini-2.5-pro",
    "google/gemini-2.5-flash":           "gemini-2.5-flash",
    # L'image + la vidéo vivent sur la MÊME clé — aucun compte fournisseur séparé :
    # "nano-banana", "nano-banana-pro", "gpt-image-2", "veo-3"
}

def to_brievio(slug: str) -> str:
    return MODEL_MAP.get(slug, slug.split("/")[-1])

# Raccourci pragmatique pour Claude/Gemini : retire le préfixe et passe le point
# en tiret dans la version. "anthropic/claude-sonnet-4.6" -> "claude-sonnet-4-6".
# Confirme chacun face à /models pour échouer bruyamment sur une faute de frappe
# plutôt que router au mauvais endroit en silence.

Pour Claude et Gemini, la règle est mécanique : retire le préfixe, et écris la version avec des tirets au lieu d’un point (4.6 → 4-6). Garde un petit dictionnaire de correspondance plutôt que de bricoler les chaînes à l’aveugle, et valide chaque slug face à la liste des modèles pour qu’une faute de frappe échoue bruyamment au démarrage au lieu de router en silence au mauvais endroit. C’est le seul rechercher-remplacer que la migration exige réellement.

Un déploiement pragmatique

Tu n’as pas à tout choisir d’un coup. Le chemin le moins risqué traite les deux passerelles comme complémentaires :

• Fais-les tourner côte à côte. Garde OpenRouter pointé sur la longue traîne open source et ton harnais d’évaluation. Ajoute Brievio comme second client pour les flagships first-party de ton chemin de production. Deux URLs de base, un seul dépôt.
• Fais du shadow avant de basculer. Recopie une fraction du trafic en direct vers Brievio et compare les réponses ainsi que les objets usage. Tu vérifies que le modèle est bien le vrai first-party et que les décomptes de tokens collent à ce que tu attends — l’ auto-test des tokens est exactement cette vérification, automatisée.
• Déplace d’abord le travail multimodal. Si tu assembles aujourd’hui un fournisseur d’image ou de vidéo séparé, consolider Nano Banana / GPT-Image-2 / Veo 3 sur une seule clé est souvent la victoire précoce la plus propre — moins de comptes, une seule facture, un seul chemin d’authentification.
• Promeus quand le diff est ennuyeux. Une fois que le trafic fantôme correspond et que les chiffres se réconcilient, bascule le défaut de production. Reviens en arrière en restaurant un seul base_url si quelque chose te surprend.

Le mot honnête de la fin

OpenRouter et une passerelle de calibre first-party ne se disputent pas vraiment le même boulot. OpenRouter optimise la portée — le catalogue le plus large et la longue traîne open source sous une seule clé, ce qui est une chose réelle et précieuse. Brievio optimise la fidélité sur un ensemble trié sur le volet — les vrais flagships first-party avec leurs fonctionnalités natives intactes, une facturation au token honnête et auditable, l’image et la vidéo sur la même clé, et une remise par modèle assez modeste pour qu’on lui fasse confiance. Les deux se trouvent derrière un unique base_url compatible OpenAI, ce qui est précisément pourquoi tant d’équipes font tourner les deux : l’étendue là où il leur faut de l’étendue, la fidélité là où elle compte.

Si tu veux les vrais modèles first-party avec leur comportement natif et une facturation que tu peux vérifier, le geste te coûte un seul base_url, une clé, et un renommage de slug de modèle. Lis le comparatif côte à côte sur Brievio vs OpenRouter, parcours les modèles et slugs exacts sur la liste des modèles, et lance l’ auto-test des tokens contre les deux avant de mettre du vrai trafic où que ce soit. La décision survit à l’examen dans un cas comme dans l’autre — et c’est le seul genre de décision qui mérite d’être expédié.