Return finish_reason=tool_calls instead of stop when a tool call is needed

[Quallyjiang]

According to openai api reference, finish_reason shall be set to tool_calls when a tool is called. Current ovms always returns stop. Some coding agents including opencode uses finish_reason to decide if step is completed or is waiting for a tool call. Setting this field properly is important for such agent software.

[dkalinowski]

Do you know about any agent that relies on finish reason = tool_calls?

[xiazhu]

For example, https://github.com/anomalyco/opencode

https://github.com/anomalyco/opencode/blob/dev/packages/console/app/src/routes/zen/util/provider/openai.ts#L366

[mzegla]

Thanks for reporting that. As OpenAI API is constantly evolving we are not 100% in sync with all the changes, so newer changes like more possible options in finish_reason are not yet incorporated. If existing tools integrations rely on that, we should plan supporting it in OVMS.

[newbhumika]

This makes sense — some agent frameworks rely on finish_reason to distinguish between normal completion and tool invocation flow.

From a compatibility perspective with the OpenAI API schema, returning "tool_calls" when tool_calls are present in the response would improve interoperability without changing core inference logic.

Before attempting an implementation, I’d like to clarify:

Is the internal generation pipeline already able to detect when a tool call was emitted (e.g., via structured tool call output)?

Would this change be limited to the REST response formatting layer, or does it require deeper adjustments in the generation handler?

If this is primarily a response-mapping adjustment, I’d be happy to explore adding conditional logic so that finish_reason reflects "tool_calls" when appropriate.