CjHuber

Every good thing is alike, every slop is sloppy in its own way

Given that codex itself now ships a proxy that wraps the subscription, it seems unlikely

https://github.com/openai/codex/blob/main/codex-rs/responses...

Probably because the general purpose subagents inherit the parent model

only if you don't specify which model should be used

Instead of requiring developers to script every step or passing every tool response back through the model, Programmatic Tool Calling in the Responses API can filter large amounts of intermediate data, retain only what matters, and adapt its workflow along the way.

this seems very interesting

but 5.5 was also no major version bump

fit a lot more work inside the model's context window before you're forced into a slow and lossy compaction step

This is something I never understood. Why the reasoning is not included until the context is full, then the reasoning stripped optionally to allow the conversation to continue. and only then when its truly full offer a compaction. Was it to optimize caching? Well I guess it doesn't matter now that you hinted that this choice was made because of prior limitations and may change very soon

Well, obviously its true as you can see in the silbing comment. But still interesting how experiences differ. I wonder did you ever use codex in more demanding workflows, because that at least something like that is going on is obvious if you use it for a few hours

Interesting to hear people like gpt-5.5. For me it feels smart only at one shot prompts, but if you try to build up session context before doing something it feels magnitudes inferior to Claude. I'm almost sure its because the thinking of previous turns is stripped with the responses API, so if I tell it to analyse something deeply, what remains of the understanding in future turns is only the short response text of that analysis

so you now have to wait in line for hours

Interesting, I go there pretty regularly and while It is well visited, I not once encountered a queue there

I agree, adaptive thinking is a pest and without a minimum thinking budget especially Claude for me currently defaults to not think at all even on max effort.

Sequential-thinking was really a step in the right direction, and works almost exactly how you've described, though when it was popular before the reasoning models and even now when I tried it recently I have never once see it use its branching feature and it tends also to have the RLHF urge to answer something "helpful" quickly instead.

I think this is a really good cause but I can't help but wonder about the contrast between the puppy analogy and then increasing the friction of installing it by making it a paid tool

What about GBrain

Yeah indeed it's very interesting. And the 60k initial context don't even contain the suggested change yet. For me if I don't do this the current models tend to fixate and local patches instead of tracing symbols and making a holistic model of what a change interacts with in the codebase

I'm always a bit confused when people say things like this. 60k token is often more than the initial context I feed the model with. And I don't think I ever had a productive session that began under 150k tokens.

So isn't that just purely security by obscurity then? Would they not rather have someone publicly break it instead of selling a zero day?

Technically yes

I‘m glad you didn’t write value

Are you… explaining the effects of being acquired to Hashimoto?

It does have an built in documentation subagent it can invoke but that doesn’t help much if they don’t document their shenanigans

This is exactly what also confused me. I had the exact same prompt in Claude code as well, and the no option implies you can also keep the whole history. But clicking keep apparently only ever kept the user and assistant messages not the whole actual thinking parts of the conversation

No of course it’s unrealistic for them to hold the cache indefinitely and that’s not the point. You are keeping the session data yourself so you can continue even after cache expiry. The point I‘m making is that it made me very angry that without any announcement they changed behavior to strip the old thinking even when you have it in your session file. There is absolutely no reason to not ask the user about if they want this

And it’s part of a larger problem of unannounced changes it‘s just like when they introduced adaptive thinking to 4.6 a few weeks ago without notice.

Also they seem to be completely unaware that some users might only use Claude code because they are used to it not stripping thinking in contrast to codex.

Anyway I‘m happy that they saw it as a valid refund reason

I think it’s crazy that they do this, especially without any notice. I would not have renewed my subscription if I knew that they started doing this.

Especially in the analysis part of my work I don‘t care about the actual text output itself most of the time but try to make the model „understand“ the topic.

In the first phase the actual text output itself is worthless it just serves as an indicator that the context was processed correctly and the future actual analysis work can depend on it. And they‘re… just throwing most the relevant stuff out all out without any notice when I resume my session after a few days?

This is insane, Claude literally became useless to me and I didn’t even know it until now, wasting a lot of my time building up good session context.

There would be nothing lost if they said „If you click yes, we will prune your old thinking making Claude faster and saving you tons of tokens“. Most people would say yes probably so why not ask them… make it an env variable (that is announced not a secretly introduced one to opt out of something new!) or at least write it in a change log if they really don’t want to allow people to use it like before, so there‘d be chance to cancel the subscription in time instead of wasting tons of time on work patterns that not longer work

I‘d much rather have it go slooower and check more. Why faster it’s way too fast

I honestly am very disappointed with this. I've only learned about CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING and showThinkingSummaries: true from this post. I've been wondering for a while where the summaries went and am always hoping like roulette that it thinks a lot. No wonder if there suddently is an "adaptive thinking" mode. I would have opted out 2 months ago if it was documented or communicated in any way publicly. Why change behavior without notice or any new user facing settings.

I just googled "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING" and it seems like many people don't know about it.

And ULTRATHINK sets the effort to high, but then there is also /effort max?

It's terrible that people think like that, especially in Georgia where they are still not tied to the debt fueled pyramid scheme that is the EU.

They still think of Europe as how it was 20 years+ ago, they always only look at the surface and never if the whole concept really works out long term.

I think your point doesn't hold up really. Telling an LLM to summarize something losslessly will loose so much more nuance than updating the plan directly every time when some useful information is gained.

That file is not even a plan but effectively a compaction as well, just better as its done on the fly only processing the last message(s) rather than expecting an LLM to catch all nuances at once over a 100-200k+ conversation.

I mean I agree the last couple of messages in a rolling window are good to include, but that is not really most of what happens in compaction, right?

there's often tiny tidbits in your prompts that don't get written to plans.

Then the prompt of what should be written down is not good enough, I don't see any way how those tidbits would survive any compaction attempts if the llm won't even write them down when prompted.

Secondly, it can keep eg long running background bash commands "going" and know what they are. This is very useful when diagnosing problems with a lot of tedious log prepping/debugging (no real reason these couldn't be moved to a new session tho).

I cannot really say anything about that, because I never had the issue of having to debug background commands that exhaust the context window when started in a fresh one.

I agree they are better now, probably because they have been trained on continuing after compaction, but still I wonder if I'm the only one who does not like compaction at all. Its just so much easier for an LLM to hallucinate stuff when it does have some lossy information instead of no information at all

I honestly still don't see the point of compaction. I mean it would be great if it did work, but I do my best do minimize any potential for hallucination and a lossy summary is the most counterproductive thing for that.

If you have it write down every important information and finding along a plan that it keeps updated, why would you even want compaction and not just start a blank sessions by reading that md?

I'm kind of suprised that anyone even thinks that compaction is currently in any way useful at all. I'm working on something which tries to achieve lossless compaction but that is incredibly expensive and the process needs around 5 to 10 times as many tokens to compact as the conversation it is compacting.

And how to get to the old verbose mode then...?

Does it not use prompt caching?