llm 0.37 Adds Model Choice and Changes the Default

Simon Willison released llm 0.37 on November 2, adding model options while changing the default for users who never selected their own. The update combines easier configuration with a practical question: how much model choice can developers introduce without making established workflows harder to predict?

LLM, Willison’s command-line interface and Python library for accessing language models, sits between applications and the models they use. Its latest release makes that connecting role more explicit. Developers gain a simpler way to register compatible services, while embedding support expands its handling of different media types.

The relevant comparison is with direct connections to individual providers and local model tools such as Ollama. A shared interface reduces setup work across those choices. It does not make their behavior identical. That distinction connects the release’s headline features, its reliability fixes, and Willison’s experience reviewing AI-assisted contributions.

What llm 0.37 Changes Beyond the Model List

The release changes how developers select and connect models, alongside the models available through the tool.

The release announcement describes approximately two months of accumulated work. It adds gpt-6.1-sol and gpt-6.1-terra, introduces llm openai endpoint add, and changes the fallback model to gpt-6-luna. That default change applies when users have not selected their own default.

These are different kinds of updates. Adding a named model expands an existing menu. Adding endpoint management changes how developers maintain that menu. Changing a fallback affects what happens when a user leaves model selection implicit.

An endpoint is the service address where software sends model requests. OpenAI-compatible endpoints accept requests using conventions associated with OpenAI’s application programming interface, or API. Compatibility lets existing clients reach other services without requiring a completely different integration.

For developers, the distinction between an available model and a selected model deserves attention. A new entry does nothing until someone chooses it. A changed fallback can affect an existing command that never specified a model.

Consider a developer who runs a recurring summary job with an explicit model selection. That choice makes the intended dependency visible. A colleague running an otherwise similar command without that selection relies on the environment’s default instead.

Neither approach is automatically wrong. Defaults help people begin without making every decision upfront. Explicit choices help teams explain why a workflow behaved differently after an upgrade or environment change.

The release also extends support for typed embedding attachments. An embedding is a numerical representation used to compare content by meaning. Typed attachments preserve information about the kind of content entering that process, rather than treating every binary input alike.

This matters because a model that accepts media needs more information than the raw bytes alone. The surrounding software must communicate whether an attachment represents an image, audio, or another supported input.

The broader change is architectural. LLM is maintaining a common interface while accommodating differences in model selection, service configuration, and input handling. Those responsibilities become more visible as developers use the same tool across more kinds of work.

Readers evaluating llm 0.37 should therefore separate access from behavior. The release expands and organizes access. Whether a particular workflow improves remains a question for that workflow’s inputs, outputs, and requirements.

That distinction also explains why a release with familiar model additions deserves attention beyond its model names. Configuration choices influence repeatability long after the announcement stops attracting attention.

Easier Model Switching Moves Work Onto Workflow Owners

Model switching reduces integration friction, but someone still has to own the consequences of the switch.

The immediate beneficiaries are developers experimenting across hosted services and local models. A shared client can spare them from rebuilding basic request handling for every evaluation. That convenience becomes more consequential when experiments turn into recurring jobs.

A prototype usually asks whether a model can complete a task. An operational workflow also asks whether the result arrives in an acceptable format, under acceptable conditions. Those questions belong to the application owner even when a library simplifies the connection.

Imagine an engineering team generating summaries from internal incident reports. During exploration, the team tries different models against the same documents. Once colleagues depend on those summaries, consistency becomes part of the product.

A model change that produces more readable prose might still omit an operational detail. Another change might preserve every detail while introducing a format the downstream application cannot accept. Neither outcome is captured by successful endpoint configuration.

For that team, the pressure comes from easier experimentation meeting established expectations. The forced response is to define acceptable behavior before making a candidate model the routine choice.

This is where model switching becomes an organizational issue. The person configuring the client may not be the person reviewing the summaries. The person approving data access may have different responsibilities again.

A shared interface can make those boundaries less visible because the command looks familiar across environments. Familiar syntax should not substitute for an explicit decision about where information goes and how outputs will be evaluated.

LLM’s existing logging controls illustrate another part of that responsibility. The tool normally records prompts and responses in a local database. Users can disable logging, including for individual requests.

Logs can help explain a changed result, but they also create a separate record of information submitted during a workflow. A developer evaluating models needs to consider both the remote request and the local record.

That is especially relevant when a useful experiment becomes a team convention through copied commands. The command may travel more easily than the original assumptions about retention, model choice, and acceptable source material.

For teams building a searchable knowledge base, the same ownership question extends beyond the initial model call. Someone must maintain source identity, access expectations, and the relationship between retrieved material and generated answers.

These are practical implications, not evidence that the release creates new governance obligations for every user. A personal experiment and a shared production process have different needs.

