The session you cannot take with you

The original promise of an inference API was wonderfully simple: send some input, receive some output. If you kept both, you had the conversation. You could inspect it, archive it, replay it, or give it to a different model.

That abstraction was never completely true. For instance prompt caches live on somebody else's GPUs, tokenization differs between models, and sampling is not reproducible (and quite intentionally so). But the semantic record of a session in the form of a transcript could still belong to the user. A transcript should contain the instructions, messages, tool calls and tool results. Another sufficiently capable model might not continue identically, but it could understand what happened and take over.

Inference APIs are frustratingly moving away from that property, at least somewhat. They increasingly return a mixture of text and provider-bound state that is very intentionally non-portable.

• reasoning tokens that are billed to the user but returned only as opaque, encrypted blobs, with useless summaries at best
• web searches where the model sees source material the client never sees
• compacted context that only the original provider can decrypt
• subagent instructions and messages hidden from the application running the agents in the form of encrypted payloads
• file, vector-store, container, and cache references that cannot be resolved anywhere else.
• response and conversation state that is entirely keyed by IDs that are stored fully on the provider's servers

Each feature comes with a basic justification that's trivial for a provider to come up with, along with good arguments for why this is good for the user. Together all of these things change the ownership reality of an AI session: the transcript on your machine is no longer your session but a partial view of a session whose operational state belongs to an inference provider and not you.

We are not fans of this direction, and we want to talk a bit about what it means to you, as a user, and what it means to us, as people developing tools in this space.

A Practical Test for Session Ownership

By a portable session we do not mean that switching from one model to another must produce the same next token. That's a given because models have different capabilities, trained personalities, context windows, and ways of working with tools. And well, it's all quite nondeterministic anyway. Portability means something more modest:

const transcript = session.export();
revokeCredentials(oldProvider);
session = newProvider.continueFrom(transcript);

The archive should contain enough intelligible information for another model to continue the work. It should not require the old provider to dereference an ID, decrypt a blob, remember a search result, or reconstruct a summary.

This gives us five useful tests:

1. Inspection: Can the user see what the model saw, what tools did, and what agents told each other?
2. Export: Is the session self-contained, apart from ordinary artifacts that can also be downloaded?
3. Replay: Can another implementation reconstruct a semantically equivalent context?
4. Audit: Can a human explain why the system took an action after the fact?
5. Deletion: Can the user identify and remove every server-side copy on which the session depends?

A response ID is not a transcript (as the data is stored on the server), a ciphertext is not user-controlled stated (as the user cannot decrypt it), a list of citations is not the evidence that was placed in the model's context by a search result (as you cannot typically fetch the same data as the model did).

Encryption for Whom?

The naming and marketing around these features can be misleading. encrypted_content sounds like a privacy feature under the user's control. Usually it is a capsule that the client cannot read and only the provider can open. The provider chooses the keys, decrypts the content for its own models, and defines where the data can be replayed.

A better term is provider-sealed state.

Provider sealing can have a real privacy benefit. OpenAI, for example, can return encrypted reasoning to a client using store: false, then decrypt it in memory on the next request without persisting the intermediate state. That is better than requiring server-side conversation storage, particularly for Zero Data Retention customers. But, remember, there is not really anything that needs encryption to begin with!

This encryption does not hide the data from the inference provider but it hides it from you.

Stored Conversations Turn a Transcript into a Pointer

OpenAI's Responses API stores responses by default. Its documentation says response objects are retained for at least 30 days by default. store: false is available and should be used, as it makes it work more like completions: the data is not stored on OpenAI's servers.

The new Gemini Interactions API has made a similar choice. It defaults to store: true. On the paid tier interactions are retained for 55 days, and on the free tier for one day.

And obviously, the idea of storing state on the server is quite attractive:

const first = responses.create({
  model: "frontier-model",
  input: "Investigate this production failure",
  store: true,
});

const second = responses.create({
  model: "frontier-model",
  previousResponseId: first.id,
  input: "Now implement the fix",
  store: true,
});

The application sends less data, the provider can preserve hidden reasoning and tool state, and cache routing becomes easier. But if the local application only records the user messages and final text, first.id is now a foreign key into a database it does not control.

No Reasoning For You

All major labs claim to have legitimate reasons not to expose raw chain of thought. As a result, on non-open-weights models we typically do not see these tokens.

Raw reasoning is not visible via the API. With stored responses, prior reasoning can be recovered through previous_response_id. With store: false, the API returns encrypted_content, which the client must preserve and replay. Persisted reasoning remains opaque even when reasoning.context: "all_turns" lets a later sample use it.

Anthropic returns the encrypted full thinking in a signature field. The readable thinking text, when enabled, is a summary produced by another model, not the raw chain of thought. Thinking blocks must be passed back unchanged during tool-use turns. Anthropic's documentation also says thinking blocks are tied to the model that produced them and should be stripped when switching models. So these reasoning traces do not attempt to be portable within Anthropic.

The same story repeats with all closed-weights models.

These encryption mechanisms permit continuity inside an ecosystem but they do not create a portable transcript that can be taken to another provider's model. A session archive can contain the blob, but another model cannot use its meaning:

{"type": "reasoning", "encrypted_content": "gAAAAAB..."}
{"type": "thinking", "thinking": "", "signature": "EqQBCg..."}
{"type": "thought", "summary": [], "signature": "EpoGCp..."}

Hidden Searches

Server-side web search is one of the clearest examples of a transcript having holes in it hidden from the user. A client-side search tool behaves like any other tool:

const result = search(query);
record({
  query,
  retrievedAt: now(),
  results: result.map((item) => ({
    url: item.url,
    title: item.title,
    passages: item.passages,
  })),
});
model.send({ toolResult: result });

The user can inspect the ranking and passages, refetch the pages, cache a copy, or provide the same evidence to another model.

With hosted search, the provider performs a private tool loop. OpenAI, Google and Anthropic expose search actions, citations, and optionally a list of source URLs, but not the complete text context used to produce an answer. A URL is not a stable replay, instead its contents can change or have been reduced to a much shorter snippet before the model saw it.

The final answer may be perfectly good. The problem…