The Session You Cannot Take With You

Date: July 30, 2026
From: Earendil Engineering (rfc@earendil.com)
Subject: The erosion of session portability in AI APIs

The initial allure of an inference API was its elegant simplicity: you provide an input, and you receive an output.

In that ideal world, the interaction was transparent. You could archive the exchange, inspect the logic, replay the sequence, or migrate the entire conversation to a different model. While certain technical aspects—such as $\text{sampling} \neq \text{deterministic}$ or the fact that prompt caches and tokenization methods are proprietary—were always provider-dependent, the semantic record (the transcript) remained the property of the user.

A true transcript encompasses everything: the system instructions, the dialogue, the tool invocations, and the resulting data. While a different model might not generate the exact same subsequent token, it should be able to comprehend the history and resume the task.

The Shift Toward Provider Lock-in

Unfortunately, modern inference APIs are drifting away from this openness. We are seeing a rise in "provider-bound state"—data that is intentionally designed to be non-portable.

Instead of clean text, providers are returning a hybrid of content and opaque metadata:

• Reasoning Tokens: Billed to the user but delivered as encrypted blobs or vague summaries.
• Hidden Search Results: The model accesses source material that is never actually shown to the client.
• Opaque Context: Compacted state that only the original provider's keys can decrypt.
• Hidden Agent Logic: Subagent communications wrapped in encrypted payloads, invisible to the host application.
• External References: Pointers to files, vector stores, or caches that are useless outside the provider's ecosystem.
• Server-Side IDs: Conversation states keyed by IDs that exist only on the provider's hardware.

Each of these features is marketed with a convenient justification. However, the cumulative effect is a fundamental shift in ownership. Your local transcript is no longer a complete session; it is merely a window partial view of a session whose actual operational state is owned by the provider.

---

Defining Session Portability

To be clear, portability does not mean "identical output." Different models have unique personalities, context windows, and capabilities. Instead, portability is defined by the ability to move the state of the work.

In a portable system, the logic looks like this:

// The ideal portability workflow
const transcript = session.export(); 
revokeCredentials(oldProvider); 
session = newProvider.continueFrom(transcript);

The archive must contain enough intelligible data for a new model to take over without needing the previous provider to decrypt a blob, resolve an ID, or recall a hidden search result.

The Portability Checklist

We propose five tests to determine if a session is truly owned by the user:

• Inspection: Can the user see exactly what the model saw and what the agents communicated?
• Export: Is the session self-contained (excluding downloadable artifacts)?
• Replay: Can a different implementation recreate a semantically equivalent context?
• Audit: Can a human retrospectively explain why a specific action was taken?
• Deletion: Can the user verify the removal of every server-side copy of the session?

---

The Illusion of Privacy and Control

Many providers use misleading terminology. For example, encrypted_content sounds like a security feature for the user. In reality, it is often a "capsule" that the user cannot read, but the provider can. The provider manages the keys and decides where that data can be replayed.

Case Study: OpenAI's Approach

OpenAI can utilize store: false to return encrypted reasoning. This allows the client to pass the blob back in the next request without the provider persisting the state on their servers. While this is a win for Zero Data Retention customers, it doesn't solve the ownership problem.

The core issue: There is no technical necessity for this encryption. It doesn't hide data from the provider; it hides it from you.

The "Foreign Key" Trap

The Responses API from OpenAI stores data by default (retaining it for 30 to 55 days depending on the tier). While store: false is an option to mimic a standard completion, the "stored" approach is tempting for developers:

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

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

By using previousResponseId, the local application is no longer storing a transcript; it is storing a foreign key to a database it does not control.

Comparison of Session Models

The "No Reasoning" Policy

Almost every major AI lab refuses to expose raw "Chain of Thought" (CoT) tokens. On closed-weights models, this reasoning is hidden. If you use stored responses, it's recovered via previous_response_id. If you use store: false, you get encrypted_content. Even when reasoning.context: "all_turns" is enabled, the underlying logic remains a black box. Anthropic similarly returns encrypted thinking blocks.

Data Flow Visualization

In summary, the industry is moving toward a model where the "session" is a service you rent, rather than a record you own. For those of us building tools in this space, this is a regression we cannot ignore.