Defensive Parsing and Skepticism Toward Claude Output

1.Read stop_reason before you read the content

Defensive parsing starts before any JSON gets parsed. Every successful Messages API response includes stop_reason, which says why generation stopped. It is not an error. The request succeeded, and this field tells you whether the output is complete and whether you should use it as it is.

Sources1

2.Truncated, empty and unfinished responses

Truncation. When stop_reason is max_tokens, the output was cut off. If the last content block is a tool_use block, that tool call is incomplete, so don't run it. Retry with a higher max_tokens instead:

# Check if response was truncated during tool use
if response.stop_reason == "max_tokens":
    # Check if the last content block is an incomplete tool_use
    last_block = response.content[-1]
    if last_block.type == "tool_use":
        # Send the request with higher max_tokens
        response = client.messages.create(
            model="claude-opus-5-5",
            max_tokens=4096,  # Increased limit
            messages=messages,
            tools=tools,
        )

**Empty end_turn.** A response can end with end_turn and still contain no content, only 2–3 tokens. This usually happens after tool results. A common cause is adding a text block right after a tool_result, which teaches Claude to expect the user to always add text after a tool result, so it ends its turn. Send tool results without extra text. If a response still comes back empty, don't just resend it, because Claude has already decided it is done. As a last resort, add a continuation prompt in a new user message.

Unfinished server tool calls. A tool_use response can include a server_tool_use block that has no matching result block yet. This typically happens when Claude calls a server tool and one of your client tools in parallel: the API returns so you can run the client tools first. Nothing else marks this state. You have to check each server_tool_use or mcp_tool_use id for a matching result block, and a call without one completes in a later response.

Sources1

3.Format consistency when you rely on prompting

If a request does not use constrained decoding, the format depends on how clearly you ask for it. The consistency guide suggests several techniques. Spell out the output format precisely as JSON, XML or a custom template, naming the keys and their allowed values. For example, "sentiment" (positive/negative/neutral). Prefill the assistant turn with the start of the structure you want. Give an example format for Claude to follow, as the market-intelligence prompt does with a full <competitor> template before it says "Now, analyze AcmeGiant and AcmeDataCo using this format."

The prompting best-practices guide backs up the examples technique: make examples relevant to your use case and varied enough to cover edge cases, and wrap them in <example> tags so Claude can tell them apart from instructions. None of these techniques gives the guarantee constrained decoding does, so their output still has to be parsed and validated before anything downstream relies on it.

Sources23

4.Valid is not the same as true

Schema enforcement guarantees structure, not accuracy. A response that is well-formed, correctly typed and complete can still contain a hallucinated fact. The hallucination guide says outright that even the most advanced models can produce text that is factually wrong or inconsistent with the context they were given. A confident tone and a clean schema tell you nothing about correctness. Output that matters needs a check that looks at its content.

These techniques also produce things a parser can check. If the prompt permits "I don't have enough information to confidently assess this", that exact string can be detected and routed. Cited claims can be checked against their quotes. Empty [] brackets where the model removed an unsupported claim can be counted. Disagreement across N runs is a measurable signal. So being skeptical can be built into the pipeline as checks, not left to a reviewer's judgement.

Sources4

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A response with stop_reason end_turn is always complete and safe to parse.Why is that wrong?

   Claude can return an empty end_turn response with no content, usually after tool results. Check for content as well as the stop reason.

   Covered in Truncated, empty and unfinished responses

2. 2.The fix for an empty response is to send the same conversation, including the empty turn, again.Why is that wrong?

   Claude has already decided it is done, so resending changes nothing. Fix the message structure, and as a last resort add a continuation prompt in a new user message.

   Covered in Truncated, empty and unfinished responses

3. 3.Once structured outputs guarantee a valid schema, the content can be trusted without further checks.Why is that wrong?

   Schema compliance covers structure only. Claude can still produce factually incorrect or inconsistent text, so important claims need grounding techniques such as citations or best-of-N comparison.

   Covered in Valid is not the same as true

Practise it for real

See stop_reason signal a truncated response, then fix it by changing the request.

1. 1.Call client.messages.create with model "claude-opus-5-5", max_tokens=10 and the user message "Explain quantum physics".

   Why: A 10-token limit is too small for this question, so the response will almost certainly be cut off.

   You should see: A successful response with no error raised, containing a few words of text.

2. 2.Print response.stop_reason, and branch on it before using response.content.

   Why: Truncation shows up only in this field. The text itself gives no sign that it is incomplete.

   You should see: stop_reason is "max_tokens".

3. 3.Send the same request with max_tokens=1024 and check stop_reason again.

   Why: The documented fix for max_tokens is to raise the limit or continue the response.

   You should see: stop_reason is "end_turn" and the explanation is complete.