I'm not sure if you're expressing how you'd like US law to work, or how it actually works. Because in reality intent matters enormously. Like felony charges and people in jail vs civil lawsuits.
Intent doesn’t factor that strongly into negligence, though, which is what they were explicitly talking about. Though it may depend on your jurisdiction.
How, exactly, would the proposed solution (combined with a setting to disable it) break, and how would implementing it the way Anthropic did address that? Be specific.
Some people might have a different CLAUDE.md and AGENTS.md because they use Claude to do one thing and $other_agent to do another thing. Or because Claude does XYZ by default, and other agents do ABC, and they want to give the correct guidance to both.
This is, to me, a completely reasonable and believable use case that could break if you implement this fix without "overengineering" it.
A setting to disable what? Be specific. See? Not so simple...
First, GP's proposal already addresses that. If both are present, CLAUDE.md would be used. Second, that is solved with a settings toggle. Read a boolean from .claude/settings.json and disable the new behavior if it's true (or false, depending on what you want to name the setting). third, you skipped the second part of my question: "how would implementing it the way Anthropic did address that?" Implementing the same behavior through multiple layers of abstraction and an order of magnitude more code doesn't solve the issue you mentioned.
Bonus forth point: why is this critical to solve for claude code, but not for all the other harnesses which have all converged on AGENTS.md for this purpose?
Okay, so we agree that this fix isn't quite as simple as it sounds then, yes? We've just had 3+ paragraphs of discussion around potential edge cases and additional considerations beyond "read one of two files."
We've had a long discussion only because you refuse to admit that a very simple solution would work (despite completely failing to show how it wouldn't). The problem is that your opinion is not in fact proof that you're right.
I see, well I'm not particularly concerned with being right on this topic (call it a difference of opinion or matter of taste), so I wish you a pleasant day.
Is accusing someone of "shilling for Anthropic" for suggesting that a bug fix might not be so simple really the level of discourse HN has devolved to now? Is it the kind of HN you want?
Is the level of HN discourse suggesting that having a large number of users worth of never making simple changes something you want? This isn't a move fast break things suggestion, this is a rational common sense suggestion. Instead, you're pushing an overly complex way of implementing something that would allow for all sorts of unknowns. Earlier comments suggesting this new mods concept was being worked on giving the dev a new 20lb sledge hammer so the CLAUDE/AGENTS situation suddenly got beat on like it was a railroad spike when it just needed a smaller hammer since it was only a finishing nail.
This conversation comes down to people saying “Why don’t you just…” to Anthropic. Anthropic has the most information and made the choice they made. That choice may have been over-engineering, an appropriate choice or both. Discussing that choice could be interesting and it could especially be informative to people without much experience. Speculating on that could lead to an interesting conversation—especially WRT how people are actually using the current status quo—but imagination seems to be lacking here.
Instead we get the implicated assertion that users’ existing workflows shouldn’t matter to Anthropic and accusations that someone you don’t agree with is a shill. When called on that you avoided the question.
To answer your question, although it wasn’t directed at me: YES. I want people to be able to discuss that exact issue even if it isn’t personally interesting to me.
> Anthropic has the most information and made the choice they made.
Anthropic is the last company I would trust to make any decisions. Look at any discussions surrounding their "Claude is a tiny game engine" idiocy, numerous bugs that a junior can discover, a full "plugin system" in which they neeeed a dozen files in the worst Clean Code manner to read one of two files etc.
Which order do you prefer them in? Since CLAUDE.md is no longer necessary, but was for so long, what happens when users only update AGENTS.md going forward while keeping a stale, unchanged CLAUDE.md around?
We're talking about changing default behaviors here in ways that can be surprising to users. It's reasonable to try and accommodate existing setups, future setups, and - yes - careless users.
There's no surprising behaviors in that situation. Someone who is aware of the change would most likely delete CLAUDE.md. Someone who is unaware of the change would assume CLAUDE.md is still the one being read by CC, which would hold true.
I've never heard of the 'move fast, break things' mentality ever giving a damn about number of users. If so, no changes would ever be made. The great thing about having millions of users is QA can be eliminated entirely as you'll start hearing about issues from the users directly.
Bash does this well, reading only the first of half a dozen config file locations it searches. And if the user needs it to read from an additional location, just add a source line to that location.
Astra was/is superior for planning type tasks. It was capable of doing seemingly magic things with rather vague/lazy instructions ("I need to be able to test this on Windows, maybe a qemu VM or something? Shrug." ... 1 hour later "yeah i built you a whole qemu + eval windows image + harness of powershell scripts + shell scripts to retrieve & verify harness.").
And for UI work -- which is not something I do a lot of but do here and there -- it was clearly superior to 5.6 Sol.
But it also feels sloppier? Somehow. And too expensive to use.
I felt this way with Sol in the 5.6 series and was one of the seemingly few people on this earth who liked Terra for that reason. I would often have a very specific code-manipulation ask, e.g. "add a parameter to this method, ensure all callers pass it in, if there is not a logical way to derive the parameter to be passed in a particular instance, flag this in your final response", and Sol would go on some rabbit hole side quest to refactor my codebase to determine some way to derive it rather than flagging it as I had asked.
Terra had the "workhorse" quality where it could do these changes in bulk and follow directions without being too 'smart' (but sloppy) as you described. Luna was a bit too dumb and would make sloppy mistakes; I see that more as a "run these tests and format the results" sort of model. Maybe 6 Luna will be better.
I also just reread your comment and realized the naming convention is still extremely confusing with respect to ordering of [Family]x[Model]x[Number].
I also get good mileage out of Terra when I need a diligent workhorse. That's a good way to describe it. We should start using character archetypes when we describe models, it'll do more good than the dubious numbers and cherry-picked quotes. Maybe RPG character-type cliches? Myers Briggs?
Glad you pointed out the UI work. I've been doing a lot of it and it's so much better than 5.6 as UI, it's unbelievable. I give it super ambiguous instructions and it's reading my mind. I do the same thing with 5.6 and I'm correcting it for a few minutes.
I use Astra for rapidly consuming my token limit on a task that would not consume it on 5.6 Sol.
(I have not done anything quantitative here. For one thing, OpenAI’s billing pages and the codex-rs frontend make it pathetically difficult to get any real data. Some day I should wire up a proxy to extract actual stats.)
About half of SpaceX revenue is Starlink subscriptions. Starlink is the one profitable division; the rest of the company operates at a loss, including xAI.
I don't know that's moving the goalpost, SpaceX's mission was not that originally. Some could say the original mission failed and they are pivoting, Elon will say it's a means to the end of the original mission still to save face. Some read it all as snake oil
A dense model (up to the amount of memory available) actually does make the most sense on unified memory architectures. But when you hit the limit of what you can hold in memory, you reach the limitation of the platform.
Whereas a hybrid architecture with distinct DRAM and VRAM with sparse MoE, you can leverage two different bit rates depending on the actual need for constant access to common layers versus sparse access to infrequent layers and arbitrage the difference in cost for each of those in distinct classes of hardware.
> 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?
They do MoE. They benchmarked GLM 5.3-flash (320B / 18B), and Qwen 3.8-flash-next (125B / 6B). The dense Qwen is only focused (I assume) because it's about the only thing that fits on a 5090, that they can compare the two heads on.
reply