AI Session Portability Compared 2026: OpenAI vs Anthropic vs Gemini

Last updated: July 31, 2026

A July 30 essay by the Earendil engineering team hit the top of Hacker News with a question most developers had not thought to ask: how much of an AI session do you actually own? The original promise of an inference API was simple - send input, receive output, and if you kept both, you had the conversation. You could archive it, replay it, or hand it to a different model.

That is increasingly not how the big providers work. Reasoning tokens arrive as encrypted blobs. Server-side compaction produces state only the original provider can decrypt. Hosted web search feeds the model evidence you never see. Subagent messages are sealed ciphertext. The transcript on your machine is becoming a partial view of a session whose operational state lives on the provider's servers.

This is a comparison of session portability across the three major providers, grounded in their live documentation (all links verified July 31, 2026). The practical question is not philosophical. It is: if a model is retired, a policy blocks your next request, a price change makes a competitor attractive, or an auditor needs to reconstruct what happened, what can you actually move?

What Session Portability Means#

The Earendil essay proposes a practical test: a portable session is one where another model can continue from your transcript without the old provider dereferencing an ID, decrypting a blob, or reconstructing a summary. Five sub-tests follow:

1. Inspection - can you see what the model saw and what tools did?
2. Export - is the session self-contained on your side?
3. Replay - can another implementation reconstruct equivalent context?
4. Audit - can a human explain why an action was taken?
5. Deletion - can you remove every server-side copy?

A response ID is not a transcript. A ciphertext is not user-controlled state. A citation list is not the evidence that was placed in the model's context. On those five tests, the three providers score very differently.

The Providers at a Glance#

Verified July 31, 2026 against the OpenAI conversation state guide, OpenAI compaction guide, Anthropic extended thinking docs, Anthropic compaction docs, and Gemini Interactions API docs.

OpenAI: Stateful by Default, Sealed Where It Counts#

OpenAI's Responses API stores responses by default. Per the conversation state docs, response objects are saved for 30 days unless you set store: false - which the docs recommend for stateless use. Stored responses give you previous_response_id chaining: you send a response ID and a new user message, and the server reconstructs the context.

The portability problem is what rides along inside those stored responses. Two features in particular make the local transcript incomplete:

Encrypted reasoning. The Responses API returns encrypted reasoning items by default. Replaying the complete output preserves them for the same provider, and models that support persisted reasoning can use reasoning.context: "all_turns". But the items are opaque to you. A different provider cannot consume them, and even you cannot inspect the actual reasoning - you can only pass the blob back unchanged. That is provider-sealed state: it works within OpenAI, it does not create a portable record.

Opaque compaction. OpenAI's compaction guide describes two modes. Server-side compaction triggers at a compact_threshold you set, and the response stream includes "the encrypted compaction item". The standalone /responses/compact endpoint returns "a new compacted context window" that the docs describe as opaque and "not intended to be human-interpretable". The docs are explicit: do not prune the output, pass it into the next call as-is. That is the definition of non-portable state - the meaning of the compaction item exists only inside OpenAI's infrastructure.

To OpenAI's credit, store: false is documented, easy, and makes the flow ZDR-friendly. The encryption can even serve a real privacy purpose: encrypted reasoning with store: false avoids persisting intermediate state on OpenAI's servers. But the encryption hides the reasoning from you as much as from the network. The Codex CLI encryption change shows the pattern applied to agents: since June 2026, Codex multi-agent v2 stores inter-agent messages as encrypted_content with the readable content field empty. An open Codex issue asking for a readable audit copy alongside encrypted delivery remains unresolved on upstream main as of July 22, 2026.

Anthropic: Readable by Default, with a Portability Catch#

Anthropic's API is stateless by default - there is no server-side conversation store to opt out of. You pass the full message history each turn, which means your client owns the transcript. On the inspection, export, and deletion tests, that is the strongest starting position of the three.

Two features complicate the picture:

Thinking signatures. Anthropic's extended thinking returns thinking blocks with a signature field - "an encrypted copy of the full reasoning that you pass back unchanged". With display: "omitted" (the default on Opus 5, Sonnet 5, and the rest of the current lineup), the readable thinking field is empty and only the signature carries the reasoning. The docs are explicit about what that means for portability: "When you switch between any two models... strip thinking and redacted_thinking blocks from prior assistant turns. Thinking blocks are tied to the model that produced them." The signature is only meaningful to Anthropic's models, and the docs tell you to delete it when switching. Your transcript preserves continuity within Anthropic, not across providers.

Readable compaction. Anthropic's server-side compaction returns a compaction block containing an actual summary - readable text you can inspect, edit, and pass to another model. The docs show the default summarization prompt producing a <summary></summary> block with "the state, next steps, learnings etc." This is the model the other providers should copy: compaction that preserves the provider's quality advantages without locking the meaning inside ciphertext.

Gemini: Stored by Default, Retrieveable but Provider-Bound#

Google's new Interactions API - the model-agnostic surface where all new Gemini features land - stores requests by default. The docs: "By default, the API stores all Interaction objects (store=true) in order to simplify use of server-side state management features." Paid-tier interactions are retained for 55 days, free-tier for 1 day. You can set store: false, but with a real tradeoff: it is incompatible with background execution and prevents previous_interaction_id continuation.

The Interactions API is actually the most transparent of the three on the state question. An interaction is "a session record, containing the entire history... as a chronological sequence of execution steps", including "model thoughts", tool calls and results, and the final output. Stored interactions can be retrieved via interactions.get and deleted programmatically. If you are inside Google's ecosystem, the audit surface is genuinely good.

