The session you cannot take with you

This is definitely not the way most software has been going in the past decades. It's rather the opposite: Companies play friendly to obtain a user base, then start applying more and more dark patters to further increase their profit. Facebook, Evernote, Instagram, Komoot... The list goes on and on.

Users at large (individuals and companies alike) don’t care much about a freedom taken away when a product is a few % better than another, so the biggest player sees if they can get away with it. And once they do it, everyone else does too.

waste of time. should be using pi mono

Sorry even if your platform is the greatest thing ever, but I’ll find a different tool. I’ve read one too many stories about Google (or Apple!) closing the entire account over some bullshit unnecessary reason like “fraudulent” gift card issues or whatever. I’m certain the affected people would’ve preferred to just pay back the amount in question instead of losing their entire Google Drive, or their 20 years of iCloud Photos or whatever.

I was going to give it a shot, but the only choice was a Google login.

So very weird.

Yes, and we as "harness providers" don't want to have to hard-code integrations for each of them, and would rather provide an out-of-the box baseline in the form on an MCP server that our customers can either extend or replace with MCP servers by third-party providers. That helps us focus on the core of our offering, while also giving our customers good flexibility, which so far has been working out great.

That's exactly what standards/protocols like MCP are for. You likely nowadays also wouldn't suggest that someone builds bespoke logging/tracing integrations for each provider on the market while the good generic solution in building OTEL logging/tracing exists.

Now?! I find it very hard to beleive that plans for enshittification haven't existed from quite early on. At some point they are going to have to do something about https://isaiprofitable.com/ and once they are extracting from you to fill that hole they won't want you jumping ship.

Although, I do use ChatGPT more nowadays because their subscriptions work with Shelley. Sometimes I try other models after I hit the weekly cap on the subscription.

https://vibeghost.org

1. Sessions are locked into Codex and Claude Code so you can’t take a session with you. Pi solves that since they all stay Pi sessions and you can change models in the same session

2. Subagent prompts are not shown. Pi solves this by not supporting subagents out of the box. You can use a number of subagent extensions or build your own which will not be encrypted or hidden.

3. Thinking is hidden and obfuscated. Pi can’t solve this since this is server-side. Though the Codex app is closed source and they could hide more things in that harness. Pi shows you as much as it can from the API. You can also run another model to “decipher” the thinking which you can’t in Codex.

I haven't used OpenCode in months so this might've changed. I'm also thinking of giving JCode a spin since it's even lighter but doesn't have extensions.

0. https://pi.dev/packages

1. https://github.com/1jehuang/jcode

Sure there are some features that you'll want immediately but when I took at look at the number of slash commands that ship with Claude code I find it ridiculous.

That's because there are no "reasoning" tokens. That is the entire point of doing it this way.

One major advantage is that I can switch to a different provider if OAI starts to get weird about this stuff and be able to have a fighting chance of re-adapting my harness to the new vendor's model. If 100% of my reasoning process is outsourced into the proprietary blackbox, there is little hope by comparison.

Even if it wasn't, the big players would lobby hard to make sure it isn't them.

I also tend to throw some huge tasks it can't do yet and watch it burn a zillion tokens, and I usually learn more about where it's limits are and am sometimes happily surprised by its success or partial success.

I'll infodump though.

I built https://wordpeek.app https://scramble-quest.app and https://playsilhouette.app this year. Those are what I've shipped anyway, a number of others too that didn't ship (I did game rules and basic clients for 7 other existing multiplayer games, and another prototype.)

Out of frustration with some stuff I've tried to build my own game framework. There's four totally separate threads I'm trying to pull together with this

1) I want all my games to work really well on web even though they are generally targeted at either mobile or PC, but it is very valuable to have early builds runnable on a website, hopefully from a phone too. I feel like I have something good here.

2) I do a lot of turn based games and strategy games. I have a rules engine framework setup that I really like and I feel makes it almost impossible for an LLM to write the bad code it loves to write where game state and UI are intermixed, or game action timing can be problematic, stuff like that. As an added bonus I get multiplayer trivially, I get replays trivially, and I get game rules tests trivial to write. I love what I have set up here.

3) I have an xml/css-based UI that is intended to make it hard for the LLM to write bad UI code, which it will still do even though it can't intermix game state in with it due to #2. I do not have something good here right now. What I have has bad performance and memory characteristics.

4) I am fascinated by the idea of shipping software that can customize and edit itself. I have built in agent harness, built in image and audio asset generation, a built in git repo. This all works in the web and it can edit the game live! And when run locally can shell out to your claude code and codex. However this whole bullet point is all not very good, I still just use claude code/codex directly for everything.

I don't really have anything to show here, but it doesn't expose any of the stuff I mention above. It does however have a full port of the game Spectromancer to my engine - https://nanogame.app/ - and I am presently having it try to write a responsive UI for it (this is very broken at the moment but it is making progress.)

The real thing that will take this alive though is people pushing back a bit against some of these newfangled APIs. Now that there is real competition from the new generation of Chinese models which have much fewer of those restrictions, I think there might be a moment.

I just tested again and even my cursor gets jump over the page. Amazing they'd do this for such a subtle, useless effect.

* a style guide with examples for different tasks (it’s sufficient to name writers with some attributes you like if they are famous)

* mechanical formatting, output and other preferences

* a short list of the things I consider most important in different writing context, this the the squishiest overall

