finish_reason
A field in LLM API responses that identifies the reason a model stopped generating output. Common values include natural completion (stop/end_turn), length truncation (length/max_tokens), and content filtering (content_filter/SAFETY), allowing callers to determine whether the model completed its output normally.
Core Facts
Timeline (last 90 days)
Production routing logic should not look only at the HTTP status code, but should also check whether finish_reason and content are non-empty, and treat finish_reason of length with empty content as a hard failure rather than a parseable result.
A finish_reason value of length or MAX_TOKENS means the model was forcibly interrupted rather than concluding on its own.
Author Serguey Asael Shinder recommends reading the stop reason after every LLM call, just as one would read an HTTP status code.
finish_reason should be logged together with call costs and plotted on the same monitoring dashboard to improve observability.
Streaming output combined with incremental validation can trigger an immediate alert or retry upon detecting finish_reason: length, without having to wait for the entire response to return.
Only responses with a finish_reason of stop or tool_calls should be cached; responses truncated by length or those that errored should not be cached.
When large language model APIs return responses, they typically include a finish_reason field with common values including stop, length, and tool_calls.
All Facts (7)
A finish_reason value of length or MAX_TOKENS means the model was forcibly interrupted rather than concluding on its own.
65%UnverifiedProduction routing logic should not look only at the HTTP status code, but should also check whether finish_reason and content are non-empty, and treat finish_reason of length with empty content as a hard failure rather than a parseable result.
50%UnverifiedAuthor Serguey Asael Shinder recommends reading the stop reason after every LLM call, just as one would read an HTTP status code.
50%Unverifiedfinish_reason should be logged together with call costs and plotted on the same monitoring dashboard to improve observability.
50%UnverifiedStreaming output combined with incremental validation can trigger an immediate alert or retry upon detecting finish_reason: length, without having to wait for the entire response to return.
50%UnverifiedOnly responses with a finish_reason of stop or tool_calls should be cached; responses truncated by length or those that errored should not be cached.
50%UnverifiedWhen large language model APIs return responses, they typically include a finish_reason field with common values including stop, length, and tool_calls.
50%