The session you can’t take with you (and how to design around it)

You know that feeling when you export a “conversation” and think, great, this is mine forever? Then you try to continue it with a different model, or even a different provider, and nothing lines up. The transcript exists… but the work doesn’t.

That mismatch is the core problem behind a new class of “inference API” behavior: the session you can read is no longer the session that actually ran.

In this post, we’ll walk through what “session portability” really means for AI systems, why provider-bound state (sometimes encrypted, sometimes referenced by IDs) breaks the user’s mental model, and what a more portable session archive should contain.

The old promise: send input, get output

At the simplest level, an inference API (an API you call to make a model generate a response) looks like this:

1. You send some input (your prompt, plus any tool instructions).
2. The model returns output (text, structured data, tool calls, etc.).

When that “send/receive” loop is designed cleanly, the conversation becomes an artifact the user controls. That artifact can be:

• inspected (readable logs)
• archived (stored for later)
• replayed (used as the basis for continuing)
• handed to another model or implementation

Many people building with AI assume a transcript (a recorded sequence of messages and tool interactions) is that artifact.

But the transcript is only enough when it includes the operational state needed to continue the work.

Session portability: a practical definition

“Portable” does not mean “two providers generate the exact same next token.” That would be unrealistic. Even within the same provider, nondeterminism shows up due to sampling (the process that decides the next token using probabilities rather than a fixed rule).

Portability in practice means something narrower and more useful:

A user can export a session, revoke access to the old provider, and continue the session somewhere else using only the exported data.

A portable workflow looks like this conceptually:

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

That implies the export must be self-contained enough to reconstruct the “meaning” of what happened—at least for continuing the reasoning and tool interactions in a semantically equivalent way.

A portable-session checklist that catches the failure modes

Here are five tests that map cleanly to user expectations. If a session fails any of these, the transcript is no longer a full record of the operational state.

1) Inspection: can the user see what the model saw?

If the system uses tools (like web search or file retrieval) or multi-agent coordination, the user needs a visible record of:

• tool calls (what actions were requested)
• tool results (what evidence the model received)
• agent-to-agent messages or instructions (what internal parties told each other)

If any of that is hidden behind opaque blobs or server-only references, inspection fails.

2) Export: is the session archive self-contained?

A transcript is exportable if it doesn’t require the old provider to dereference an ID, decrypt an opaque capsule on the user’s behalf, or “remember” a search result the client never received.

An ID pointer into provider storage is not the same thing as the data.

3) Replay: can another implementation reconstruct context?

Replay means another model (or even another library) can accept the exported transcript and treat it as the available context.

If continuity relies on provider-specific encryption semantics that other providers cannot interpret, replay fails.

4) Audit: can a human explain what happened after the fact?

Auditability is where “opaque state” hurts. If an action was taken based on state the user can’t view, a postmortem becomes guessing.

5) Deletion: can the user identify and remove every server-side copy?

Deletion is the hardest test, because it requires you to know what server-side state your session depends on. If state is keyed by IDs stored entirely in the provider’s systems—and those IDs aren’t fully discoverable—deletion becomes partly illusory.

A key point: a response ID is not a transcript, and opaque encrypted bytes the client can’t decode are not user-controlled state.

Provider-sealed state: when “encryption” hides the user from the record

Modern APIs often include fields named like encrypted_content, ciphertext, signature, or “sealed state.” The marketing vibe suggests privacy. But the more accurate lens is:

provider-sealed state = data the provider controls, encrypted or sealed such that only the provider (and its models) can interpret it.

It can improve privacy in a narrow sense (for example, avoiding persistent storage during certain modes), but it also changes ownership: the user can’t recover the underlying operational record in a way that can be audited or ported.

One concrete example appears across providers: “reasoning” continuity is frequently implemented as provider-bound artifacts.

Reasoning tokens: billed, but not portable

Many closed-weight models don’t expose raw chain-of-thought text through the API. Instead, APIs return structured items that let the provider continue reasoning across turns.

For OpenAI’s Responses API, when you manage history manually, the guidance explicitly mentions that for store: false (or Zero Data Retention), you should replay the encrypted reasoning items the API returns by default. That’s a strong signal that the “record” is not a plain transcript—it includes provider-specific encrypted reasoning payloads. (developers.openai.com)

Thinking encryption on Claude-style models

On Amazon Bedrock documentation for Claude’s “thinking encryption,” encrypted thinking can be returned as a redacted_thinking block, decrypted when passed back to the API to continue context. In other words: the client gets an artifact, but meaning is unlocked only in the provider ecosystem. (docs.aws.amazon.com)

This is continuity inside a system, not portability for a user.

Stored conversations turn a transcript into a pointer

