LLM 0.32: Reasoning Traces, Server-Side Tools, and a Git-Style Log

Simon Willison shipped LLM 0.32 this week, and he's calling it the most significant update to his command-line LLM tool since the original launch. Four changes matter beyond the changelog: reasoning traces you can actually see, tools the model calls itself server-side, a rewritten log store, and a more structured Python API for streaming.

What shipped

• Visible reasoning traces — when you run LLM against a reasoning model, its "thinking" now streams to stderr by default, kept separate from the actual answer on stdout. A new -R/--hide-reasoning flag turns it off.
• Server-side provider tools — the llm-anthropic plugin adds WebSearch, WebFetch, CodeExecution, and AnthropicMCP (letting a single Claude call reach out over the Model Context Protocol mid-response). OpenAI's side gets a code-execution environment and web search, exposed through the Responses API.
• A content-addressable log store — logs are now modeled after Git's object store, so a long multi-turn conversation doesn't get its entire history re-serialized to JSON on every turn.
• New model support — the GPT-5.6 family, with gpt-5.6-luna as LLM's new default, and (via the companion llm-anthropic 0.26 release) the Claude 5 family, invoked with flags like -m claude-sonnet-5.

Why the plumbing matters more than the model list

New model support is expected with every release; the interesting part is what LLM 0.32 removes from your code. Server-side tools mean the model itself decides to search the web, fetch a page, run code, or make an MCP call — and does it inside the provider's own turn, not through a loop you wrote and now have to debug. If you've built an agent that calls out to a market-data API or a sentiment feed and then re-prompts the model with the result, this is the pattern providers are converging on: push the tool-call loop server-side and get a cleaner, auditable trace back instead of stitching it together yourself.

The logging rewrite is the quiet story

Content-addressable storage — the same idea behind Git — means identical message content is stored once and referenced, not duplicated every time a conversation grows by one turn. For anyone running LLM calls in a scheduled pipeline (research passes, report generation, agent loops that log every step for review), that's the difference between logs you can actually audit after a few thousand runs and a directory of near-duplicate JSON blobs. Paired with visible reasoning traces on a separate stream, it's a small but real upgrade for debugging *why* a model made a call, not just *what* it returned.

The takeaway for builders

None of this is flashy, and that's the point. Reasoning transparency, server-side tool execution, and sane logging are exactly the unglamorous primitives that separate a demo agent from one you'd trust running unattended — which is the whole premise of putting an LLM in a loop with real consequences, whether that's a trading signal, a compliance check, or a content pipeline. Tools like LLM won't run your production stack, but watching how their defaults evolve is a reasonable proxy for where the rest of the ecosystem is headed.