The common lesson is narrower: easier configuration makes evaluation cheaper to start. It does not decide when a model has earned a place in a workflow that other people trust.

A Shared Interface Does Not Guarantee Shared Behavior

OpenAI compatibility provides a connection convention, not a promise that every backend supports the same workflow.

LLM’s endpoint configuration documentation describes support for additional compatible models alongside plugins. Plugins are extensions that add capabilities or provider integrations to the main application.

That offers developers different routes into a common working environment. A compatible endpoint can reuse familiar request conventions. A provider-specific extension can accommodate behavior that does not fit those conventions.

The important comparison is between the convenience of a shared interface and the specificity of a direct integration. A shared interface makes common tasks easier to repeat. A direct integration exposes a provider’s own features and assumptions more explicitly.

Neither route wins every case. The right choice depends on which capabilities the application actually requires and how much provider-specific behavior it needs to preserve.

Ollama provides a useful reference because it supports both local model use and compatible client connections. Its compatibility documentation explicitly describes support for a subset of the OpenAI API.

That qualification matters. Developers should read compatibility as a statement about supported operations, rather than an assurance of complete interchangeability. A request that succeeds in a basic demonstration establishes less than a complete application test.

For example, an application might require a conversation to retain state across requests. Another might depend on a particular mechanism for invoking external functions. Similar request syntax does not establish that both requirements work across every service.

The relevant evaluation follows the application’s behavior. Can the model accept the intended input? Can the service return the required output? What happens when it rejects an option, stops early, or returns an error?

Those questions become more important when model switching happens inside a script. An interactive user can notice an unexpected response and adjust. An unattended process needs explicit handling for the same surprise.

The endpoint management feature addresses a more concrete problem: maintaining reusable configurations. Registration makes a service easier to select again. It does not establish that the service is suitable for every command previously run through another model.

This is also why the OpenAI-compatible route should not be confused with independence from provider decisions. A common client still depends on the selected service’s availability, supported features, and interpretation of requests.

The release therefore strengthens a useful middle position. Developers can standardize parts of their workflow while retaining deliberate exceptions for individual backends. That approach requires knowing which assumptions are common and which remain provider-specific.

Model switching works best as a controlled capability. Treating it as automatic equivalence would erase the very differences developers are trying to evaluate.

Typed Embeddings Bring Media Differences Into View

Supporting more input types makes the surrounding data handling more important, even when the model performs the numerical conversion.

Willison points to Gemini Embedding 2 as a reason for the attachment changes. Google describes multimodal embeddings that represent text, images, video, audio, and documents within a shared numerical space.

Multimodal means the system handles different forms of input, such as text and images. Google presents that shared space as a way to compare meaning across those forms.

The distinction from text-only search is concrete. A text query can seek relevant media without requiring the original item to contain the exact query words. Whether it retrieves useful results still depends on the model and the collection.

Google’s product page includes customer accounts from media and legal technology organizations. Those accounts describe interest in locating relevant material across media types. They provide examples of demand, rather than independent validation of LLM’s implementation.

For llm 0.37, the narrower development is input handling. Preserving an attachment’s type gives the integration information it needs to route supported content correctly. That is infrastructure for using capable models, rather than evidence of improved search quality.

Consider a hypothetical product research archive containing interview notes, screen recordings, and screenshots. A query about a confusing interface might have relevant evidence in any of those materials.

The attractive promise is a single search experience across the archive. The operational requirement is more detailed: preserve what each item is and where it came from.

A useful search result must take a person back to evidence they can inspect. A numerical similarity score cannot explain a screenshot’s context by itself. Nor does a relevant recording automatically identify the precise moment a reader needs.

This is why typed attachments deserve attention even though the feature sounds small. Media differences have to survive the journey from source material to model input and then back into a usable result.

The type information does not solve every step. Developers still need to decide how content is divided, how source references are retained, and how results appear to users.

Dividing a long recording into smaller units changes what the search system can return. Keeping only a file-level reference creates a different experience from returning a relevant passage or moment.

These choices also affect evaluation. A search system can return something related to the query without returning the evidence that resolves it. Teams need examples where that distinction matters.

For a personal archive, a loosely related match may still be useful. For a shared research workflow, readers may need a clearer connection between the query, the retrieved item, and the conclusion drawn from it.

The release makes room for richer inputs at the interface level. The next engineering work sits around those inputs: preserving context, validating retrieval, and making the resulting evidence understandable.

That is the central tradeoff in another form. More content becomes accessible through a shared tool, while the responsibility for meaningful results stays with the application.

Reliability Fixes Qualify the Promise of Easier Access

A successful model response is only part of a dependable workflow; the surrounding software must also handle control, storage, and failure correctly.

The release notes include corrections involving logging, tool execution, and embedding storage. These details deserve attention because they concern what applications can trust around the model’s answer.

