fix: strip prompt_cache_key for non-OpenAI openai-responses endpoints by ShaunTsai · Pull Request #49877 · openclaw/openclaw

ShaunTsai · 2026-03-18T15:23:38Z

Summary

Problem: Volcano Engine DeepSeek (and other non-OpenAI providers using the openai-responses API) returns HTTP 400 unknown field "prompt_cache_key" because pi-ai unconditionally injects prompt_cache_key and prompt_cache_retention into OpenAI Responses request bodies.
Why it matters: users configuring Volcano Engine models cannot use them at all — every request fails with a 400.
What changed: added prompt_cache_key/prompt_cache_retention stripping to the existing createOpenAIResponsesContextManagementWrapper in openai-stream-wrappers.ts, using the existing isDirectOpenAIBaseUrl() check to determine whether the endpoint actually supports these fields.
What did NOT change (scope boundary): prompt caching behavior for direct OpenAI, Azure OpenAI, and GitHub Copilot endpoints (they pass the isDirectOpenAIBaseUrl check). Anthropic caching uses a different mechanism (cacheRetention option) and is unaffected. The existing createBedrockNoCacheWrapper for non-Anthropic Bedrock models is also unchanged. No changes to extra-params.ts.

Change Type (select all)

Bug fix

Scope (select all touched areas)

Gateway / orchestration

Linked Issue/PR

Fixes [Bug]: prompt_cache_key not supported by Volcano Engine DeepSeek #48155
Supersedes fix: strip prompt_cache_key for providers that reject unknown fields #49727 (closed — that approach used a separate provider allowlist that duplicated knowledge already in openai-stream-wrappers.ts and was missing azure-openai)

User-visible / Behavior Changes

Volcano Engine DeepSeek (and other non-OpenAI providers using openai-responses API) will no longer fail with HTTP 400 on unknown prompt_cache_key field.

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) No
Data access scope changed? (Yes/No) No

Repro + Verification

Environment

OS: macOS
Runtime/container: Node 22+
Model/provider: volces/deepseek-v3-2-251201

Steps

Configure a volces provider with deepseek-v3-2-251201 model
Send a message to the agent

Expected

Agent responds normally

Actual

HTTP 400: unknown field "prompt_cache_key"

Evidence

Code inspection: traced prompt_cache_key injection from pi-ai openai-responses stream through to the HTTP request body; confirmed the field is only meaningful for OpenAI's own API
Verified the isDirectOpenAIBaseUrl() check correctly identifies OpenAI (api.openai.com), ChatGPT (chatgpt.com), and Azure OpenAI (*.openai.azure.com) endpoints — all other baseUrls (including Volcano Engine) return false

Human Verification (required)

Verified scenarios: traced the full code path from applyExtraParamsToAgent → createOpenAIResponsesContextManagementWrapper → applyOpenAIResponsesPayloadOverrides; confirmed stripPromptCache is true for non-direct-OpenAI endpoints and false for direct OpenAI
Edge cases checked: azure-openai provider with *.openai.azure.com baseUrl passes isDirectOpenAIBaseUrl and keeps prompt cache fields; providers with no baseUrl (empty string) get fields stripped (safe — no-op since pi-ai only injects for openai-responses)
What I did not verify: live Volcano Engine API call (no credentials available); full pnpm check currently has pre-existing typing debt failures on main unrelated to this PR

AI Disclosure

AI-assisted (Kiro CLI)
I understand what the code does

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No

Failure Recovery (if this breaks)

How to disable/revert: revert this commit
Files/config to restore: src/agents/pi-embedded-runner/openai-stream-wrappers.ts
Known bad symptoms: if isDirectOpenAIBaseUrl fails to recognize a legitimate OpenAI endpoint, prompt caching would silently stop working for that endpoint

Risks and Mitigations

Risk: a new OpenAI-compatible endpoint hostname (not api.openai.com, chatgpt.com, or *.openai.azure.com) would need isDirectOpenAIBaseUrl updated.
- Mitigation: this is the same function already used for store field decisions — any such endpoint would already be broken for store: true forcing, so the fix would naturally cover both.

greptile-apps · 2026-03-18T15:26:32Z

Greptile Summary

This PR fixes a real user-facing bug where third-party providers (e.g. Volcano Engine DeepSeek) using the openai-responses API format received HTTP 400 errors because pi-ai unconditionally injected prompt_cache_key and prompt_cache_retention fields that are only meaningful for OpenAI's own API.

What changed:

A new stripPromptCache boolean is computed in createOpenAIResponsesContextManagementWrapper using the already-established isDirectOpenAIBaseUrl() guard.
applyOpenAIResponsesPayloadOverrides now deletes prompt_cache_key and prompt_cache_retention from the payload when stripPromptCache is true.
The early-return optimization gate at line 313 is extended with !stripPromptCache so the wrapper is correctly engaged for affected non-OpenAI providers.

Assessment:

