datasette-llm 0.1a10 corrige un bug qui rétablissait des modèles exclus

datasette-llm 0.1a10 corrige un bug qui permettait au filtrage des modèles de rétablir des choix qu’un opérateur avait déjà exclus. Simon Willison a publié la mise à jour le 4 novembre 2026. Les notes de version décrivent une correction apportée aux listes blanches de modèles précédemment configurées, qui définissent les modèles autorisés par une application.

La tension se situe entre la configuration d’un opérateur et les choix qu’une application accepte réellement. Une liste de modèles restreinte ne vaut guère si un autre composant peut ensuite l’élargir. La pression immédiate concerne les développeurs qui combinent l’accès aux modèles, la comptabilité et les interfaces d’agents au sein d’un même déploiement.

LiteLLM, une passerelle qui assure l’accès aux fournisseurs d’IA, offre une comparaison utile quant à l’emplacement de ces contrôles dans les applications. Ici, le problème signalé concernait des filtres au sein d’une intégration de plugin Datasette. La version corrige une erreur précise de composition, tout en laissant aux responsables des déploiements le soin de vérifier leurs propres combinaisons.

Ce que change datasette-llm 0.1a10

La mise à jour préserve les exclusions lorsque des filtres de modèles fonctionnent ensemble. Cette version concerne donc le comportement de l’application, plutôt qu’un nouveau modèle, une amélioration de benchmark ou un catalogue de fournisseurs élargi.

La correction de composition des filtres du projet décrit la défaillance. Chaque hook de filtrage, une fonction d’extension qui modifie les choix disponibles, recevait la même liste initiale de modèles. Les listes renvoyées remplaçaient le résultat accumulé. Avec le plugin de comptabilité actif, son filtre de tarification pouvait rétablir des modèles exclus.

La pull request indique également que Datasette Agent proposait ces modèles et les acceptait lors de la création de conversations. Ce détail confère au problème une importance pratique au-delà d’un menu élargi de manière inattendue. Selon le projet, le décalage atteignait le comportement de création de conversations de l’application.

La correction croise les résultats par identifiant de modèle, en conservant les modèles qui passent les filtres applicables. Le projet fait état de 75 tests réussis et d’une vérification d’intégration utilisant les plugins de comptabilité et d’agent. Lors de cette vérification, un modèle exclu a reçu HTTP 400, une réponse d’erreur, tandis qu’un modèle autorisé a reçu HTTP 200, une réponse réussie.

Ces résultats constituent une validation rapportée par les mainteneurs. Ils étayent la correction annoncée sans établir que chaque déploiement ou combinaison de plugins tiers se comporte de façon identique. Ils donnent également aux opérateurs un comportement concret auquel comparer leurs installations.

La version modifie la relation entre les restrictions. Un composant qui évalue s’il peut comptabiliser un modèle ne devrait pas annuler silencieusement la décision d’un autre composant de l’exclure. Sinon, l’ajout d’une fonctionnalité opérationnelle modifie l’accès d’une manière que l’opérateur n’a pas demandée.

Cette distinction importe lors de l’évaluation de la portée de la mise à jour. Un modèle nouvellement disponible peut résulter d’un changement de configuration intentionnel. Le retour d’un modèle précédemment exclu parce qu’un autre filtre s’est exécuté plus tard produit un résultat différent, même si l’application continue de fonctionner.

Pour les lecteurs qui suivent cette version, le fait à retenir est l’interaction. L’erreur est apparue lorsque des composants individuellement utiles ont combiné leurs réponses. Considérer la sortie de chaque composant comme la réponse définitive permettait à une décision ultérieure d’écarter une restriction antérieure.

Cela explique pourquoi une version de maintenance limitée mérite l’attention des équipes qui utilisent des logiciels d’IA extensibles. Une installation réussie et une génération réussie ne démontrent pas que les restrictions ont survécu au parcours qui les sépare. La correction signalée concerne ce parcours.

L’implication pratique est précise : la disponibilité des modèles doit refléter toutes les restrictions applicables au moment où une application effectue son choix. Un fichier de configuration exprime une intention ; la combinaison en cours d’exécution détermine si les utilisateurs la constatent.

Les opérateurs font face à un écart entre accès configuré et accès effectif

Les responsables des déploiements assument les conséquences lorsque les restrictions prévues diffèrent de l’accès effectif. Les développeurs définissent l’intégration, mais les opérateurs choisissent les modèles qu’ils sont prêts à exposer.

