openclaw - 💡(How to fix) Fix [Bug]: Custom OpenAI-compatible provider cannot complete tool calling with local vLLM + Qwen3.5 [1 comments, 1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When using OpenClaw with a custom OpenAI-compatible provider backed by a local vLLM endpoint serving Qwen3.5-35B-A3B-AWQ-4bit, normal chat works, but tool calling does not complete successfully.

OpenClaw repeatedly reports:

[agent/embedded] incomplete turn detected: ... stopReason=toolUse payloads=0 — surfacing error to user

This suggests the agent enters a toolUse stop state, but no valid payload is produced for the next step, so the turn is treated as incomplete.

Steps to reproduce

Environment

OpenClaw

• Version(s) observed: 2026.3.31 and 2026.3.2
• Mode: local gateway
• Provider type: custom OpenAI-compatible provider

Local model serving

• Backend: vLLM
• Model: Qwen3.5-35B-A3B-AWQ-4bit
• Endpoint: http://127.0.0.1:8000/v1
• Serving mode: OpenAI-compatible API

Local platform

• Linux host
• Local Docker-based vLLM serving

vLLM configuration

The local model works correctly for normal chat.

Example serving command in use:

vllm serve /data \
  --served-model-name Qwen3.5-35B-A3B-AWQ-4bit \
  --host 0.0.0.0 \
  --port 8000 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes \
  --reasoning-parser qwen3 \
  --default-chat-template-kwargs '{"enable_thinking": false}'

I also verified direct curl requests to /v1/chat/completions work correctly for normal generation.

OpenClaw provider config

{
  "models": {
    "providers": {
      "vllm-local": {
        "baseUrl": "http://127.0.0.1:8000/v1",
        "apiKey": "sk-local",
        "api": "openai-completions",
        "models": [
          {
            "id": "Qwen3.5-35B-A3B-AWQ-4bit",
            "name": "Qwen3.5-35B-A3B-AWQ-4bit",
            "reasoning": false,
            "input": ["text"],
            "contextWindow": 32768,
            "maxTokens": 8192
          }
        ]
      }
    }
  }
}

Symptoms

1. Normal chat works

Direct requests to vLLM return correct answers.

2. Tool calling fails inside OpenClaw

When the agent attempts tool use, OpenClaw logs:

[agent/embedded] incomplete turn detected: runId=... sessionId=... stopReason=toolUse payloads=0 — surfacing error to user

This happens repeatedly across multiple runs.

3. Failure appears specific to tool-use turn completion

The failure is not a general model-serving issue:

• non-tool chat works
• thinking enable/disable works
• reasoning parser works
• UI requests to the local model work

The problem appears when OpenClaw needs to complete a tool-calling turn through the custom OpenAI-compatible provider path.

Expected behavior

When the model decides to use a tool:

1. OpenClaw should send tool definitions and tool call context correctly to the provider.
2. The provider response should be parsed into a valid tool-use payload.
3. The tool call should execute and the turn should continue normally.

Actual behavior

OpenClaw reaches:

stopReason=toolUse

but produces:

payloads=0

and surfaces an error to the user instead of continuing the tool flow.

OpenClaw version

2026.3.31

Operating system

ubnutu24.04

Install method

npm全局

Model

Qwen3.5-35B-A3B-AWQ-4bit

Provider / routing chain

openclaw--local vLLM server--qwen

Additional provider/model setup details

What has already been verified

The following parts have already been ruled out:

• Local model availability: OK
• Basic OpenAI-compatible chat completion: OK
• Non-thinking mode: OK
• Reasoning parser path: OK
• Network reachability to local vLLM: OK

This makes the issue look more like:

• tool definitions not being sent
• tool-call response not being parsed
• custom provider tool-use turn handling being incomplete
• openai-completions provider path not fully compatible with tool calling

Suggested areas to inspect

1. Whether tools are actually sent for custom openai-completions providers

It would be helpful to confirm that OpenClaw sends tool definitions to the provider in this path.

2. Whether tool-call responses from OpenAI-compatible custom providers are parsed correctly

The model may be returning a tool call in a format OpenClaw does not fully convert into internal payloads.

3. Whether stopReason=toolUse handling assumes a payload shape not produced by custom providers

The current behavior suggests the turn is recognized as tool-use, but the follow-up payload object is missing.

4. Whether this path depends on openai-responses rather than openai-completions

If tool-calling support is incomplete for openai-completions, that should be documented clearly in provider configuration docs.

Requested improvements

1. Clarify whether tool calling is officially supported for custom OpenAI-compatible providers using api: "openai-completions".
2. Add debug logging for:
   • whether tools were sent
   • raw provider tool-call response
   • why payload generation resulted in payloads=0
3. Document any required provider format constraints for local vLLM + Qwen3.x / Qwen3.5 models.
4. If unsupported, fail early with a clearer message instead of surfacing an incomplete-turn error.

Logs, screenshots, and evidence

[agent/embedded] incomplete turn detected: runId=5817aa3c-22f3-40be-a45e-a8273321d09e sessionId=e2c78585-4c5f-4588-b7a9-1598fec4e053 stopReason=toolUse payloads=0 — surfacing error to user
[agent/embedded] incomplete turn detected: runId=ff5b2295-0631-4d69-b4e6-1496e9efeecf sessionId=e2c78585-4c5f-4588-b7a9-1598fec4e053 stopReason=toolUse payloads=0 — surfacing error to user
[agent/embedded] incomplete turn detected: runId=83cceb07-16c3-4575-a388-f5e0de182bfe sessionId=e2c78585-4c5f-4588-b7a9-1598fec4e053 stopReason=toolUse payloads=0 — surfacing error to user
[agent/embedded] incomplete turn detected: runId=8d6afd7b-de17-4ea2-be52-b215ad2753c8 sessionId=e2c78585-4c5f-4588-b7a9-1598fec4e053 stopReason=toolUse payloads=0 — surfacing error to user


---

Impact and severity

影响VLLM环境本地部署qwen3.5的用户 严重程度：令人烦恼、阻碍工作 频率：总是 后果：额外费用

Additional information

I am not reporting a general vLLM or Qwen3.5 serving failure.

The local model is usable for direct chat. The issue appears specifically in the OpenClaw custom-provider tool-calling integration path.

If needed, I can provide:

• exact openclaw.json provider config
• complete vLLM serve command
• side-by-side OpenClaw and vLLM logs from the same failing tool-use turn