GitHub Repo
Ollama 0.34.3 release candidate exposes model thinking options, reducing hardcoded agent settings
The update lets the model information API return supported thinking levels and defaults, reducing the need for clients to maintain their own configuration tables. The release is still in prerelease, and other metadata gaps and documentation discrepancies require further checking.

Ollama released 0.34.3-rc1 on September 19, enabling the model information endpoint `/api/show` to return supported thinking options and defaults. The release notes use the GLM-5.3-Flash cloud model as an example: `thinking.values` lists low, high, and max, while `thinking.default` is max. Agents and chat interfaces can now query this information to build menus tailored to each model. [Release notes](https://github.com/ollama/ollama/releases/tag/v0.34.3-rc1)
The change addresses a practical integration problem. In an issue filed on September 11, a Pi extension developer noted that the existing API only indicated whether a model supported thinking. To discover the accepted levels, the developer had to load third-party data, maintain a table of defaults, or even deliberately send invalid parameters to infer the options from error responses. These approaches can break as models are updated, and the new fields can reduce some of that maintenance work. [Developer report](https://github.com/ollama/ollama/issues/18385)
Thinking settings also cannot be applied uniformly across models. The official documentation explains that requests use the `think` field, with some models accepting Boolean values or intensity levels. GPT-OSS accepts low, medium, and high, and ignores Boolean values. Thinking content is returned separately from the final answer, and hiding that text does not stop that part of generation. From an engineering perspective, clients should validate inputs against the discovered options and manage display preferences separately from inference settings. [Thinking documentation](https://docs.ollama.com/capabilities/thinking)
One documentation discrepancy still warrants attention: the release notes describe the endpoint as GET, but the accompanying curl example includes a data argument that causes it to send a POST request. The official API documentation also specifies POST. Integrations should follow the official API specification when submitting the model name, rather than changing the HTTP method based solely on the release summary. [Endpoint documentation](https://docs.ollama.com/api-reference/show-model-details)
For evaluation pipelines, this adds another condition worth recording: alongside the model name and server version, teams can save the discovered default and the setting actually submitted. If the upstream provider changes the default thinking intensity, comparisons based only on speed or billing could mistake configuration differences for a model regression. Adoption testing should therefore hold tasks, inputs, and thinking settings constant while measuring latency and quality.
The release is still a release candidate. The announcement does not say that all other metadata requests, such as pricing, cache rates, or maximum output length, have been addressed. Although the same release also adds support for running Nemotron H vision models with MLX on Apple Silicon, it provides no performance figures. Further checks should examine whether local and cloud models return consistent information, how clients fall back when older servers lack these fields, and whether the settings actually affect generation behavior. [Release changes](https://github.com/ollama/ollama/releases/tag/v0.34.3-rc1)