I seriously do not comprehend how a consumer like you can have sympathy for Anthropic, as if you are part of their organisation or something. Competition is good for us. Wouldn't it have been for asian labs, we would would be fully dependent on OpenAI, Anthropic and Googles services.
Anthropic just stole the internet and put it in a transformer and pat itself on the back for it - well no to be honest we have to suffer through hearing them saying that this model is really really dangerous until they got a reaction for they fear mongering
Anthropic are the pathetic ones. The pariah of the AI industry that nobody likes because all they do is lie, cheat and steal. Now no one can access ChatGPT 5.6 because of their 5 year long fearmongering regulatory capture campaign.
Hopefully they go bankrupt and someone else takes their place.
> Now no one can access ChatGPT 5.6 because of their 5 year long fearmongering regulatory capture campaign.
I'm sympathetic to this arguement, but it's silly to ignore the other half; that the administration has openly feuding with them for months over limits to military capabilities.
No one is ignoring the other half, the feud is rooted in Anthropic's insatiable desire for power and control over everyone and everything, including the administration. The same desire that is fueling the strategic fearmongering campaign underpins all of their behavior and the repercussions and sentiment they're facing from the administration and the general public.
If their company hadn't been posturing like this for 5 years they'd have played ball with the administration like all of the other AI companies and they wouldn't have caught all that heat and taken down the AI industry with them. Just remember that Dario was pushing the narrative that GPT 2 was too dangerous to release to the public, while he was working at OpenAI. GPT 2!
Now it's an inevitability that China takes the lead - which was probably the case anyway, but a certainty if this continues.
> No one is ignoring the other half, the feud is rooted in Anthropic's insatiable desire for power and control over everyone and everything, including the administration.
Again, this is ignoring half of it. See what they did to Intel prior:
"President Donald Trump said Monday that he and members of his cabinet met with Intel CEO Lip-Bu Tan, days after he called on the head of the chipmaker to resign. Intel shares rose 2% in extended trading."
"U.S. Government to make $8.9 billion investment in Intel common stock as company builds upon its more than $100 billion expansion of resilient semiconductor supply chain."
“That unlocks something beyond energy savings: the possibility of eliminating water consumption entirely.”
They’ve made this claim numerous times in the article and I really don’t understand it. The building has tons of water being recirculated through it. That water came from somewhere in the surrounding natural world. How is that 0 water consumption?
As someone else noted - it's effectively zero compared to the water evaporated in evaporative chillers.
But it's still misleading. The major source of water use in datacenters, by _far_, is the water used in power generation. This improves PUE, which reduces power draw, but the savings are almost certainly under about 20% given that many modern datacenters already operate at a PUE of under 1.2. So if you're running on coal or gas, you're still consuming quite a bit of water indirectly.
Now that said again - the water consumption part of this equation is generally overhyped. The power draw is the problem, as are the really bad temporary hacks to the power problem (e.g., what x.ai is doing with "temporary" gas turbines).
Sorry! Power Usage Effectiveness. It's a measure of the overhead of delivering power to the servers (or motherboards, depending on how you measure it), taken to include all other datacenter power overheads: AC/cooling, UPS losses, and sometimes transformer/rectifier losses.
A PUE of 1.2 means that for every watt of power you're using in a server, you're using 1.2 watts drawn from the grid (approximately). Those extra 0.2 watts are being spent on cooling and other things.
After filling the tanks once, subsequent draw would be zero. Most data centers currently use evaporative cooling - where they pull tons of water in, and then... Let it evaporate.
Imagine a residential building that reclaims and reprocesses and purifies 100% of all the water it uses. This would be dramatically more difficult and better than the status quo, and would be called 'net zero' by any sensible accounting method.
---
Obviously, evaporative cooling is net-zero water use when accounted across the entire globe (the water falls as rain, somewhere, eventually), but it is net-negative for a local community.
We’ve got a company of several thousand employees serving hundreds of millions of people arguably the best AI model in the market. Meanwhile you’re asking for a handkerchief for your pool of tears because their product is struggling to do your daily job functions for you, with much of that due to being limited by the worlds supply of silicon, electricity, water, and other resources. Cry me a river.
Sorry but are you implying that for every system you integrate with, you verify the scope of an API key by checking each CRUD operation on every API endpoint they provide?
I think the suggestion from their "somewhat sympathetic" position is that if you are integrating with something you should (a) find out up front what limits it does or doesn't have on its API keys, so that it's not a nasty surprise later, and (b) absolutely don't give keys without really tight scopes to "agents."
The person here who deleted prod DB with their agent made an assumption that an API key wouldn't have broad permission if there weren't warnings ("We had no idea — and Railway's token-creation flow gave us no warning — that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete. "). I don't know what the UI looks like exactly, but unless I'm explicitly selecting a specific set of limited permissions, I don't know why I'd assume "this won't do more than I am creating it for". Like "I didn't ask the guy at the gun store to put bullets in, I wouldn't have given the gun to the agent if I'd known there were bullets in it."
I also would be wary of running on an "infrastructure provider" that didn't make things like that very clear.
Is this overly harsh? I don't know. I've had to explain far too many times to people (including other engineers) what makes doing certain things unsafe/foolish (since they initially think I'm wasting time checking things like that). So I think stories like this need to be taken as "absolutely do not make the same mistakes" cautionary tales by as many people as possible.
For every API you publish, do you verify that scoped API keys work as they should before you go live? If so, why would you not do the same for APIs you integrate with? It's all part of "your" system from the user's perspective.
I think the author is being deceptive with this part:
>3. CLI tokens have blanket permissions across environments.
>The Railway CLI token I created to add and remove custom domains had the same volumeDelete permission as a token created for any other purpose. Tokens are not scoped by operation, by environment, or by resource at the permission level. There is no role-based access control for the Railway API — every token is effectively root. The Railway community has been asking for scoped tokens for years. It hasn't shipped.
They're trying to make it sound like there was some misleading design around scopes, but the last sentence gives it away. They simply assumed that a scope would be enforced somehow, even though they never explicitly defined one like you would in a service that actually supports them. (Or worse, they actually knew all this ahead of time and still proceeded).
That said, I haven't used this service so I can't evaluate the UX. I know that in GitHub or cloud IAM there is no ambiguity about what you're granting. And if I didn't have full confidence in the limits of a credential then I sure as hell wouldn't give it to an agent.
“why would you not do the same for APIs you integrate with?”
Who does that? Jira and Salesforce have hundreds of endpoints each. AWS has hundreds of services, and each may have hundreds of endpoints. Who on your team is testing key scopes of every endpoint? Do you do it for each key you generate? After all, that external system could have a bug at any moment in managing scopes. Or they could introduce new endpoints that aren’t handled properly. So for existing keys, how frequently do you re-validate the scope against all the endpoints?
Yes but my original reply was to someone that seemed to imply that this founder was dumb not to verify that Railway’s API key that should have been limited to managing custom domains, truly was limited to managing custom domains. I’ve never used Railway but my pushback is that no one in the real world exhaustively verifies a key is scoped properly against all 3rd party endpoints. We trust vendors to document how they’re scoped and to actually do that.
I think it is meaningful that the author didn't say "there was a bug in scope enforcement" or "the UX is really misleading- look at these screenshots." In fact they even state this a long standing community FR. And they don't even say they only discovered this after the incident!
It actually seems like they knew ahead of time and proceeded anyway, but are just using this critique as a way to shift blame.
No I'm not. But it's clearly stated in the article that the API doesn't have scopes at all... So there was no reason to assume that some would be magically applied!
In GitHub or AWS etc you expect scopes to work because you define them. However if there is no way to define them in the first place, would you assume the system can somehow read your mind about what the client can access??
In fact I now believe this is a deliberate rhetorical sleight of hand. Point out a legit critique of the API design as if it is an excuse. But really any responsible engineer would notice the lack of scopes immediately, and that would be a flashing siren not to trust them to an agent.
Can you do basic addition of 2 arbitrary numbers with 100% accuracy (no tools) ? No you can't. You will make mistakes for a sufficiently large N even with pen and paper, and a very small N without. Are you no longer generally intelligent ?
LLMs should use tool calling (which is 100% reliable) instead of doing math internally. But in general it would be nice to be able to teach a process and have the AI execute it deterministically. In some sense, reliability between 99% and 100% is the worst because you still can't trust the output but the verification feels like wasted effort. Maybe code gen and execution will get us there.
This is the exact problem CognOS was built to solve.
99% reliable means you still can't remove the human from the loop — because you never know which 1% you're in. The only way to actually trust output is to attach a verifiable confidence
signal to each response, not just hope the aggregate accuracy holds.
We built a local gateway that wraps every LLM output with a trust envelope: decision trace, risk score, and an explicit PASS/REFINE/ESCALATE/BLOCK classification. The point isn't to make
LLMs more accurate — it's to make their uncertainty legible so the human knows when to step in.
Open source if you want to look at the architecture: github.com/base76-research-lab/operational-cognos
“I think the decision was made because the people making this decision at Anthropic are well-intentioned, driven by values, and motivated by trying to make the transition to powerful AI to go well.”
Every single one of these CEOs happily pirated unimaginable amounts of copyrighted content. That directly hurt millions of real human beings. Not just the prior creators but also crushing the future potential for success of future ones.
“You never needed 1000s of engineers to build software anyway”
What is the point of even mentioning this? We live in reality. In reality, there are countless companies with thousands of engineers making each piece of software. Outside of reality, yes you can talk about a million hypothetical situations. Cherry picking rare examples like Winamp does nothing but provide an example of an exception, which yes, also exists in the real world.
This was a great article. The section “Training for the next state prediction” explains a solution using subagents. If I’m understanding it correctly, we could test if that solution is directionally correct today, right? I ask a LLM a question. It comes up with a few potential responses but sends those first to other agents in a prompt with the minimum required context. Those subagents can even do this recursively a few times. Eventually the original agent collects and analyzes subagents responses and responds to me.
Any attempt at world modeling using today's LLMs needs to have a goal function for the LLM to optimize. The LLM needs to build, evaluate and update it's model of the world. Personally, the main obstacle I found is in updating the model: Data can be large and I think that LLMs aren't good at finding correlations.
reply