Rosa Del Mar

Daily Brief

Issue 84 2026-03-25

Release Milestone And New Extension Surface

Issue 84 Edition 2026-03-25 5 min read
General
Sources: 1 • Confidence: High • Updated: 2026-04-13 03:53

Key takeaways

  • datasette-llm version 0.1a1 has been released.
  • Dependent plugins can request a model by purpose via an API (for example purpose="enrichment") and can register their purpose strings via register_llm_purposes() to enable centralized purpose listings for features such as an admin UI.
  • datasette-llm is a base plugin that makes models from the LLM project available to other Datasette plugins, including datasette-enrichments-llm.
  • datasette-llm 0.1a1 adds a register_llm_purposes() plugin hook and a get_purposes() function to retrieve registered purpose strings.
  • datasette-llm centrally configures which models are used for different purposes, such as data enrichment versus SQL query assistance.

Sections

Release Milestone And New Extension Surface

  • datasette-llm version 0.1a1 has been released.
  • datasette-llm 0.1a1 adds a register_llm_purposes() plugin hook and a get_purposes() function to retrieve registered purpose strings.

Centralized Purpose-Based Model Routing

  • Dependent plugins can request a model by purpose via an API (for example purpose="enrichment") and can register their purpose strings via register_llm_purposes() to enable centralized purpose listings for features such as an admin UI.
  • datasette-llm centrally configures which models are used for different purposes, such as data enrichment versus SQL query assistance.

Shared Base Layer For Llm-Enabled Plugin Ecosystem

  • Dependent plugins can request a model by purpose via an API (for example purpose="enrichment") and can register their purpose strings via register_llm_purposes() to enable centralized purpose listings for features such as an admin UI.
  • datasette-llm is a base plugin that makes models from the LLM project available to other Datasette plugins, including datasette-enrichments-llm.

Unknowns

  • What is the concrete configuration format and precedence model for mapping purposes to models (e.g., where it lives, how overrides work, and how defaults are chosen)?
  • What standardized purpose strings exist or are recommended, and how are naming collisions or conflicting semantics across plugins handled?
  • Which models from the LLM project are supported through datasette-llm in practice, and what are the operational constraints (latency, quotas, cost visibility) exposed to administrators?
  • Is there an implemented admin UI (or equivalent management surface) that consumes get_purposes(), and how widely is it used in real deployments?
  • What are the security and governance controls associated with purpose-based model selection (e.g., preventing unapproved purposes/models, logging/auditing by purpose)?

Investor overlay

Read-throughs

  • Purpose based model routing could lower integration friction across Datasette plugins, increasing adoption of an LLM enabled plugin ecosystem if configuration is clear and centrally managed.
  • A standardized purpose registry may enable admin tooling such as UIs and governance features, suggesting a pathway to enterprise readiness if the ecosystem converges on shared purpose strings.
  • Positioning datasette-llm as a base layer could concentrate model access and configuration, implying downstream plugins may align on this interface rather than bespoke LLM integrations.

What would confirm

  • Documentation of configuration format and precedence for mapping purposes to models, including defaults and override behavior across deployments.
  • Evidence of ecosystem adoption such as multiple plugins using purpose requests and registering purposes, plus a discoverable list via get_purposes in real deployments.
  • An implemented admin management surface consuming get_purposes, alongside stated controls for security, auditing, and cost or quota visibility by purpose.

What would kill

  • No clear or stable configuration and precedence model emerges, causing downstream plugins to hard code models or implement parallel configuration paths.
  • Purpose strings fragment or collide across plugins with no recommended standards, reducing interoperability and limiting usefulness of centralized listings.
  • Operational constraints such as latency, quotas, or cost visibility are not exposed to administrators, limiting deployment beyond experimentation.

Sources

  1. 2026-03-25 simonwillison.net