@Takhoffman Would appreciate your review on this one - small targeted fix for the store parameter issue reported in #39086.

The core problem: createOpenAIResponsesContextManagementWrapper() early-exits at line 308 when neither forceStore nor useServerCompaction apply. This skips the onPayload hook entirely, so the store: false that pi-ai upstream hardcodes for Responses API stays in the payload. Strict OpenAI-compatible endpoints (Gemini via Cloudflare AI Gateway) reject it as an unknown field.

Fix adds a stripStore path that installs the hook and deletes store from the payload when compat.supportsStore === false. Two files changed, 34 lines added.

Greptile Summary

This PR fixes a targeted bug where the upstream pi-ai library hardcodes store: false in Responses API payloads, causing strict OpenAI-compatible endpoints (e.g. Gemini via Cloudflare AI Gateway) to reject requests with HTTP 400 when the model declares compat: { supportsStore: false }. The fix adds a stripStore condition that prevents the early-exit path and installs an onPayload hook to delete the store field before the request reaches the provider.

• extra-params.ts: Adds a stripStore boolean computed from !forceStore && OPENAI_RESPONSES_APIS.has(model.api) && model.compat?.supportsStore === false, and uses it to both prevent the early-return and delete payloadObj.store in the hook. The forceStore and stripStore branches are mutually exclusive by construction (since shouldForceResponsesStore already returns false when supportsStore === false), so the ordering of the two if blocks is safe.
• Test updates: The existing Azure OpenAI test assertion is correctly tightened from toBe(false) to not.toHaveProperty("store"), and a new test covers a non-OPENAI_RESPONSES_PROVIDERS custom provider (Gemini via Cloudflare), validating that provider membership in OPENAI_RESPONSES_PROVIDERS is not required for stripping to occur.

Confidence Score: 5/5

• This PR is safe to merge — it is a narrow, well-tested fix with no risk of regressions to existing behaviour.
• The change is minimal and surgical: one new boolean (stripStore) and one delete in an already-isolated onPayload hook. The conditions are mutually exclusive with the existing forceStore path by design, so the fix cannot interfere with direct OpenAI or Azure Responses store-forcing behaviour. Two new/updated test cases directly verify the affected code path for both an Azure and a custom provider scenario.
• No files require special attention.

_{Last reviewed commit: 608e201}

Landed on main in 3a761fbcf.

What we changed while landing:

• kept your core compatibility fix: remove store from Responses payloads when compat.supportsStore === false
• kept provider coverage for non-OpenAI OpenAI-compatible Responses providers
• kept the TS-safe compat access refinement
• retained/expanded regression coverage in pi-embedded-runner-extraparams.test.ts for both direct and non-OpenAI provider paths
• added changelog entry under 2026.3.7 fixes

Source commits reviewed:

• 608e2016c
• 8472052ae

Thanks @ademczuk.

Cheers for landing this. Good catch tightening the type narrowing on the cast.

@Takhoffman - would appreciate your review when you have a moment. This is a small fix (2 files, +23/-1) for #39086 where strict OpenAI-compatible endpoints reject the store field that pi-ai hardcodes.

Rebased onto latest main, all CI green, 58 tests passing.