JSON schema field order: put reasoning before the answer

Does the order of fields in a JSON schema matter for structured outputs? Yes, a lot, for small models: put the reasoning field before the answer. With a grammar forcing the declared order, Qwen 3.5 0.8B solved 20 of 50 grade-school math problems with {"reasoning", "answer"} and 0 of 50 with {"answer", "reasoning"}. Qwen 3.5 2B solved 15 of 20 against 3 of 20. A reasoning field written after the answer was worth nothing: answer-first scored the same as a schema with no reasoning at all. And if you run the model through Ollama, check the order you actually get. Ollama sorts schema keys alphabetically, so {"reasoning", "answer"} comes out as {"answer", "reasoning"}: on the 0.8B that dropped the declared reasoning-first schema from 20 of 50 to 1 of 50. Naming the keys a_reasoning and b_answer survives the sort and got 20 of 50 back.

This is the ninth post on local models on a laptop CPU, and a follow-up to the structured outputs post, which found the sorting on an extraction task and left the reasoning question open.

How I tested

The first 50 problems of the GSM8K test set (MIT license), grade-school math word problems whose answer is one number. Qwen 3.5 0.8B ran all 50 in every condition; Qwen 3.5 2B ran the first 20, because at about 3 minutes per problem on this CPU the full 50 would not have fit in the night. Both are bartowski’s Q4_K_M GGUFs, thinking off, greedy decoding (temperature 0, same seed), at most 1,024 output tokens, two parallel slots on a 2-core laptop CPU with no GPU. Every request went to /v1/chat/completions with response_format: {"type": "json_schema", ...} in the shape the OpenAI SDK sends.

Five conditions, each with its own schema:

Condition	Schema properties, in declared order
free	no schema: “think step by step, end with Answer: <number>”
answer_only	answer (number)
reasoning_first	reasoning (string), answer (number)
answer_first	answer (number), reasoning (string)
prefixed	a_reasoning (string), b_answer (number)

The system prompt shows the schema exactly as declared and asks for the keys in that order. Upstream llama-server (llama.cpp b11554) builds the grammar in declared order, so it is the clean test of the order itself. Ollama 0.40.16 got the three schema conditions that matter for it. A reply counts as right when its answer equals GSM8K’s answer. “Right incl. cut-off” also credits replies that ran out of tokens after the answer was already written. Other programs used 30% to 41% of the CPU during the runs, so I report output tokens rather than seconds.

Does putting reasoning before the answer improve accuracy?

Yes. Upstream llama-server, so the grammar keeps the declared order:

Condition	0.8B right (of 50)	2B right (of 20)	0.8B mean output tokens	0.8B cut off at 1,024 tokens
free (plain text)	28	15	331	2
answer_only	2	3	12	0
reasoning_first	20	15	226	4
answer_first	0 (1 incl. cut-off)	3	554	22
prefixed	22	13	226	4

Paired by problem, reasoning first beat answer first on 20 problems and lost on none for the 0.8B, and 12 to 0 for the 2B (exact sign test, p < 0.001 for both). The two conditions differ only in where one key sits.

prefixed is the same schema as reasoning_first with different key names. It landed within 2 problems of it on both models (22 against 20, 13 against 15), which is the noise floor for this test: renaming a key changes the text a small model writes, and a different text gets some problems right or wrong by chance.

Plain-text reasoning was as good as or better than any JSON condition: 28 against 20 on the 0.8B (12 to 4 on the problems where they differed, p = 0.08, so not conclusive), 15 against 15 on the 2B. The JSON reasoning was shorter (226 tokens against 331 on the 0.8B), which fits the claim of Tam et al. that format restrictions cost reasoning. On this data that cost is small next to the cost of the wrong key order.

Why does an answer field first hurt so much?

Because the model writes the answer before it has done any work, and then cannot change it. The reasoning that comes after is often right. On the first problem (eggs: 16 laid, 3 eaten, 4 baked, the rest sold at $2), the 0.8B with answer_first wrote:

{
  "answer": 16.0,
  "reasoning": "Janet lays 16 eggs per day. She eats 3 for breakfast, so she has 16 - 3 = 13 eggs remaining. She bakes muffins for 4 days, so she has 13 - 4 = 9 eggs remaining. She sells the remainder at the farmers' market for $2 per egg. Therefore, she makes 9 * $2 = $18.0 per day. However, the question asks for the amount she makes *every day at the farmers' market*, which implies the daily revenue from selling the remaining eggs. The calculation yields $18.0."
}

The answer is 18. The reasoning found it, one key too late. Counting the answer-first replies that finished (“reasoning right” means the last number in the reasoning is the correct answer; “differs” means it is not the answer the reply committed to):

Model	Finished	Answer wrong	Reasoning right	Differs
0.8B	28	28	19	24
2B	19	16	12	14

The other 22 of the 0.8B’s 50 answer-first replies never finished. After committing to a number, the model kept re-checking it in the reasoning string (“re-read” appears in 19 of the 22, “Wait” in 16) until it hit the 1,024-token cap, so the JSON never closed. That also made answer first the slowest condition: 554 output tokens on average, against 226 for reasoning first. A wrong answer, more tokens, and sometimes no valid JSON at all.

