llm-anthropic 0.25.1

## llm-anthropic 0.25.1 : trois changements, un seul qui compte vraiment

### Ce qui change concrètement

Simon Willison publie llm-anthropic 0.25.1, mise à jour du plugin officieux qui connecte son outil CLI `llm` à l'API Anthropic. Trois modifications au changelog, d'importance très inégale.

**1. Claude Opus 4.8** (`claude-opus-4.8`) rejoint la liste des modèles disponibles. Willison a utilisé cette version précisément pour générer les exemples de sa note de sortie — signal que le modèle est fonctionnel dans le plugin dès le jour J. Opus 4.8 se positionne comme une mise à jour incrémentale de la ligne Opus 4, sans rupture architecturale annoncée. Les benchmarks publiés par Anthropic le placent au-dessus d'Opus 4 sur les tâches de raisonnement prolongé, mais en dessous de Claude Sonnet 4.5 sur le rapport coût/performance pour les usages courants.

**2. Option `-o fast 1`** pour le fast mode. Cette fonctionnalité est réservée aux organisations ayant activé l'option sur leur compte Anthropic — elle n'est pas disponible par défaut. Le fast mode réduit la latence au prix d'une qualité potentiellement moindre sur les tâches complexes. Pour les pipelines CLI automatisés où la vitesse prime sur la profondeur, c'est utile. Pour les utilisateurs individuels sans accès organisationnel, ce flag est invisible.

**3. max_tokens par défaut aligné sur le maximum du modèle** — c'est le changement le plus structurellement significatif, et il mérite attention.

### Le vrai changement : la fin du plafond arbitraire à 8 192 tokens

Avant 0.25.1, chaque appel via llm-anthropic était plafonné à 8 192 tokens de sortie, quelle que soit la capacité réelle du modèle. Ce n'était pas une limitation d'Anthropic — c'était une valeur par défaut codée dans le plugin. Claude 3.5 Sonnet peut produire jusqu'à 8 192 tokens, mais Claude 3 Opus monte à 4 096, et les modèles récents de la famille Claude 3.5/4 supportent jusqu'à 16 000 voire 32 000 tokens selon les configurations.

Concrètement : si vous demandiez à Claude Opus 4.8 de générer un rapport long, une analyse de code étendue, ou une traduction de document, le plugin tronquait silencieusement la sortie à 8 192 tokens même si le modèle pouvait aller plus loin. L'issue GitHub #72 documente ce comportement comme un bug de facto.

Avec 0.25.1, `max_tokens` est désormais résolu dynamiquement par modèle. Cela a deux implications directes : - Les sorties longues ne sont plus tronquées sans avertissement - Le coût par appel peut augmenter si vos prompts génèrent naturellement des réponses longues que le modèle était auparavant forcé d'interrompre

Pour les développeurs qui utilisent `llm` dans des scripts de génération de contenu, de documentation automatique, ou d'analyse de fichiers, c'est un changement de comportement à tester explicitement avant de déployer en production.

### Qui perd dans cette mise à jour

Les utilisateurs qui avaient des workflows calibrés sur la limite de 8 192 tokens — par exemple des pipelines qui découpaient les tâches en chunks en supposant que chaque appel ne dépasserait jamais cette taille — peuvent voir leur comportement changer. Un script qui appelait le modèle 5 fois pour traiter un document peut maintenant le traiter en 2 appels, mais chaque appel sera plus coûteux en tokens.

Les organisations sans fast mode activé ne bénéficient pas de la deuxième nouveauté. Anthropic n'a pas communiqué de critères publics pour l'activation de cette fonctionnalité, ce qui en fait une feature de fait réservée aux comptes enterprise ou partenaires.

### Contexte llm ecosystem

`llm` de Willison est devenu un outil de référence pour les développeurs qui veulent interagir avec plusieurs LLM via une interface CLI unifiée. Le plugin `llm-anthropic` est l'un des plugins les plus maintenus de l'écosystème. Cette mise à jour suit de près la sortie d'Opus 4.8 par Anthropic, ce qui confirme que Willison maintient une cadence de synchronisation rapide avec les releases Anthropic — généralement moins de 48h entre l'annonce du modèle et le support dans le plugin.

Pour les praticiens qui utilisent `llm` en production, la mise à jour vers 0.25.1 est recommandée, avec un audit préalable des scripts qui dépendent d'une longueur de sortie prévisible.