The portability gap is structural rather than hidden: the canonical record lives on Google's servers. Your local copy is whatever your client logged. store: false and previous_interaction_id are mutually exclusive, so the two paths are "stateless but manually reconstructable" or "stateful but server-hosted". There is no mode where a full-fidelity transcript exists on both sides.

Where the Lock-In Actually Bites#

The theoretical concern (can I switch providers?) matters less than the practical ones, because most teams do not switch models mid-session. The Earendil essay names the scenarios where portability is not an abstraction:

• Model retirement and policy blocks. When a model is deprecated, a policy change refuses the next request, or a pricing change makes a competitor attractive, you need to move accumulated context. See our model dependency risk analysis for how quickly that scenario arrives.
• Long agent sessions. A coding or research session accumulates days of decisions. If that context can only be interpreted by one provider, the switching cost compounds with session length.
• Audit and debugging. When a subagent changes the wrong file or a research agent cites bad evidence, the question is "what was that agent actually asked to do?" With encrypted inter-agent messages, the answer is not in your logs. This is exactly the agent receipts problem: work without a readable trail is work you cannot verify.
• Cost routing. Teams now route between models per task - see our routing strategies. Routing is much easier when the transcript survives the handoff.

The Portability Checklist for Your Integration#

Whatever provider you standardize on, you can improve your position with five practices:

1. Set store: false where you do not need server state. OpenAI and Gemini both document it; it is the single biggest control you have. OpenAI's docs note that server-side compaction is ZDR-friendly when you also pass store: false.
2. Keep the local event log canonical. Record user messages, assistant text, tool calls, and tool results yourself, and treat the provider's IDs as acceleration, not as your record.
3. Ask for readable handoffs. When a provider offers opaque compaction (OpenAI) or sealed thinking (both closed providers), log what you actually know: the visible text, the summaries, the citations. A summary you can read beats a blob you cannot.
4. Strip thinking blocks on model switches. Anthropic's docs require it. If you move a conversation to a different model, remove prior thinking blocks rather than passing ciphertext around.
5. Plan deletion. Know where each provider stores your data and how to remove it - OpenAI's 30-day TTL, Gemini's 55-day window, and the deletion APIs for both.

When Portability Is Not Worth the Complexity#

The honest counterargument: for most teams, most of the time, provider-sealed state is a fair trade. Stored conversations reduce payloads, encrypted reasoning is a genuine ZDR benefit, and server-side compaction lowers latency and cost. The Earendil essay's own framing is careful - it does not object to stateful APIs, only to "better performance being coupled to less user control."

Skip the portability work if you are a solo developer with short sessions, no compliance requirements, and no plan to switch providers. The overhead of maintaining a full local event log is real. Add it when sessions get long, when you route between models, or when anyone will ever ask you "what did the agent do and why?"

Frequently Asked Questions#

What is session portability in AI APIs?#

Session portability is the ability to take the record of a conversation - messages, tool calls, reasoning, and state - from one provider and continue it with another model or in another system. A portable session can be inspected, exported, replayed, audited, and deleted without the original provider dereferencing internal IDs or decrypting sealed state.

Does OpenAI store my API conversations?#

By default, yes. Responses API response objects are saved for 30 days and can be viewed in dashboard logs or retrieved via the API. Setting store: false on your requests disables storage. Conversations API objects are not subject to the 30-day TTL.

Does Gemini store my API conversations?#

Yes, by default. The Interactions API stores all interaction objects (store: true default) - 55 days on the paid tier, 1 day on the free tier. Setting store: false opts out but is incompatible with background execution and previous_interaction_id continuation.

Does Anthropic store my API conversations?#

No. The Anthropic API is stateless by default - you pass the full message history with each request and there is no server-side conversation store. However, thinking blocks carry an encrypted signature field that must be passed back unchanged and must be stripped when switching models, which limits cross-provider portability.

Can I move a session from OpenAI to Anthropic?#

Partially. If you kept the visible text, tool calls, and results (which store: false chaining encourages), another model can understand and continue the conversation. What does not transfer is encrypted reasoning items and opaque compaction state, whose meaning only exists inside OpenAI's infrastructure. Anthropic's docs also require stripping thinking blocks when switching models, so the reverse direction has its own caveat.

What is the portable alternative to encrypted compaction?#

Anthropic's compaction block is the reference design: server-side summarization that returns a readable summary you can inspect, edit, and pass to any model. OpenAI's compaction returns an opaque encrypted item that the docs explicitly say is not human-interpretable. If portability matters, prefer providers and configurations that give you readable summaries over sealed blobs.

---

Official Sources#

Continue Reading#

• Codex Now Encrypts Multi-Agent Prompts - the Codex-side story of sealed subagent messages
• Terminal Agents Are the New Developer Runtime - why the runtime surface matters more than the model brand
• Agent Memory as a Context Ledger - what survives a session, and how to keep it auditable
• Agent Replays with TraceTrail - reconstructing what an agent did after the fact
• OpenAI API Control Plane June 2026 - the stateful API surface around Responses

Sources#

• Earendil: The Session You Cannot Take With You (accessed July 31, 2026)
• OpenAI conversation state guide (accessed July 31, 2026)
• OpenAI compaction guide (accessed July 31, 2026)
• Anthropic extended thinking docs (accessed July 31, 2026)
• Anthropic compaction docs (accessed July 31, 2026)
• Gemini Interactions API docs (accessed July 31, 2026)
• Codex issue #28058: encrypted MultiAgentV2 messages remove readable task audit trail (accessed July 31, 2026)
• Codex PR #26210: Encrypt multi-agent v2 message payloads (merged June 5, 2026)
• Hacker News discussion: The Session You Cannot Take With You (729 points, July 31, 2026)