Faites tourner les agents Letta sur un endpoint compatible OpenAI.

Réponse rapide : deux variables d'environnement sur le serveur.

Le chemin documenté de Letta pour les endpoints compatibles OpenAI est la configuration d'environnement sur le serveur auto-hébergé : réglez OPENAI_API_BASE sur l'URL de l'endpoint et OPENAI_API_KEY sur sa clé au démarrage du serveur, et Letta enregistre les modèles que sert cet endpoint. Pour APIsRouter, la base est https://api.apisrouter.com/v1. Il n'y a pas de champ base-URL par agent dans l'interface ; l'endpoint est une décision au niveau du serveur, ce qui explique pourquoi l'environnement est la surface qui compte. Une exigence n'est pas négociable et mérite d'être lue avant tout le reste : la documentation de Letta affirme que les endpoints compatibles OpenAI doivent supporter l'appel de fonctions, parce que la boucle d'agent est construite sur des appels d'outils. Un endpoint qui ne fait que de simples chat completions ne peut pas du tout faire tourner un agent Letta. Les modèles du catalogue sur APIsRouter parlent l'appel d'outils standard via /v1/chat/completions, exactement la forme qu'attend Letta.

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

Pourquoi Letta sollicite son modèle plus durement qu'une app de chat.

Letta (letta-ai sur GitHub, environ 24 000 étoiles) est né du projet de recherche MemGPT et construit des agents à état : des agents avec une mémoire persistante et auto-éditable qui survit entre les sessions. Là où un client de chat envoie votre message et affiche la réponse, un agent Letta fait tourner une boucle interne à chaque interaction, raisonnant sur ce qu'il sait, appelant des outils de mémoire pour lire et réécrire sa propre mémoire centrale et son stockage d'archive, et ne produisant qu'ensuite une réponse. Cette architecture a deux conséquences pour le routage de l'endpoint. D'abord, chaque étape de la boucle est une requête d'appel d'outils, ce qui explique pourquoi l'appel de fonctions est une exigence dure plutôt qu'un agrément ; un modèle qui bâcle les schémas d'outils ne se dégrade pas gracieusement ici, il casse la capacité de l'agent à se souvenir. Ensuite, le volume de requêtes par interaction est plus élevé que ne le suggère la transcription de conversation, parce que la gestion de la mémoire se déclenche à côté de la réponse visible. L'id de modèle servant tout cela est une simple chaîne pour l'endpoint, donc avec une passerelle multi-fournisseurs derrière OPENAI_API_BASE, un id Claude peut faire tourner la boucle d'agent tandis qu'un id rapide sert des agents plus légers sur le même serveur, chacun adressé par son handle.

L'état de support honnête, directement du projet officiel.

La documentation de Letta elle-même dit que les endpoints proxy OpenAI ne sont pas officiellement supportés et que vous êtes susceptible de rencontrer des erreurs, recommandant plutôt des connexions directes aux fournisseurs. Cette mise en garde mérite d'être citée plutôt qu'enfouie, parce que la plupart des pages sur ce sujet font comme si elle n'existait pas. Ce que cela signifie en pratique est plus étroit qu'il n'y paraît : Letta teste contre des API de première partie, et un endpoint qui dévie de la sémantique OpenAI, en particulier autour de l'appel d'outils, produit des échecs que le projet officiel ne priorisera pas. Un endpoint qui implémente réellement la spécification, appels d'outils inclus, fonctionne bien, et c'est précisément la barre de compatibilité dont dépend la survie d'une passerelle. L'historique du support a aussi connu un vrai bug qui mérite d'être connu. Jusqu'au début 2026, les modèles enregistrés via OPENAI_API_BASE étaient auto-préfixés comme fournisseur openai-proxy tandis que la création d'agent validait contre une liste plus courte de préfixes acceptés, donc les modèles proxy s'enregistraient mais ne pouvaient pas être utilisés pour créer des agents. Le problème a été clos avec un correctif en janvier 2026 ; si vous faites tourner un serveur ancien épinglé et que la création d'agent rejette des modèles que le serveur liste clairement, c'est ce décalage que vous rencontrez, et la mise à jour est le correctif. Encore une cible mouvante : la surface produit de Letta a bougé, et sa documentation oriente actuellement les nouveaux utilisateurs vers des modes de déploiement plus récents tout en notant que l'image Docker classique n'est plus la surface activement maintenue. Les variables d'environnement ci-dessus sont le mécanisme documenté pour le serveur auto-hébergé ; vérifiez la documentation actuelle pour savoir quel artefact serveur le projet officiel recommande la semaine où vous déployez.

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

Choisir des modèles pour des agents à état.

L'évaluation qui compte est la fidélité de la boucle : créez un agent de test, ayez une conversation qui force des mises à jour de mémoire, puis lisez la mémoire centrale de l'agent et vérifiez qu'elle a réellement changé. Un modèle peut écrire des réponses charmantes et échouer quand même au contrat de mémoire, et seul le test de boucle l'attrape.