* a (growing) list of banned Claudisms. Nothing is really banned, but it includes things like: you may only ever use “scar tissue” in reference to actual regenerated tissue, never metaphorically

The thing is you have to be discipline with it. Every time they output something you don’t like, you’ve got to spend time verbalizing what about it you don’t like and in what context and then add it to the rules file. The first few docs you generate will take a long time, but each repeated generation gets better and by the 4th are 5 time you do this it’s like 80% of the way to where it needs to be and that generalizes well.

I do not really like (even if it is my daily driver for a lot of things) gpt-5.x for text. It really needs heavy hand holding and beating it into submission to produce readable/human sounding text.

Tbh. I am still looking for my "go to model". But the Chinese models were for my use cases significantly better than openAI models and personally I liked them better than Anthropic ones as well.

The thing is here but you might find hard time setting it up unless you are a Nix user: https://github.com/7mind/cq

I have only just started with it in the last few hours so I could be massively disappointed but I live in hope.

    {'continue_conversation_id': 123, 'message': 'another message?'}

Also, isn't it without caching even something like O(N^2) because you have to replay the whole conversation on every request to reach the same internal state? My point was I shouldn't have to pay for cache misses if hitting the cache is not deterministic. Give me a guarantee that you keep the session "hot" for N minutes, and cached on disk for M months, charge a little bit more on average, but then the pricing is at least transparent.

[1] Except the general market pressure to keep total cost for the same problem solved lower than the competition.

The questions that the article poses are, and this is the way fyai addresses them:

Inspection: Can the user see what the model saw, what tools did, and what agents told each other?

fyai> Full session log, tool calls, agent invocation, along with their durable state is stored locally in the durable arena and are available for inspection.

Export: Is the session self-contained, apart from ordinary artifacts that can also be downloaded?

fyai> The session is completely self-contained, no artifacts are stored anywhere besides the arena. Not only that sessions are export-able, import-able and transferable to other fyai sessions.

Replay: Can another implementation reconstruct a semantically equivalent context?

fyai> Full canonical and provider dumps can be generated. There is a standard schema, and the format is just YAML. Other tools are free to ingest it, and replay it.

Audit: Can a human explain why the system took an action after the fact?

fyai> Complete conversation logs, mcp session logs, authentication logs + full wire logs are available via fyai log.

Deletion: Can the user identify and remove every server-side copy on which the session depends?

fyai> Obviously fyai cannot help there. But as a business model, FYAI can work with a completely stateless, inference provider where absolutely no logs are kept, beside the ephemeral KV caches of the active sessions.

The rest of the article deals with the woes of the encrypted session content (reasoning and compaction). fyai fully supports their use, but, it is completely capable of operating without their use - you merely pay the cost of not hitting the cache of the provider.

The article then offers action points for portable inference.

This is how fyai answers:

1. The local event log is canonical. Server storage may mirror or accelerate it, but the client can reconstruct the session without dereferencing server IDs.

fyai> This is exactly the model that fyai provides. No server IDs are needed besides reconstructing the provider session that is hitting the cache.

2. Storage is explicit. store: false should be easy, documented, and preferably the default. Features that require retention should say so at the point of use.

fyai> fyai provides a --transient option, where no content is committed to durable storage; the operation only works on a transient RAM arena that is overlaid and then discard at the end of the operation.

3. No opaque item is the sole carrier of meaning. Encrypted reasoning, compaction, and tool signatures may be included for same-provider quality, but each has a readable, provider-neutral handoff representation.

fyai> Opaque items are the providence of the provider meta stream and is not required for operation; merely for cache optimization.

4. Hosted tools have full-fidelity logs. Record exact inputs, outputs, evidence, filtering, provenance, timestamps, and content hashes — not only a polished answer and citations.

fyai> The arena records all operations of the main conversation, tool calls _and_ their agent invocations. There is not context loss what-so-ever, by design.

5. Subagent communication is auditable. Persist the exact readable task, messages, results, lineage, model, and tool permissions for every agent.

fyai> All agent communication, and agent tool calls are inspectable because it is stored, again by design.

6. Compaction is inspectable. Return a readable summary, the instructions used to create it, and enough lineage to understand what was discarded.

fyai> Compaction is configurable; you can configure the agent to only use model summary compaction which is generating a text answer, which is stored durably.

7. Artifacts are exportable. Files, container outputs, search snapshots, and generated media can be downloaded into a content-addressed local archive.

fyai> All artifacts are local; Nothing is executed on a hidden provider server.

In conclusion, I think fyai address the points of the article quite well, don't you think?

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.

you can also read this: https://try.works/first-principles-of-model-routing

cache hit rate is kept high by 1) keep the number of models small, for coding there should only be two. 2) keeping cache warm for both models.

the cache hit rate is only 0 the first time a model is used in a session. after that, cache is preserved. the losses are small, here is an example:

you have a 200k cache. your message delta for each turn is an additional 1k tokens. you have two models and just for the thought exercise, lets say we route between them each request.

1k/200k means if you never switched models, you would always have a 99.5% cache hit.

when you route between the two models each turn, now the message delta for each model per turn is 1k+1k.

the cache hit rate then becomes 2k/200k = 99% instead of 99.5%.

is it worth it? depends on the models in your pool. If you have GPT 5.6 and DeepSeek, it's worth it because the cost difference is vast.