What happens
The OpenAI Chat decoder accepts assistant reasoning from either reasoning_content or reasoning. After normalization, the original field name is no longer available. If Switchyard rebuilds the Chat request, it emits the reasoning as reasoning.
For example, this assistant history:
{
"role": "assistant",
"content": "Visible answer",
"reasoning_content": "Historical reasoning"
}
can become:
{
"role": "assistant",
"content": "Visible answer",
"reasoning": "Historical reasoning"
}
Untouched same-format traffic may use the preserved request body and avoid this path. The problem appears when Switchyard must rebuild from its normalized request, including cross-format translation, disabled preservation, and request mutation.
Why it matters
Some OpenAI-compatible models require previous assistant reasoning to be returned under the same field name they produced. Together documents that the field is model-dependent and that callers should use the same field for input and output:
https://docs.together.ai/docs/inference/chat/reasoning
Changing the field name can cause a later turn or tool continuation to be rejected.
Expected behavior
A rebuilt request should use a reasoning field accepted by the selected target without duplicating the reasoning under both names.
The fix should account for both cases:
- faithful replay when the source and target use the same dialect;
- an explicit target choice when routing or translation changes the destination dialect.
Prior work
The fork PR is useful as a reproduction and prototype, but this issue does not prescribe its public protocol changes as the final implementation.
What happens
The OpenAI Chat decoder accepts assistant reasoning from either
reasoning_contentorreasoning. After normalization, the original field name is no longer available. If Switchyard rebuilds the Chat request, it emits the reasoning asreasoning.For example, this assistant history:
{ "role": "assistant", "content": "Visible answer", "reasoning_content": "Historical reasoning" }can become:
{ "role": "assistant", "content": "Visible answer", "reasoning": "Historical reasoning" }Untouched same-format traffic may use the preserved request body and avoid this path. The problem appears when Switchyard must rebuild from its normalized request, including cross-format translation, disabled preservation, and request mutation.
Why it matters
Some OpenAI-compatible models require previous assistant reasoning to be returned under the same field name they produced. Together documents that the field is model-dependent and that callers should use the same field for input and output:
https://docs.together.ai/docs/inference/chat/reasoning
Changing the field name can cause a later turn or tool continuation to be rejected.
Expected behavior
A rebuilt request should use a reasoning field accepted by the selected target without duplicating the reasoning under both names.
The fix should account for both cases:
Prior work
The fork PR is useful as a reproduction and prototype, but this issue does not prescribe its public protocol changes as the final implementation.