Fast-coding pool returns malformed tool_calls responses

[stgreenb]

Summary

Models in the fast-coding pool (routeway/deepseek-v4-flash:free, nvidia/kimi-k2.6:free, openrouter/kimi-k2.6:free) return malformed responses when the client includes tool definitions in the request.

Observed Behavior

When a request includes a tools array (OpenAI-compatible), the fast-coding pool models respond with finish_reason: "tool_calls" but the message object does NOT contain a tool_calls array.

Expected Behavior

Either return a valid tool_calls array with function call arguments, or return finish_reason: "stop" if the model does not support tool calling.

Impact

Breaks client-side structured output capture. Pi agents on the fast-coding pool hang because they see finish_reason: "tool_calls" and wait for a tool_calls payload that never arrives.

Workaround

Use the default pool (model: "fcm:default") which handles tool calls correctly.

Steps to Reproduce

1. POST to FCM endpoint with tools array
2. Observe finish_reason: "tool_calls" with no tool_calls array in message

[houleixx]

This looks like a provider contract mismatch rather than a client-side agent-loop issue.

If the response contains:

```json
{
  "finish_reason": "tool_calls",
  "message": {
    "role": "assistant"
  }
}

but there is no message.tool_calls array, most OpenAI-compatible clients will get stuck or fail because finish_reason: "tool_calls" means the client should execute tool calls, but there is nothing executable in the response.

The provider should probably do one of these two things:

1. Return a valid message.tool_calls array with function name and JSON arguments.
2. Return finish_reason: "stop" if the selected model/pool does not support tool calling.

For the issue report, I would include one minimal raw request and raw response:

• model name
• tools array
• tool_choice, if present
• whether stream is true or false
• full assistant response shape
• whether the same request works with fcm:default

For collecting that evidence, a local OpenAI-compatible proxy is useful. I use ccglass for this kind of debugging because it shows the exact request body, tool schema, response body, streamed response reassembly, tool calls/tool results, usage, and latency in a local dashboard. It can also export the request as a raw transcript so maintainers can reproduce the malformed response more easily.

Project: https://github.com/jianshuo/ccglass