La configuration des plugins de Datasette se trouve normalement sous des entrées de plugin dans son fichier de configuration. Cette organisation donne aux opérateurs un emplacement reconnaissable pour exprimer leurs réglages. Elle ne démontre pas, à elle seule, comment chaque extension combinera ces réglages pendant l’exécution.

Cette distinction ressemble à un problème opérationnel familier. Un document peut décrire correctement une politique alors qu’un logiciel l’implémente de manière incorrecte. Examiner le document établit ce qui a été demandé. Observer le comportement de l’application établit si la demande a pris effet.

Pour une démonstration publique, une sélection restreinte peut définir l’expérience prévue. Les visiteurs devraient voir les choix sélectionnés par son propriétaire. Si le comportement d’un plugin sans rapport élargit cette sélection, la démonstration ne correspond plus aux hypothèses de fonctionnement déclarées par son propriétaire.

Pour une application interne, ce raisonnement s’étend aux fournisseurs approuvés et aux flux de travail pris en charge. Une organisation pourrait délibérément limiter les choix aux modèles évalués par son équipe. Une disponibilité inattendue nécessiterait une enquête avant que quiconque puisse déterminer si une violation réelle de la politique s’est produite.

Il s’agit de conséquences potentielles, et non de résultats signalés pour cette version. La correction publique n’établit ni perte financière, ni exposition d’informations sensibles, ni utilisation non autorisée d’un fournisseur. Ces conclusions exigent des preuves concernant les requêtes, les identifiants et le déploiement affecté.

La question immédiate de l’opérateur change néanmoins. Avant la correction, une configuration restreinte pouvait coexister avec des choix effectifs plus larges dans l’interaction de plugins décrite. Après la mise à niveau, l’opérateur a besoin d’éléments démontrant que l’application en cours d’exécution correspond désormais aux restrictions prévues.

Ces éléments doivent refléter la combinaison installée. Le test isolé d’un développeur peut manquer un comportement introduit par une extension de comptabilité ou un autre composant de l’application. Le système pertinent comprend les composants qui participent à la requête réelle.

La charge organisationnelle traverse également les frontières entre équipes. La personne qui maintient la configuration peut ne pas maintenir l’interface de sélection des modèles. La personne qui ajoute la comptabilité peut raisonnablement supposer que la comptabilité ne peut pas élargir l’accès. Le défaut révèle l’importance de rendre cette hypothèse explicite.

Le propriétaire d’une application a donc besoin d’une définition partagée d’un choix de modèle approuvé. L’approbation concerne-t-elle ce qui apparaît dans l’interface, ce qu’une requête peut nommer, ou ce qui reçoit finalement un prompt ? Ces questions décrivent des observations liées mais distinctes.

Une réponse claire aide les équipes à éviter de débattre à partir d’éléments différents. Un responsable d’interface peut montrer un menu restreint tandis qu’un autre développeur découvre une requête acceptée en dehors de ce menu. Les deux observations peuvent être exactes, mais seule leur combinaison explique la limite effective.

La pression est immédiate pour les déploiements concernés et plus durable pour les auteurs de plugins. Les opérateurs ont besoin d’une correction vérifiée. Les développeurs ont besoin de règles de combinaison qui restent compréhensibles lorsqu’une autre extension rejoint l’application.

Pourquoi la combinaison de filtres exige une règle explicite

Un système de filtrage doit définir si les composants peuvent restreindre les choix, les élargir ou faire les deux. Sans cette règle, le mot « filtre » laisse subsister une ambiguïté lourde de conséquences.

Les modifications du filtrage des modèles mettent en œuvre une approche par intersection. En termes simples, un candidat doit passer les restrictions participantes. Un résultat ultérieur ne peut pas simplement remplacer le résultat restreint précédent par une collection plus large.

Considérons une application hypothétique avec un modèle approuvé et un modèle exclu. Son composant de politique n’autorise que le choix approuvé. Un composant de comptabilité distinct reconnaît les deux choix, car il sait mesurer leur utilisation.

La réponse de la comptabilité répond à une autre question. Savoir mesurer un modèle n’autorise pas son utilisation. Si l’application traite cette réponse comme un remplacement de la politique, la comptabilité devient accidentellement une décision d’accès.

Combiner les restrictions préserve cette distinction. L’application ne peut sélectionner un modèle que lorsque les composants pertinents conviennent qu’il reste disponible. Le composant de comptabilité apporte des informations utiles sans annuler l’exclusion de l’opérateur.

