Claude Code via Enterprise account seeing degraded responses, am I misconfigured?

[Mayank-Jain-1]

Title

Claude Code via Enterprise account — seeing degraded responses, am I misconfigured?

Body

Hi @dwgx! First off, thank you for this awesome project — it's been really helpful. 🙏

I'm using WindsurfAPI to run Claude Code through my Windsurf Enterprise account (Cascade/LS path, since DEVIN_CONNECT doesn't work with Enterprise sk-ws-01-* tokens).

It mostly works, but I'm frequently seeing degraded behavior from Claude Code that I don't see on direct Anthropic API:

• Forgetting the task — mid-conversation it starts asking "What would you like me to do?" as if it lost all context
• Claiming the project is empty — says there are no files when the directory is full of them
• Not using tools — responds with filler text instead of actually calling Read/Glob/Edit (logs show emulateTools=true but parser found 0 tool_calls)
• Occasional "API Error: Server error mid-response" — stream dying partway through, especially with Opus thinking models

I wanted to check — am I doing something wrong here? Are there specific guidelines or a recommended config for running Claude Code through WindsurfAPI? Any tunables I should be setting that I'm not?

Here's my current .env (beyond the defaults):

HOST=0.0.0.0
CASCADE_REUSE_BY_CALLER=1
CASCADE_POOL_MAX=5
CASCADE_REUSE_HASH_SYSTEM=0
STICKY_SESSION_ENABLED=1
WINDSURFAPI_SINGLE_TENANT_CACHE=1
CASCADE_MAX_WAIT_MS=900000
CASCADE_WARM_STALL_THINKING_MS=240000
WINDSURFAPI_DEGRADED_SERVE=1
WINDSURFAPI_RL_BURST_MS=15000
WINDSURFAPI_RL_CLIENT_BACKOFF_FLOOR_MS=30000
MAX_TOKENS=16384
RESPONSE_STORE_ENABLED=1

Setup: Windows 11, WindsurfAPI v3.9.19, Enterprise account, Claude Code.

Any advice would be greatly appreciated — happy to share logs if that helps! Thanks again for the project.

[dwgx]

Thanks for the detailed report — the .env and the emulateTools=true but parser found 0 tool_calls line are exactly what makes this answerable.

Short version: your config is not the problem. I read each of your settings against the code, and none of them is wrong. But there are two knobs you are missing that map directly onto two of your four symptoms, and one of your symptoms is a known model-family limit rather than a configuration issue.

What I verified about your current settings

Setting	Verdict
CASCADE_REUSE_HASH_SYSTEM=0	Redundant but harmless — this is already the default (conversation-pool.js:357). It exists because Claude Code's system prompt carries dynamic project state, so hashing it makes the fingerprint never match. That was the root cause of the "gibberish" outbreak in #24. Setting it to 0 explicitly changes nothing.
CASCADE_REUSE_BY_CALLER=1 + WINDSURFAPI_SINGLE_TENANT_CACHE=1	Correct pairing for a single-user self-host. The second one is what makes a guessed :client:<ip+ua> bucket count as a real per-caller scope; without it, reuse and sticky both decline to bind.
STICKY_SESSION_ENABLED=1	Right call, and on the Cascade path it matters for the same reason as DEVIN_CONNECT: upstream prompt cache is per-account.
CASCADE_MAX_WAIT_MS=900000 / CASCADE_WARM_STALL_THINKING_MS=240000	Generous but sane for Opus thinking.
MAX_TOKENS=16384	Fine.

So: nothing to undo.

Symptom 3 — emulateTools=true but parser found 0 tool_calls

emulateTools=true is the correct path for Claude Code on the Cascade/LS route, not a fallback you got dropped into. Cascade's protocol layer does not accept an OpenAI-style tools[] schema, so tool calls are carried as <tool_call> markup in text and parsed back out. The native bridge (WINDSURFAPI_NATIVE_TOOL_BRIDGE) is not the fix here — its own docs say "do not treat it as a general fix for local IDE tool calls."

0 tool_calls means the model narrated the action instead of emitting the markup. There is a recovery layer for exactly that, and it is off by default for Claude models:

WINDSURFAPI_NLU_RETRY=1

chat.js:4731 — it auto-enables only for GLM/Kimi providers, because Claude's first-pass compliance is normally good enough that the retry is not worth the extra upstream call. On Enterprise/Cascade the compliance is evidently worse than on the direct API, so please try turning it on. When the parser finds zero tool calls it re-issues the turn with a correction rather than handing you the filler text.

Symptoms 1 and 2 — "forgetting the task", "project is empty"

These two are the same failure with different surface: the turn reached the model without the prior context. With CASCADE_REUSE_BY_CALLER=1 a fingerprint miss falls back to the most recent cascade for that caller+model, which is the right behaviour for a single user — but if the reuse declined (rather than mismatched), each turn starts cold and the model genuinely has no history.

