The Visible Change Is New Models, but the Real Change Is the Call Boundary
Simon Willison released llm 0.36 on September 22, 2026. It is a version update for a command-line tool and plugin ecosystem that works with multiple large language models. The release adds OpenAI’s `gpt-6-sol` and `gpt-6-luna`, corresponding to GPT-6 Sol and GPT-6 Luna. It also introduces a way for model plugins to declare conversational capabilities, changes how reasoning traces appear in logs, and includes fixes from five new contributors.
The model names are the most visible part of the release, but the supplied material contains no capability benchmarks, pricing data, or deployment comparison for them. That means the release does not support a claim of a major model leap. Its more consequential change is architectural. It addresses a distinction that unified interfaces often hide: accepting one prompt does not mean that a model can carry an ongoing conversation.
Single-Turn Models Finally Have an Explicit Interface Type
llm 0.36 allows a model plugin to declare `supports_conversation = False`. When such a model receives assistant-message history or tool-call history, LLM raises `llm.ConversationNotSupported`. When a user tries to use it through `llm chat`, the command rejects the request before starting a session instead of creating an apparently valid session that fails on the second request.
This mechanism does not add conversational capability to single-turn models. It describes their limitation more accurately. The model can still process an isolated prompt and response, but the caller cannot ask it to reuse earlier state or assume that it understands a history made from assistant and tool messages. For system designers, a hidden assumption that once depended on convention becomes an interface property that can be checked.
llm-typesafe Shows the Practical Risk Behind a Unified Entry Point
The first plugin to use this declaration is `llm-typesafe`. The material describes it as an integration for TypeSafe classification and scoring models, which accept single-turn prompts. Their task is to classify or score an input, not to maintain the context of an ongoing chat session. Automatically appending assistant or tool history has no obvious benefit and may change the input shape that the model expects.
This shows why a unified entry point should not be interpreted as proof that every backend has the same interaction semantics. A plugin telling the framework “I can be called” does not establish that it can accept conversational state, tool results, or assistant history. The value of `supports_conversation` is that it moves this declaration to the framework boundary. Callers can then distinguish a one-off inference from the creation of a genuine conversation.
Moving the Error Earlier Changes the Cost of Failure
Without a capability declaration, compatibility problems can travel deep into the call chain. A request may appear to have started successfully, only for the backend to fail once assistant history or tool history is attached because the input shape is unsupported. By that point, the failure may occur in the middle of a business flow. State may already have been written, resources may have been consumed, and a user may be waiting for a session that cannot complete.
The new mechanism moves the problem to two earlier points. A direct call receives the explicit `ConversationNotSupported` exception when unsupported history is supplied. The `llm chat` command rejects the model before the session begins. This does not eliminate every integration error, and it cannot prove that a plugin’s declaration is correct. It does reduce the room for disguising a single-turn interface as a chat interface. For teams integrating several models, that is easier to govern consistently than repeating manual checks at every business call site.
Collapsed Logs Show That Observability Also Needs Boundaries
Another change in llm 0.36 affects reasoning traces in Markdown-formatted logs. They are now wrapped in HTML `<details><summary>` tags. The traces have not been removed, and readers can still expand them, but the default reading path presents the main result first instead of allowing a long process trace to occupy the entire log. This is a change in information presentation, not a new claim about model capability.
The two changes operate at different layers, yet they reflect the same toolchain principle. The capability declaration controls which kinds of state may enter a model request. The collapsed trace controls which process information receives priority in a human reader’s view. Technical owners should not equate observability with simply recording more data. A more durable approach is to preserve what is needed for diagnosis while defining default exposure, pre-call checks, and failure behavior. The practical decision from llm 0.36 is clear: declare capability and reject the conversation path when integrating single-turn models, while retaining reasoning traces without letting them obscure the result.