The same holds without a grammar. Dylan Castillo measured gpt-4o in JSON mode on LiveBench reasoning questions: 46.67% with reasoning first, 33.33% with answer first. On models this small the gap is much larger.

Does Ollama keep the schema’s property order?

No. Ollama decodes the schema into a Go map before it reaches llama.cpp, and Go writes map keys in sorted order (ollama/ollama#18717, open since September). answer sorts before reasoning, so the schema I declared reasoning-first was generated answer-first. Every finished reply had its keys as answer, reasoning, on both of Ollama’s APIs: probe_order.py sent the same schema through /v1 with response_format and through the native /api/chat with format, and both replies started with "answer". The system prompt still showed the declared order and asked for it; the grammar won.

Same models and problems, Ollama 0.40.16, only the schema and its key names differ:

Condition on Ollama	Keys as generated	0.8B right (of 50)	2B right (of 20)	0.8B cut off at 1,024 tokens
answer_only	answer	1	3	0
reasoning_first (declared)	answer, reasoning	1 (2 incl. cut-off)	3	18
prefixed	a_reasoning, b_answer	20	15	3

On the 0.8B, the schema declared reasoning-first scored 1 of 50 on Ollama and 20 of 50 on llama-server, with the same problems, the same prompt and the same model file. It behaved exactly like answer first: 18 replies ran out of tokens after the answer was written (16 of them with “re-read” in the reasoning), and in 17 of the 31 wrong finished replies the reasoning ended on the right number. The first problem again came back as "answer": 16.0, followed by reasoning that reached $18. The 2B told the same story: 3 of 20 declared reasoning-first on Ollama, the same 3 as answer-first on llama-server, and 15 of 20 with the prefixed keys, the same 15 as reasoning-first on llama-server. Paired by problem, the prefixed keys beat the declared schema 19 to 0 on the 0.8B and 12 to 0 on the 2B.

Nothing warns you. The request returns HTTP 200, the JSON is valid and matches the schema, and the reasoning field is there. Only the order of two keys in the reply shows that the model answered before it reasoned.

How to keep reasoning first on Ollama

Name the keys so that alphabetical order is the order you want. a_reasoning and b_answer came back in that order on both APIs, and scored 20 of 50 on the 0.8B, the same as reasoning-first on llama-server (22 there with the same prefixed keys). Any names that sort right work: reasoning before result would too, since rea sorts before res, but I only measured the prefixes.

These are the schemas the benchmark sent (from bench.py); only the property names and their order differ:

def obj(*props):
    return {"type": "object", "properties": dict(props), "required": [k for k, _ in props],
            "additionalProperties": False}

SCHEMAS = {
    "answer_only": obj(("answer", NUM)),
    "reasoning_first": obj(("reasoning", STR), ("answer", NUM)),
    "answer_first": obj(("answer", NUM), ("reasoning", STR)),
    "prefixed": obj(("a_reasoning", STR), ("b_answer", NUM)),
}

With Pydantic models the same applies to the field names: declare a_reasoning before b_answer and map them back after parsing.

Two other ways around it: send the request to upstream llama-server, which kept the declared order in every finished reply here, or use json_object mode with the schema in the prompt, which in the structured outputs post kept the model’s own key order (I did not test it on this task). Whatever you do, look at the keys of a real reply once: that is how this showed up.

What broke and what I would do differently

• The 2B ran on 20 problems, not 50. With other programs using a third of the CPU, it took about 3 minutes per problem across the five conditions, and I cut it rather than skip Ollama. Its results agree with the 0.8B’s, but 20 problems is a small sample.
• Greedy decoding, one run per problem. The prefixed control shows how much a cosmetic change moves the score (2 problems either way), so differences of that size here mean nothing.
• GSM8K is old and public, so these models have probably seen it. That would help every condition equally, and plain-text reasoning still beat the 0.8B’s answer-only by 28 to 2, so the model was not reciting answers.
• One task, one model family. Extraction tasks (like the ticket schema) showed a smaller effect from key order. The size depends on how much the answer needs work that has not been written yet.
• I did not test a thinking model with thinking on. With a separate thinking channel, the reasoning field may matter less.

Takeaways

• Put the field that does the work before the field that holds the result. For a classifier, that means the explanation before the label; for an extractor, the evidence before the decision.
• Check the key order of a real reply, not the schema you sent. On Ollama, every schema-constrained reply in this test came back sorted.
• If your runtime sorts keys, prefix them (a_reasoning, b_answer) until the bug is fixed (ollama/ollama#18717).
• Do not expect a reasoning field to beat plain-text reasoning. If you only need the number, let the model write freely and parse the last line, as the free condition did.

The code, every reply and the summary tables are in the project folder. Earlier posts in this cluster: small LLM JSON output on what a grammar fixes, and Ollama structured outputs on the /v1 endpoint and the sorted keys, and temperature and JSON output on what sampling does to validity (this test was greedy).