oterm : un client de terminal pour Ollama et les autres fournisseurs pydantic-ai
the terminal client for LLMs
En bref
- De quoi s’agit-il ?
- oterm place une interface de chat en mode texte devant Ollama, OpenAI, Anthropic et tout fournisseur pris en charge par pydantic-ai. Le projet est passé d'un client Ollama à un client multi-fournisseurs, et ce changement de périmètre explique aussi bien son intérêt que ses limites.
- À qui s’adresse-t-il ?
- oterm convient à qui travaille déjà dans un terminal, garde Ollama ou une clé d'API à portée de main et veut un fil de discussion persistant sans quitter son shell. Il ne convient pas à qui a besoin d'un client graphique multi-utilisateurs, ni à qui refuse de dépendre d'un fournisseur précis pour le rendu de ses réponses.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 14 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : discuter avec un modèle sans quitter son shell
La plupart des interfaces de dialogue avec un modèle local supposent un navigateur ou une application de bureau. oterm prend le parti inverse : c'est un client de terminal, et la description du dépôt le résume par une phrase, le client de terminal pour les LLMs. Le public visé est donc celui qui vit déjà dans un shell, qui a installé Ollama ou qui détient une clé d'API, et qui veut poser une question, garder le fil, revenir dessus plus tard, sans changer de fenêtre ni de contexte. La page d'accueil du projet n'existe pas, mais le README renvoie vers une documentation hébergée sur GitHub Pages pour l'installation complète, la configuration et l'usage. C'est là que se trouve le mode d'emploi réel, pas dans le README, qui reste volontairement court.
Ce que le passage à pydantic-ai change dans l'architecture
La version 0.23.0 a introduit un changement qualifié de cassant dans les notes de version : oterm n'est plus un client Ollama uniquement. Il pilote désormais tout fournisseur pris en charge par pydantic-ai. Le README cite OpenAI, Anthropic, Google (AI et Vertex), Groq, Mistral, Cohere, AWS Bedrock, DeepSeek, Cerebras, Grok, Hugging Face, Ollama, ainsi que les points d'accès compatibles OpenAI comme vLLM, LM Studio, llama.cpp, OpenRouter et LiteLLM. Le mécanisme est simple à décrire : on renseigne la clé d'API correspondante, et le fournisseur apparaît dans la liste déroulante de nouvelle conversation. Il n'y a donc pas de configuration par fournisseur à écrire dans un fichier, du moins d'après le README. La conséquence pratique est double. D'un côté, le même outil couvre un modèle local et un modèle distant. De l'autre, le comportement de rendu dépend d'une couche externe, pydantic-ai, dont les évolutions peuvent se répercuter sur oterm. Le mot cassant employé pour cette version signale d'ailleurs que le changement n'a pas été indolore pour les configurations existantes.
Installation : uvx en première ligne, extras en option
Le README donne une commande d'installation principale, courte : uvx oterm. Elle suppose uv présent sur la machine, puisque uvx est l'outil d'exécution de paquets associé. Le README précise que les méthodes d'installation complètes se trouvent dans la documentation, ce qui laisse entendre qu'il existe d'autres voies que uvx sans les détailler. Une capacité fait exception et s'installe séparément : la lecture vocale des réponses. La commande devient uvx "oterm[speak]", et cette variante exige Python 3.11 ou plus récent. Le README insiste sur un point : l'installation de base n'est pas modifiée, et la capacité n'apparaît qu'une fois l'extra présent. C'est un choix d'empaquetage cohérent, mais il implique de connaître le nom exact de l'extra, speak, et de savoir que les crochets doivent être protégés dans le shell, d'où les guillemets dans l'exemple fourni.
MCP : un schéma de configuration repris de Claude Desktop
La version 0.23.0 a aussi réécrit la prise en charge de MCP, là encore avec une rupture. Le bloc de configuration nommé mcpServers adopte le schéma standard de pydantic-ai, présenté comme compatible avec Claude Desktop et Cursor. L'intérêt est de ne pas inventer un format maison : qui a déjà un fichier de configuration MCP pour l'un de ces deux outils peut réutiliser la même structure. Le coût est un travail de migration pour les utilisateurs existants, et le README renvoie explicitement à une page de documentation dédiée aux notes de migration. Je n'ai pas installé le projet et je ne peux pas décrire le contenu de ce bloc au-delà de ce que le README en dit : la clé s'appelle mcpServers, le schéma est celui de pydantic-ai, et le reste est dans docs/mcp. Si votre usage de MCP repose sur une configuration écrite pour une version antérieure, considérez la mise à jour comme un chantier, pas comme un simple remplacement de binaire.
Le rendu du streaming et la question des longues réponses
Parmi les changements annoncés, un mérite qu'on s'y arrête, parce qu'il touche au confort réel d'usage. Le markdown est désormais mis à jour au fil des deltas au lieu d'être re-rendu à chaque token. La justification donnée est directe : les réponses longues ne ralentissent plus le terminal au fur et à mesure qu'elles s'allongent. C'est un problème classique des clients en terminal, où le coût de rendu croît avec la taille du texte déjà affiché. La correction annoncée attaque la cause plutôt que le symptôme. À côté de cela, l'interface a été retravaillée : mise en page sans bordures, invite qui grandit automatiquement, jetons de pièce jointe en ligne de la forme [Image #N], section de réflexion repliable, et un pied de page affichant l'usage de tokens en direct à la place d'un indicateur d'activité. Ce dernier point est un vrai apport pour qui surveille sa consommation, notamment sur des fournisseurs facturés au token.
La capacité speak et le choix de piper
La lecture vocale des réponses passe par piper, et le README précise que les réponses sont lues au fil de leur arrivée, dans la voix GLaDOS. Deux remarques. D'abord, cette capacité est conditionnée à l'extra speak et à Python 3.11 ou plus récent : sur une machine dont l'interpréteur est plus ancien, elle est hors de portée, quelle que soit la version d'oterm. Ensuite, la voix par défaut est un clin d'œil assumé, pas un réglage neutre. Le README ne dit pas comment changer de voix ni si c'est possible ; il faut consulter la documentation pour le savoir. Pour un usage professionnel, une synthèse vocale qui lit chaque réponse en flux peut être utile en contexte de lecture à distance, et gênante dans un espace partagé. C'est une capacité à activer en connaissance de cause, pas un comportement par défaut.
Ce qu'oterm ne fait pas, et à quoi le comparer
oterm est un client de terminal. Si votre besoin est une interface graphique avec historique partagé entre plusieurs personnes, gestion fine des conversations par dossiers ou export structuré, ce n'est pas l'outil. De même, la dépendance à pydantic-ai pour la couche fournisseurs signifie que la liste des fournisseurs disponibles est celle de pydantic-ai, pas celle d'oterm : un fournisseur absent de cette bibliothèque ne sera pas accessible par configuration. Sur le créneau du terminal, l'alternative la plus directe est d'utiliser Ollama en ligne de commande, en appelant directement son API locale. La différence d'approche est nette. Ollama en ligne de commande vous donne un appel ponctuel, sans fil de discussion persistant ni interface de chat ; oterm ajoute la couche de conversation, la sélection du modèle et, depuis la version 0.23.0, la possibilité de basculer vers un fournisseur distant sans changer d'outil. Inversement, si vous n'avez qu'un seul modèle local et des besoins simples, la couche supplémentaire n'apporte pas grand-chose et ajoute une dépendance à uv et à pydantic-ai.
Maintenance, licence et coût de mise à jour
Le dépôt n'est pas archivé et les versions récentes sont rapprochées : 0.23.0 fin juillet 2026, 0.23.1 début août, 0.24.0 début septembre. Le rythme est soutenu, et deux des changements récents sont explicitement marqués comme cassants, la couche fournisseurs et la configuration MCP. Concrètement, cela veut dire qu'une mise à jour peut demander de retoucher un fichier de configuration, et que la lecture des notes de version n'est pas optionnelle si vous avez personnalisé quelque chose. La licence est MIT, ce qui autorise la réutilisation et la modification du code, y compris dans un contexte commercial, sous réserve de conserver la mention de licence. Ce paragraphe n'est pas un avis juridique : pour un usage en entreprise, faites relire la licence et ses implications par qui de droit. Le coût réel d'adoption se situe moins dans l'installation, une seule commande, que dans le suivi des ruptures annoncées.
Conclusion éditoriale
oterm convient à qui travaille déjà dans un terminal, garde Ollama ou une clé d'API à portée de main et veut un fil de discussion persistant sans quitter son shell. Il ne convient pas à qui a besoin d'un client graphique multi-utilisateurs, ni à qui refuse de dépendre d'un fournisseur précis pour le rendu de ses réponses. Avant d'adopter, vérifier deux points dans la documentation : la disponibilité du paquet pour votre version de Python, et la présence effective des clés d'API correspondant aux fournisseurs que vous voulez voir apparaître dans la liste déroulante.
Notes de la communauté