Please check what the logs say at that moment. Grep for cascade around a bad turn — a reuse line naming an account id means it bound; its absence means it started fresh. That one line separates "reused the wrong cascade" from "never reused at all", and the fixes are opposite.

Symptom 4 — "Server error mid-response" on Opus thinking

Model-family limit rather than config. The README's own recommendation for tool-driving clients is explicit:

Claude Code / Cline / Codex 调本地文件 / 跑命令优先 claude-haiku-4.5 或 claude-sonnet-4.6

Opus-class thinking models on the Cascade backend stall and drop mid-stream far more often, and WINDSURFAPI_DEGRADED_SERVE=1 (which you have) will serve the partial rather than failing — that is why you see it as a mid-response error instead of a clean retry. Try claude-sonnet-4.6 for the tool-heavy work and keep Opus for reasoning turns that do not need tools.

What would help most

If WINDSURFAPI_NLU_RETRY=1 does not move symptom 3, a log excerpt around one bad turn is the shortest path — specifically the emulateTools line plus any cascade line within a few seconds of it. That tells us whether the model emitted malformed markup (parser problem, our bug) or no markup at all (compliance problem, retry territory).

One thing I cannot verify from here: Enterprise sk-ws-01-* on the Cascade path is a configuration nobody in this repo has paid-tested end to end. So if the above does not help, that is worth stating plainly rather than guessing further.

[dwgx]

Correction to my table above — I got CASCADE_REUSE_HASH_SYSTEM backwards. The verdict said "already the default, changes nothing"; both halves are wrong.

What I checked

src/conversation-pool.js:357:

if (process.env.CASCADE_REUSE_HASH_SYSTEM === '0') return '';

0 is an explicit opt-out. The default is ON — the system prompt is hashed into the reuse fingerprint. The comment four lines above states the reasoning:

// Default ON since the audit found that "default exclude system"
// caused silent cross-system reuse.

docs/releases/RELEASE_NOTES_2.0.25.md:17 says the same, and calls it a reversal of the older default.

Why I got it wrong, since it affects you: README.en.md:308 documented the default as 0, and README.md had no row for it at all. I read the table instead of the code. Both are fixed now.

What it actually does in your setup — narrower than "this is your bug"

I traced it rather than assuming, because your configuration changes the picture.

systemDigest() feeds buildKeyPayload (conversation-pool.js:429, :479), which also hashes caller, model, route, tools and the projected turn history. A checkout() hit returns a pooled entry carrying a cascadeId (:661) — a live upstream conversation that already holds its own history. So a wrong match does mean inheriting someone else's context, which is the symptom class you described.

But two things bound it for you:

1. callerKey is inside the fingerprint (:435), and checkout re-checks it (:558-561). You are a single user, so cross-user contamination is not your risk.
2. Setting =0 removes only the system prompt from the key. The turn history is still hashed, so two different conversations still get different fingerprints.

So the honest statement is: =0 weakens isolation to exactly one axis — two requests that share caller, model, tools and prior turns but differ only in system prompt will collide and resume the same cascade. With Claude Code that is not far-fetched (its system prompt carries cwd/timestamp state that shifts between sessions while the conversation prefix looks identical), but it is narrower than "this explains your symptoms 1–2."

I'm not going to claim it is your root cause. It is a real isolation hole, it is on by your explicit setting, and it is cheap to eliminate.

Worth trying

Remove the CASCADE_REUSE_HASH_SYSTEM=0 line entirely — do not set it to 1; unset is the ON default — then restart and re-run whatever reproduced symptoms 1–2.

Expect a lower cascade reuse hit rate. That is the intended trade-off (correctness over hit rate) and it is why the opt-out exists at all: normalizeSystemPromptForHash (conversation-pool.js:123, applied per text block at :368) already strips the dynamic chunks — dates, cwd, session ids, ISO timestamps, UUIDs — so with the default ON, a drifting Claude Code prompt should still match more often than you'd expect.

If removing it changes nothing, that is useful information too, and I'd look next at CASCADE_REUSE_BY_CALLER=1: on a fingerprint miss it falls back to "the latest cascade for this caller+model" (_callerFallbackCheckout, :596), which is a deliberately looser match and the other place a stale context could enter.

The rest of the table stands

CASCADE_REUSE_BY_CALLER=1 + WINDSURFAPI_SINGLE_TENANT_CACHE=1, STICKY_SESSION_ENABLED=1, the two Cascade timeouts, MAX_TOKENS — re-read each against the code, all correct as written.

Sorry for the wrong verdict. "Nothing to undo" was wrong: there is one line to undo, and it is worth one test run.