The implementation is consistent with the existing patterns (shouldForceResponsesStore, shouldStripResponsesStore) and correctly scopes the change to openai-responses streams only.
The fix correctly preserves prompt caching for api.openai.com, chatgpt.com, and *.openai.azure.com endpoints (all pass isDirectOpenAIBaseUrl).
The main gap is the absence of unit tests for the new behavior; createOpenAIResponsesContextManagementWrapper has no dedicated test file, so a future regression could silently break prompt caching for legitimate OpenAI users without any observable error.

Confidence Score: 4/5

Safe to merge — the fix is scoped, logic is sound, and the only concern is missing test coverage for the new behavior.
The change is small, targeted, and reuses an already-trusted helper (isDirectOpenAIBaseUrl). The fix correctly solves the reported HTTP 400 regression for Volcano Engine and similar providers without altering the path for direct OpenAI, Azure, or ChatGPT endpoints. Score is 4 rather than 5 solely because there are no unit tests covering the new stripPromptCache logic, making it harder to prevent future regressions to OpenAI prompt-caching behavior.
No files require special attention beyond the noted lack of test coverage.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/openai-stream-wrappers.ts
Line: 309-312

Comment:
**No test coverage for stripPromptCache**

The new `stripPromptCache` behavior has no test coverage. Given that:
1. A regression here would silently break prompt caching for all direct OpenAI users without any observable error.
2. The existing `createOpenAIResponsesContextManagementWrapper` has no dedicated test file (confirmed by the absence of `openai-stream-wrappers.test.ts`).

It would be valuable to add unit tests covering at least:
- Volcano Engine (or any non-`isDirectOpenAIBaseUrl` provider) — `prompt_cache_key` and `prompt_cache_retention` are stripped from the payload.
- Native OpenAI (`baseUrl: "https://api.openai.com/v1"`) — fields are **not** stripped.
- Azure OpenAI (`baseUrl: "https://myinstance.openai.azure.com/..."`) — fields are **not** stripped.
- Model with `api !== "openai-responses"` — `stripPromptCache` is `false` (no unnecessary wrapper overhead).

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "fix: strip prompt_ca..."}

greptile-apps · 2026-03-18T15:26:36Z

+    const stripPromptCache =
+      typeof model.api === "string" &&
+      OPENAI_RESPONSES_APIS.has(model.api) &&
+      !isDirectOpenAIBaseUrl(model.baseUrl);


No test coverage for stripPromptCache

The new stripPromptCache behavior has no test coverage. Given that:

A regression here would silently break prompt caching for all direct OpenAI users without any observable error.

The existing createOpenAIResponsesContextManagementWrapper has no dedicated test file (confirmed by the absence of openai-stream-wrappers.test.ts).

It would be valuable to add unit tests covering at least:

Volcano Engine (or any non-isDirectOpenAIBaseUrl provider) — prompt_cache_key and prompt_cache_retention are stripped from the payload.

Native OpenAI (baseUrl: "https://api.openai.com/v1") — fields are not stripped.

Azure OpenAI (baseUrl: "https://myinstance.openai.azure.com/...") — fields are not stripped.

Model with api !== "openai-responses" — stripPromptCache is false (no unnecessary wrapper overhead).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-runner/openai-stream-wrappers.ts Line: 309-312 Comment: **No test coverage for stripPromptCache** The new `stripPromptCache` behavior has no test coverage. Given that: 1. A regression here would silently break prompt caching for all direct OpenAI users without any observable error. 2. The existing `createOpenAIResponsesContextManagementWrapper` has no dedicated test file (confirmed by the absence of `openai-stream-wrappers.test.ts`). It would be valuable to add unit tests covering at least: - Volcano Engine (or any non-`isDirectOpenAIBaseUrl` provider) — `prompt_cache_key` and `prompt_cache_retention` are stripped from the payload. - Native OpenAI (`baseUrl: "https://api.openai.com/v1"`) — fields are **not** stripped. - Azure OpenAI (`baseUrl: "https://myinstance.openai.azure.com/..."`) — fields are **not** stripped. - Model with `api !== "openai-responses"` — `stripPromptCache` is `false` (no unnecessary wrapper overhead). How can I resolve this? If you propose a fix, please make it concise.

frankekn · 2026-03-19T06:40:51Z

@codex review

chatgpt-codex-connector · 2026-03-19T06:45:43Z

Codex Review: Didn't find any major issues. Another round soon, please!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

pi-ai unconditionally injects prompt_cache_key and prompt_cache_retention into openai-responses request bodies. Third-party providers using the openai-responses API (e.g. Volcano Engine DeepSeek) reject these unknown fields with HTTP 400. Instead of maintaining a separate provider allowlist, fold the stripping logic into the existing createOpenAIResponsesContextManagementWrapper which already handles openai-responses payload overrides. Use the existing isDirectOpenAIBaseUrl() check to determine whether the endpoint actually supports these fields. Fixes openclaw#48155

frankekn · 2026-03-19T07:12:44Z

Thanks @ShaunTsai. Landed in bcc725f from source head ShaunTsai@7185eb5 .

@ShaunTsai