LLM 0.32a0 is a major backwards-compatible refactor

Why does this matter? Simon Willison's LLM library is a popular, lightweight tool in the Python ecosystem that provides a unified interface for calling various large language models via plugins. The release of version 0.32 alpha might seem like just another tool update, but it reflects a profound shift happening in AI application development paradigms. It marks the evolution of our fundamental unit of interaction with LLMs—from simple Q&A-style text to complex, structured, multimodal "conversation flows." What has changed? Historically, the core abstraction of the LLM library was straightforward: send a text prompt, receive a text response. This made sense in early 2023 when model capabilities were limited. But in just a few years, model capabilities have exploded: support for image, audio, and video input; the ability to output strict JSON structured data; the capacity to call external tools to perform actions; and even emerging reasoning and image generation abilities. The old "text in, text out" pipeline had become a bottleneck. This refactor does two key things:

1. Input Refactoring: Transforms the input from a simple text string into a "sequence of messages." This directly mirrors the conversational format of mainstream APIs (like OpenAI Chat Completions). Each message has a role (e.g., user, assistant) and can contain multimodal content. You're no longer sending an isolated command but submitting a complete "conversation script" for the model to understand the full context. 2. Output Refactoring: Changes the response from a static text block into a "stream of differently typed parts." This means the model's reply isn't just a single block of text but could be a piece of text, a tool call request, a generated image, a piece of structured data, etc., with these parts arriving incrementally like a stream. This perfectly aligns with modern models' streaming output and mixed-response characteristics (e.g., thinking before calling a tool). How does this relate to you? For engineers currently using or considering using LLM APIs for development, this is not an ignorable "library update." It reveals a trend we must confront: the complexity of AI applications is shifting from the model side to the engineering side. In the past, you might only need to figure out how to ask a question. Now, you need to design the state management for entire conversations, handle the encoding and transmission of multimodal data, parse heterogeneous responses (text, tool calls, data) arriving in streams, and dynamically update your application's UI or backend logic based on these components. Simon's refactor, done while maintaining backward compatibility, is precisely to help developers transition smoothly to this new paradigm. A Deeper Trend: Conversation as the New Interface The most profound takeaway from this is that "conversation" itself is becoming a more universal computing interface. The model's input is no longer a one-time function argument but a continuously maintained history of dialogue. The model's output is no longer a single return value but a series of real-time event streams. The developer's role is evolving from a "command sender" to a "conversation director and event stream processor." A Counter-Intuitive Point You might think this is just about following OpenAI's API format. But Simon's approach goes further. He's building an abstraction layer designed to unify the differences between various model providers (who might have different formats for multimodal or tool-calling features in the future). This means if you develop based on the LLM library's abstraction, your application will be able to switch more easily between different models (like GPT, Claude, Gemini) without rewriting core interaction logic. In today's landscape of rapidly iterating LLM capabilities and an unsettled vendor market, this has extremely high practical value. It allows you to focus on application logic rather than getting bogged down in adapting to underlying API changes.