Bug: OpenAI responses API does not send previous_response_id in multi-turn sessions

[wildoranges]

Description

This issue had an initial gap in OpenCode’s Responses caching chain: previous_response_id was not persisted/reused across turns.

That part is now fixed in PR #20848, but we also found a second cache-hit gap:

For custom providers using npm: "@ai-sdk/openai" (with a non-openai provider ID), promptCacheKey was not always set because the old condition mostly relied on providerID === "openai" (or manual setCacheKey).

So requests could carry previous_response_id but still miss stable cache routing from prompt_cache_key.

This is now addressed by extending cache option wiring for SDK-based OpenAI providers.

Plugins

oh-my-opencode

OpenCode version

• Reproduced on: v1.3.13 and local dev build
• Verified fixed on: 0.0.0-feat/gpt-incremental-caching-202604031035

Steps to reproduce

1. Configure a custom provider using npm: "@ai-sdk/openai" with a provider ID not equal to openai.
2. Start a multi-turn session with a stable large prompt prefix.
3. Inspect outgoing requests / logs.
4. Before fix: previous_response_id may be present, but prompt_cache_key may be missing.
5. After fix: both are present and cache behavior improves.

Screenshot and/or share link

N/A

Operating System

Linux

Terminal

bash

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The issue does not use one of the required issue templates (Bug Report, Feature Request, or Question). Bug reports require a Description field and steps to reproduce so maintainers can verify the behavior.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Codex model response latency increases significantly as conversation grows #9045: Describes the same root cause — OpenAI Responses API responseId is returned but never stored, and previousResponseId is never passed on subsequent turns, causing full history to be resent each time.

If you believe this was flagged incorrectly, please let a maintainer know.

[wildoranges]

Additional reference for the Codex CLI implementation pattern:

• prompt_cache_key is set from the conversation id:

  • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/src/client.rs#L734-L752

• WebSocket create supports previous_response_id:

  • type definition:
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/codex-api/src/common.rs#L197-L214
  • set on follow-up turns:
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/src/client.rs#L852-L856

• Incremental input reuse logic (append-only extension check + delta slicing):

  • baseline/delta computation:
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/src/client.rs#L782-L819
  • actual slice:
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/src/client.rs#L811-L815
  • tests asserting previous_response_id + incremental payload behavior:
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/tests/suite/client_websockets.rs#L1145-L1183
    • https://github.com/openai/codex/blob/af8a9d2d2ba84a1dafad6fa51fe3d63e96aceb75/codex-rs/core/tests/suite/client_websockets.rs#L1264-L1297

For this issue, PR #20848 already covers the critical part (persisting/reusing response id in OpenCode).
Incremental-input slicing can be a follow-up optimization if desired.

[wildoranges]

Update: this is now fully covered in PR #20848.

In addition to the original previous_response_id persistence/reuse fix, the branch now also includes a cache-hit follow-up for SDK-based OpenAI providers:

• promptCacheKey is now applied for @ai-sdk/openai and @ai-sdk/github-copilot (not only providerID === "openai").

This closes the gap where custom OpenAI providers could carry previous_response_id but miss stable prompt_cache_key routing.

[wildoranges]

Additional compatibility fix pushed in a064a2f66:

• Copilot backend rejects previous_response_id (previous_response_id is not supported).
• Updated transform logic to only send previousResponseId for @ai-sdk/openai.
• promptCacheKey behavior remains unchanged.

This keeps OpenAI caching improvements while restoring Copilot compatibility.