LLM 0.32: visible reasoning traces, server-side tools, and Git-style logs
LLM, Simon Willison’s CLI and Python framework for working with models, reaches version 0.32. Willison describes it as the most important release since the project began. Three converging directions: inspectable reasoning traces, server-side tools, and content-addressable logs on SQLite.
Why it matters to you. If you’re building agents, these features solve concrete problems. Reasoning models now send their thinking trace to stderr, separate from output: you can pipe the result into another tool without carrying the reasoning along. Server-side tools let you delegate capabilities to the provider instead of implementing them yourself: OpenAI offers code execution and web search, the llm-anthropic plugin adds web search, code execution, and most importantly AnthropicMCP, which executes MCP calls directly at the provider within a single request. SQLite logs rewritten in Git style save each message once only, referencing it by hash instead of duplicating the entire history at each conversation turn.
The default model becomes GPT-5.6 Luna, the cost-effective variant of the GPT-5.6 family that by late July had already dropped to $0.20 per million tokens. The llm openai endpoint command executes one-off prompts against any OpenAI-compatible API, even a local model in LM Studio, without installing LLM.
Willison writes that many changes were guided by Datasette Agent, his agent project. “I’m imagining LLM as a framework for agents now,” concludes the post.
In detail
What came before. LLM began as a CLI wrapper for calling models from the terminal and tracking them in SQLite. In recent months the landscape changed: models do internal reasoning before answering, return tool calls instead of just text, and multi-turn conversations became the standard schema for agents. LLM 0.32 rewrites the architecture to follow this evolution.
Reasoning traces. When you call a reasoning model, it produces “thinking” text before the response. Before, LLM didn’t handle this text distinctly. Now it sends it to stderr and keeps stdout clean for the response. This separation matters: if you use LLM inside a shell pipeline, reasoning doesn’t pollute the result. The -R / --hide-reasoning flag suppresses it entirely.
Server-side tools. Until now tools in LLM ran client-side: your code executed the function and returned the result to the model. Now LLM supports tools that the provider executes directly. The most interesting example is AnthropicMCP: you pass an MCP endpoint and Anthropic calls it within the same API request, without your code acting as intermediary.
Willison shows it with a command that asks Claude how many rows are in a table, having Anthropic execute the MCP calls against a Datasette server. In a single request and response, the model queries the database and answers.
Content-addressable logs. The problem: in a multi-turn conversation, each request carries all the history of previous messages with it. If you log every request, you duplicate the same JSON at each turn. The new architecture saves each message once only, with a hash identifying it, like Git does with blobs. The llm logs and llm logs --json commands reconstruct the readable view from the content-addressable format. For those running agents with long contexts, disk space stops growing quadratically.
Python API. Two changes. The messages=[] parameter lets you pass the entire history in one call, instead of creating a conversation and sending messages one at a time. The stream_events() method returns typed events (reasoning, text, others) instead of a sequence of strings, because models today return heterogeneous content: text, reasoning, tool calls, attachments.
Compatibility. Existing plugins continue to work, but those providing extra models need updating to 0.32 to support the new streaming events system. llm-anthropic 0.26 is already ready with Claude 5 models. llm-gemini, llm-openrouter, and llm-mistral are coming.
Limitations. The llm openai endpoint command doesn’t log requests: useful for one-off prompts, but you lose traceability if you use it in a repetitive flow. The llm-chat-completions-server plugin implements OpenAI’s semi-standard API, but “semi” is significant: compatibility isn’t guaranteed on every client. Server-side tools depend on what the provider offers: no portability between OpenAI and Anthropic on the same capabilities.