Cet exemple illustre la logique de la correction ; il ne constitue pas un incident supplémentaire signalé. Il explique également pourquoi une extension apparemment inoffensive peut modifier le comportement de l’application. Le problème réside dans la manière dont les réponses se combinent, sans exiger d’intention malveillante de la part d’un composant.

Une règle d’intersection crée une attente prudente. L’ajout d’un autre filtre restrictif devrait préserver les exclusions existantes ou réduire davantage la disponibilité. Il ne devrait pas rétablir un choix qu’un autre filtre applicable a supprimé.

Toutefois, une composition prudente soulève ses propres questions opérationnelles. Les filtres peuvent être en désaccord au point qu’aucun modèle ne reste disponible. Les applications ont besoin d’un comportement compréhensible dans ce cas, en particulier lorsqu’un utilisateur s’attend à démarrer une conversation.

Un résultat vide devrait susciter une enquête sur les restrictions pertinentes. Substituer silencieusement un modèle sans restriction compromettrait la raison même de combiner les filtres de manière prudente. Il s’agit d’une implication architecturale, et non d’une affirmation selon laquelle cette version ajoute une politique de repli particulière.

L’ordre importe également dans l’évaluation de la conception. Si modifier l’ordre d’enregistrement des plugins change les modèles restreints qui deviennent disponibles, les opérateurs font face à une politique instable. Une restriction ne devrait pas dépendre d’un détail d’installation qu’ils n’ont jamais eu l’intention d’utiliser comme paramètre d’autorisation.

Le point analytique plus large concerne les responsabilités. La découverte répond à la question des modèles que le logiciel connaît. La comptabilité répond à la question des modèles qu’un composant peut mesurer. L’autorisation répond à la question des choix qu’une application donnée permet.

Ces responsabilités peuvent partager des mécanismes d’implémentation sans devenir interchangeables. Les problèmes apparaissent lorsqu’une sortie créée pour une responsabilité devient silencieusement déterminante pour une autre. Des règles de composition explicites rendent ce transfert visible et vérifiable.

Pour les applications d’IA extensibles, la valeur de la correction dépasse donc la syntaxe d’une liste de modèles. Elle clarifie ce qu’un composant contributeur est autorisé à modifier. C’est le fondement nécessaire pour raisonner sur de futures combinaisons sans devoir reconstruire chaque interaction à partir de zéro.

Les contrôles des modèles se situent à différentes couches de l’application

Des outils comparables présentent des préoccupations similaires pour les opérateurs tout en plaçant l’application des règles dans différentes parties du système. L’architecture constitue donc une comparaison plus utile qu’une liste de fonctionnalités.

La documentation actuelle de gestion des modèles de datasette-llm décrit les listes globales de modèles, les modèles bloqués, les valeurs par défaut et la configuration spécifique à chaque usage. Elle documente également des points d’extension pour le filtrage et la gestion de l’utilisation. Comme il s’agit de la documentation de développement actuelle, elle ne doit pas automatiquement servir de spécification historique pour chaque version antérieure.

Les clés virtuelles de LiteLLM proposent une approche contrastée. Sa documentation décrit des contrôles d’accès aux modèles et un suivi de l’utilisation associés à des identifiants émis via un proxy, un service placé entre les clients et les fournisseurs.

La comparaison reste limitée. Ces sources n’établissent pas des garanties équivalentes, des exigences de déploiement identiques, ni une raison de remplacer un produit par un autre. Elles illustrent différents emplacements où exprimer et appliquer des restrictions.

Une intégration au niveau de l’application peut prendre des décisions au plus près de la tâche de l’utilisateur. Le logiciel qui l’entoure comprend pourquoi un modèle est sollicité. Cette proximité peut aider à relier le choix d’un modèle à l’interface ou au flux de travail qui le présente.

Une passerelle peut placer les contrôles à la frontière d’un service partagé. Les applications qui envoient des requêtes à travers cette frontière sont soumises à ses règles. La question architecturale est alors de savoir si toutes les requêtes concernées passent effectivement par le service censé les appliquer.

Aucun de ces emplacements ne dispense d’examiner la composition. Une application peut combiner incorrectement plusieurs restrictions locales. Un déploiement plus large peut aussi présenter des divergences entre ce que son application autorise et ce que son infrastructure partagée autorise.

La comparaison utile consiste donc à demander à quel endroit une décision devient contraignante. Un menu restreint constitue un indice sur la présentation. Un rejet par l’application constitue un indice sur le traitement des requêtes. Une requête adressée au fournisseur apporte une autre observation sur ce qui s’est finalement produit.

