LLM 0.32 adiciona rastreamento de raciocínio e primitivos de agente ao CLI do Python

Simon Willison lançou LLM 0.32 em 4 de agosto de 2026, chamando-a de a versão mais significativa desde o lançamento. A atualização adiciona ferramentas de provedor do lado do servidor do OpenAI e Anthropic, apresenta rastreamento de raciocínio em stderr, reestrutura a API Python em torno de objetos de mensagem tipados, e redesenha o log SQLite usando o esquema de endereçamento por conteúdo do Git — tudo impulsionado por requisitos reais do Datasette Agent, projeto agêntico do próprio Willison. Resumo de Willison: "Acho que LLM é um framework de agente agora."

Para usuários de CLI, a mudança mais visível é a saída de rastreamento de raciocínio. Modelos que expõem chain-of-thought agora o transmitem para stderr, mantendo stdout redirecionado limpo. A flag `-R/--hide-reasoning` a suprime. O modelo padrão mudou de GPT-4o mini para GPT-5.6 Luna, com variantes Luna, Sol e Terra disponíveis de imediato. Usuários OpenAI na Responses API agora podem escolher entre `service_tier` `fast` (custo mais alto, latência mais baixa) e `flex` (mais barato, mais lento) por prompt.

Ferramentas do lado do servidor são a primitiva agêntica de destaque. OpenAI expõe duas: `CodeInterpreter` e `WebSearch`, invocadas via `-T CodeInterpreter` ou `-T WebSearch`. O plugin `llm-anthropic` na versão 0.26 oferece quatro: WebSearch, WebFetch, CodeExecution e AnthropicMCP. A última é arquiteturalmente distinta — passando `-T 'AnthropicMCP("https://your-datasette/-/mcp")'` faz com que a API do Anthropic execute chamadas MCP contra um servidor remoto dentro do ciclo de requisição/resposta sem loop separado do lado do cliente. Isso importa: execução de ferramentas hospedadas pelo provedor significa que lógica de latência e retry executam na infraestrutura do provedor, não na sua.

A API Python substitui o padrão antigo de objeto de conversa com `model.prompt(messages=[])`, que aceita uma lista completa de objetos `Message` tipados construídos com construtores `llm.user()`, `llm.assistant()` e `llm.system()`. A API antiga mascarava a natureza stateless dos serviços LLM; a nova é transparente sobre o que vai pela rede. `response.stream_events()` substitui a interface anterior iterável de string com um fluxo de eventos tipado carregando eventos `reasoning`, `text`, chamada de ferramenta e anexo em um único loop. A exceção `llm.PauseChain` interrompe o loop para aprovação humana; a cadeia pode retomar depois do histórico de mensagens sem re-executar chamadas concluídas.

A revisão de logging é operacionalmente significativa. O esquema antigo registrava JSON de conversa completo a cada turno — uma sessão de 10 turnos duplicava o histórico crescente 10 vezes. O novo esquema tem endereçamento por conteúdo: mensagens são armazenadas uma vez por hash SHA e referenciadas de uma tabela `turns`, como blobs do Git. Registros legados de tabela `responses` permanecem intactos; `llm logs` lida com ambos os esquemas. Antes de atualizar, o changelog recomenda executar `llm logs backup logs-backup.db` para quem estiver executando LLM como um daemon de longa duração com um log grande.

Dois novos comandos são lançados com a versão. `llm openai endpoint <url>` executa um prompt único contra qualquer endpoint compatível com OpenAI sem um plugin configurado — útil para modelos locais via LM Studio ou Ollama, e não registrado. `llm chat-completions-server --port 9000` inicia um servidor REST compatível com OpenAI local apoiado pelo registro completo de plugins LLM, deixando qualquer cliente OpenAI SDK rotear através dele.

O custo: plugins que fornecem modelos customizados devem atualizar para a API 0.32 para suportar o novo sistema de eventos de streaming. Autores de plugin devem implementar mensagens estruturadas e a interface `stream_events()`. Willison observa que atualizações de `llm-gemini`, `llm-openrouter` e `llm-mistral` estão quase completas; até que sejam lançadas, esses backends não exporão rastreamento de raciocínio ou fluxos de eventos tipados.

Para equipes usando LLM em pipelines de produção, o esquema de log com endereçamento por conteúdo e a API de persistência `response.to_dict()` / `Response.from_dict()` merecem avaliação imediata — são fundamentais para estado confiável de agente de múltiplos turnos.