OpenRouter contre LiteLLM (2026) — ce sont des couches différentes, et la plupart des équipes qui posent la question devraient utiliser les deux

La comparaison est mal formulée presque partout où elle apparaît, et le quatrième résultat de cette recherche le révèle : il s’agit de la propre page de documentation de LiteLLM sur OpenRouter. LiteLLM fournit une intégration OpenRouter parce que ces deux solutions ne sont pas des substituts — elles se situent à des niveaux différents. LiteLLM est un proxy que vous déployez au-dessus des comptes fournisseurs que vous détenez ; OpenRouter est un service hébergé qui détient les comptes fournisseurs pour vous et revend l’accès aux modèles. Un proxy a besoin d’une source ; OpenRouter en est une. De nombreuses équipes utilisent volontairement les deux.

Biais déclaré : Kunavo est notre produit, et il appartient au côté OpenRouter de cette page — une source de modèles hébergée, pas un proxy. Il ne constitue pas une alternative à ce que fait LiteLLM, et cette page ne prétend pas le contraire.

La différence de niveau, dans un tableau

Lisez la ligne « est-ce une source de modèles ? » : le cadrage devient évident. Toutes les autres différences en découlent.

Les utiliser ensemble, le cas courant

LiteLLM devant, OpenRouter derrière : vos applications s’adressent à un seul point de terminaison interne, LiteLLM applique les budgets par clé et le routage d’équipe, et OpenRouter fournit le catalogue sans que vous ouvriez un compte auprès de chaque fournisseur. Tout point de terminaison compatible avec OpenAI s’intègre de la même manière ; une seconde source pour le basculement ne demande que quelques lignes :

# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: openrouter/anthropic/claude-sonnet-4.6
      api_key: os.environ/OPENROUTER_API_KEY

  # A second source behind the same proxy — any OpenAI-compatible
  # endpoint works the same way.
  - model_name: claude-sonnet-backup
    litellm_params:
      model: openai/claude-sonnet-5
      api_base: https://api.kunavo.com/v1
      api_key: os.environ/KUNAVO_API_KEY

C’est généralement ainsi que la question « vs » aurait dû être formulée : non pas lequel choisir, mais avez-vous réellement besoin de la couche proxy au-dessus d’une source hébergée ?

Quand vous n’avez réellement besoin que d’une seule solution

• OpenRouter seul — vous n’avez aucun compte fournisseur, vous n’en voulez pas, et vos besoins de routage sont satisfaits par ce qu’offre déjà une passerelle hébergée. Ajouter LiteLLM vous apporte ici un service à exploiter, et peu d’autre chose. Alternative dans cette catégorie : le comparatif OpenRouter.
• LiteLLM seul — vous détenez déjà des comptes fournisseurs, éventuellement à des tarifs négociés, et ce qui vous manque est le contrôle : un point de terminaison unique, des budgets par clé, une politique de routage et un texte de prompt qui ne quitte jamais votre infrastructure. Aucun revendeur ne peut vous garantir ce dernier point, quel qu’en soit le prix.
• Aucun des deux — vous voulez le routage et la gouvernance, mais pas un service à exploiter. Il vous faut un plan de contrôle BYO-key hébergé, une troisième catégorie à laquelle aucun de ces deux produits n’appartient : les quatre catégories de passerelles LLM.

Les deux points à vérifier avant de vous engager pour l’un ou l’autre

Du côté de LiteLLM : la surface opérationnelle. Un proxy auto-hébergé est un paquet intégré à votre build, ce qui place votre CI/CD et votre cluster dans son rayon d’impact — ce n’est pas théorique pour ce projet, comme l’a montré l’incident de la chaîne logistique de mars 2026. La réponse de LiteLLM a été substantielle et l’incident est clos pour toute personne utilisant v1.83.0 ou une version ultérieure, mais le point structurel reste valable pour tout proxy auto-hébergé.

Du côté d’OpenRouter : le plancher tarifaire. Un revendeur qui répercute les tarifs catalogue avec des frais sur les achats de crédits n’est pas automatiquement moins cher que votre propre compte — ni automatiquement plus cher si votre compte applique le tarif catalogue public. La comparaison pertinente consiste à comparer votre tarif réel à celui de la passerelle, modèle par modèle, pour les modèles que vous utilisez. Kunavo référence la plupart des modèles sous les tarifs officiels des fournisseurs ; c’est la même comparaison dans l’autre sens : Kunavo contre OpenRouter.

Compatibilité du protocole, pour que changer reste peu coûteux

Les deux parlent le protocole OpenAI, comme toutes les alternatives hébergées à l’un ou l’autre (documentation d’OpenRouter · documentation de LiteLLM). Quel que soit votre choix, le coût d’une erreur se résume à un base_url et à un changement de clé, ce qui est le fait le plus utile de cette page : cette décision ne mérite pas les semaines que certaines équipes y consacrent. Les détails se trouvent dans le guide de l’API compatible avec OpenAI.

Questions fréquentes