Distinguer ces observations aide les acheteurs à poser de meilleures questions. Une démonstration de changement de modèle ne prouve pas l’application effective des restrictions. Une capture d’écran de configuration ne montre pas si les composants ultérieurs préservent ses choix.

Les développeurs qui évaluent l’une ou l’autre approche devraient rechercher une attribution claire de la responsabilité des restrictions. Quel composant définit l’ensemble approuvé ? Quel composant peut le restreindre ? Dans quelles conditions documentées un autre composant peut-il introduire une exception ?

Ces questions restent pertinentes même lorsque les organisations utilisent plusieurs couches ensemble. Une application et une passerelle peuvent imposer des restrictions complémentaires. Leurs politiques doivent néanmoins être suffisamment claires pour qu’un opérateur puisse expliquer l’accès qui en résulte.

Pour les équipes qui conservent des éléments probants sur ces décisions, une base de connaissances consultable peut aider à préserver la justification des configurations et l’historique des revues. Cette documentation facilite l’enquête ; les contrôles à l’exécution établissent ce que l’application autorise réellement.

La version ne tranche pas un débat architectural. Elle fournit un exemple concret montrant pourquoi l’architecture retenue doit prévoir une règle explicite pour combiner les restrictions, quel que soit l’endroit où elles résident.

Ce que la correction établit, et ce qui reste non prouvé

Les éléments publics étayent un défaut précis et sa correction, tout en laissant sans réponse l’ampleur historique de l’incident. Cette distinction devrait orienter à la fois la couverture et la réponse opérationnelle.

La version et le dossier de développement associé décrivent des restrictions configurées qui étaient outrepassées. Ils décrivent également une réparation et des vérifications rapportées par le projet. Ensemble, ces éléments offrent une base plus solide qu’une affirmation non expliquée selon laquelle la sélection de modèles était incorrecte.

Ils n’établissent pas la fréquence à laquelle le comportement concerné s’est produit en usage réel. Une acceptation lors d’un contrôle de développement constitue un élément sur le comportement de l’application. Elle ne révèle ni le volume historique des requêtes ni tous les déploiements utilisant la combinaison de plugins concernée.

De même, une disponibilité plus large de modèles n’établit pas automatiquement que des prompts ont atteint un fournisseur non prévu. Cette conclusion exige des éléments sur les choix soumis par les utilisateurs et les requêtes qui ont abouti. Le dossier de version ne remplace pas les journaux de déploiement.

Il existe aussi une différence entre une exposition potentielle aux dépenses et une perte mesurée. Une restriction de modèle peut servir la politique d’utilisation d’un opérateur. La question de savoir si le bug a généré une consommation supplémentaire dans une installation donnée dépend de ce qui a réellement été exécuté.

La même prudence s’applique au traitement de l’information. Une destination inattendue serait importante si du contenu sensible l’avait atteinte. Les éléments de version disponibles n’établissent pas cette séquence, et l’article ne devrait pas transformer une conséquence possible en événement rapporté.

Ce cadrage plus étroit ne minimise pas la correction. Une restriction que le logiciel ne parvient pas à préserver mérite d’être réparée avant même que quelqu’un ne démontre des dommages en aval. La prévention et la mesure d’un incident répondent à des questions différentes.

La validation rapportée doit aussi être interprétée avec précision. Des tests réussis étayent le comportement que ces tests exercent. Un contrôle d’intégration ajoute des éléments concernant une combinaison particulière. Aucun des deux ne constitue un audit indépendant de chaque chemin au sein d’une application extensible.

Un lecteur sceptique peut donc accepter la correction tout en demandant une confirmation propre au déploiement. Cette position découle des éléments disponibles : le projet explique une défaillance plausible et la correction correspondante, tandis que les opérateurs conservent la responsabilité de leurs extensions installées.

Les étiquettes de version introduisent une autre distinction pratique. Un identifiant de version indique à un opérateur quelle compilation du paquet est présente. Il ne décrit pas chaque réglage local, modification de compatibilité ou plugin supplémentaire qui façonne le comportement final.

C’est pourquoi l’évaluation de datasette-llm 0.1a10 exige davantage que la présence de la version attendue dans un inventaire. La question pertinente est de savoir si l’application préserve ses restrictions prévues dans les conditions rencontrées par ses utilisateurs.

Le dossier public ne devrait pas non plus être étendu à un récit de sécurité plus large sans sources supplémentaires. Il n’établit ni exploitation publique, ni identifiant de vulnérabilité normalisé, ni évaluation indépendante. Ces affirmations exigeraient leurs propres éléments.

