end_turnMaps to stopThe assistant naturally finished its turn.
Status and Stop Reasons
Status and Stop Reasons
Section titled “Status and Stop Reasons”Different protocols use different names for “the model stopped producing output”. ProxAI treats these as related protocol concepts, not interchangeable raw fields.
Terminal concepts
Section titled “Terminal concepts”| Protocol | Terminal fields or events | Meaning |
|---|---|---|
| OpenAI Responses | status, output items, response.completed | The response envelope and typed events describe completion. |
| OpenAI Chat Completions | choices[].finish_reason, [DONE] | Each choice has a finish reason; the stream ends with [DONE]. |
| Anthropic Messages | stop_reason, stop_sequence, message_stop | The final message carries stop metadata; streaming ends with message_stop. |
Reason map
Section titled “Reason map”Anthropic Messages stop_reason
max_tokensMaps to lengthGeneration stopped because the token budget was reached.
stop_sequenceMaps to stopA configured stop sequence was generated. stop_sequence may identify the matched sequence.
tool_useMaps to tool_callsThe assistant produced a tool-use request and expects the client/tool loop to continue.
pause_turnMaps to stop or protocol-specific continuationProvider asks the client to continue later; conversion must be careful not to pretend it is a normal final answer.
refusalMaps to content_filter or refusal metadataProvider refused the request. Preserve refusal semantics where the target protocol can represent them.
OpenAI Chat Completions finish_reason
stopMaps to end_turn / stop_sequenceThe model stopped normally or hit an explicit stop condition.
lengthMaps to max_tokensThe model stopped because the token budget was exhausted.
tool_callsMaps to tool_useThe assistant emitted tool calls.
content_filterMaps to refusal / filtered statusThe provider stopped output for safety or policy reasons.
Why nullable fields exist
Section titled “Why nullable fields exist”Wire structs often use nullable/missing-compatible shapes even when provider documentation says a field is required. This is deliberate:
| Case | Why ProxAI accepts it |
|---|---|
| SDK schemas mark required-nullable fields | Some SDK-generated types allow the field to be omitted while still treating null as valid. |
| Upstream compatibility layers omit null fields | OpenAI-compatible or Anthropic-compatible proxies may drop fields whose value is null. |
| Streaming accumulation is partial before terminal event | Before the terminal event, stop information may not be known yet. |
| Error or interrupted responses are not normal final messages | A failed upstream response should be handled as an error, not forced into a fake stop reason. |
From a logical non-streaming success path, a final Anthropic message should include stop information. The parser still accepts missing/null values so ProxAI can produce a clear translation or upstream error instead of crashing on an overly strict model.
Contract
Section titled “Contract”- ProxAI observes streaming terminal events; it does not treat arbitrary byte-stream closure as semantic completion.
- ProxAI does not fabricate provider-specific reason details such as upstream
code,param, or matched stop sequences. - Cross-protocol mappings should preserve behavior first, exact field spelling second.
- Tool-call terminal states must remain distinct from natural text completion.