datasette-llm 0.1a10 Fixes a Bug That Restored Excluded Models

datasette-llm 0.1a10 fixes a bug that let model filtering restore choices an operator had already excluded. Simon Willison released the update on November 4, 2026. The release notes describe a correction to previously configured model allowlists, the lists defining which models an application permits.

The tension sits between an operator’s configuration and the choices an application actually accepts. A restricted model list means little if another component can expand it later. The immediate pressure falls on developers combining model access, accounting, and agent interfaces within the same deployment.

LiteLLM, a gateway that mediates access to AI providers, offers a useful comparison for where applications place these controls. Here, the reported problem involved filters inside a Datasette plugin integration. The release addresses a specific composition error, while leaving deployment owners responsible for checking their own combinations.

What datasette-llm 0.1a10 changes

The update preserves exclusions when model filters work together. That makes this release about application behavior rather than a new model, a benchmark improvement, or an expanded provider catalog.

The project’s filter composition fix describes the failure. Each filtering hook, an extension function that modifies available choices, received the same initial model list. Returned lists replaced the accumulated result. With the accounting plugin active, its pricing filter could restore excluded models.

The pull request also says Datasette Agent offered those models and accepted them when creating conversations. That detail gives the issue practical significance beyond an unexpectedly broad menu. According to the project, the mismatch reached the application’s conversation creation behavior.

The correction intersects results by model identifier, retaining models that survive the applicable filters. The project reports 75 passing tests and an integration check using accounting and agent plugins. In that check, an excluded model received HTTP 400, an error response, while an allowed model received HTTP 200, a successful response.

Those results are maintainer-reported validation. They support the stated repair without establishing that every deployment or third-party plugin combination behaves identically. They also give operators a concrete behavior to compare against their installations.

The release changes the relationship between restrictions. A component assessing whether it can account for a model should not silently cancel another component’s decision to exclude it. Otherwise, adding an operational feature changes access in a way the operator did not request.

This distinction matters when evaluating the update’s scope. A newly available model can be an intentional configuration change. A previously excluded model returning because another filter ran later is a different outcome, even when the application continues functioning.

For readers following the release, the memorable fact is the interaction. The error appeared where individually useful components combined their answers. Treating each component’s output as the final answer allowed a later decision to displace an earlier restriction.

That explains why a narrow maintenance release deserves attention from teams using extensible AI software. Successful installation and successful generation do not establish that restrictions survived the journey between them. The reported correction concerns that journey.

The practical implication is specific: model availability needs to reflect all applicable restrictions at the point where an application makes its choice. A configuration file expresses intent; the running combination determines whether users experience it.

Operators face a gap between configured and effective access

Deployment owners carry the consequences when intended restrictions differ from effective access. Developers define the integration, but operators choose the models they are prepared to expose.

Datasette’s plugin configuration normally lives under plugin entries in its configuration file. That arrangement gives operators a recognizable place to express settings. It does not, by itself, demonstrate how every extension will combine those settings during execution.

The distinction resembles a familiar operational problem. A document can accurately describe a policy while software implements it incorrectly. Reviewing the document establishes what was requested. Observing application behavior establishes whether the request took effect.

For a public demonstration, a restricted selection can define the intended experience. Visitors should encounter the choices its owner selected. If unrelated plugin behavior expands that selection, the demonstration stops matching its owner’s stated operating assumptions.

For an internal application, the reasoning extends to approved providers and supported workflows. An organization might deliberately limit choices to models its team has evaluated. Unexpected availability would require investigation before anyone could determine whether an actual policy violation occurred.

These are potential consequences, not reported outcomes from this release. The public correction does not establish financial loss, sensitive information exposure, or unauthorized provider use. Those conclusions require evidence about requests, credentials, and the affected deployment.

Still, the operator’s immediate question changes. Before the fix, a narrow configuration could coexist with broader effective choices under the described plugin interaction. After upgrading, the operator needs evidence that the running application now matches the intended restrictions.

That evidence has to reflect the installed combination. A developer’s isolated test can miss behavior introduced by an accounting extension or another application component. The relevant system includes the components that participate in the real request.

The organizational burden also crosses team boundaries. Someone maintaining configuration may not maintain the model selection interface. Someone adding accounting may reasonably assume that accounting cannot broaden access. The defect exposes the importance of making that assumption explicit.

An application owner therefore needs a shared definition of an approved model choice. Does approval concern what appears in the interface, what a request can name, or what ultimately receives a prompt? Those questions describe related but distinct observations.

A clear answer helps teams avoid arguing from different evidence. An interface owner can show a restricted menu while another developer finds an accepted request outside that menu. Both observations can be accurate, yet only their combination explains the effective boundary.

