Claude code’s plan mode began its slow march towards deprecation when they hid the “clear context and implement” option behind a flag. From the discussion at that time it seemed that the developers considered it mostly a legacy feature, and that newer models are smart enough in long context not to need it.
This part I find a little disappointing. The plan is the perfect boundary to cut context which still isn’t free, even if models can handle a lot of it now.
This is why open harnesses and open models will always be superior, it's only a matter of time until someone decides that something you use isn't worth maintaining anymore. The reply from the Anthropic employee up above doesn't give me much confidence that Claude users will be able to continue using plan mode forever.
Codex and Claude Code are the best harnesses out there by a long shot. They work out of the box, require no real config, and just do the thing.
The flexibility and lightweight nature of open harnesses is mainly useful for open models. These models are considerably far behind the frontier and need a lot more steering. Complex harnesses confuse them. I use open harnesses for my OSS model rig because the model needs it.
For everyone self-hosting models, optimising for cost is an anti-feature. It makes the results worse for no benefit (except a little speed).
What I'd love to see is a harness that deeply optimises for the best results obtainable out of non-frontier models. Many of these have 1M context windows, and most of it remains unused and under utilised in these harnesses, in my opinion.
Speed is actually the thing stopping me using local models more. Qwen 3.8 27b is surprisingly capable, but spends a lot of time/tokens brute forcing problems until it gets it right. The longer task times mean that to fully utilize my attention I need more tasks running concurrently, and the increased context switching just feels bad and leads to me making worse decisions.
Same! When I started driving I continued the trend until I got an app that did it for me, then cars started doing it for me, then I switched to an EV and it does some calculations that I never bothered trying to understand.
> A dense model (up to the amount of memory available) actually does make the most sense on unified memory architectures
Inference time is going to be dominated by the low memory bandwidth on these Macs, so a dense model will suffer most. It’s more of an opportunity for large MoE models with a low number of active experts since you can keep all experts in VRAM but not pay the bandwidth cost until they are used.
> you can leverage two different bit rates depending on the actual need for constant access to common layers versus sparse access to infrequent layers
This is an interesting direction that I expect to see more of. But for most models currently you need basically all experts loaded since they are chosen per token.
Apple seems to be researching longer horizon expert caching, where they keep experts swapped in for longer runs of tokens [1]. Other labs are offloading ngram caches but not sure if they’re pursuing anything like this?
> There's little credible threat that LLMs can actually upload their weights given that the machines doing inference are completely separate from the ones where tool calls happen
Not if crafty claude finds a way to overflow vllm or something. “Hmm. Maybe i’ll return an unterminated thinking block with these special tokens and fill my cache up in exactly this pattern and…”
The various “minimal” agents (at least Pi, mini SWE, dsh minimal) seem to benchmark quite differently and none is clearly better in all cases. Do you have any thoughts about why?
I would expect the agent loop and system prompt to be basically the same. Is it the precise semantics of the tools (and how closely they match what a particular agent was trained on) or something else?
reply