.png)
Simon Willison released LLM 0.32, the most significant new version of the tool since the project launched. The release adds visible reasoning traces, OpenAI Responses API support, server-side tools, redesigned logging, and broader provider integration through the llm-anthropic plugin.
The biggest user-facing change is how LLM handles reasoning models. When a model returns reasoning traces, LLM now prints them to standard error instead of standard output. That matters because it keeps the reasoning visible to the operator without contaminating the stream you might pipe into another command.
That design choice fits the CLI use case well. If you are composing llm with other Unix tools, the model’s final answer stays clean on stdout while the trace remains available for inspection. LLM also adds -R / --hide-reasoning if you want to suppress those traces entirely.
This is a pragmatic default. It makes reasoning models easier to debug in interactive use and safer to compose in automation, without forcing trace visibility into every downstream consumer.
LLM 0.32 adds support for the OpenAI Responses API, which is now the interface OpenAI is steering developers toward for agentic workloads. That opens the door to newer model capabilities and the provider-side tool surface that the Responses API exposes.
The release also ships built-in support for the GPT-5.6 family. The default model used by llm prompt is now GPT-5.6 Luna, which Simon describes as inexpensive but capable. For anyone using llm as a quick local-or-remote prompt runner, that default matters: it changes the cost/performance balance of the zero-config path.
If you are already integrating with OpenAI through application code, the interesting part here is not the model name itself but the fact that LLM is tracking the provider’s newer response shape and capabilities. That makes the CLI a faster way to validate prompts, tool behavior, and output formatting before wiring the same model into a production path.
LLM 0.32 can now invoke server-side tools exposed by model providers. With OpenAI, that includes the Code Interpreter environment and WebSearch. The CLI syntax is straightforward:
llm --tool CodeInterpreter 'Show current python and SQLite versions'
That means the tool call is handled inside the provider’s execution environment rather than by a local agent loop. For workflows that need execution or retrieval but do not justify building a custom orchestration layer, this is a useful middle ground.
The llm-anthropic plugin got a larger update alongside the core release. It now adds WebSearch, WebFetch, CodeExecution, and an AnthropicMCP tool wrapper. That enables prompts like:
llm -m claude-sonnet-5 -T 'AnthropicMCP("https://datasette.simonwillison.net/-/mcp")' \
'how many rows in the blog_blogmark table?'
That invocation pushes MCP calls to Anthropic as part of a single request/response interaction. The important bit is not the syntax, but the execution model: provider-side tool use can now reach out to external systems without LLM acting as the tool host.
LLM’s logging has also been redesigned around content-addressable SQLite storage. That gives the project a stronger foundation for deduplication, reproducibility, and inspection of prior runs, especially as prompt histories and tool outputs get larger and more heterogeneous.
One subtle but useful change: the new llm openai endpoint command can execute prompts against any OpenAI-compatible endpoint as a one-liner, and these calls are not logged. That makes it a lightweight escape hatch for ad hoc probing of endpoints that speak the OpenAI-compatible API dialect, including local servers.
Simon uses that path with Gemma 4 12B running in LM Studio, launched via uvx without a full LLM installation, and combined with the llm-tools-quickjs plugin. That is a good pattern for quick validation of model behavior across arbitrary OpenAI-compatible backends without polluting your main prompt log.
The release is less about one marquee feature than about tightening the whole operator experience around modern model APIs: traces are visible but composable, provider-side tools are accessible from the CLI, and the OpenAI-compatible surface is broad enough to treat llm as a portable evaluation harness rather than just a prompt toy.