The pressure is immediate for affected deployments and longer lasting for plugin authors. Operators need a verified correction. Developers need combination rules that remain understandable when another extension joins the application.

Why combining filters requires an explicit rule

A filtering system needs to define whether components can narrow choices, expand them, or do both. Without that rule, the word “filter” leaves a consequential ambiguity.

The model filtering changes implement an intersection approach. In plain language, a candidate must survive the participating restrictions. A later result cannot simply replace the earlier restricted result with a broader collection.

Consider a hypothetical application with an approved model and an excluded model. Its policy component permits only the approved choice. A separate accounting component recognizes both choices because it knows how to measure their usage.

The accounting answer addresses a different question. Knowing how to measure a model does not authorize its use. If the application treats that answer as a replacement for policy, accounting accidentally becomes an access decision.

Combining the restrictions preserves the distinction. The application can select a model only when the relevant components agree it remains available. The accounting component contributes useful information without undoing the operator’s exclusion.

That example illustrates the logic of the repair; it is not an additional reported incident. It also explains why an apparently harmless extension can change application behavior. The problem lies in how answers combine, rather than requiring malicious intent from a component.

An intersection rule creates a conservative expectation. Adding another restrictive filter should preserve existing exclusions or reduce availability further. It should not restore a choice that another applicable filter removed.

However, conservative composition introduces its own operational questions. Filters can disagree so completely that no model remains. Applications need understandable behavior for that outcome, especially when a user expects to start a conversation.

An empty result should prompt investigation into the relevant restrictions. Quietly substituting an unrestricted model would undermine the reason for combining filters conservatively. That is an architectural implication, not a claim that this release adds a particular fallback policy.

Order also matters when assessing the design. If changing plugin registration order changes which restricted models become available, operators face an unstable policy. A restriction should not depend on an installation detail they never intended as an authorization setting.

The broader analytical point is about responsibility. Discovery answers which models the software knows about. Accounting answers which models a component can measure. Authorization answers which choices a particular application permits.

These responsibilities can share implementation machinery without becoming interchangeable. Problems emerge when an output created for one responsibility silently becomes authoritative for another. Explicit composition rules make that transfer visible and reviewable.

For extensible AI applications, the value of the correction therefore exceeds the syntax of a model list. It clarifies what a contributing component is allowed to change. That is the foundation for reasoning about future combinations without reconstructing every interaction from scratch.

Model controls sit at different application layers

Comparable tools expose similar operator concerns while placing enforcement in different parts of the system. That makes architecture a more useful comparison than a feature checklist.

The current datasette-llm model management documentation describes global model lists, blocked models, defaults, and purpose-specific configuration. It also documents extension points for filtering and usage handling. Because this is the current development documentation, it should not automatically serve as a historical specification for every earlier release.

LiteLLM’s virtual keys provide a contrasting arrangement. Its documentation describes model access controls and usage tracking associated with credentials issued through a proxy, a service positioned between clients and providers.

The comparison is limited. These sources do not establish equivalent guarantees, identical deployment requirements, or a reason to replace one product with another. They illustrate different locations for expressing and applying restrictions.

An application-level integration can make decisions close to the user’s task. Its surrounding software understands why a model is being requested. That proximity can help connect a model choice to the interface or workflow presenting it.

A gateway can place controls at a shared service boundary. Applications that send requests through that boundary encounter its rules. The architectural question becomes whether all relevant requests actually travel through the service expected to enforce them.

Neither location removes the need to examine composition. An application can combine several local restrictions incorrectly. A broader deployment can also have mismatches between what its application permits and what its shared infrastructure permits.

The useful comparison therefore asks where a decision becomes binding. A restricted menu is evidence about presentation. An application rejection is evidence about request handling. A provider request supplies another observation about what ultimately happened.

Keeping those observations distinct helps buyers ask better questions. A demonstration of model switching does not establish enforcement. A configuration screenshot does not show whether later components preserve its choices.

Developers evaluating either approach should look for clear ownership of restrictions. Which component defines the approved set? Which component can narrow it? Under what documented conditions can another component introduce an exception?

Those questions remain relevant even when organizations use several layers together. An application and a gateway can impose complementary restrictions. Their policies still need enough clarity for an operator to explain the resulting access.

For teams maintaining evidence about these decisions, a searchable knowledge base can help preserve configuration rationale and review history. That documentation supports investigation; runtime checks establish what the application actually allows.

The release does not settle an architectural contest. It supplies a concrete example of why the chosen architecture needs an explicit rule for combining restrictions, wherever those restrictions live.

What the fix establishes, and what remains unproven

