Caret Router : Pourquoi nous sommes passés de LiteLLM à any-llm

Lors de la conception du routeur LLM chez Caret, la chose la plus importante pour nous était « la simplicité que nous pouvons contrôler ». Les modèles ne cessent de se multiplier, les fournisseurs changent et les exigences augmentent — et nous avons appris plus d’une fois que si le routeur devient trop lourd, la complexité opérationnelle finit par nuire à la vélocité du produit.

Nous avons utilisé LiteLLM pendant un certain temps. Fonctionnellement, il est excellent et très bien conçu. Mais au fil du temps, il est devenu clair que certaines parties ne correspondaient pas à la direction que prenait Caret ni à la façon dont nous opérons en production. Nous avons donc changé notre routeur de LiteLLM → any-llm.

Il ne s’agit pas d’un « examen comparatif », mais d’un enregistrement de la raison pour laquelle nous avons changé — et de ce qui est devenu possible après le changement.

---

1. LiteLLM était trop complexe et Caret n’avait pas besoin de bon nombre de ses fonctionnalités

LiteLLM se rapproche plus d’une passerelle/serveur proxy d’IA qu’un simple SDK. Multi-tenancy, clés virtuelles, gestion de l’organisation, contrôles budgétaires, journalisation, alertes, intégrations de bases de données… Dans les « environnements d’entreprise », ce sont indéniablement de puissants avantages.

Le problème est que le routeur de Caret n’avait pas besoin de ce type d’ensemble de fonctionnalités.

• Le changement de routeur a entraîné une base de données, une configuration de worker et des paramètres opérationnels
• Nous devions maintenir une structure qui comprenait des fonctionnalités que nous n’utilisions pas
• Au final, « l’exploitation du routeur » devient plus importante que le « routage des LLM »

Par conséquent, LiteLLM est devenu un choix lourd pour Caret non pas parce qu’il manquait de fonctionnalités, mais parce qu’il en avait trop.

---

2. any-llm était allégé et facile à étendre

La principale raison pour laquelle nous avons choisi any-llm est simple.

« Un routeur doit être mince. »

any-llm est fondamentalement une bibliothèque axée sur une interface API propre.

• Il ne vous force pas à utiliser un serveur proxy
• Il se concentre sur l’abstraction des appels de modèles
• La structure est simple, il est donc facile à comprendre au niveau du code

Il ne s’agit pas seulement d’être « léger » — cela signifie que nous pouvons l’intégrer naturellement dans notre architecture de service.

Pour nous, qui souhaitions que le routeur soit un composant interne de la plateforme Caret plutôt qu’un service autonome, cela a été décisif.

---

3. Nous pourrions étendre ce que any-llm ne fournit pas, d’une manière qui convient à Caret

L’une des parties les plus difficiles de l’utilisation de LiteLLM était « l’adaptation de Caret à une structure qui était déjà décidée ».

Après être passés à any-llm, notre approche a complètement changé.

Le routeur route — nous construisons tout le reste.

Par conséquent, nous pourrions ajouter des fonctionnalités qui ne sont pas dans any-llm mais qui sont essentielles pour Caret — à notre manière.

• Gestion des profils
• Facturation/paiements
• Gestion des clés API
• Gestion du crédit
• Connexion sociale et authentification

Ces fonctionnalités ne doivent pas être appliquées au niveau du routeur ; elles devaient s’intégrer naturellement à la logique métier de Caret.

Grâce à la structure API simple d’any-llm, ce type d’extension est devenu beaucoup plus facile.

---

4. Étant donné que any-llm ne fournit qu’une API, nous pourrions créer l’interface utilisateur en toute liberté

LiteLLM se rapproche plus d’une « plateforme qui comprend une interface utilisateur d’administration ». Mais Caret a déjà sa propre UX et sa propre philosophie de conception.

any-llm n’impose aucune interface utilisateur.

• Fournit uniquement une API
• Le service décide entièrement de l’UI/UX

Cela nous a permis de concevoir :

• Une interface utilisateur alignée sur les flux d’utilisateurs de Caret
• Des écrans où les crédits, les paiements et la gestion des clés se connectent naturellement
• Une expérience où les fonctionnalités LLM ressemblent à des « outils »

— sans contraintes.

Au lieu que le routeur définisse l’UX, le produit enveloppe le routeur.

---

5. any-llm facilite également l’amélioration des performances avec Go plus tard

À long terme, Caret se soucie de la performance et de la rentabilité. La couche de routeur en particulier est l’endroit où le trafic a tendance à se concentrer.

Étant donné que la structure d’any-llm est simple :

• Il n’est pas verrouillé dans un langage/runtime spécifique
• Le reconstruire en Go — ou remplacer des parties par des composants Go plus tard — est une option réaliste

Cela aurait été une décision plus difficile si nous étions liés à une conception qui suppose un serveur proxy lourd. Avec une structure basée sur any-llm, nous pouvons garder notre stratégie de performance flexible.

---

6. Nous allons l’ouvrir une fois qu’il sera nettoyé

Alors que nous passions de LiteLLM à any-llm et que nous ajoutions nous-mêmes des fonctionnalités spécifiques à Caret, une chose est devenue claire.

Cette structure est trop belle pour que nous la gardions pour nous.

Nous sommes donc en train de nettoyer le code, et une fois qu’il sera prêt, nous le publierons en open source.

• Une architecture de routage basée sur any-llm
• Les modèles d’extension que nous utilisons réellement dans Caret
• Les enseignements opérationnels tirés de son exécution

Nous recherchons des développeurs qui souhaitent réfléchir et construire ensemble. Plutôt qu’un « framework fini », nous espérons qu’il deviendra une base que nous développerons ensemble.

---

En conclusion

Ce changement ne signifie pas que « LiteLLM est mauvais ». LiteLLM reste un excellent outil et convient à de nombreuses équipes.

Mais pour Caret, nous avions besoin de :

• Un routeur plus mince
• Plus de liberté pour étendre
• Une séparation plus claire des responsabilités

Et any-llm était l’option qui correspondait à ces besoins.

Ce à quoi ce choix mènera deviendra plus clair grâce aux opérations en cours et au processus open source.

Nous laisserons bientôt le code parler de lui-même.