[lukebuehler]

Fair. But in the background of the article is clearly the goal to make sessions portable, not just being able to inspect it. It's partially implied even in the title.

There is just a whole discussion to be had about the second issue and the two are connected. For example session caching--and similar features in the future--will introduce session incompatibilities that break portability too.

[the_mitsuhiko]

> But in the background of the article is clearly the goal to make sessions portable, not just being able to inspect it. It's partially implied even in the title.

But not on the level that providers need to agree to a common format. Within Pi we are able to model portable sessions between providers even if they have provider specific APIs. For instance most models do not agree on how to do deferred tool loading. But they now have some support for that even if it diverges between models and APIs. So we can model deferred tool loading specifically for different providers without having to align on a common set of APIs or similar.

What cannot be made portable, is when information is sealed in the transcript or the information is entirely locked away on the provider's servers (store = true).

[lukebuehler]

Yes, I agree with your point and article regarding hidden or sealed state.

So, I'm aware that this is a separate point from the article, and I'm well aware of Pi's model abstraction layer, which is one of the best (others are a big pain... looking at you LangChain). I've come to the conclusion that full session portability will come to an end very soon, and really already has. Partially because of the hidden state stuff, partially because of feature divergence. We can still kinda patch over it right now, but it's getting harder by the week. Some examples: computer use structures in OAI responses, until recently MCP tunnels were only supported by OAI, not Anthropic, and tool discovery/search API is also getting very difficult to model fully in a unified abstraction (still possible as you point out), automatic compaction is also getting gnarly, etc.

[the_mitsuhiko]

It definitely is getting quite challenging. That said, a lot of user experiences are modelled around retaining transcripts for longer than a few minutes. Every claw or chat based application creates a very real user experience desire of that conversation being something you can continue, even weeks after when the model might have gone away / have been replaced.

Now unless you fully want to commit yourself to one provider, you will on the application layer need to deal with this anyways in one form or another. We want to at least try to address most of this on the harness layer, regardless of how tricky that is.

[lukebuehler]

All the power to you, and I hope Pi will be able to continue its unified layer.

However, there is an alternative: model the session fully in the provider native structures, extract only what is needed for harness specific branching, and treat a provider switch as a _migration_ that you apply at the time of the switch. So treat a provider switch as a migration from provider A to B, with custom logic, etc. This is IMO a more sustainable model. But I'm aware that Pi, OpenClaw, et al have their commitments here.