LLM 0.32: New CLI Reasoning Traces & Server-Side Tools

LLM CLI is an open-source command-line tool built by Simon Willison that lets you talk to dozens of large language models — OpenAI, Anthropic, Google, and locally-hosted models via Ollama — through a single llm command. It handles running prompts, logging every conversation to SQLite, adding new models through plugins, and piping text in and out from the shell.

Released on August 4, 2026, version 0.32 is what its author calls "the biggest backward-compatible update since the project began." Four pillars define the release: reasoning traces streamed to stderr, server-side tool calls for OpenAI and Anthropic, a rebuilt SQLite logging schema, and a new messages= parameter for the Python API — all while keeping existing prompts and scripts working unchanged.

- Adds dozens of LLM providers (OpenAI, Anthropic, Google Gemini, local models via Ollama) through plugins, all callable from one command
- Automatically logs every prompt and response to a SQLite database, searchable later with full-text search
- Accepts multimodal input — images, audio — as attachments
- Composes with Unix pipes, e.g. cat file | llm -s "...", for shell workflows like code review or summarization
- Supports both an interactive chat mode (llm chat) and one-shot execution
- Can be imported as a Python library and embedded directly in scripts and tools

At the core of LLM CLI is a plugin-first design: the base tool ships with no model built in, and support for a provider is added by installing a plugin, such as llm install llm-anthropic or llm install llm-ollama. That means new model families can be supported plugin by plugin, without waiting on a core release. The fact that llm-anthropic shipped its own 0.26 update alongside 0.32, adding Anthropic's server-side tools, is a direct result of that architecture.

To upgrade an existing install, use your package manager's upgrade command (uv tool upgrade llm, pipx upgrade llm, and so on). Because 0.32 rebuilds the internal logging schema, it's recommended to back up your log file first by running llm logs backup logs-backup.db before upgrading.

No provider works without a key, so start by registering one with something like llm keys set openai. Since 0.32 switched the default model to "GPT-5.6 Luna", the low-cost member of the GPT-5.6 family, a bare llm 'prompt' is enough to get a first response.

When you use a reasoning-capable model, its chain of thought is now streamed to standard error as it's generated. Standard output stays clean — only the final response text goes there — so piping into something like llm '...' | jq still works reliably. If you don't want to see the trace, pass -R/--hide-reasoning to suppress it.

For OpenAI's reasoning models (the GPT-5 family and similar), the CLI now defaults to calling the /v1/responses endpoint internally. That preserves reasoning continuity across tool calls, giving more consistent behavior in multi-turn tool-use scenarios.

Server-side tools such as OpenAI's WebSearch and CodeInterpreter can now be invoked directly from the CLI — for example, llm --tool CodeInterpreter '...' hands code execution off to the model provider itself. The llm-anthropic plugin also picked up WebSearch, WebFetch, CodeExecution, and AnthropicMCP in its own 0.26 release, so server-side tools from both OpenAI and Anthropic are now reachable through LLM CLI.

The SQLite log that records every conversation has been rebuilt around a content-addressable model similar to Git's object store: identical messages are referenced by hash rather than duplicated, which cuts down on redundant records while making it easier to filter and full-text search by model or tool name. Because the schema changes, backing up first with llm logs backup logs-backup.db is recommended before upgrading.

- llm openai endpoint: a new command that runs a one-liner against any OpenAI-compatible endpoint without logging — handy for checking a locally-hosted inference server
- llm -m MODEL --options: lists the options a given model accepts
- llm prompt --json: returns the response in JSON format
- -o service_tier fast/flex: selects an OpenAI service tier

As a Python library, model.prompt(messages=[...]) now accepts a full conversation history through the messages= parameter, and helper functions llm.user(), llm.assistant(), and llm.system() make it easy to build that list. On the response side, response.stream_events() lets you process structured events — reasoning, text, and so on — as they arrive; response.to_dict()/from_dict() handle serialization; and Response.log_to_db() lets you log at any point you choose. Tools can also raise llm.PauseChain to pause execution for human approval and resume later.

LLM CLI isn't the only way to talk to a model from the terminal. Each of the alternatives leans toward a different job, so picking the right one depends on what you're actually trying to do.

In short, where Ollama is a runtime for running a model locally, LLM CLI is a thin common layer for calling whatever model is running — local or cloud — from the command line and keeping a record of it. For more on choosing local LLM tooling, see our Ollama vs LM Studio comparison.

Logging is where LLM CLI stands apart from most terminal chat tools. Many treat conversation history as disposable terminal output; LLM CLI instead structures every prompt and response into a SQLite database as it runs. With 0.32's move to a content-addressable log, cross-model search and filtering down to a specific tool call both become practical. It's probably more accurate to think of it as a record-keeping layer for LLM usage than as a one-off prompt runner.

LLM CLI isn't limited to cloud APIs. Install the llm-ollama plugin and a model hosted by Ollama becomes callable through the same llm -m model-name 'prompt' syntax as any cloud model — sharing the same log database and command structure. The new llm openai endpoint command in 0.32 is also handy for a quick, unlogged check against a locally-hosted OpenAI-compatible inference server, such as one running through vLLM or LM Studio's server mode. For more on building an efficient local terminal workflow, see our Hunk terminal diff viewer piece.

This article draws on the following primary sources.
- Simon Willison, "A new release of LLM" https://simonwillison.net/2026/Aug/4/new-release-of-llm/
- LLM Releases (GitHub) https://github.com/simonw/llm/releases
- LLM official documentation https://llm.datasette.io/