Intermittent tool call parsing issues when using WindsurfPoolAPI through OpenAI-compatible clients

[mik3lang3lo]

Hi! First of all, thank you for the project. We have been testing WindsurfPoolAPI in a private self-hosted/home-lab setup and it has been very useful for exposing Windsurf models through an OpenAI-compatible interface.

I wanted to open this issue to check whether other users have experienced similar behavior around tool/function calling.

Context

We are using WindsurfPoolAPI as part of a local agent stack, roughly like this:

• OMP / Pi Coding Agent / Hermes Agent
• CLIProxyAPI as a central OpenAI-compatible gateway
• WindsurfPoolAPI as a provider behind CLIProxyAPI
• Models such as swe-1.6 and deepseek-v4
• Deployment through Docker/Coolify on a private Ubuntu Server, accessible only through Tailscale

So the path is generally:

OMP / Pi / Hermes
→ CLIProxyAPI
→ WindsurfPoolAPI
→ Windsurf Language Server / Windsurf models

I am not sure yet whether the issue is specific to our setup with Coolify + CLIProxyAPI, or whether it can also happen when using WindsurfPoolAPI directly.

Problem observed

In multiple agent clients, tool calls sometimes worked correctly, but in other cases the model output appeared as visible text instead of being parsed/executed as a structured tool call.

Examples of the kind of behavior we observed:

• The assistant would print something resembling a tool call in the chat instead of executing it.
• Files that should have been created by a tool call were not created.
• The agent would stop after emitting something that looked like a tool call.
• Some runs ended with no useful final answer after a tool operation.
• The behavior was intermittent: sometimes the same model/client path produced proper tool calls, sometimes it leaked tool-call-like markup into the visible response.

The issue appeared especially noticeable in coding-agent style workflows, where the user asks the agent to create/edit/validate files and then provide a final summary.

Affected clients in our tests

We observed this while experimenting with:

• OMP
• Pi Coding Agent
• Hermes Agent
• Telegram/Hermes workflows
• Windows and Ubuntu clients using the same backend gateway

This made it feel like the issue was not isolated to one frontend client.

What we changed locally

We made some local changes to improve the behavior in our environment, mainly around making the tool-call handling/parsing more tolerant of different model output formats.

We are not posting the exact patch in this issue yet because we first wanted to ask:

1. Is this a known issue?
2. Have other users seen similar tool-call parsing problems?
3. Is there an expected/canonical tool-call format that WindsurfPoolAPI currently supports?
4. Could this be caused by using WindsurfPoolAPI behind another OpenAI-compatible gateway such as CLIProxyAPI?
5. Would you be interested in a reproduction case or in us sharing the local adjustments we made?

Why I am opening this issue

We managed to get our local stack working better after some adjustments, but before assuming our fix is generally useful, I wanted to check whether this behavior is known or expected.

If helpful, I can provide:

• examples of leaked tool-call outputs;
• a minimal reproduction request;
• details about our OpenAI-compatible request payload;
• information about the models involved;
• the local parser changes we made.

Thanks again for the project.

[mik3lang3lo]

Just to add a positive note here: I really like this project and ended up choosing WindsurfPoolAPI over WindsurfAPI for our setup.

When comparing both projects, WindsurfPoolAPI felt like a better fit for our use case for a few reasons:

• it already provides an OpenAI-compatible API, which made integration with OMP, Pi Coding Agent, Hermes and CLIProxyAPI much easier;
• the dashboard is useful for account/model management;
• the pool/account approach is more complete for our scenario;
• model detection and allowlist/blocklist controls are very helpful;
• the Docker/runtime approach felt cleaner for a private self-hosted deployment;
• compared with WindsurfAPI, it looked a bit safer operationally for our setup, especially because we did not want self-update/docker.sock style behavior;
• extracting and mounting the official Windsurf Language Server manually also gave us more confidence about what was running.

So overall, thank you again for building this. It has been very useful in our home-lab/private agent stack.

The tool-call issue I described above is not meant as criticism of the project. We are pushing the setup through several OpenAI-compatible layers and multiple coding-agent clients, so it may be an edge case caused by our architecture. I just wanted to report it in case others are seeing similar behavior, and I’m happy to share more details if it helps.