Thanks for the details. One important note up front: BYOK with the GPT-5 family via the Responses format is that known mismatch, and there’s no official proxy spec for it. We don’t officially support this setup, so what follows isn’t a guaranteed contract, it’s just what we’ve observed in practice.
On the main question about the encrypted reasoning blob: what you’re seeing (Cursor sends store: false, but the passed encrypted blob doesn’t get picked up) is a known weak spot. Passback reasoning or encrypted content for BYOK in multi-turn is currently unreliable, so even a correctly returned blob may not be used, and continuity between turns can break. There’s no ETA for a native fix.
In practice this isn’t critical for rendering: mapping the live reasoning text into delta.reasoning_content is enough for Cursor to show the reasoning, and other users in the thread below confirmed that. Round-tripping the encrypted blob in its current form isn’t guaranteed, so I wouldn’t rely on it for multi-turn continuity yet.
The closest public material to your case is how the community bridge handles streaming deltas: GitHub - Pil0tXia/Cursor-OpenAI-BYOK-Bridge: Bridge Cursor OpenAI-compatible BYOK requests to Responses API endpoints. · GitHub, plus the general thread with request and response payload examples from other users: Cursor Agent sends Responses API format to /chat/completions endpoint
If you share a concrete example, the request from Cursor and what you return, especially what the assistant message looks like on the second turn, we can look together and see exactly where the blob gets lost.