The Session You Cannot Take With You — and Why Your Routing Layer Is the Exit

On July 31, 2026, an essay titled "The Session You Cannot Take With You" hit #1 on Hacker News with 467 points and 118 comments. The argument is simple and correct: AI agent sessions are permanently locked to the vendor that created them. Conversation history, tool state, reasoning context, and compacted memory cannot be exported or migrated between providers.

"The session you cannot take with you is a platform lock-in strategy masquerading as a technical limitation."

— earendil.com, July 2026

The author catalogues five mechanisms that make sessions non-portable:

• Opaque reasoning tokens — billed to you, returned as encrypted blobs only the original provider can decrypt
• Compacted context — provider-side compression that only the originating API can reconstruct
• Hidden subagent payloads — instructions embedded in encrypted packages invisible to the caller
• Non-portable references — file stores, vector stores, and cache keys that resolve only against the provider's infrastructure
• Provider-keyed state — response and conversation state identified by IDs stored on the provider's servers, not yours

The conclusion: "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."

This is not a theoretical concern. It is the most upvoted technical essay on the most influential engineering forum on the internet, on a Friday morning, with 118 comments from engineers who are experiencing it in production.

The lock-in progression

The lock-in progression works in three stages:

Stage 1: Convenience lock-in

Your team picks a provider. The SDK is clean. The dashboard works. You build around it. Switching means rewriting integration code, re-training operators, re-building dashboards. This is the lock-in every vendor relies on and every buyer accepts. It's manageable.

Stage 2: Optimization lock-in

Six months in, you enable provider-native features: compacted context, server-side caching, sub-agent orchestration. Each feature reduces latency or cost — and each one moves state from your infrastructure to the provider's. You can still switch, but you lose the optimizations. The switching cost is now economic, not just engineering.

Stage 3: Structural lock-in

Compacted context that only the provider can decrypt. Reasoning tokens returned as opaque blobs. Subagent instructions hidden in encrypted payloads. Conversation state keyed by provider-side IDs. At this stage, switching providers means losing session continuity entirely. Your agents start over. Your context windows reset. Your tool state evaporates.

The earendil.com essay is about Stage 3 — and the observation that providers are designing for it deliberately. Not because they're malicious, but because lock-in is the most profitable outcome of a feature that looks like a performance optimization.

What a routing layer does about it

Trimio's proxy sits at the API call layer, not the session layer. This is a critical distinction:

• What the proxy captures: which team made the call, which virtual key was used, which model responded, what it cost, how long it took, what the routing decision was. This metadata lives at the Trimio layer and is fully portable.
• What the proxy does not capture: the provider's internal session state, encrypted reasoning tokens, compacted context blobs, or provider-keyed conversation IDs. These remain provider-side — but the proxy gives you the option to route around them.

The practical outcome: when you move from Anthropic to OpenAI (or to a mix of both), you lose nothing about attribution, cost history, or routing rules. The session state that lives inside the provider's infrastructure is lost — but the proxy layer was never dependent on it. Your cost reporting, team budgets, and routing policies are intact.

The five portability tests

The essay proposes five portability tests. Here's how a routing layer addresses each:

1. Inspection: Can you see what's in your session? — The proxy logs every API call, every response, every routing decision. Full visibility at the call layer. The provider's internal state remains opaque, but the wire-level transcript is yours.
2. Export: Can you extract it? — Yes. Every call log, cost record, and routing rule is exportable from the proxy layer. No provider-side extraction required.
3. Replay: Can you resume with a different provider? — Partially. The proxy can route the same prompt to a different provider, but provider-side session state (compacted context, reasoning tokens) cannot be replayed. This is the remaining gap — and it's a provider-side limitation, not a proxy limitation.
4. Audit: Can you verify what happened? — Yes. The proxy maintains a complete audit trail of every call, every routing decision, and every cost attribution record. This is the same evidence SOC 2 auditors require.
5. Switch: Can you change providers without losing continuity? — Yes at the routing layer. A routing rule change moves traffic from one provider to another. No code changes, no re-integration. The session-level continuity that lives inside the provider's infrastructure is lost — but the operational continuity (cost, attribution, routing policy) is preserved.

The enterprise question

The earendil.com essay ends with an observation that applies directly to enterprise AI procurement:

Every organization that standardizes on a single inference provider without a routing layer is accepting Stage 3 lock-in by default. Not because the provider is malicious, but because the provider's optimization features are designed to move state from your infrastructure to theirs. That's where the lock-in lives — in the accumulation of session state that you can't export.

The question for procurement is not "which provider should we standardize on?" The question is: "What infrastructure lets us switch providers without re-platforming?"

A routing layer is that infrastructure. It doesn't solve session portability — that's a provider-side problem the providers have no incentive to fix. But it solves the problem that matters for the buyer: the ability to make routing decisions based on cost, quality, and risk — without losing the operational metadata that makes those decisions defensible.

The bottom line

The earendil.com essay is the most clearly articulated argument for why inference providers are building lock-in into the session layer. The 467-point HN response confirms the market recognizes it. The question is what to do about it.

Session portability is a provider-side problem that providers have no incentive to solve. A routing layer is the buyer-side answer: capture attribution and cost at the proxy layer, keep routing rules portable, and make provider switching a configuration change rather than a re-platforming project.

If your AI infrastructure depends on a single provider's session format, you're already in Stage 3. The exit is a routing layer.

Trimio is the LLM API gateway that sits between your applications and your inference providers — capturing attribution, enforcing budgets, and routing across providers without code changes. See how it works.