The public evidence supports a specific defect and correction, while leaving the incident’s historical scope unresolved. That distinction should guide both coverage and operational response.

The release and linked development record describe configured restrictions being overridden. They also describe a repair and project-reported checks. Together, those materials provide a stronger basis than an unexplained claim that model selection was wrong.

They do not establish how often the affected behavior occurred in live use. Acceptance during a development check is evidence about application behavior. It does not reveal historical request volume or identify every deployment with the relevant plugin combination.

Likewise, broader model availability does not automatically establish that prompts reached an unintended provider. That conclusion requires evidence about which choices users submitted and which requests completed. The release record is not a substitute for deployment records.

There is also a difference between potential spending exposure and measured loss. A model restriction can serve an operator’s usage policy. Whether the bug produced additional consumption in a particular installation depends on what actually ran.

The same care applies to information handling. An unexpected destination would matter if sensitive content reached it. The available release evidence does not establish that sequence, and the article should not turn a possible consequence into a reported event.

This narrower framing does not minimize the correction. A restriction that software fails to preserve deserves repair even before someone demonstrates downstream damage. Prevention and incident measurement answer different questions.

The reported validation should also be read precisely. Passing tests support the behavior those tests exercise. An integration check adds evidence about a particular combination. Neither constitutes an independent audit of every route through an extensible application.

A skeptical reader can therefore accept the fix while asking for deployment-specific confirmation. That position follows the evidence: the project explains a plausible failure and corresponding correction, while operators retain responsibility for their installed extensions.

Version labels introduce another practical distinction. A release identifier tells an operator which package build is present. It does not describe every local setting, compatibility change, or additional plugin shaping the final behavior.

That is why evaluating datasette-llm 0.1a10 requires more than seeing the expected version in an inventory. The relevant question is whether the application preserves its intended restrictions under the conditions its users encounter.

The public record also should not be stretched into a broader security narrative without additional sourcing. It does not establish public exploitation, a standardized vulnerability identifier, or an independent assessment. Those claims would require their own evidence.

The defensible conclusion remains useful and actionable. The maintainers identified a combination error, changed how filters interact, and reported validation. Historical impact and deployment-wide assurance remain separate subjects for investigation.

What to watch after the model filtering fix

The strongest follow-up evidence will concern preserved behavior across realistic deployments. Over the coming months, three signals deserve attention in a specific order.

First, watch for deployment reports showing agreement between intended restrictions and accepted requests. A useful report would describe the relevant plugin combination and distinguish visible choices from choices accepted when starting a conversation.

Such evidence would strengthen confidence that the correction reaches the application boundary users encounter. Reports of excluded models returning under comparable conditions would weaken that confidence and identify a specific interaction requiring further investigation.

The important signal is repeatable behavior, rather than a general statement that an upgrade worked. Operators need enough context to understand whether another team tested a similar configuration or a substantially different application.

Second, watch whether future filter changes preserve exclusions when extensions combine. A correction can remain effective today while a later feature introduces a new path with different assumptions. Changes involving model discovery, accounting, or selection warrant particular scrutiny.

Evidence that these combinations retain predictable restrictions would strengthen the design’s credibility. Evidence that registration order or an additional extension broadens access would challenge the expectation established by the repair.

This signal concerns maintenance discipline rather than release frequency. More releases do not inherently mean better control. Clear explanations of changed behavior give operators a firmer basis for deciding what requires another deployment check.

Third, watch for documentation that makes empty results, exceptions, and responsibility boundaries easy to understand. Operators should be able to explain why a model is available without guessing which component supplied the decisive answer.

Clearer documentation would strengthen confidence in the system’s usability. Conflicting explanations would weaken it, especially if application authors cannot determine whether a component merely discovers models or authorizes their use.

For AI product buyers, these signals offer a practical way to assess model control claims. Ask for evidence connecting a stated restriction to a rejected request. Then ask which installed components participated in that decision.

For developers, the enduring issue is composability: whether independently useful components retain their intended behavior when combined. Model integrations need that property because selection, usage measurement, and application interfaces often share the same request flow.

The release provides a concrete correction to examine, without supporting claims about an industry-wide failure rate or a universal solution. Its significance rests on the specificity of the failure and the clarity of the changed rule.

If your application depends on restricted model choices, compare its intended policy with its current behavior before treating the upgrade as complete. Keep the relevant configuration, installed plugin versions, and observed results together so another maintainer can understand the decision. Include an excluded choice in that evidence, since a successful allowed request answers only part of the question. Use the datasette-llm 0.1a10 correction as a reason to examine how your own components combine their decisions. The useful outcome is a documented connection between what your team permits and what the running application accepts. Start with the restriction your deployment most depends on, and verify that it survives the full request path.