LLM 0.32 adds reasoning traces and agent primitives to the Python CLI

Simon Willison shipped LLM 0.32 on August 4, 2026, calling it the most significant release since launch. The update adds server-side provider tools from OpenAI and Anthropic, surfaces reasoning traces to stderr, restructures the Python API around typed message objects, and redesigns the SQLite log using Git's content-addressable schema — all driven by real requirements from Datasette Agent, Willison's own agentic project. Willison's summary: "I guess LLM is an agent framework now."

For CLI users, the most visible change is reasoning trace output. Models that expose chain-of-thought now stream it to stderr, keeping piped stdout clean. The flag `-R/--hide-reasoning` suppresses it. The default model has shifted from GPT-4o mini to GPT-5.6 Luna, with Luna, Sol, and Terra variants available out of the box. OpenAI users on the Responses API can now choose between `service_tier` `fast` (higher cost, lower latency) and `flex` (cheaper, slower) per prompt.

Server-side tools are the headline agentic primitive. OpenAI exposes two: `CodeInterpreter` and `WebSearch`, invoked via `-T CodeInterpreter` or `-T WebSearch`. The `llm-anthropic` plugin at version 0.26 offers four: WebSearch, WebFetch, CodeExecution, and AnthropicMCP. The last is architecturally distinct — passing `-T 'AnthropicMCP("https://your-datasette/-/mcp")'` causes Anthropic's API to execute MCP calls against a remote server inside the request/response cycle with no separate client-side loop. This matters: vendor-hosted tool execution means latency and retry logic run in the provider's infrastructure, not yours.

The Python API replaces the old conversation object pattern with `model.prompt(messages=[])`, which accepts a full list of typed `Message` objects built with `llm.user()`, `llm.assistant()`, and `llm.system()` constructors. The old API masked the stateless nature of LLM services; the new one is transparent about what goes over the wire. `response.stream_events()` replaces the previous string-iterable interface with a typed event stream carrying `reasoning`, `text`, tool call, and attachment events in a single loop. The `llm.PauseChain` exception halts the loop for human approval; the chain can resume later from message history without re-executing completed calls.

The logging overhaul is operationally significant. The old schema logged full conversation JSON on every turn — a 10-turn session duplicated the growing history 10 times. The new schema is content-addressed: messages are stored once by SHA hash and referenced from a `turns` table, like Git blobs. Legacy `responses` table records stay untouched; `llm logs` handles both schemas. Before upgrading, the changelog recommends running `llm logs backup logs-backup.db` for anyone running LLM as a long-running daemon with a large log.

Two new commands ship with the release. `llm openai endpoint <url>` runs a one-off prompt against any OpenAI-compatible endpoint without a configured plugin — useful for local models via LM Studio or Ollama, and not logged. `llm chat-completions-server --port 9000` spins up a local OpenAI-compatible REST server backed by LLM's full plugin registry, letting any OpenAI SDK client route through it.

The cost: plugins providing custom models must upgrade to the 0.32 API to support the new streaming events system. Plugin authors must implement structured messages and the `stream_events()` interface. Willison notes that `llm-gemini`, `llm-openrouter`, and `llm-mistral` updates are nearly complete; until they ship, those backends won't expose reasoning traces or typed event streams.

For teams using LLM in production pipelines, the content-addressed log schema and the `response.to_dict()` / `Response.from_dict()` persistence API merit immediate evaluation — they're foundational for reliable multi-turn agent state.