Sessions You Can't Take With You

The basic premise of the existing Inference API was that keeping the inputs and outputs would let the user own the entire conversation. Even if a different model can't reproduce the exact same next token, a transcript containing instructions, messages, tool calls, and results should still be understandable and continuable by another model.

But recent APIs return provider-dependent state along with the text. Representative examples include encrypted blobs of reasoning tokens that users can't directly inspect, web search results visible only to the model, compressed context that only the provider can decrypt, subagent messages hidden from the application, file/vector store/container/cache references that can't be interpreted externally, and conversation state tied only to a server ID.

In this structure, a transcript stored locally is no longer the entire session but merely a record showing part of the operational state held by the provider. To determine whether a session is actually owned by the user, the following five points must be checked.

• Inspection: Can the user see what the model saw, the results of tool execution, and messages between agents?
• Export: Aside from ordinary downloadable artifacts, is the session self-contained?
• Replay: Can a different implementation reconstruct semantically equivalent context?
• Audit: Can a human explain after the fact why the system behaved as it did?
• Deletion: Can all server-side copies that the session depends on be found and deleted?

A response ID merely points to data stored on the server and is not a transcript, and ciphertext that the user cannot decrypt is not user-controlled state either. Likewise, a citation list from search results doesn't replace the actual evidence that went into the model's context.

So-called encrypted_content is also mostly not a privacy feature where the user manages the keys, but rather provider-sealed state that the provider opens and replays in its own model. That said, there are cases where provider sealing offers a real privacy benefit by avoiding server-side conversation storage—such as OpenAI's approach of returning reasoning encrypted under the store: false setting and decrypting it in memory on the next request.