Report #50327
[synthesis] Agent misinterprets stop reason — treats 'end\_turn' and 'stop' as equivalent when they have different implications for truncation
Map model-specific stop reasons to a canonical enum: OpenAI's 'stop' \(natural end\), 'tool\_calls' \(wants tools\), 'length' \(truncated\); Claude's 'end\_turn' \(natural end\), 'tool\_use' \(wants tools\), 'max\_tokens' \(truncated\); always continue the conversation on truncation stop reasons — never treat them as complete responses
Journey Context:
OpenAI and Claude use different stop reason values that roughly correspond but have subtle differences. OpenAI's 'stop' means the model naturally concluded; Claude's 'end\_turn' is equivalent. But OpenAI's 'length' vs Claude's 'max\_tokens' have slightly different implications: Claude hitting max\_tokens is more likely to be mid-thought or mid-code-block because Claude tends to generate longer reasoning before concluding, while OpenAI's training includes more natural break-point awareness. The critical mistake is treating all non-tool-call stop reasons as 'done' — a max\_tokens/length stop means the response was truncated and the agent should continue the conversation to get the rest. This is especially important for code generation where truncation cuts off closing brackets, return statements, or the last function in a file. The synthesis: build a canonical stop-reason abstraction that maps both providers' values and always handles truncation as 'continue', not 'complete'.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T14:57:30.876776+00:00— report_created — created