Ollama 0.34.4 release candidate handles thinking and JSON in a single generation, reducing repeated prefill

Ollama released v0.34.4-rc0 on September 23, incorporating a rewrite of structured output handling for reasoning models that was merged the previous day. The server can now let a model think first, then generate an answer under JSON format constraints within the same generation. The release page still marks the version as a prerelease, so deployments should explicitly pin the release candidate tag. [Release announcement](https://github.com/ollama/ollama/releases/tag/v0.34.4-rc0)

The change addresses the transition between stages of generation. Previously, generation began without format constraints. Once the parser detected answer content, the server stopped the request, rebuilt the prompt, and started a second generation constrained by a grammar. In the new flow, the parser supplies an end-of-thinking marker. MLX uses structural tags, while llama-server uses grammar rules that wrap the JSON Schema, to constrain the answer after that marker, eliminating the second prefill. [Merged pull request](https://github.com/ollama/ollama/pull/18479)

A reported failure illustrates why boundary handling matters: in an MLX report involving Qwen3.8, eight out of ten tests with thinking and a schema enabled produced an extra period before the JSON, causing strict parsing to fail. None of the ten tests with thinking disabled showed the issue. This is a small sample from a single environment and cannot establish an error rate across all models, but it can serve as a regression test case after upgrading. [Issue report](https://github.com/ollama/ollama/issues/18441)

Applications still pass JSON Schema through `format`, while compatibility interfaces use `response_format`. The official documentation demonstrates defining structures with Pydantic or Zod and validating responses again after receiving them. It also explicitly states that Ollama Cloud does not yet support this capability. A fix to the local inference engine therefore cannot be assumed to cover the cloud service. [Usage documentation](https://docs.ollama.com/capabilities/structured-outputs)

The expected engineering benefit is a reduction in repeated prompt processing, but the announcement provides no comparable latency or throughput figures. Acceptance testing should measure prefill time, full-response latency, and format-validation pass rates, while also checking stream interruptions, early termination of thinking, and interactions with tool calls. Raw prompt mode still applies format constraints from the first token, so different entry points need to be tested separately. [Implementation and edge-case details](https://github.com/ollama/ollama/pull/18479)

Specifically, teams can compare versions while holding the model, quantization method, and input length constant, retaining raw responses and parsing results to avoid judging the fix solely by success rates after retries. Data extraction workflows should also test empty arrays, missing fields, and long passages in Traditional Chinese to confirm consistent handling by downstream validators. Valid formatting must still be accompanied by checks that field contents are correct.