There’s an alternative way to break portability that doesn’t require encryption: store the operational state on the server, then send you an ID.

That design is efficient and can preserve hidden internal structure. It also flips ownership.

OpenAI: storage by default with time windows

OpenAI’s platform documentation describes storage behavior for Responses API “application state” and notes that response data is stored for at least 30 days by default when store is enabled. It also describes Zero Data Retention changing store behavior by forcing store to be treated as false. (platform.openai.com)

Gemini Interactions: retention windows and stateful defaults

Google’s Gemini Interactions API similarly stores interactions by default (when store=true) and documents retention windows. The Interactions overview explains that past interactions for paid tier can be retained up to 55 days, while for free tier the retention is shorter, and it also describes programmatic deletion by interaction ID. (ai.google.dev)

Whether the exact numbers differ by plan, the architectural pattern is the same: the “session” lives server-side, and the transcript is just a view.

Why previous_response_id breaks replay elsewhere

A stored conversation approach often looks like this:

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

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

If your local archive stores only user messages and the final text, then first.id becomes a foreign key into someone else’s database. A transcript that cannot be replayed without that database fails export and replay.

Hidden searches and missing evidence: the transcript has holes

Another portability killer is “web search the model can see, but you can’t.”

A client-side search tool behaves like any other tool:

• you call search(query) in your app
• you record query, ranking, passages, timestamps
• you pass tool results to the model

Then the transcript includes the evidence.

But server-side search can create transcripts with invisible gaps: the model performs retrieval, provider code assembles citations or passages, and the user never receives the full evidence used for the decision.

That breaks inspection and audit. It also breaks replay, because another provider cannot reconstruct the same evidence unless you stored it.

So what should “portable session export” contain?

To make portability realistic, a session export needs to be more than conversational text.

At minimum, it should capture:

• User-visible inputs: user messages, system instructions, tool schemas.
• Tool calls: action name, arguments, and the order in which calls happened.
• Tool results: returned data the model saw (not just summaries).
• Agent handoffs: any internal multi-agent coordination messages you can represent.
• Evidence snapshots: for retrieval tasks, store the retrieved content you passed into the model.
• A well-defined replay contract: a format other implementations can interpret.

Once you store tool results locally, the portability story gets stronger because the transcript contains the “facts” and not just the “operation happened.”

And this is the tricky but liberating realization: a session becomes portable when the user—not the provider—owns the record of tool-observed reality.

What about encrypted reasoning? A pragmatic stance

Encrypted reasoning creates a genuine gray area.

Even if you archive the encrypted blob, another provider might not be able to interpret it. That means replay becomes “provider-specific continuity,” not “portable meaning.”

The best you can do in that case is often:

• archive the inputs that led to the reasoning
• archive tool results and evidence
• archive the model outputs you do receive (even if they are summaries)

That turns the transcript into an auditable, inspectable artifact, even if perfect cross-provider replay of internal reasoning is impossible.

This is the difference between “portable archive” and “portable operational continuity.” The first can still be deeply valuable for users and for compliance.

And yes, the question many engineers end up searching is: “Can I port an AI session to another provider without losing context?” The answer is: sometimes, but only when the export contains everything that matters (especially tool results), and the provider isn’t relying on sealed or server-resident state for meaning.

The real lesson: treat transcripts as data contracts, not logs

A transcript is not automatically an ownership guarantee.

If the API treats session state as provider-resident—keyed by IDs you can’t dereference elsewhere—or returns provider-sealed reasoning artifacts that only the original ecosystem can interpret, then the “conversation export” is more like a bookmark than an archive.

The fix isn’t necessarily to demand deterministic outputs. It’s to insist on a contract:

• What exactly is recorded?
• What exactly is replayable?
• What exactly is inspectable?
• What exactly can be deleted?

Once you frame it that way, “session portability” stops being a philosophical argument and becomes a testable engineering requirement.

Fact checks for retention and thinking-encryption details

• OpenAI documents that Responses API stores application state for at least 30 days by default (when store is enabled), and that Zero Data Retention changes store behavior to be treated as false. (platform.openai.com)
• Gemini Interactions documentation describes retention windows for stored interactions and the ability to delete stored interactions by interaction ID. (ai.google.dev)
• Amazon Bedrock documentation describes Claude “thinking encryption,” where thinking may be returned as redacted_thinking blocks and decrypted when passed back to the API for continuity. (docs.aws.amazon.com)

Closing thought

Portability is what happens when the transcript stops being a story you read and becomes the operational data you own. The minute an API starts turning your session into provider-sealed state, the export can still look complete while quietly missing the parts that matter most.

That’s why a good “session archive” isn’t a chat log. It’s a replay contract—built out of inputs, tool evidence, and clearly specified continuity semantics.