TL;DR
Reasoning-first is a rule for structured answers (JSON, XML): put the reasoning field before the answer field. The model writes text left to right and can't go back. If the reasoning comes first, the answer builds on it. If the answer comes first, the reasoning gets written after the fact.
The "structure tax" (the drop in accuracy caused by JSON/XML) turned out to be not a property of structure but a consequence of field order. The typical "rate it and justify" schema puts the answer first. The model blurts out a verdict and then tailors an explanation to fit it. On multi-step tasks this wrecks the result: on arithmetic, accuracy dropped from ~85% to ~11% for small models. Strong models fall less sharply, but noticeably: GPT-4o lost about 40 points compared to a plain answer. When the reasoning comes first, accuracy is equal to a free-form answer or higher.
The method is one step in one prompt: define a schema with the <reasoning> field first, then <answer>. XML tags worked better on average than JSON keys.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: <reasoning> field — the model reasons step by step → text
STEP 2: <answer> field — the model locks in the result → short answer
⚠️ Order is mandatory: reasoning STRICTLY before answer.
Everything in one prompt. No separate requests needed.
Example in Practice
Task: An Amazon store owner built an automation in n8n. The model calculates the final margin per product, accounting for the marketplace fee, fulfillment, a promo discount, and returns. That's multi-step arithmetic. The old prompt asked for {"margin_usd": ..., "explanation": ...}, meaning the answer came first, and the numbers kept "drifting."
Prompt:
You are calculating the unit economics of a product sold on Amazon.
Data:
- Unit cost: $8.00
- List price before discount: $29.99
- Promo discount: 25%
- Amazon referral fee: 15% of the price after discount
- Fulfillment to the customer: $4.50
- Keep rate: 85% (each return costs $3.00)
Return the answer strictly in XML. Tag order is mandatory:
<reasoning>
Calculate step by step: price after discount, fee, fulfillment,
losses on returns, margin per unit. Show every operation.
</reasoning>
<answer>
Margin per unit sold in dollars, a single number.
</answer>
Write <answer> only after you have finished <reasoning>.
Result: The model will first write out the step-by-step calculation: discounted price, fee, fulfillment, returns. Only then will it output a single number in <answer>. That number follows from the work above rather than being guessed before it. The automation only needs to extract the contents of the <answer> tag, and <reasoning> can be saved for review.
Why It Works
The weakness. The model generates text one piece at a time, and each next piece rests only on what's already written. If "answer" comes first in the schema, it has to name the result before any reasoning. After that, the justification field can only defend the choice. The authors identified two failure modes. The first is rationalization: on multiple-choice tests, the justification shrinks to a short excuse (33 words versus 121 with the correct order). The second is premature commitment: on arithmetic, the model writes just as much text, but the calculation can no longer change the answer that's already locked in.
The strength. The model reasons well step by step when it's given room to do so before the answer. That's the old Chain-of-Thought principle, but here it works inside the schema.
How the method exploits this. Field order turns the schema into a forced Chain-of-Thought. The answer takes shape after the reasoning. XML tags additionally draw a clear line between "thinking" and "answering."
Control knobs:
- Field order — the main knob. Change it first if accuracy sags.
- XML instead of JSON → slightly more reliable on average. Tags mark the transition from reasoning to answer better. The gap reached 12 points.
- Instructions inside <reasoning> ("calculate step by step," "check the conditions") → control the depth of reasoning.
- Dropping <reasoning> from the output → keep the field in the model's response but don't show it to the customer. Parse only <answer>.
- Simple structural tasks (e.g., SQL) → order barely matters, no need to complicate things.
Prompt Template
{task_and_role_description}
Data:
{input_data}
Return the answer strictly in XML. Tag order is mandatory:
<reasoning>
{how_to_reason: step by step, which conditions to check}
</reasoning>
<answer>
{final_answer_format: a single number / yes-no / a label / a short conclusion}
</answer>
Write <answer> only after you have finished <reasoning>.
Don't write anything outside these tags.
What to fill in:
- {task_and_role_description} — what the model is solving.
- {input_data} — the source numbers, text, conditions.
- {how_to_reason} — a step-by-step hint. For arithmetic: "write out every operation."
- {final_answer_format} — what the result should look like so it's easy to parse.
🚀 Quick start — paste into a chat:
Here is the reasoning-first template (reasoning before the answer). Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what input data you have, what form the final answer should take, and which reasoning steps are needed. This is so it can fill in <reasoning> and <answer> correctly. It will keep the tag order from the template.
Limitations
⚠️ Tasks with a rigid structure of their own: on SQL generation, field order barely matters, and the XML wrapper sometimes even gets in the way. There, a free-form answer stays competitive.
⚠️ It doesn't substitute for knowledge: the format makes the model reason in order but doesn't give it missing facts. On knowledge questions (MMLU), the gain is more modest than on logic.
⚠️ Not universal across models: there were anomalies. Claude Sonnet 4.5 handled JSON with "answer first" on arithmetic (96%), yet in XML with the same order it dropped to 62%. On logic tasks, its JSON with the correct order turned out noticeably worse than a plain answer. Test on your own model.
⚠️ Small models are more fragile: for 4–8 billion parameter models, the collapse with the wrong field order is nearly total, and run-to-run variance is higher.
⚠️ Self-rated confidence is weak: XML improves calibration on average (the match between stated confidence and actual accuracy). But the ability to tell a right answer from a wrong one by a "confidence from 1 to 10" number stays low. Don't build hard decisions on that number. For small models, it's closer to a heuristic than to genuine uncertainty.
⚠️ Models with built-in "thinking" weren't tested: they tested GPT-4o, Gemini Flash 2.0, Claude Sonnet 4.5 (standard mode), and two small open models. How this works with reasoning modes, the paper doesn't show.
How They Studied It
A PayPal team asked: is the structure tax a death sentence for any JSON/XML, or the result of a schema design mistake? They took five models (GPT-4o, Gemini Flash 2.0, Claude Sonnet 4.5, Llama-3.1-8B, Gemma3-4B) and four task sets. The sets ranged from rigidly structural (SQL generation) to loosely structured (knowledge questions, logic), with arithmetic in between. Each model was run in five formats: free text, JSON and XML with the answer first, JSON and XML with the reasoning first. Each experiment was repeated five times.
Reasoning first won in 13 of 20 "model–task" pairs and never flopped where the other order won. The sharpest collapse was on arithmetic: for the two small models, XML with the answer first gave about 11% versus 83–87% with the correct order. To check whether this was an artifact of wording, the authors varied the instruction text, the key casing, and whitespace: the gap stayed at least 37 points across all 24 combinations.
Then the authors looked inside the two open models. They checked whether the model was ready to answer while still in the reasoning stage. With the "reasoning → answer" order, the answer was recognizable in the model's internal layers; with "answer → reasoning," it wasn't. That explains the mechanics: the model names a letter without any internal preparation.
The practical insight: the less the task itself dictates structure, the stronger the effect. For arithmetic and logic, order is critical; for SQL, it barely matters.
Original from the Study
The paper moves the full prompt templates to Appendix A.1, which isn't in the provided text. Only the general scheme is known from the main text.
Reasoning-first (R,A): <reasoning> ... </reasoning> then <answer> ... </answer>
Answer-first (A,R): "answer": "...", then "reasoning": "..." (JSON)
<answer> ... </answer>, then <reasoning> ... </reasoning> (XML)
Context: these are the comparison conditions in Figure 1: a single anatomy question from MMLU was solved in three formats. Free text and reasoning-first XML gave the correct answer D; answer-first JSON gave the wrong A.
Adaptations and Extrapolations
💡 Adaptation for an LLM judge or grader: the familiar "rate it and justify" phrasing puts the verdict first. Flip the order.
Evaluate the support agent's reply for compliance with the guidelines.
Return XML. Order is mandatory:
<reasoning>Go through each guideline item, find violations, quote the relevant fragments.</reasoning>
<verdict>compliant / non-compliant</verdict>
🔧 Technique: move the verdict out of the first line of the chat → less "tailoring." Even without XML, add to the prompt: "First break the task down step by step. Write the final conclusion at the very end, on a separate line." It's the same principle carried over to a regular conversation. In the paper, it was tested specifically on structured schemas.
💡 Adaptation for agents: in tool descriptions with a reasoning, plan, or thought field, put it before the action parameters. If your tool-call schema has the decision before the explanation, the agent "chooses" first and justifies afterward. This is a transfer of the principle to agent schemas; the paper didn't test it directly.
Resources
- Paper: Structure Tax: How Structured Output affects LLMs Performance
- Authors: Vineet Kumar, Kanishka, Bhuvanesh Mandora (PayPal AI, Bangalore, India)
- Prior work: Tam et al., 2024 (the original "structure tax" hypothesis); Long et al., 2025 (fifteen formats); Sclar et al., 2024 and He et al., 2024 (sensitivity to prompt wording); Wei et al., 2022 (Chain-of-Thought)
- Task sets: GSM8K, MMLU, LogicBench, Spider