fix: reuse OpenAI Responses previous_response_id across turns

[YanzheL]

Issue for this PR

Closes #20847

Related: #9045, #20848

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This PR fixes the OpenAI Responses continuity bug that makes long-running sessions slower over time.

Today, follow-up OpenAI Responses requests can miss previous_response_id, which means later turns fall back to replaying more history instead of continuing the existing response chain. The practical cost is worse latency and weaker cache continuity as the conversation grows.

This PR fixes that by persisting the response id in message history and reusing the latest matching one on later OpenAI follow-ups, including compaction follow-ups.

The reason this PR exists separately from #20848 is that it takes a smaller, more local approach:

• it derives continuity from the message history already being used to build the next request
• it reuses a response id only when the provider/model match
• it covers the compaction path explicitly
• it avoids schema, migration, projector, and extra session-surface changes

So the benefit is the same user-facing fix with less persistence surface and tighter coupling to the actual request context.

How did you verify your code works?

• bun typecheck
• bun test test/session/llm.test.ts
• bun test test/session/message-v2.test.ts
• bun test test/provider/transform.test.ts

I also pushed the branch through the repo hook/typecheck path during git push, which passed.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found

PR #20848 — fix(opencode): wire OpenAI previous_response_id session caching
#20848

This PR appears to be directly related to the current PR (#22149). According to the PR description, #20848 is explicitly listed as "follow-up implementation path for wiring OpenAI response reuse/session caching." This suggests #20848 may have been a previous attempt or partial implementation of the same feature that PR #22149 is now completing or refining.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[YanzheL]

This definitely overlaps with #20848, but I think it is still worth considering because it makes a different tradeoff.

The main difference is where continuity is sourced from:

• fix(opencode): wire OpenAI previous_response_id session caching #20848 stores a session-global lastResponseId
• this PR derives previous_response_id from the actual assistant message history being replayed for the request

I think that is a better fit here for a few reasons:

1. It is more local to the request context. The response id is chosen from the messages that are actually being used to build the next prompt, instead of from a single mutable session-level field.
2. It is more conservative when sessions change model/provider. This branch only reuses a response id when the provider/model match the assistant message being resumed.
3. It covers the compaction follow-up path explicitly.
4. It avoids schema, migration, projector, and extra session-surface changes for what is fundamentally a request continuity bug.

So I do not think this is just a duplicate with different formatting. It is a smaller message-history-based implementation of the same fix.

If maintainers prefer the session-row approach in #20848, that is fine, but I wanted to make the tradeoff explicit because I think there is a legitimate reason to keep this implementation open for comparison.

[rekram1-node]

Codex itself doesnt use the previous response id.

[YanzheL]

Fair point.

My reasoning here is that OpenAI Responses documents previous_response_id as a public continuity mechanism, and opencode already has separate session/cache continuity via sessionID and promptCacheKey.

So this PR wires the documented OpenAI response-level continuity path into opencode’s existing OpenAI Responses flow, rather than trying to mirror Codex internals exactly.