LLM 0.32 : traces de raisonnement visibles, outils côté serveur et logs en style Git
LLM, le framework CLI et Python de Simon Willison pour travailler avec les modèles, sort en version 0.32. Willison la décrit comme la release la plus importante depuis le lancement du projet. Trois directions convergentes : traces de raisonnement inspectables, outils côté serveur et logs content-addressable sur SQLite.
Pourquoi ça te concerne. Si tu construis des agents, ces fonctionnalités résolvent des problèmes concrets. Les modèles de reasoning envoient désormais la trace de leur réflexion sur stderr, séparée de l’output : tu peux rediriger le résultat vers un autre outil sans traîner le raisonnement. Les outils côté serveur te permettent de déléguer des capacités au provider au lieu de les implémenter toi-même : OpenAI propose l’exécution de code et la recherche web, le plugin llm-anthropic ajoute la recherche web, l’exécution de code et surtout AnthropicMCP, qui fait exécuter les appels MCP directement par le provider dans une seule requête. Les logs SQLite réécrits en style Git sauvegardent chaque message une seule fois, en le référençant par hash au lieu de dupliquer tout l’historique à chaque tour de conversation.
Le modèle par défaut devient GPT-5.6 Luna, la variante économique de la famille GPT-5.6 qui fin juillet était déjà tombée à 0,20 dollar par million de tokens. La commande llm openai endpoint exécute des prompts one-off contre n’importe quelle API compatible OpenAI, même un modèle local dans LM Studio, sans installer LLM.
Willison écrit que beaucoup de modifications ont été guidées par Datasette Agent, son projet d’agent. « J’imagine que LLM est devenu un framework pour agents maintenant », conclut le post.
Dans le détail
Ce qu’il y avait avant. LLM naît comme un wrapper CLI pour appeler des modèles depuis le terminal et en garder une trace dans SQLite. Au fil des mois le panorama a changé : les modèles font du raisonnement interne avant de répondre, retournent des appels à des outils au lieu de seulement du texte, et les conversations multi-tour sont devenues le schéma normal pour les agents. LLM 0.32 réécrit l’architecture pour suivre cette évolution.
Les traces de raisonnement. Quand tu appelles un modèle de reasoning, celui-ci produit un texte de « réflexion » avant la réponse. Avant, LLM ne gérait pas ce texte de manière distincte. Maintenant il l’envoie sur stderr et garde stdout propre pour la réponse. C’est une séparation qui compte : si tu utilises LLM dans un pipeline shell, le raisonnement ne pollue pas le résultat. Le flag -R / --hide-reasoning le supprime complètement.
Outils côté serveur. Jusqu’à présent les outils dans LLM tournaient côté client : ton code exécutait la fonction et retournait le résultat au modèle. Maintenant LLM supporte des outils exécutés directement par le provider. L’exemple le plus intéressant est AnthropicMCP : tu passes un endpoint MCP et Anthropic l’appelle dans la même requête API, sans que ton code serve d’intermédiaire.
Willison le montre avec une commande qui demande à Claude combien de lignes il y a dans une table, en faisant exécuter par Anthropic les appels MCP contre un serveur Datasette. En une seule requête et réponse, le modèle interroge la base de données et répond.
Logs content-addressable. Le problème : dans une conversation multi-tour, chaque requête porte avec elle tout l’historique des messages précédents. Si tu loggues chaque requête, tu dupliques le même JSON à chaque tour. La nouvelle architecture sauvegarde chaque message une seule fois, avec un hash qui l’identifie, comme Git le fait avec les blobs. Les commandes llm logs et llm logs --json reconstruisent la vue lisible depuis le format content-addressable. Pour qui fait tourner des agents avec des contextes longs, l’espace disque cesse de croître quadratiquement.
API Python. Deux changements. Le paramètre messages=[] te permet de passer tout l’historique en un seul appel, au lieu de créer une conversation et d’envoyer les messages un par un. La méthode stream_events() retourne des événements typés (reasoning, text, autres) au lieu d’une séquence de chaînes, parce que les modèles d’aujourd’hui retournent du contenu hétérogène : texte, raisonnement, appels à des outils, pièces jointes.
Compatibilité. Les plugins existants continuent de fonctionner, mais ceux qui fournissent des modèles supplémentaires doivent être mis à jour vers 0.32 pour supporter le nouveau système de streaming events. llm-anthropic 0.26 est déjà prêt avec les modèles Claude 5. llm-gemini, llm-openrouter et llm-mistral arrivent bientôt.
Limitations. La commande llm openai endpoint ne logue pas les requêtes : utile pour les prompts one-off, mais tu perds la traçabilité si tu l’utilises dans un flux répétitif. Le plugin llm-chat-completions-server implémente l’API semi-standard d’OpenAI, mais le mot « semi » est significatif : la compatibilité n’est pas garantie sur tous les clients. Les outils côté serveur dépendent de ce que le provider offre : pas de portabilité entre OpenAI et Anthropic sur les mêmes capacités.