211–220 of 238 posts
Earlier quoted context omitted.
And yet people still go with Sign in with Google as the only login method.
Because with the alternative they'll require you to "confirm your e-mail" instead of just picking a password
Janet and Jake, I am sick of getting your stuff. Learn your actual email.
This is an important article. I hadn’t realized it was already getting this bad. Like a frog enjoying a nice warm bath ... > Most people do not switch their operating system or phone provider every week either. But even if you do not utilize that freedom, it matters because it changes the relationship you have with the provider and the provider has with you. This is why it’s important to utilize your freedoms. Do NOT…
Anything new is going to be an extremely rapid race to the bottom.
This is an important article. I hadn’t realized it was already getting this bad. Like a frog enjoying a nice warm bath ... > Most people do not switch their operating system or phone provider every week either. But even if you do not utilize that freedom, it matters because it changes the relationship you have with the provider and the provider has with you. This is why it’s important to utilize your freedoms. Do NOT…
But being able to decode the blobs that subagents returned in a conversation I've already forgotten about? That doesn't affect my ability to switch at all! I can't even imagine what trivial detail of an operating system this is analogous to. Maybe an undo buffer of a document that gets cleared on exit anyway?
I can still pass all my code, and any associated documentation, to any other agent at any time. What am I missing?
Earlier quoted context omitted.
what would it take for this to be more than just hn blog fodder?
We were thinking about it while writing it. I think one thing at least open source harnesses can do is push back on using some of these conveniences from the providers. For instance the moment we start compromising on the idea of portable sessions, then there will be less pressure (For instance people asked for OpenAI server side compaction or built-in native web_search support). The real thing that will take this al…
uhh openai just did a whole thing with arc agi where they very clearly explained that you will lose a lot of performance if you do, this isnt just about convenience
This is exactly why Pi will win. It lets you hot swap models when one is struggling or straight up refusing the task. And since it works with any sub outside Claude Code, you can use it to try different models on OpenCode Go sub or even OpenRouter. As far as subagent prompts and results being obfuscated, I just let Pi spawn new agents. Using skills and extensions, I’ve essentially built a software factory using Pi an…
"I’ve essentially built a software factory using Pi and a custom terminal multiplexer." I'm curious to know more about this. I was thinking about doing something similar using tmux (i.e. have one coding agent open up new ones in tmux and use 'send-keys' to control them). Is there any reason I might want to consider a different path? Something built on libghostty?
Earlier quoted context omitted.
They mentioned a few things 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 h…
I see your point. I was thinking mainly about #3 and how nothing, not even pi, can solve that when the reasoning traces are encrypted by the model provider.
Claude and Codex flag this as a distillation attempt so you have to use an open weight model and the results are, of course, just a guess.
Earlier quoted context omitted.
How will Pi help? If I'm using pi with my ChatGPT subscription, that won't unlock access to full, unencrypted reasoning traces. If I switch a pi conversation from 5.6-sol to kimi k3, the 5.6-sol reasoning traces won't be visible to kimi k3. I think that's the main point of the article, no?
They mentioned a few things 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 h…
OpenAI has been nudging their users toward the Responses API lately. Chat completion can still do everything if you are clever. The obvious reason to push everyone into the Responses API is that the reasoning process can be locked down and encrypted. The semantics of the chat completion API are fundamentally transparent. 100% of the tokens are visible. If you have patience and the willingness to endure a little bit o…
Earlier quoted context omitted.
We were thinking about it while writing it. I think one thing at least open source harnesses can do is push back on using some of these conveniences from the providers. For instance the moment we start compromising on the idea of portable sessions, then there will be less pressure (For instance people asked for OpenAI server side compaction or built-in native web_search support). The real thing that will take this al…
> one thing at least open source harnesses can do is push back on using some of these conveniences from the providers. uhh openai just did a whole thing with arc agi where they very clearly explained that you will lose a lot of performance if you do, this isnt just about convenience
Which part are you referring to here? web_search coming from the provider hiding the tokens is just a convenience, there is no reason it can't be done with revealing information. Their compaction on the server might be amazing, but at least in principle it can be replicated on the client side as well and it could have been implemented in a way that reveals the new initial context.
OpenAI is doing this so that you can't preserve cache when routing between for example GPT 5.6 and DeepSeek V4, or other providers. I'm building a router that easily reaches >99% cache hit rate in Pi when routing between GPT 5.4, Kimi, DeepSeek etc. Working on a big update that's coming out in a week or so.
Awesome! Any place I can follow the project? Also, how to achieve these levels when switching mid conv? Don’t you effectively need to read the tokens per model switch?
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.