This sucks and it makes me sad. The end of an era.

I really hope Anthropic doesn't follow, but I assume they will eventually because why wouldn't they? Google and Meta obviously will, with great enthusiasm.

Open models are the only hope, I guess.

I dont see a problem its just a small suggestion at the bottom and im sure some hacker will make a chrome extension that blocks it.

Ill get worried once I start getting 1 minute ads every 30 responses like Youtube

There is no way a company makes money doing a thing and doesn’t “optimize” it over time to enshittify to the greatest extent possible.

Come on now, arguing it's a good feature is different than arguing that it should be turned on by default for everyone with no documented option to turn it off.

I like this feature as an OPTION that is DOCUMENTED. But that's not how it was rolled out. The CC team + processes clearly failed here. And this is far from the first example of this kind of slopiness.

I don't think it was malicious, but I do think it was quite obviously reckless/careless, and I feel like most of the comments here match that sentiment. Everyone and every team makes mistakes, but unfortunately I don't see the CC team really learning from those mistakes even though they keep happening.

CC is not a stable or reliable tool, it is bleeding edge, and that's a tradeoff you make when you pick it over other harnesses.

Sadly, it seems the pelican benchmark is now saturated. Time for Pelicanbench Pro!

I will never stop being fascinated with takes like this. Maybe you're right. But people said very similar things over the last few years and many of those statements look unbelievably naive in retrospect.

Sure, AI can auto-complete the line, but it can't write full functions.

Sure, AI can write functions, but it can't complete full features.

Sure, AI can write full features, but it can't build full applications.

Sure, AI can write full applications, but it can't build them in the right way / ask the right questions / write beautiful maintainable code / do what _I_ do..

Time will tell.

Even the early versions of AI autocomplete tools like Tabnine and the original Copilot could autocomplete entire functions, so I think you might be strawmanning a bit.

This is "Feature Factory" thinking, and it is usually not ideal. Feature count is a poor metric to optimize against. Instead, ROI and delivered customer value should be the focus of product development investments.

I think this is clearly be design. They don't want to provide support, they want you to give up and let your issue go.

It might be. It also lets my loyalty go slowly by slowly. Monopolies work until they collapse.

If you can't tell, it frustrates me so much. I wonder how the internal culture of Uber changed when it went from almost zero interest rates to now trying to make lots of profit.

My friend said he realized Uber can just rely on a steady stream of people either growing up or getting laid off and trying to make a quick buck, so they can treat their drivers poorly as well.

I'm not sure what's happening, just know support may be a lot simpler and cheaper to address than nothing, or at least in the medium to long term, but maybe not?

I understand and sympathize with this point of view.

I would just say this: there is a difference between advice for using a product, and for _optimizing_ your use of a product. Between a user and a power user.

I think devs probably disproportionately like to see themselves as power users of any given tool, and thus with coding agents, there are 1000 "systems" being thrown out on GitHub on any given day. Generally speaking, it is safe to avoid these, especially if you're new to the tool.

But saying the fact that people are into optimizing their setups indicates some fundamental deficiency of the tool misses the point, I think.

Claude Code and Codex CLI (and OpenCode, and I'm sure many others) are _remarkably_ effective right out of the box. The teams behind these tools must make them _generically_ useful so that they are accessible to as many people, and as many use cases, as possible. That is part of why, when you become familiar with the tool, there is typically going to be a level of customization you can apply to it to optimize it for _your_ use cases, beyond the generic out of the box configuration.

Similarly, I don't think it would be fair to critique VS Code simply because most power users augment it with a suite of extensions. In fact, it's customizability/extensibility is part of what makes it great.

I absolutely understand the power user perspective. The point is not that, and maybe I wasn't clear enough in pointing it out.

Here, something different is going on instead of the usual "base tool is ok for 90% of use cases, remaining 10% is covered by plugins and extensions". A lot of developers are finding it difficult to commit to agentic coding workflows, feeling a stretch on a lot of different aspects.

Companies, with the help of a very prominent and vocal part of the web and social media community, are addressing every issue by simply blaming the users, saying it's their fault if they're not keeping up with all the alleged advancements in prompt strategies. See the whole "maybe you haven't tried it in the last two months, everything's changed now". While it's true that things have been moving very fast, the fundamental idea behind the technology is the same, and some concerns about it simply cannot be wiped away by scaling some factors.

Just use a fallback, like Codex CLI. Takes a little effort upfront to ensure your configuration is wired correctly for both harnesses, but it is pretty easy to get them 90% identical (there will almost always be some experimental / edge case features that differ across harnesses, but in my experience those are negligible in practice).

Came here to say this -- humans are not always rational actors. I get asked questions all the time, which I have no special knowledge of, and which the asker could have easily Googled or ChatGPTed. And yet...

Humans. Can't live with 'em, can't serve 'em with some fava beans and a nice Chianti.

I feel like caching should be mentioned in tradeoffs, right? If you change the tool list frequently, that's a cache bust. In long sessions that seems like it could significantly affect costs.

Great question... and there are two answers depending on what you were originally referring to:

re: Claude Code... we actually don't filter or modify the tool list so all tools stay visible -- disallowed calls get blocked at execution time with an error message. No cache busts on transitions, the model sees the full tool sets. The cost there is prompt caching dollars not latency I suppose

re: The research (Rust agent + Ollama) the model only receives tool schemas for the current states' allowed tools. Ollama does have a KV cache reuse facility so changing the tool list busts that cache. Depending on your workflow this can happen as many times as you expect your states to transition until completion. For simple workflows this is 3-5x. Within each state the tool list is stable and cache operates normally. Presenting fewer tools instead of dozens on every agent processing step reduces input tokens and decision complexity, which is where the measurable gains come from.

Both enforce the same constraints depending on the execution interface. The schema level filtering in the research is the S-tier approach. Adding tools/list filtering to the MCP gateway would be beneficial if possible (it looks like we could only filter MCP tools not core ones, which could provide tangible benefit. I've added this evaluation to the roadmap.

Nice, thanks for the detailed answer!