Ollama 0.34.4 switches structured outputs for thinking models to a single generation pass

Ollama released version 0.34.4 on September 23, switching structured outputs for thinking models to a single generation pass across both the MLX and llama-server paths. The update directly affects local data extraction and agent workflows: applications need parseable JSON, while the inference engine must correctly separate thinking from the answer. [Release notes](https://github.com/ollama/ollama/releases/tag/v0.34.4)

The previous workflow let the model generate freely, canceled generation once the parser detected answer content, then put the thinking output back into the prompt and regenerated with format constraints. Maintainers noted that restarting added a second prefill and discarded output chunks that crossed the boundary; MLX could also introduce extraneous characters into the JSON. Users had reported a period appearing before the answer when thinking was enabled, causing strict parsing to fail. [Implementation details](https://github.com/ollama/ollama/pull/18479), [issue report](https://github.com/ollama/ollama/issues/18441)

In the new version, the parser supplies a string marking the end of thinking, and the execution engine waits until after that boundary to apply format constraints within the same generation pass. MLX uses structural tags, while llama-server incorporates the end string into a grammar derived from the schema. The prompt needs to be prefilled only once, and metrics no longer need to be combined across two requests. [Merged changes](https://github.com/ollama/ollama/pull/18479)

Developers still pass a JSON Schema through `format` and can validate the returned data with Pydantic or Zod. The official documentation currently states that Ollama Cloud does not yet support structured outputs; this local engine update cannot be assumed to apply to the cloud service. [API documentation](https://docs.ollama.com/capabilities/structured-outputs)

Streaming integrations still need to separate thinking chunks from answer content. The official API returns the two separately, allowing the frontend to switch its display when the answer begins, while downstream parsers should receive only the answer field. Engineering tests also need to distinguish time spent thinking from time spent generating the actual answer to reveal the effects of this workflow change. [Thinking output documentation](https://docs.ollama.com/capabilities/thinking)

Single-pass generation also has limitations: a model may stop during the thinking phase without producing a formatted answer. Once format constraints take effect, tool calls generally cannot replace the answer, though the Harmony format provides an exception. Teams using thinking, tools, and a fixed schema together should include these combinations in their upgrade tests. [Implementation details](https://github.com/ollama/ollama/pull/18479)

The release notes provide no comparable end-to-end benchmarks. Useful engineering metrics to track include the rate of complete JSON outputs passing validation, latency to the start of the answer, and retry counts. Comparisons between versions should keep the model, prompt, and output limit fixed. Based on the workflow change, eliminating the second prefill may benefit long prompts, but actual gains will still depend on the workload. Correct formatting also still needs to be paired with business-rule validation of field contents.