How did you search? I really wonder if I just have a vastly different Google algorithm than others because whenever a post similar to this pops up I have no problem finding the info using the most obvious and basic of Google searches, while other people seemingly struggle to find authoritative information. At any rate, the info comes from S&P themselves:
Simply untrue. You think everyone is complaining about this because the ones complaining are the only people commenting. The vast majority of people using Claude don't really care or even notice this one way or another. Sure among those who are irritated by it, it's good to have some ways to mitigate it, but I highly doubt Anthropic is going to devote much resources to an issue that affects a vocal minority.
I do have a way of knowing, but I actually appreciate and respect your reply... My suggestion to you is to take this shred of skepticism that you decided to apply to me, and apply to every comment you read on Hacker News, not simply the ones that don't align with your preconceived notions.
The comment situation is really bad. I generally don't see a lot of complaints people have about it, but the fact that it references random transient stuff, will delete a line and _leave a comment about the deleted line instead of just deleting the comment_, writes multiple paragraphs for the simplest stuff. It is absurd.
Users who are unhappy with some idiosyncrasies of a product tend to be significantly more vocal than users who are fine with it, and for any feature whatsoever there are going to be an unhappy group of people who vocally complain about it.
It's why time and time again you see people complaining on Internet forums about issues, and if you're part of a specific Internet bubble you might think that this complaining represents a general trend among the broader population and wonder how it is that no one is doing anything about this issue that you and the rest of your bubble are constantly complaining about... and the answer is mostly because the vast majority of people, who don't live in the same bubble you do, are mostly fine with how things work, but you're not going to hear them express it.
I usually dont comment, but just had to. Opus 5 talls garbage, Im back om 4.8 which is better but still verbose. I use the caveman skill, but after a while it is just ignored.. I switched to Deepseek for a task lately. It was a wow experience (the language part)
Over the last 6 months Claude's written material has gone from mediocre to unacceptable. The specific actual content and insights are somewhat better, but the claudisms are increasingly insufferable.
I've observed a bunch of people not being vocal and complaining, but just flat out switching. For every person you see online complaining, there's bound to be more who are equally annoyed and not being vocal, but just acting. Any many others that aren't bothered at all.
Compacting mostly gets rid of reasoning tokens, and honestly it would be nice of reasoning tokens did not constantly follow every follow up query. Asking even a simple/trivial question can have Claude use thousands of tokens. Compacting is good for getting rid of those.
I've had Claude immediately fall back to its usual verbose style immediately after compaction.
To be fair, I've had it do that immediately after re-reading the output style instructions, too.
My chat history is filled with "Yes, I broke the language rule. Let me rephrase that and update my memory. — You already have that in memory — Yes, true, I ignored that" (because "Memory" is a yet another .md file)
Claude Code supposedly supports a "post-compaction" hook, so you could have it automatically run the prompt "We just compacted the context, quickly refresh yourself on the rules in CLAUDE.md etc..".
Depending on what you've got in those files, maybe that will just use up all the context again though.
> supposedly supports a "post-compaction" hook, so you could have it automatically run the prompt
Keyword "supposedly" :)
I've had it in my settings forever, and still...
Asking it to analyse and fix the issue it produced a plausible "my training supercedes/overrides settings especially if triggered by certain words in the phrase" (paraphrasing the long text)
>There is no “oops, I wrote ‘th’ but I should have written ‘tw’ so I guess I’m stuck writing three instead of tween”.
You're mixing up two claims here, and only one of these is kind of true. Yes LLMs do internally plan ahead in a way that is emergent rather than strictly part of their architecture, so that part of your claim is true. The way you word it by saying they are "coalescing the probabilities of a range of tokens at a time" is poetic sounding jibberish though. What's actually happening is one distribution output for the next token computed from a hidden state that implicitly encodes where the text headed.
Your claim that if an LLM does happen to pick a token "th" instead of "tw", then the LLM isn't stuck with that decision is entirely false for autoregressive LLMs which is what all of the frontier models are. Whatever an LLM picks as its output token is final, it has no ability to undo that token selection and it must continue on the basis of that choice. It can't go back on that decision and revise the output.
If you're interested in this, Anthropic has a summary of a very technical paper on this topic that mostly deals with this issue with respect to poetry:
So we train a second copy of Claude to work backwards—reconstruct the original activation from the text explanation. We consider an explanation to be good if it leads to an accurate reconstruction. We then train Claude to produce better explanations according to this definition using standard AI training techniques.
Incentives to train a pathological liar. There's no baseline so can only catch out the worst of the lies/errors. Anything (including fabrications) that passes our filters is reinforced?
What are you even talking about? If there was a "baseline" for how to decode activations into text we wouldn't be having this conversation.
The choice is between "this reconstruction sucks" and "no reconstruction", and we're only now beginning to learn how to make those reconstructions suck less.
The reason the world didn't end is because people refused to upgrade Visual Studio, in particular Microsoft's bigger customers. Microsoft surveyed their users for why people weren't making the switch to VS 2013 despite all the "nice" and "new" features introduced and the predominant reason was due to all the ABI breakages.
For VS 2015 they adopted a policy of having a stable ABI and have preserved ABI compatibility for over 10 years now [1].
Knowing a definition is not the same as understanding. I know this first hand from interviewing people who at the beginning of the interview can confidently tell me the definition of certain principles in statistics that I ask them about, and then later on in the very same interview when I present to them a real world scenario to analyze, they are completely oblivious that the very concept they explained to me so articulately when we started the interview is the very same concept needed to solve the real world scenario being presented to them.
In general Wikipedia isn't a great way to learn new concepts; it's a good reference when you're already familiar with something and need to brush up on it.
I agree. What I meant to say is that the Wikipedia article tells you upfront where it is going. In TFA, you need to push many little paragraph cards across the screen before you get an idea what you are going to learn.
True, but remember that everyone learns differently. I read the bit you quoted four times, and while I can parse it, the actual understanding doesn't sink in for me. The Mario Kart article (even if much longer to read) helped me actually feel what it means.
>A program with undefined behavior is by definition an incorrect program.
This is simply false and an oft repeated myth. Undefined behavior has a specific technical definition that is in the C++ standard [1] and there is absolutely no mention in that definition or the implication of that definition that undefined behavior necessarily results in an invalid or incorrect program.
The definition of undefined behavior, right from the standard itself is... and I quote... get ready for it...
"behavior for which this document imposes no requirements"
That's it, nothing more, nothing less.
The standard even goes out of its way to state the following:
"Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, *to behaving during translation or program execution in a documented manner* characteristic of the environment".
Behaving in a documented manner characteristic of an environment is a far cry from being by incorrect by definition.
>This document imposes no requirements on the behavior of programs that contain undefined behavior
That's saying that programs that exhibit undefined behaviour are not governed by the C++ spec. For a program to be a valid, spec governed piece of C++ code it has to exhibit no undefined behaviour (outside of some constraints). Its accurate to say that any undefined behaviour results in the code being executed no longer being C++, and it can have any behaviour. That's synonymous in common developer speak with 'incorrect', as its desirable for your C++ code to be executed as C++
If the C++ standard imposes no requirements on such a program, then that means that the program is not C++. It's quite reasonable to describe such a program as an "incorrect [C++] program."
This is a semantic quagmire, and the threads on what undefined behaviour is are interminable. But just note this time around that correctness is not the same as conformity.
What's the difference? There's no such thing as "incorrect C++, but still C++." A program is either correct/valid/conforming C++, or it's not. We can reasonably describe "not" as "incorrect," or "invalid," "nonconforming," or just "not C++."
Do I love selective quoting! "Undefined behavior may be expected... when a program uses an incorrect construct or invalid data". There is also "erroneous behaviour" which "is always the consequence of incorrect program code".
Honestly, you'd have a better argument by quoting that "Correct execution" can include undefined behavior and erroneous behavior, depending on the data being processed". Which is quite a wild sentence to read, but here we are.
There is absolutely no special treatment afforded to the GSL by any of the target platforms. While we can't inspect MSVC's source code, both clang and GCC do not have any support or affordance for the GSL whatsoever and it would be very unusual to expect MSVC's source code to have some kind of affordance for this library.
The 'special treatment' isn't technical, it's procedural -- insofar as if, during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping. Since they're built as part of the same operating system, they can make sure not to step on one another's toes -- which is not a guarantee that they can make to third-party applications.
I have no idea where you possibly got this idea from since the Github Issues tracker for GSL has numerous instances of new releases of MSVC breaking GSL compilation.
I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land.
You may wish they target every possible compiler brand and version, but they are free to disagree with you and only "support" specific ones.
Unfortunately this also has the same effect as the Linux kernel now in that it is no longer technically compliant with any C++ (or C) standard.
How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library?
Your interpretation contradicts the statement that "during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping."
> How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library?
Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the library's assumptions of such behavior, as long as those are the only versions they officially "support."
Here is the original statement about special treatment:
"It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment."
My claim is that Microsoft is not giving any special treatment to the GSL... the GSL is written using functionality that is officially available to any third party library, and hence not special.
Are you disputing this? If so then what is the special treatment you're claiming that Microsoft is giving to GSL or what special treatment is GSL making use of?
I am not claiming there is any special treatment at all. I think the situation is much simpler:
They (Microsoft) test GSL with specific compiler versions to observe how their usage of the UB is treated, and if satisfactory, that compiler version is now "supported" in their eyes. They do not claim to "support" any other version because they have not tested them to know how the UB functions there.
What is the relationship between your claim, and the claim I replied to about GSL having special treatment? In other words, why did you reply to me with an interpretation about a post that claimed GSL is afforded special treatment by MSVC if your claim is that GSL does not get any special treatment from MSVC?
I'm not sure exactly where the disagreement really is. Perhaps when OP said "ensure that the changes were reverted or fixed to support" you were thinking they meant MSVC reverting changes, while I was thinking of GSL doing it instead, in order to "support" specific compiler versions they have on hand at the time to test.
Either way I think we are on the same page in thinking that compilers don't know/care that GSL exists and aren't doing anything special for it, and that's good enough for me.
https://press.spglobal.com/2026-09-04-Bloom-Energy,-Illumina...
>Sept 21, 2026 S&P 100 Deletion NIKE NKE Consumer Discretionary
reply