llm 0.33 : deux gabarits pour un appel

Ce qui se passe

llm, l'outil en ligne de commande de Simon Willison pour interroger des modèles, passe en 0.33. Trois changements méritent l'attention, dont un qui modifie une façon de travailler.

Le changement qui compte : des gabarits composables

Jusqu'ici, un gabarit (--template) était un bloc unique : il portait à la fois le prompt et la configuration — modèle, options, effort de raisonnement. Résultat prévisible : une bibliothèque de prompts finissait soudée à un modèle, et tester le même prompt ailleurs demandait de dupliquer le gabarit.

L'option -t/--template peut désormais être répétée, et les gabarits sont combinés dans l'ordre indiqué. La configuration et les options de l'un s'appliquent au prompt de l'autre :

# un gabarit qui n'est qu'une configuration
llm -m gpt-5.6-luna -o reasoning_effort high --save lhigh

# un gabarit qui n'est qu'un prompt
llm "Generate an SVG of a pelican riding a bicycle" --save pelican

# on combine à l'appel
llm -t lhigh -t pelican

Le gain concret : une matrice au lieu d'une liste. Trois configurations et dix prompts donnent trente combinaisons sans dupliquer un seul fichier. Pour comparer un même prompt sur plusieurs modèles — l'exercice de base quand on choisit un modèle pour une tâche — c'est un changement de gabarit, plus une réécriture.

Les clés d'embedding, par appel

llm embed et llm embed-multi acceptent maintenant --key. Côté Python, EmbeddingModel.embed(), embed_multi(), Collection.embed() et Collection.embed_multi() acceptent un argument key=, qui transmet la clé résolue au plugin sans modifier l'état partagé du modèle.

La nuance a de l'importance dès qu'un même processus traite plusieurs comptes ou plusieurs clients : jusqu'ici, changer de clé revenait à muter un objet partagé, ce qui n'est pas ce qu'on veut dans un script qui boucle. Les plugins existants qui lisent self.key continuent de fonctionner via un repli de compatibilité — la migration n'est donc pas urgente. Les modèles d'embedding suivent désormais le même schéma de gestion des clés que les modèles de génération.

Le point de vigilance : la dépendance HTTP

La version passe à la bibliothèque OpenAI Python 3.x et remplace httpx par httpx2. Un correctif rapide (0.32.1) était sorti la veille pour parer au plus pressé ; la 0.33 est le traitement complet.

C'est le genre de changement invisible jusqu'au jour où il ne l'est pas : si llm est installé dans un environnement partagé avec d'autres outils Python, une contrainte de version sur httpx peut suffire à provoquer un conflit de résolution. Un environnement virtuel dédié, ou uv tool install, évitent la question.

Dernier ajout : les modèles compatibles Responses API dotés de raisonnement acceptent une option reasoning_summary avec les valeurs auto, concise et detailed, utilisable avec llm openai endpoint --responses. Utile surtout pour exercer les modèles tiers qui imitent cette API.

Comment s'y prendre

• Découpez vos gabarits en deux familles : ceux qui décrivent un modèle et ses options, ceux qui décrivent une tâche. Ne les mélangez plus.
• Si vous appelez llm depuis un pipeline avec des versions épinglées, testez la mise à jour avant de la déployer, à cause du changement de client HTTP.
• Si vous maintenez un plugin d'embedding, prévoyez le passage à key= sans urgence : le repli de compatibilité tient.