datasette-llm plugin 0.1a9 drops manual model configuration to run Datasette Agent

New version of the datasette-llm plugin, released on October 31, 2026, now uses the default model already configured in LLM, eliminating a manual step for those who want to test Datasette Agent locally.

Simon Willison, creator of Datasette and the LLM command-line tool, announced the release of datasette-llm 0.1a9 on his personal blog on October 31, 2026. It's a small release, a one-line change, but one that removes real friction for anyone who wants to try Datasette Agent without reading the documentation first.

What datasette-llm is (and why it's just the glue)

datasette-llm is not a plugin you use directly. Willison himself describes it as an "LLM integration plugin for other plugins to depend on." In practice, it's the layer that connects Datasette (Willison's SQLite data viewer and publisher) to the LLM library (his CLI and Python SDK for talking to language models, whether local or via API).

The one depending on this glue today is Datasette Agent, the ecosystem's newest plugin, which gives Datasette an agentic interface capable of exploring a database, writing queries, and answering questions about its content. Without datasette-llm, the Agent wouldn't know who to ask; without the Agent, datasette-llm would have no practical reason to exist on its own.

The concrete change in version 0.1a9

Before this version, bringing up Datasette Agent required explicitly declaring which model to use, via a configuration flag in Datasette itself:

uvx --with datasette-agent datasette content.db --internal internal.db -s plugins.datasette-agent.default_model gpt-6-astra

With datasette-llm 0.1a9, that step is no longer required. The plugin now reads the default model already configured in the local LLM installation and uses that same value for the Agent, without requiring the -s flag:

uvx --with datasette-agent datasette content.db --internal internal.db

It's the difference between needing to know the exact identifier of a model ahead of time (gpt-6-astra, in Willison's own example) and simply running the command, trusting that the environment already has a preference configured.

Where this "default model" comes from

The mechanism isn't new: the LLM tool already has the concept of a default model for the CLI, used whenever no model is explicitly specified in a call. Willison's post doesn't detail the exact syntax for configuring that default, it only confirms that datasette-llm now reads that value already present in the local LLM installation.

What datasette-llm 0.1a9 does is simply stop ignoring that configuration. Instead of Datasette Agent loading its own isolated default value (and requiring someone to declare it again, specifically for the plugin, via -s plugins.datasette-agent.default_model), it now inherits what's already set in LLM. A single source of truth for "which model do I use by default," instead of two.

I have some big upgrades to Datasette Agent in the pipeline, but in the meantime here's a tiny user experience improvement to the underlying datasette-llm plugin.

Simon Willison, creator of Datasette and LLM

The rest of the command nobody notices

It's worth breaking down the full command, because it packs in a good chunk of the stack this audience already uses. uvx is a tool from Astral's uv package manager, which runs a Python package in a temporary environment without needing to install it globally or create a venv manually. The --with datasette-agent flag injects the Agent plugin into that ephemeral environment, just for that run.

--internal internal.db, in turn, points to a separate SQLite database for internal plugin state, a mechanism built into Datasette itself for plugins that need to write data (such as an agent's conversation history) without mixing it with the content database being queried (content.db, in the example). It's this internal database that lets Datasette Agent keep context across interactions without polluting the data the user is actually exploring.

Why this matters for people building with data locally

In short: the gain here isn't new capability, it's less friction on first contact. For those who already use llm daily (for example, to run quick questions in the terminal or integrate models into a Python script), running Datasette Agent is now a natural extension of what's already configured, instead of a parallel system with its own flag and its own default model.

This is relevant to the usage pattern Willison has been describing in recent LLM and Datasette releases: fast, local experimentation on SQLite data, without depending on infrastructure beyond the developer's own machine. A shorter command reduces the odds of someone abandoning the test at the first configuration error, something that weighs heavily on voluntary-adoption tools like this one.

The limits: it's UX, not a new capability

The version number already signals what to expect: 0.1a9 is an alpha, its ninth iteration. There's no change to the Agent's behavior itself, no answer-quality benchmark, no guarantee of API stability between alpha versions. Anyone relying on reproducibility in production should treat this integration as unstable until Willison himself signals a stable release.

Nothing changes regarding cost or credentials either: LLM's default model still needs to be configured with a valid API key (or point to a local model, via one of LLM's provider plugins) before any run will actually work. The change eliminates a redundant flag, not the work of configuring access to the model itself.

The post itself makes clear this is just the appetizer: Willison mentions "big upgrades" to Datasette Agent still in the pipeline, without detailing what they are. For those following the ecosystem, it's worth keeping an eye on the plugin's upcoming releases rather than treating this version as the tool's final state.