Ollama released 0.40.14 with fixes to default generation settings and conversation input handling for apps using models through OpenAI-compatible APIs. When no settings are sent, it follows the values packaged with the model. Apps that resend previous responses retain readable input, including refusal content.

1. OpenAI-compatible routes follow model settings

According to the release notes published on November 3, OpenAI-compatible endpoints, which receive and handle requests, no longer override model sampler defaults. Sampler settings control how much variety is allowed when selecting the next expression during generation.

If a request omits temperature and top_p, the model's own values are used instead of the previously applied 1.0. This fixes the point where generation settings packaged with a model were replaced with different values through compatible access.

The release notes say this behavior matches Ollama's /api/chat. For developers using the same model through both routes, this aligns the defaults used when values are omitted.

2. Check omitted values in the model file

A model file can contain runtime parameters, settings that determine execution behavior. The official documentation provides the following command to inspect it.

ollama show --modelfile llama3.2

The official documentation explains that raising temperature makes responses more creative. Where an omitted value is determined therefore concerns generation behavior, not merely configuration housekeeping.

When updating, it is useful to inspect the model's settings first, then check whether the client, the app sending requests to the server, includes those same fields. This change directly affects calls that omit values. Comparing requests with and without explicit values helps narrow down the cause.

Clients that need to retain specific generation settings can specify the required values directly in requests. Whether defaults belong in the model file or individual requests depends on whether the app should follow the model's default behavior.

3. Responses preserves readable input content

The release states that /v1/responses preserves readable input content. This includes refusal content in previous assistant messages, changing the behavior that indiscriminately flattened input.

In apps with multiple conversation turns, previous responses become material for the next request. This change focuses on keeping that material readable when resent, including refusals. The sampler fix concerns generation settings, while this fix concerns the conversation content being passed along.

According to the official documentation, Responses does not support the server carrying state over from previous requests. Apps that continue conversations must include the necessary history in the request input.

4. Benefits and checking costs of changing defaults

Developers benefit from less work aligning a model's sampler settings across routes. However, existing calls that omitted values may produce different results as they follow model-specific defaults. The update effort therefore shifts toward recalibrating existing test expectations.

When comparing results, check whether requests include sampler values rather than matching only the model and input. Conversation apps can also check flows that resend previous responses containing refusals. Separating the effects into generation settings and conversation input makes changed behavior easier to identify after updating.

The core of this version is making compatible routes respect model sampler settings while preserving the meaningful form of Responses conversation input.