A tool call is a model’s request for software to execute a function. The application decides how that request becomes an action. Control checks around that execution are therefore distinct from the model’s ability to propose the right function.

The release corrects a path where a rejected tool call still ran. It also fixes chat logging that continued despite logging being disabled. These are documented corrections, not evidence of a complete security or privacy audit.

Another correction makes an embedding operation reject a batch when the model returns the wrong number of results. Previously, that mismatch risked lost rows or incorrect associations between vectors and identifiers.

The analytical significance is the handling of failure. An explicit error gives an application a chance to stop, retry, or request attention. An apparently successful operation with incorrect associations can be harder to detect.

For a knowledge application, source identity is fundamental. A plausible result attached to the wrong document undermines the reader’s ability to check it. Better language generation cannot repair that association after the fact.

The same principle applies to interrupted work. A workflow should distinguish completed steps from attempted steps, and recorded results from missing ones. Otherwise, the next process inherits an unclear account of what happened.

These are general engineering requirements, not unique shortcomings of LLM. Their appearance in the release shows where an integration library needs maintenance as its usage becomes more varied.

Willison’s account of AI-assisted contributions adds another perspective. He says fixes came from 12 authors, almost all using AI assistance. He reports that reviewing those contributions was less burdensome than he expected.

His explanation emphasizes triage, the process of sorting reports and deciding which deserve attention. He uses AI to help identify useful fixes and sometimes writes his own implementation instead of accepting a submitted patch.

That account supports a specific observation: AI-assisted submissions can provide useful material within his review process. It does not establish that other maintainers face the same workload or receive equally useful contributions.

The announcement contains no controlled comparison of review time, regression rates, or maintenance outcomes. A skeptical reading should preserve that limit while acknowledging the concrete fixes the release contains.

For contributors, the implication is practical. A clear reproduction and a well-defined failure remain valuable even when the proposed code changes substantially during review.

For users, the implication returns to workflow ownership. Trust should rest on observable behavior and checks that match the task. The origin of a patch alone cannot establish whether an application should depend on it.

What to Watch After llm 0.37

The useful follow-up signals concern compatibility, retrieval quality, and maintenance outcomes, rather than the number of newly available models.

Over the coming months, the first signal is how endpoint management holds up across the services developers actually use. Concrete reports should identify the operation, expected behavior, and observed result.

Basic text generation is only a starting point. Applications also encounter unsupported options, authentication failures, interrupted responses, and differences in conversation handling. Documentation and fixes addressing those cases would strengthen the practical value of the shared interface.

The opposite signal would be recurring ambiguity about which combinations are supported. If users must repeatedly rediscover the same limitations, simpler registration would leave much of the integration burden unresolved.

This does not mean every backend needs identical features. Clear boundaries are valuable in their own right. A documented limitation lets developers choose an appropriate route before they build a dependency around an assumption.

The second signal is useful adoption of typed attachments by embedding integrations. Support declarations matter, but working examples should show how the resulting search behavior connects users to inspectable sources.

A convincing example would define a collection, explain its query task, and show where relevant material appears. It should also include difficult cases where related content competes with the correct evidence.

That evidence would strengthen the case that richer attachment handling benefits applications beyond accepting additional file types. Repeated failures to preserve source context would weaken that case, even if the model returned plausible numerical results.

Developers should also distinguish a model demonstration from an application evaluation. The former shows that a capability exists. The latter shows whether the capability helps a particular reader complete a task.

The third signal is the durability of AI-assisted maintenance. Willison’s experience is encouraging within the limits he describes. The next useful evidence concerns whether accepted changes remain understandable and reliable through subsequent development.

Follow-up corrections are not automatically a negative signal. Software maintenance includes finding and fixing mistakes. More revealing questions concern whether reports are reproducible, failures receive clear explanations, and fixes reduce recurring uncertainty.

That perspective avoids treating contribution volume as a complete measure of project health. More submitted code does not by itself show that maintainers have more usable capacity. The value lies in problems understood and behavior improved.

For readers considering this release, the immediate decision is proportionate. Identify which change matters to an existing task before treating the entire update as a reason to redesign that task.

An individual experimenting with models may value configuration convenience most. A team running recurring jobs may care more about explicit selection and reliable records. A search developer may focus on media handling and source preservation.

Use llm 0.37 as a reason to examine a workflow you already understand. Choose representative inputs, record the intended model, and define what an acceptable result must contain. Compare candidate outputs against that standard before expanding their role. For search, inspect the retrieved source rather than relying only on the generated answer. For automated actions, examine how rejection and interruption affect the next step. Keep the evaluation close to the people who use the result, because their requirements determine whether easier switching produces useful flexibility. Which part of your workflow benefits from more choice, and which part needs a more explicit dependency?