• L'édition de mémoire est un travail d'outils structuré. claude-sonnet-4-6 et gpt-5.5 gèrent de façon fiable la boucle de réécriture de sa propre mémoire, la compétence centrale dont a besoin un agent Letta.
• Les agents à longue durée de vie accumulent du contexte. Les modèles qui restent cohérents loin dans une fenêtre de contexte comptent plus ici que dans un chat sans état, et c'est là que claude-opus-4-7 mérite sa place pour les assistants à forts enjeux.
• Des flottes d'agents légers, un par utilisateur ou par tâche, sont des charges de volume. claude-haiku-4-5-20251001 garde le coût par agent stable tout en faisant des appels d'outils compétents.
• deepseek-v4-pro vaut la peine d'être testé pour des agents qui mélangent raisonnement et trafic bilingue ; l'exigence d'appel d'outils est le portail, donc testez la boucle, pas seulement la prose.
• Quoi que vous choisissiez, choisissez par agent. Le serveur enregistre tout le catalogue, et chaque agent se lie à un handle, donc un concierge lourd en mémoire et un agent de tâche jetable peuvent faire tourner des ids différents côte à côte.

Paiement à l'usage · en dessous du tarif officiel

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modes d'échec spécifiques à Letta.

La création d'agent qui rejette un modèle que le serveur liste est le bug historique de préfixe. Les modèles enregistrés via un proxy portaient un préfixe de fournisseur que la création d'agent refusait d'accepter sur les versions affectées. Le correctif est arrivé en janvier 2026 ; sur les versions actuelles, le handle affiché dans le listing de modèles est le handle qui fonctionne. Si vous êtes épinglé à une image plus ancienne, c'est la raison la plus forte de mettre à jour avant de déboguer quoi que ce soit d'autre. Un agent qui répond mais ne se souvient jamais est un échec d'appel d'outils. Soit l'endpoint n'implémente pas l'appel de fonctions, soit le modèle derrière l'id gère mal les schémas d'outils. Le symptôme est des conversations qui fonctionnent tandis que la mémoire centrale ne se met jamais à jour. Testez le même agent sur claude-sonnet-4-6 pour séparer les problèmes d'endpoint des problèmes de modèle. Des variables d'environnement réglées au mauvais endroit sont le classique Docker : OPENAI_API_BASE exportée dans votre shell ne fait rien pour un conteneur démarré sans les flags -e. Les variables doivent atteindre le processus serveur lui-même. Et comme l'endpoint est au niveau du serveur, rappelez-vous le rayon d'impact : changer OPENAI_API_BASE déplace chaque agent sur ce serveur. Il n'y a pas de surcharge d'endpoint par agent, donc un serveur par passerelle est la topologie propre, le choix de modèle par agent faisant la différenciation.

Qui route Letta via une passerelle.

• Les créateurs d'assistants persistants qui veulent une édition de mémoire de qualité Claude sans compte fournisseur, clé et surface de facturation séparés pour chaque modèle qu'ils essaient.
• Les équipes qui font tourner des flottes d'agents où chaque utilisateur a un agent, et où le suivi d'usage par clé transforme le vrai coût de la couche mémoire en rapport lisible.
• Les chercheurs qui comparent comment les modèles gèrent la mémoire auto-éditable, où chaque candidat est un changement de handle sur un agent de test plutôt qu'une migration de fournisseur.
• Les auto-hébergeurs dans des environnements où l'accès API direct aux fournisseurs est bloqué et où un seul endpoint de passerelle est ce que la politique réseau autorise.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.

Vérifiez l'endpoint et déboguez le premier agent.

Vérifiez la passerelle avant le serveur : listez les modèles avec la clé, et lancez une completion de chat avec une définition d'outil attachée, parce que l'appel d'outils est la capacité dont Letta dépend réellement. Si l'aller-retour d'appel d'outil fonctionne en curl, la moitié endpoint est prouvée. Démarrez ensuite le serveur avec les deux variables et lisez son listing de modèles. Des modèles qui y apparaissent prouve l'enregistrement ; un agent créé avec succès depuis un handle listé prouve le chemin de préfixe ; une conversation qui met à jour la mémoire centrale prouve la boucle de bout en bout. Déboguez dans cet ordre, parce que chaque étape a un ensemble d'échecs distinct : les variables d'environnement, la version du serveur, et la compétence d'outils du modèle respectivement. Une fois les agents en fonctionnement, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Les agents à état facturent plus par interaction que ne le suggèrent leurs transcriptions, puisque la gestion de mémoire tourne derrière chaque réponse, et le journal d'usage est l'endroit où ce multiplicateur caché devient un chiffre que vous pouvez budgétiser.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

Questions fréquentes