Platform Extensibility And Interface Taxonomy (Llm Hooks; Sync Vs Async Usage Patterns)

Issue 90 Edition 2026-03-31 4 min read

General

Sources: 1 • Confidence: High • Updated: 2026-04-12 10:22

Key takeaways

Enabling sync-to-async conversion required an additional LLM plugin hook mechanism that shipped in LLM 0.30.
The llm-mrchatterbox plugin is synchronous only.
The llm-all-models-async plugin converts synchronous models into asynchronous models using a thread pool.
Version 0.1 of the llm-all-models-async plugin has been released.
LLM plugins can define new models in both synchronous and asynchronous forms.

Enabling sync-to-async conversion required an additional LLM plugin hook mechanism that shipped in LLM 0.30.
LLM plugins can define new models in both synchronous and asynchronous forms.
Async model variants are usually used for API-backed models, while sync variants more often run the model directly inside the plugin.

The llm-mrchatterbox plugin is synchronous only.
Datasette can only use asynchronous models, which blocks use of sync-only plugins for features such as datasette-enrichments-llm.

The llm-all-models-async plugin converts synchronous models into asynchronous models using a thread pool.
Version 0.1 of the llm-all-models-async plugin has been released.

What are the latency, throughput, and resource-usage characteristics of thread-pool-based sync-to-async conversion under concurrent workloads (including risks like thread exhaustion)?
Which specific LLM 0.30 hook API enables this conversion, and what are its stability/compatibility guarantees across LLM versions?
Does the adapter preserve functional correctness for all sync model behaviors (streaming outputs, cancellation, timeouts, exception propagation), or are there known edge cases?
How many widely used LLM plugins are sync-only today, and which Datasette features are most impacted by the async-only requirement?
Is there any direct decision-readthrough (operator, product, or investor) stated in the corpus tied to these changes?

LLM 0.30 plugin hook changes may lower integration friction by enabling sync to async adapters, potentially increasing usable model options for async-only consumers like Datasette.
The llm-all-models-async adapter may unlock previously blocked sync-only plugins in async-only workflows, shifting usage from plugin rewrites to compatibility layers.
Version alignment may become a gating factor for plugin interoperability, with LLM 0.30 serving as a prerequisite for certain extensibility patterns.

Published latency, throughput, and resource-usage benchmarks for thread-pool sync to async conversion under concurrent workloads, including limits and mitigation for thread exhaustion.
Evidence of Datasette features successfully using formerly sync-only plugins via the adapter, with documented functional parity for streaming, cancellation, timeouts, and error handling.
Clear documentation that identifies the specific LLM 0.30 hook API used and states stability and compatibility expectations across future LLM versions.

Reports that thread-pool conversion degrades performance or reliability under load, such as thread exhaustion, high latency, or resource spikes that make it impractical in real deployments.
Known edge cases where the adapter breaks correctness for common behaviors like streaming outputs, cancellation, timeouts, or exception propagation, limiting applicability.
Upstream changes that alter or deprecate the LLM 0.30 hook API used for conversion, forcing frequent adapter updates or breaking compatibility.