La conclusion défendable reste utile et exploitable. Les responsables du projet ont identifié une erreur de combinaison, modifié la manière dont les filtres interagissent et rapporté une validation. L’impact historique et l’assurance à l’échelle de l’ensemble des déploiements restent des sujets distincts à examiner.

À surveiller après la correction du filtrage des modèles

Les éléments de suivi les plus probants concerneront le maintien du comportement dans des déploiements réalistes. Au cours des prochains mois, trois signaux méritent une attention dans un ordre précis.

Premièrement, surveillez les rapports de déploiement montrant une concordance entre les restrictions prévues et les requêtes acceptées. Un rapport utile décrirait la combinaison de plugins concernée et distinguerait les choix visibles de ceux acceptés au démarrage d’une conversation.

De tels éléments renforceraient la confiance dans le fait que la correction atteint la frontière applicative rencontrée par les utilisateurs. Des rapports indiquant le retour de modèles exclus dans des conditions comparables affaibliraient cette confiance et identifieraient une interaction précise nécessitant une enquête supplémentaire.

Le signal important est un comportement reproductible, plutôt qu’une déclaration générale selon laquelle une mise à niveau a fonctionné. Les opérateurs ont besoin de suffisamment de contexte pour comprendre si une autre équipe a testé une configuration similaire ou une application sensiblement différente.

Deuxièmement, surveillez si les futures modifications des filtres préservent les exclusions lorsque des extensions sont combinées. Une correction peut rester efficace aujourd’hui tandis qu’une fonctionnalité ultérieure introduit un nouveau chemin avec des hypothèses différentes. Les modifications touchant à la découverte des modèles, à la comptabilisation ou à la sélection justifient une attention particulière.

Des éléments montrant que ces combinaisons conservent des restrictions prévisibles renforceraient la crédibilité de la conception. Des éléments indiquant que l’ordre d’enregistrement ou une extension supplémentaire élargit l’accès remettraient en cause l’attente créée par la réparation.

Ce signal concerne la discipline de maintenance plutôt que la fréquence des versions. Davantage de versions ne signifient pas intrinsèquement un meilleur contrôle. Des explications claires sur les changements de comportement donnent aux opérateurs une base plus solide pour décider de ce qui nécessite un nouveau contrôle de déploiement.

Troisièmement, surveillez une documentation qui facilite la compréhension des résultats vides, des exceptions et des frontières de responsabilité. Les opérateurs devraient pouvoir expliquer pourquoi un modèle est disponible sans devoir deviner quel composant a fourni la réponse décisive.

Une documentation plus claire renforcerait la confiance dans l’utilisabilité du système. Des explications contradictoires l’affaibliraient, en particulier si les auteurs d’applications ne peuvent pas déterminer si un composant se contente de découvrir les modèles ou autorise leur utilisation.

Pour les acheteurs de produits d’IA, ces signaux offrent une manière pratique d’évaluer les affirmations relatives au contrôle des modèles. Demandez des éléments établissant un lien entre une restriction annoncée et une requête rejetée. Demandez ensuite quels composants installés ont participé à cette décision.

Pour les développeurs, l’enjeu durable est la composabilité : la capacité de composants utiles indépendamment à conserver leur comportement prévu lorsqu’ils sont combinés. Les intégrations de modèles ont besoin de cette propriété, car la sélection, la mesure de l’utilisation et les interfaces applicatives partagent souvent le même flux de requêtes.

La version fournit une correction concrète à examiner, sans étayer d’affirmations sur un taux de défaillance à l’échelle du secteur ou une solution universelle. Son importance repose sur la spécificité de la défaillance et la clarté de la règle modifiée.

Si votre application dépend de choix de modèles restreints, comparez sa politique prévue avec son comportement actuel avant de considérer la mise à niveau comme terminée. Conservez ensemble la configuration pertinente, les versions des plugins installés et les résultats observés afin qu’un autre responsable de maintenance puisse comprendre la décision. Incluez un choix exclu dans ces éléments, car une requête autorisée réussie ne répond qu’à une partie de la question. Utilisez la correction de datasette-llm 0.1a10 comme une raison d’examiner comment vos propres composants combinent leurs décisions. Le résultat utile est un lien documenté entre ce que votre équipe autorise et ce que l’application en cours d’exécution accepte. Commencez par la restriction dont votre déploiement dépend le plus et vérifiez qu’elle survit à l’ensemble du cheminement de la requête.