HTTP error
A non-success response, or a streaming error event, with error.type, a message, and request_id. There is no finished assistant answer.
Exam context: The status decides whether you retry, fix the request, or stop. When: The call fails before you have a usable stop_reason. When not: The API returned 200 and an assistant message. That path uses stop_reason.
See also: 4.1 Debugging and Error Handling
stop_reason
The field on a successful Messages response that says why generation stopped.
Exam context: end_turn, max_tokens, tool_use, and pause_turn need different next steps. When: You have a message object and you are about to parse it or loop. When not: The body is an error object. stop_reason is not how HTTP errors are classified.
See also: 4.1 Debugging and Error Handling
request_id
The request-id header and the request_id field on an error body. SDKs expose it on the response or the raw response.
Exam context: Support and CloudTrail correlate a failure to one call. When: An error, a timeout, or a streaming error needs a ticket. When not: A finished end_turn answer is wrong. The id does not explain a bad total.
See also: 4.1 Debugging and Error Handling
tool_result is_error
A flag on the tool_result block you send back when the tool failed.
Exam context: Claude recovers from a stated failure. An empty success removes that choice. When: The tool threw, timed out, or returned a domain error. When not: The tool succeeded. A real empty result stays is_error false and says it is empty.
See also: 4.1 Debugging and Error Handling
Trace
The ordered record of status or stop_reason, token use, content block types, and tool ids for one turn.
Exam context: The row separates a rejected call, an unfinished loop, a truncation, and a bad answer. When: A production failure has to be assigned to a layer. When not: You are designing the happy path and do not yet have a call to inspect.
See also: 4.1 Debugging and Error Handling
Integration layer
Your client, request assembly, tool runner, parser, and retry policy.
Exam context: Those bugs are deterministic and are yours to fix. The model never saw a valid finished turn. When: The trace shows a 4xx or 5xx, a dropped tool_result, a mutated thinking block, or a hidden tool error. When not: The API completed the turn and the content fails a business check.
See also: 4.1 Debugging and Error Handling
Model output
The assistant content after a successful, complete turn.
Exam context: Quality problems are handled with instructions, checks, and a retry that includes the validation error. When: stop_reason is end_turn, the token cap was not hit, and the tools reported honestly. When not: The text is a prefix from max_tokens or the window. That prefix is not the model's finished claim.
See also: 4.1 Debugging and Error Handling