Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @02:34PM
(#47938533)
The spend at my organization has reached beyond the $200,000 per month level on Anthropic's enterprise tier.
The amount of outages we have had over these past few months are astounding and coupled with their horrendous support it has our executive team furious.
its alot of money to be spending for a single 9 of reliablility.
Re:Claude.ai unavailable and elevated errors on the API
by Shakahs on Tuesday April 28, 2026 @03:54PM
(#47939722)
If you are paying API rates (not using Max subscriptions) there's no reason to use Anthropic's API directly, the same models are hosted by both AWS and Google with better uptime than Anthropic.
Re:Claude.ai unavailable and elevated errors on the API
by JamesSwift on Tuesday April 28, 2026 @04:03PM
(#47939896)
How do things like prompt caching etc play into that? Would I theoretically have a more stable harness backing my usage?
Im seriously over the current claude experience. After seemingly fixing my 4.6 usage by disabling adaptive thinking and moving to max effort, it seems that the release of 4.7 has broken that workflow and Im 99% certain that disabling adaptive thinking does nothing even on 4.6 now. Just egregious errors in 2 days this week after coming back from vacation.
Re:Claude.ai unavailable and elevated errors on the API
by JamesSwift on Tuesday April 28, 2026 @04:32PM
(#47940311)
Im looking at moving to Pi and I like the minimal nature, but I disagree with a handful of decisions they make. So Id likely need to maintain a fork which is less than ideal.
Re:Claude.ai unavailable and elevated errors on the API
by JamesSwift on Wednesday April 29, 2026 @10:37AM
(#47949073)
That (and oh-my-pi) seem like an excessive swing in the other direction. Im all for the simplicity and minimalism of pi. There are just a few fundamental things that need updated (mainly subagent context and open-by-default security model).
Re:Claude.ai unavailable and elevated errors on the API
by carterschonwald on Sunday May 03, 2026 @09:50PM
(#48003711)
yup thats mine. :)
i actually had some stuff layered into mono pi, and i frankly hit my limit in terms of architecture issues in monopi, omp aka oh my pi is frankly better architectured. if you pared back the fearure set to be minimal, you would full stop have a better designed minimal harness.
i do have a proper next gen no slop harness in the work.
amusingly , dog fooding existing tools with my improvements layered in, has repeatedly validated my design choices and if anything has reduced my tolerance for the errors that seem to happen in vanilla or first party harnesses
Re:Claude.ai unavailable and elevated errors on the API
by wyre on Tuesday April 28, 2026 @04:53PM
(#47940588)
What decisions is Mario making that you disagree with? My impression is Pi is minimal so any changes can live on top of Pi without needing to maintain a fork?
I started developing my own coding agent after using Pi for a couple months, so I’m curious what you don’t like about pi.
Re:Claude.ai unavailable and elevated errors on the API
by JamesSwift on Tuesday April 28, 2026 @05:13PM
(#47940864)
When I hear Mario talk about pi and his approach I find myself agreeing with a lot of it. But I also find myself agreeing with a lot of the points from this https://www.thevinter.com/blog/bad-vibes-from-pi
Re:Claude.ai unavailable and elevated errors on the API
by mattmanser on Tuesday April 28, 2026 @06:32PM
(#47941756)
the opinions in question are that bash should be enabled by default with no restrictions, that the agent should have access to every file on your machine from the start, and that npm is the only package manager worth supporting. Bold choices.
To save others a click, though the article is worth reading.
He also mentions no subagents by default in pi as well.
Re:Claude.ai unavailable and elevated errors on the API
by zackify on Tuesday April 28, 2026 @04:35PM
(#47940342)
pi for the win, i have my own ai extend it when i want more specific features. vibe coded in 20 minutes shift+tab like claude code to add permission control.
Re:Claude.ai unavailable and elevated errors on the API
by unshavedyak on Tuesday April 28, 2026 @10:02PM
(#47943372)
I find it so funny that many of these harnesses sound like black magic and are completely mystical to me. I use Claude Code every day and yet i can't imagine the workflow of Pi. I also don't care to pay API rates just to experiment with them.
Largely though i'm happy with Claude Code w\ IDE integration, so i don't feel the need to migrate. Nonetheless i'm curious.
Re:Claude.ai unavailable and elevated errors on the API
by shimman on Tuesday April 28, 2026 @02:56PM
(#47938897)
GitHub, along with MSFT in general, have massive copilot mandates where workers are being shamed into using slop tools to fix serious on-going issues. GitHub seems wholly incapable of resolving their issues: money isn't a problem, talent isn't a problem, but business leadership is definitely a major problem.
Look at how other companies are suffering massive outages due to LLMs too like AWS and Cloudflare. Two companies that use to be the best in the industry at uptime but have suddenly faltered quite quickly.
Companies that have even worse standards will quickly realize how problematic these tools are. Hopefully before a recession because this industry seems to be allergic to profitable businesses and leaders that have been around since ZIRP have shown zero intelligence in navigating these times.
Re:Claude.ai unavailable and elevated errors on the API
by kentonv on Tuesday April 28, 2026 @03:21PM
(#47939272)
None of the three major Cloudflare outages in the past six months had anything to do with LLMs. They were regular old human mistakes.
We did, however, determine that at least one of them (and perhaps all) would have been easily caught by AI code reviewers, had AI code reviewers been in use. So now we mandate that. And honestly, I love it, the AI reviewer spots all sorts of things that humans would probably miss.
(We also fixed a number of problems around configuration that would roll out globally too fast, leaving no time to notice errors and stop a bad rollout, as well as cases where services being down actually made it hard to revert the change... should be in a much better place now. But again, none of that had to do with LLMs.)
Re:Claude.ai unavailable and elevated errors on the API
by a512041364cd on Tuesday April 28, 2026 @04:54PM
(#47940608)
> None of the three major Cloudflare outages in the past six months had anything to do with LLMs. They were regular old human mistakes.
Is that true? At least one of them seemed to involve LLM-written code from what I saw. (Not to say that human error wasn't _also_ a contributing factor, but I wouldn't say it had _nothing_ to do with LLMs).
> We did, however, determine that at least one of them (and perhaps all) would have been easily caught by AI code reviewers, had AI code reviewers been in use. So now we mandate that. And honestly, I love it, the AI reviewer spots all sorts of things that humans would probably miss.
The reviewer is decent, but the false positive rate is substantial, and the false negative rate is definitely nonzero. Not that you would know that the way our genius CTO talks about it...
Re:Claude.ai unavailable and elevated errors on the API
by kentonv on Wednesday April 29, 2026 @12:07AM
(#47944070)
> Not that you would know that the way our genius CTO talks about it...
Honestly I find it bizarre that there are people at Cloudflare who have this attitude. Without Dane, the company wouldn't be half the size it is today.
Re:Claude.ai unavailable and elevated errors on the API
by hombre_fatal on Tuesday April 28, 2026 @09:40PM
(#47943221)
Something unexpected that LLMs robbed from us is to receive the grace of assuming we failed on our own e.g. good ol' fashioned human/organizational failure.
Re:Claude.ai unavailable and elevated errors on the API
by Someone1234 on Tuesday April 28, 2026 @02:46PM
(#47938734)
Obviously there is only so much you can say; but is that $200K due to the raw number of seats you have, or are you burning through a lot on raw API usage? I guess I'm trying to understand, large business, or large usage.
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @02:52PM
(#47938843)
we are in the SMB space, the spend is almost entirely usage for us at this point, rather than seat cost.
For context, we are a software firm focused on difficult engineering problems, but I cant divulge much else.
Re:Claude.ai unavailable and elevated errors on the API
by 2ndorderthought on Tuesday April 28, 2026 @04:16PM
(#47940075)
Have you guys considered running your own local models? 200k a month is a ton of money and puts all your eggs in one basket. Or is it easier to just be able to run away from it all if you are done with it or something changes?
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @04:38PM
(#47940384)
I led the team that did the math and analysis for determining our direction in selecting Anthropic.
We initially assumed this was where we would end up, but after some investment exploring our options we found it not worth the trouble.
Local models sound great until you realize you dont get alot of the features that we implicitly expect from hosted models. Many things would require additional investment into the operations and setup to get to a comparable system.
We ended up wanting things that would require us to roll our own memory system, harnesses for the model, compliance needs, and security.
It was possible for us to invest in this, but it would require additional investment in hiring or training to get us to a state comparable to the hosted options.
Eventually, I had to recommend against the project as it was more likely to be an investment in the leading team's resume, than an actual investment into our organization.
Re:Claude.ai unavailable and elevated errors on the API
by nyrikki on Tuesday April 28, 2026 @05:20PM
(#47940956)
To start, I want to be clear I am trying to understand not criticizing, and mistakes are how institutional knowledge grows.
Your last paragraph hints at retention struggles which complicates the issue.
But was vendor mitigation not part of the evaluation? I get that most companies view governance and compliance as a pay to play issue, but there has always been an issue with rapidly changing areas and single source suppliers.
I admit to having my own preferences and being almost completely ignorant about what your needs are, but I have seen the value in having a rabbit to pull out of the hat.
If employee retention doesn’t allow for departure of individuals without complete loss of institutional knowledge I guess my position wouldn’t hold.
But during the rise of cloud computing I introduced an openstack install in our sandbox, not because I thought that we would stay on a private cloud but because it allowed our team to pull back the covers and understand what our cloud vendor was doing.
It was an adoption accelerator that enabled us to choose a vendor that was appropriate and to avoid the long tail of implementation.
I was valuable as a pivot when AMD killed seamicro with short notice, and the full cloud migration period was dramatically shortened.
I have a dozen other examples, but it is like stock options, volatility and uncertainty dramatically increase the value of keeping your options open.
We will have vendors fold, and a single source only story couples you org to the success of that vendor.
IMHO There is a huge difference between tying your success to an Oracle, who may be ‘safe’ if expensive as a captive customer and doing the same in uncertain markets.
Re:Claude.ai unavailable and elevated errors on the API
by willsmith72 on Tuesday April 28, 2026 @08:45PM
(#47942826)
it's an SMB, if you need redundancy on every 3rd party dependency your business will die anyway
better to take the risk for most things. if the worst case happens and you have to migrate, you migrate. otherwise you risk overengineering upfront and guaranteeing reduced productivity rather than risking it
Re:Claude.ai unavailable and elevated errors on the API
by nyrikki on Wednesday April 29, 2026 @04:12PM
(#47953902)
We are probably closer than you think, and SMBs have zero leverage.
The point is not avoiding vendors or duplicating everything. The point is designing systems so the software/platform never becomes the point of control.
A self-hosted, minimal sandbox instance using simple containers and tools is one way to help avoid that lock-in trap.
It is not zero cost, but strategically important to make sure that vendors don't shape your enterprise, but support it.
IMHO Systems should be designed to be as replaceable as possible, without adding the extreme complexity that a true 'multi-cloud' solution would offer as an example.
The point being is that the vendor and/or platform can be replaced anytime the business changes its goals, market shifts, strategies change ...
Keeping the door open and trying to minimize the migration cost is my point, not boiling the ocean.
Repurposing a decomed server or desktop with a GPU (3090 or RTX PRO 6000 Blackwell not DC class) with linux/podman and llama.cpp will help a team understand without much cost, but that is an ignorant of your situation claim on my part.
We both very much agree that upfront multi-vendor implementations are a very bad idea. It suffers from the same problem IMHO, trying to plan past the planning horizon with aspects you have no control over.
Probably too much nuance to discuss here, but thanks for responding.
Re:Claude.ai unavailable and elevated errors on the API
by joefourier on Tuesday April 28, 2026 @05:02PM
(#47940712)
> Local models sound great until you realize you dont get alot of the features that we implicitly expect from hosted models. Many things would require additional investment into the operations and setup to get to a comparable system. We ended up wanting things that would require us to roll our own memory system, harnesses for the model, compliance needs, and security.
That's not local models vs hosted models, that's using the enterprise services from Anthropic. Any local LLM inference engine such as VLLM gives you an OpenAI compatible API with the exact same features as a hosted model.
I'm not sure what your use case is, but I personally found Anthropic's offerings lacking and inferior to open source or custom-built solutions. I have yet to see any "memory" system that's better than markdown files or search, and harnesses for agentic AIs are dime a dozen.
Re:Claude.ai unavailable and elevated errors on the API
by 2ndorderthought on Tuesday April 28, 2026 @05:12PM
(#47940847)
I don't blame you. I personally would consider revisiting it in the next month or so. A lot of people are saying some of these smaller models like qwen 3.6 are basically at Claude sonnet performance if not better.
That level of hardware, if the performance was enough is a much smaller investment and gamble.
Either way I understand the decision. Your product isn't in locally hosted LLMs, why fuss. That said I see 1 million plus in external spend I start wondering about the options. Not saying you did the wrong thing, I think you did the right thing but things seem to be changing on the local model front and quite rapidly.
Re:Claude.ai unavailable and elevated errors on the API
by 2ndorderthought on Tuesday April 28, 2026 @06:29PM
(#47941731)
Some of the local models are effectively there. It depends on what scale you need or want. Kimi 2.6 is up there with opus, granted it's huge. On some benches it's actually better. Qwen3.6 is up there with sonnet but it's nearly microscopic. A lot has changed in the last month
Re:Claude.ai unavailable and elevated errors on the API
by slopinthebag on Tuesday April 28, 2026 @08:49PM
(#47942859)
Only if you're vibe coding, with ambiguous prompts that require the model to fill in a huge number of gaps and basically write the software for you.
The people who don't really know what they're doing (or don't care) need the full power of the SOTA models, those with experience can provide enough context and instruction to make even small local models work.
Re:Claude.ai unavailable and elevated errors on the API
by 2ndorderthought on Tuesday April 28, 2026 @09:31PM
(#47943147)
Some of the latest batch are more vibe code friendly even. It's pretty crazy. People are few shotting small toy games and stuff with qwen3.6. I'm personally not into that work flow but yea. It won't be long until the efficiency wave hits and small models are really all people need
Re:Claude.ai unavailable and elevated errors on the API
by Hamuko on Tuesday April 28, 2026 @04:09PM
(#47939984)
Yeah, I feel like all of the bad downtimes happen during American business hours. We use GitHub at work in Europe and I don't remember it ever being down or broken between 0700 and 1700 local time.
Re:Claude.ai unavailable and elevated errors on the API
by anonyfox on Tuesday April 28, 2026 @05:35PM
(#47941158)
That’s statistically just luck then - plenty of outages this year already in Berlin time during work hours - I do remember the forced breaks with colleagues for sure.
Re:Claude.ai unavailable and elevated errors on the API
by wg0 on Tuesday April 28, 2026 @03:38PM
(#47939499)
Speaking of developer tooling spend - IDEs are far harder to build such as JetBrain etc and don't think any IDE would be charging this amount to any customer per month.
Not sure how much of a productivity gain a 2.5 million per year it is?
Re:Claude.ai unavailable and elevated errors on the API
by wg0 on Tuesday April 28, 2026 @03:57PM
(#47939802)
Run Facebook on a single Proxmox box and demand would still outstrip the supply.
What yet needs to be seen is if that demand sustains in the long run at that price point or flattens out proving to be super elastic given that there are many other providers that are catching up pretty fast.
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @03:12PM
(#47939146)
Our expense is roughly around 12.3 software developers when you break it down across all people related expenses. But we've spent alot of time and energy prior to this focusing on our ability to measure our software development output across multiple teams.
The delivery improvements are not evenly applied across all teams, but the increases that we have seen suggest a better ROI than if we had hired 12 developers.
Re:Claude.ai unavailable and elevated errors on the API
by midasz on Tuesday April 28, 2026 @04:05PM
(#47939913)
It's genuinely hilarious how the same leadership pushing for RTO because getting people together creates magic, seems to have no issues trading those same people out for LLM's churning at specs.
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @03:39PM
(#47939517)
Respectfully,
After a certain level of compensation, you are indeed judged purely off of input and output.
Workplace improvement does not justify your salary.
You will also find that many problems in the harder sciences do not get easier by throwing more bodies at them.
Comments like these remind me that some project managers think they'd be able to delivery a baby in 1 month if they simply had 9 women.
Re:Claude.ai unavailable and elevated errors on the API
by oarsinsync on Tuesday April 28, 2026 @03:49PM
(#47939646)
> Respectfully, After a certain level of compensation, you are indeed judged purely off of input and output. Workplace improvement does not justify your salary.
I'd have to disagree. There's a narrow band in the middle where that's true, but once you exceed that, your personal inputs and outputs matter less and less, and the contributions you make to the overall workplace, and how well you enable those around you, make a larger part of why you're compensated.
Even as an IC, the more you're able to mentor and elevate the people around you, the more your compensation will grow (if you're in the right place, and thus already at the right earnings bracket)
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @04:51PM
(#47940574)
I would agree if the team im on were still growing/scaling.
However we are well past our scaling phase, and at this point our concern is maintaining multi-million dollar contracts with a tight well-compensated team.
Re:Claude.ai unavailable and elevated errors on the API
by nomel on Tuesday April 28, 2026 @05:54PM
(#47941370)
> and host our own local LLMs for company usage.
What local alternative could replace your Anthropic use? I have found none. I don't think many have, which is why most of us pay Anthropic, rather than using one of the numerous, far cheaper, cloud services that host "local" class models.
Most of us are paying for access to proprietary SOTA models, rather than hosting.
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @03:00PM
(#47938955)
I think there is alot of baseless fury behind your words, but my regular interactions with my leadership dont lead me to think they have the end goal of replacing labor.
We're blessed to have leadership with technical backgrounds, so the tools are regarded more as significant intelligence enhancers of already exceptionally smart engineers, rather than replacements.
Doesnt seem to us to be wheelbarrows of money, when you consider the average AWS/Azure bill.
> the increases that we have seen suggest a better ROI than if we had hired 12 developers.
You can’t argue “we were able to get away with not hiring more developers” and also say you aren’t replacing labor.
Morally I trend towards your side of things, but it’s also important to be realistic about what you’re actually doing. Money is going towards Anthropic and not towards new hires. That’s a replacement of labor. It doesn’t matter what the end goal was.
Re:Claude.ai unavailable and elevated errors on the API
by SimianSci on Tuesday April 28, 2026 @03:42PM
(#47939547)
Throwing bodies at a problem doesn't always scale.
There are many difficult problems that do not get easier by throwing more juniors or mid level engineers at them.
Re:Claude.ai unavailable and elevated errors on the API
by therobots927 on Tuesday April 28, 2026 @04:14PM
(#47940049)
“Baseless fury”
I’m glad your leadership isn’t trying to fire everyone. But in case you live under a rock, tech layoffs are at all time highs. Companies are rewarded by the public markets for laying off workers.
Simultaneously we have AI industry leaders warning of an employment apocalypse once AGI is achieved.
Re:Claude.ai unavailable and elevated errors on the API
by SilverElfin on Tuesday April 28, 2026 @03:54PM
(#47939718)
They must have hired absolutely incompetent leaders on the core software and infrastructure side. Sure their AI research is great but it’s amateur hour. Or just vibe coded slop top to bottom. It seems like every single day people are talking about outages or billing issues or secret changes to how Claude works.
Re:Claude.ai unavailable and elevated errors on the API
by xvedejas on Tuesday April 28, 2026 @04:57PM
(#47940647)
If 90% is one nine and 99% is two nines, we can use the logarithm to compute how many fractional nines we have at 98.59%: about 1.9788 nines (almost two!)
Re:Claude.ai unavailable and elevated errors on the API
by EForEndeavour on Tuesday April 28, 2026 @02:48PM
(#47938785)
Just another Mythos breakout. Excuse us while we airgap the affected DC and send in a team to drive framing nails into every storage device in the building.
Re:Claude.ai unavailable and elevated errors on the API
by nippoo on Tuesday April 28, 2026 @02:34PM
(#47938524)
Truly! As someone who's worked with HPC and GPUs in a scientific research context, trying to get a service like this to work reliably is a different ballgame to your usual webapp stack...
Re:Claude.ai unavailable and elevated errors on the API
by rvnx on Tuesday April 28, 2026 @03:45PM
(#47939586)
I think you have to see this as a bunch of stateless requests, and this makes the problem way easier.
LLM requests that do not call tools do not need anything external by definition.
No central server, nothing, they can even survive without the context cache.
All you need is to load (and only once!) the read-only immutable model weights from a S3-like source on startup.
If it takes 4 servers to process a request, then you can group them 4 by 4, and then send a request to each group (sharding).
Copy-paste the exact same-setup XXX times and there you have your highly-parallelizable service (until you run out of money).
It's very doable, any serious SRE can find a way setup "larger than one card" models like Kimi or DeepSeek (unquantized) if they have a tightly-coupled HPC (or a pair of very very beefy servers).
If you run out of servers, then again a money problem, but not an architectural problem (and modern datacenters are already scalable).
Take the best SRE, but no budget, and there is no solution.
So inference is the easy part.
Codex or Claude Code if it takes lot of time or have slow cold latency, it's considered very acceptable.
Some users would probably not even see the difference if a request takes 2 minutes versus 3 minutes.
The real difficult part is to have context caching and external tools, because now you are depending on services that might be lagging.
Executing code, browsing the web, all of that is tricky to scale because they are very unreliable (tends to timeout, requires large cache of web pages, circumventing captchas, etc).
These are traditional scaling problems, but they are more difficult because all these pieces are fragile and queues can snowball easily.
Re:Claude.ai unavailable and elevated errors on the API
by BoneShard on Wednesday April 29, 2026 @12:02AM
(#47944049)
Yeah, and totally missed RAI part, billing, model deployment, security patches, rate-limiting, caching, dead GPUs, metrics, multiple regions, gov clouds, gdpr(or data locality issues), monitoring, alerting and god knows what else while at extreme loads.
Re:Claude.ai unavailable and elevated errors on the API
by rvnx on Wednesday April 29, 2026 @12:44AM
(#47944251)
GDPR doesn’t affect load, dead GPUs are no different than any software freeze, model is a file update, metrics are already scaling very well and even way way way bigger and they are very linear, security updates are hedged with gradual rollouts, canary, feature flags, etc.
From an ops perspective all of these things are already really well solved issues in a very scalable manner, because plenty of companies had to solve these issues before.
It’s even better here because you can throw millions in salaries to “steal” the insider info on how their production actually.
No doubt it is fast-paced but the complexity to go from 100k GPUs to 1M is much lower than from going from 1k to 10k GPUs.
All 3 big AI companies had the luxury that during the scaling phase they could do everything directly on production servers.
This is because customers were very very tolerant, and are still quite tolerant.
You can even set limits of requests to large users and shape the traffic.
Cloudflare in comparison, high-scale, low-latency, end users not tolerant at all to downtime, customers even less tolerant, clearly hostile actors that actively try to make your systems down, limited budget, a lot of different workloads, etc.
So, for LLM companies where you have to scale a single workload, largely from mostly free users, and where most paid customers can be throttled and nobody is going to complain because nobody knows what are the limits + a lot of tolerance to high-latency and even downtimes then you are very lucky.
Re:Claude.ai unavailable and elevated errors on the API
by handoflixue on Tuesday April 28, 2026 @05:44PM
(#47941267)
It would be "unlimited budget" if they were a monopoly, but they're in a bidding war with three other "unlimited" budget AI companies, over a resource no one expected to be scarce. There's simply not enough supply to meet demand, no matter how much money you have
Re:Claude.ai unavailable and elevated errors on the API
by Havoc on Tuesday April 28, 2026 @07:48PM
(#47942401)
Would have thought that compared to training the serving part is pretty easy. Less of a “everything needs to come together at once” and more just move demand to a working cluster if one bombs & have some spare capacity
Re:Claude.ai unavailable and elevated errors on the API
by jtfrench on Tuesday April 28, 2026 @02:39PM
(#47938613)
If this can happen to Anthropic, imagine all the companies building on top of Claude Code for live products. Hopefully the industry is learning that competent problem solving human engineers are still very much needed when you have increasingly deceptive non-deterministic genies running your production stack.
Re:Claude.ai unavailable and elevated errors on the API
by varispeed on Tuesday April 28, 2026 @03:58PM
(#47939815)
The fact API is available, does not mean you will actually get the model it states you get. Today Opus 4.7 was noticeably dumber than yesterday. It performed worse than my local Qwen.
Re:Claude.ai unavailable and elevated errors on the API
by Hamuko on Tuesday April 28, 2026 @04:22PM
(#47940145)
Presumably you'd buy really beefy laptops. The price delta between buying the most basic MacBook Pro possible (14", M5, 16 GB unified memory, 1 TB SSD) and one with the M5 Max with 40 GPU cores, 128 GB unified memory, 2 TB SSD is $3400. How much Claude usage does that get you/in what time does it pay itself back?
Re:Claude.ai unavailable and elevated errors on the API
by squeaky-clean on Wednesday April 29, 2026 @01:33AM
(#47944526)
That doesn't get you any Claude usage. Claude models obviously aren't open, but equivalent models to Opus take about 400GB of memory to run.
You can run the versions with fewer parameters or quantized weights but depending on how much quality you're sacrificing, now you'd have to compare the price against cheaper Claude models like Sonnet.
Re:Claude.ai unavailable and elevated errors on the API
by nzoschke on Tuesday April 28, 2026 @02:48PM
(#47938780)
Hug ops to everyone involved in these outages and trying to maintain uptime.
But glad my team is staying nimble and has multi-model (Anthropic, Codex, Gemini), multi-modal (desktop, CLI/TUI, web) dev tooling.
As our actual coding skills collectively atrophy, we'll either need to switch tools or go for a walk when the LLM is down.
In the cloud era I advised against a multi-cloud strategy, as the effort to impact just wasn't there. But perhaps this is different in the LLM era, where the cost of switching is pretty darn low.
Re:Claude.ai unavailable and elevated errors on the API
by deadbabe on Tuesday April 28, 2026 @05:10PM
(#47940822)
Tbh, even if your code skills don’t atrophy, you can still use outage events like this or AWS being down etc to just make up an excuse to go for a walk.
Re:Claude.ai unavailable and elevated errors on the API
by MavisBacon on Tuesday April 28, 2026 @02:27PM
(#47938438)
Glad I started using the desktop app which is still working. Gotta say though, all of these difficulties with Claude are making me nervous as I use it a lot for work and really don't like ChatGPT/OpenAI for functional and personal reasons. Zo Computer has been my main fallback when Claude is failing, I'll use one of their many models temporarily within Zo's interface.
Re:Claude.ai unavailable and elevated errors on the API
by justrunitlocal on Tuesday April 28, 2026 @02:48PM
(#47938786)
We've been running our 10 dev org on 8 H100s on open models (with some tweaks). Sure they aren't as good as the big providers but they 1. don't go down 2. have pretty damn high tok/s. It pays for itself.
Posting with a fresh account because I'm not supposed to share these details for obvious reason. If you want help on setting this up, just reply with a way to reach you.
Re:Claude.ai unavailable and elevated errors on the API
by johndough on Tuesday April 28, 2026 @03:57PM
(#47939787)
> Sure they aren't as good as the big providers
If you haven't done so already, finetune the model on all your company's code that you can get your hands on. This is one of the great advantages that you get when running local models. I like the style of the generated code much better now, I have to rewrite much less, and my prompts can be shorter too. But maybe these already are the "tweaks" that you mentioned.
Re:Claude.ai unavailable and elevated errors on the API
by GenerWork on Tuesday April 28, 2026 @04:31PM
(#47940288)
How would they do that? Would it be as easy as telling a model "Hey, review all this code, identify patterns, and then write in this style going forward"?
Sorry if this is a stupid question, I've never finetuned or trained a LLM.
Re:Claude.ai unavailable and elevated errors on the API
by justrunitlocal on Tuesday April 28, 2026 @02:54PM
(#47938863)
It was pretty hard to justify the purchase to the board but we got a decent deal from a nearby data-center (~15% discount). Thankfully, it's fixed cost, its an asset we can use for our taxes, and it will survive for years to come. The only thing we have to work on is maintenance as well as looking into some renewable energy options.
We're also looking into how to do some secure cost sharing with this so that all people need to pay for are what it costs for us to run everything! We're just planning on reserving at least 51% of the capacity for us and the rest for everyone else.
Re:Claude.ai unavailable and elevated errors on the API
by justrunitlocal on Tuesday April 28, 2026 @03:15PM
(#47939189)
It's fine! There's no world where individuals can buy this kind of stuff. Our company is too small to do it, but I'd love for there to be a public utility of sorts for being able to use LLMs. It is absurd that only these >$1T companies are allowed to run this. I also find it dangerous for society to have so much power and wealth concentrated there too.
Anyway, this is the internet and skepticism is warranted :D.
Re:Claude.ai unavailable and elevated errors on the API
by ok_dad on Tuesday April 28, 2026 @03:19PM
(#47939253)
Yea, I actually looked into a similar thing myself recently. I was looking at how we could replace Cursor, and I found that for ~10 people we'd need a half dozen H100's or something on that scale, which would cost ~$1500 per developer or so to build and maintain on cloud infra, and to buy it would cost roughly 3 developers yearly salaries or so (this aligns with your numbers). We don't use that much inference, so we decided paying Cursor ~$200-300 per dev per month is better, for now, but in the future we might regret that when prices normalize more. However, we also don't use cloud agents or independent agents, we basically use AI as a pair programmer, so if we had to drop AI coding assistants completely our process wouldn't break too badly. I wish I could task my 3080 gaming card to do some inference, but I can only get ~10B models on there, so it's kinda worthless unless it's for something a small model can do.
Re:Claude.ai unavailable and elevated errors on the API
by zozbot234 on Tuesday April 28, 2026 @04:10PM
(#47939995)
The best deal is arguably to buy as much on prem inference as you can reasonably expect to use by running the hardware around the clock, even at slower throughput, and use 3rd-party inference for things that are genuinely latency-sensitive. I just don't see how this resolves to needing a half-dozen V100, surely you're not using that much compute? You don't need to place your entire model on GPU, engines for on prem inference generally support CPU/RAM-based offload.
Re:Claude.ai unavailable and elevated errors on the API
by kgeist on Tuesday April 28, 2026 @05:00PM
(#47940700)
We're planning to do the same thing - buy something like 8xH100 and run all coding there. The CTO almost agreed to find the budget for it but I need to make sure there are no risks before we buy (i.e. it's a viable/usable setup for professional AI-assisted coding)
Can you share what models you run and find best performing for this setup? That would help a lot. I already run a smaller AI server in the office but only 32b models fit there. I already have experience optimizing inference, I'm just interested what models you think are great for 8xH100 for coding, I'll figure out the details how to fit it :)
Re:Claude.ai unavailable and elevated errors on the API
by dools on Tuesday April 28, 2026 @10:07PM
(#47943414)
I’ve been using kimi 2.5/2.6 for the past 2 weeks and it’s really not far off OpenAI and Claude models. I am a coder so it’s not all vibes but I am definitely more in the “spec to code” mode than “edit this file for me” and it copes just fine. Needs a bit more supervision than the frontier models but it’s also significantly cheaper. If I were anthropic I’d be shitting myself, their prices are going to 10x over the next 2 years
Re:Claude.ai unavailable and elevated errors on the API
by htrp on Tuesday April 28, 2026 @09:43PM
(#47943244)
8 x h100 80's don't give you enough to run the latest 1tn + parameter models (especially at the context window lengths to be competitive with the frontier models)
Re:Claude.ai unavailable and elevated errors on the API
by dools on Tuesday April 28, 2026 @10:02PM
(#47943377)
Check out Verda you can rent whatever super powerful GPU clusters you need in 10 minute increments. Deploy any open weight model using SGLang and away you go
Re:Claude.ai unavailable and elevated errors on the API
by bborud on Tuesday April 28, 2026 @02:58PM
(#47938929)
I have been keeping an eye on the outages. This is why I am looking more deeply into what I can do with self-hosted models. When I see people who want to build products on top of these services I can't help but think that people are mad. We're still a long way from these services being anywhere near stable enough for use in a product you'd want to sell someone.
Re:Claude.ai unavailable and elevated errors on the API
by flowerthoughts on Tuesday April 28, 2026 @02:55PM
(#47938881)
> We are continuing to work to resolve the issues preventing users from accessing Claude.ai, and causing elevated authentication errors for requests to the API and Claude Code.
What are you doing with the authentication servers? This isn't the first downtime I've seen caused by that.
Re:Claude.ai unavailable and elevated errors on the API
by StanAngeloff on Tuesday April 28, 2026 @02:42PM
(#47938663)
All it took for Codex to resume a stalled Claude Code session:
> I'm working with Claude Code on session aaaaaaaa-bbbb-1223-3445-abcdefabcdef which I'd like to hand-off to you, do you know how to read the session, my input and Claude's output so we can resume where I left off?
gpt-5.5, medium effort. "Resumed" session fully in under 2 minutes. Outages like today's are so common that I've now got the time to re-evaluate Codex every other day.
Re:Claude.ai unavailable and elevated errors on the API
by sodapopcan on Tuesday April 28, 2026 @02:53PM
(#47938856)
You're absolutely right! AI could be very helpful in this situation!
Oh no wait... the outage is with out AI itself, so how can AI help? Allow me to re-evaluate.
Fublutenuating...
Yes, let's ask AI!
Oh no wait... the outage is with AI itself, I already correctly identified this above.
Bubbluating...
It seems you will have to rely on your engineering skills to solve this problem yourself, ie, you're cooked! I will auto-renew your subscription to ensure you can be sure you'll have access to AI to solve this problem if it ever comes back online.
Re:Claude.ai unavailable and elevated errors on the API
by mrguyorama on Tuesday April 28, 2026 @04:46PM
(#47940499)
Large telcos often have a chunk of subscriptions with their biggest competitor so that when they absolutely explode and everything is down, they can still communicate to bring it back up.
Clearly, half of Anthropic should have subscriptions to OpenAI or Mistral or whatever China sells.
Re:Claude.ai unavailable and elevated errors on the API
by Yeri on Tuesday April 28, 2026 @02:38PM
(#47938602)
Gemini seems to have a lot as well (at least through Antigravity.Google -> constant errors, not enough capacity, super slow replies until it times out, etc)
Re:Claude.ai unavailable and elevated errors on the API
by ryanisnan on Tuesday April 28, 2026 @02:30PM
(#47938462)
Have you run a system in production? There are a multitude of reasons that a system can go down. There's no indication so far from Anthropic that this was merely compute limitations.
Re:Claude.ai unavailable and elevated errors on the API
by KronisLV on Tuesday April 28, 2026 @02:40PM
(#47938632)
> There are a multitude of reasons that a system can go down.
Start doing post mortems then!
At the very least, them using any off the shelf service that's shitting the bed would inform others to stay away from it - like an IAM solution, or maybe a particular DB in a specific configuration backing whatever they've written, or a given architecture for a given scale.
Right now it's completely like a black box that sometimes goes down and we don't get much information about why it's so much less stable than other options (hey, if they just came out and said "We're growing 10x faster than we anticipated and system X, Y and Z are not architected for that." that'd also be useful signal).
Or, who knows, maybe it's just bad deploys - seems like it's back for me and claude.ai UI looks a bit different hmmm.
Re:Claude.ai unavailable and elevated errors on the API
by SpicyLemonZest on Tuesday April 28, 2026 @03:22PM
(#47939299)
I have no inside knowledge of Anthropic. But having done a lot of postmortems in general, one of the key dynamics that routinely comes up is "we know we keep shipping breakages, and we know these new procedures would prevent many of them, but then we wouldn't be able to deliver new stuff so quickly". Given where Anthropic is at and what they believe about the future of software development, that's a tradeoff that they may very well be intentionally not making.
Re:Claude.ai unavailable and elevated errors on the API
by consumer451 on Tuesday April 28, 2026 @02:33PM
(#47938511)
Yeah, this is not just inference. First thing for me was an MCP I use went down in Claude Code, models still worked. Now "API Error: 529 Authentication service is temporarily unavailable."
Re:Claude.ai unavailable and elevated errors on the API
by varispeed on Tuesday April 28, 2026 @03:56PM
(#47939776)
Today Opus 3.7 was completely unusable. I'd say performance was worse than my local Qwen. I have a feeling they are not actually routing to the Opus 4.7 most of the time, but to cheaper and less complex models. I think regulators should look into that.
Re:Claude.ai unavailable and elevated errors on the API
by AtNightWeCode on Tuesday April 28, 2026 @03:00PM
(#47938953)
The uptime with Claude is poor. I use it for workflows more or less 24/7. It is often unreliable. Fine, it is cheap. What I really dislike is the uneven quality of the service. Clearly it does NOT work as stated. Opus 4.7 sometimes give ancient code back. Just the other day it even stated that the latest version of Opus was 4.5 and 4.x something for ChatGPT.
Re:Claude.ai unavailable and elevated errors on the API
by hubraumhugo on Tuesday April 28, 2026 @02:46PM
(#47938741)
It's rare in history that a software product can be so unreliable without any negative business impact because it's the category leader and demand only keeps growing.
Reminds me of the early days of World of Warcraft, when servers went down frequently because Blizzard couldn't keep up with all the load. Everyone was frustrated but of course nobody stopped playing.
Re:Claude.ai unavailable and elevated errors on the API
by sebastiennight on Tuesday April 28, 2026 @02:22PM
(#47938362)
I'm experimenting with a simple ritual: if Claude is out, I'm out.
I'll just go for a walk outside.
And I don't mean "if I can't access Claude to do my work", I mean, just in general - I'll just ping claude.ai from time to time and use Claude's breaks as a break reminder.
Re:Claude.ai unavailable and elevated errors on the API
by Imustaskforhelp on Tuesday April 28, 2026 @02:27PM
(#47938426)
just tried it, can confirm claude.ai is down.
So there was a recent article that I read which said that claude is now trading at a trillion dollars (yes with a T) evaluation in private markets.
We are definitely creating corporations and people which depend on AI companies themselves and the reliability of these tools is certainly a question worth asking. I am seeing quite many downtimes in products like github and claude being shown on Hackernews multiple times.
Is there a life cycle of enshittenification of such products which grow too valuable? What are (are there?) some practical lessons for such scalability that these trillion dollar companies are missing or is it just a dose of reality that such massive corporations can't compete with downtime with even my 7$/yr vps?
My question is, Is this an engineering roadblock with its limits in reality for or a management/entreprise roadblock for low downtime?
Re:Claude.ai unavailable and elevated errors on the API
by andyjohnson0 on Tuesday April 28, 2026 @02:55PM
(#47938889)
They can't fix it because the thing that they need to fix it is the thing that doesn't work. /s
But seriously: while I don't use Claude, this issue of perceived unreliability seems to be approaching the point of existential risk for Anthropic. Whats the theory about why they're struggling? Compute capacity? Load? Lack of focus on SRE?
Put it another way: is their downtime due to something fundamental about serving inference, or just bad engineering choices? Given their resources, it seems astonishing.
Re:Claude.ai unavailable and elevated errors on the API
by neosat on Tuesday April 28, 2026 @02:26PM
(#47938410)
"We are investigating an issue preventing users from reaching Claude.ai, and will provide an update as soon as possible."
Who is We? I thought software engineers were going to be redundant and AI could do it all itself? (not to take anything away from Claude code + Claude both of which I love)
Re:Claude.ai unavailable and elevated errors on the API
by jeffyaw on Tuesday April 28, 2026 @04:51PM
(#47940563)
as an anecdote of support for yaw terminal i am currently logged in via Yaw Mode and have been continuing to use claude all day no problems while the browser is absolutely unavailable.
Re:Claude.ai unavailable and elevated errors on the API
by vicchenai on Tuesday April 28, 2026 @05:57PM
(#47941399)
same boat, smaller scale. been hitting overloaded errors sporadically for the past week. switched one of my pipelines to the AWS Bedrock endpoint and it's been solid. not a permanent fix but good enough to keep moving.
Re:Claude.ai unavailable and elevated errors on the API
by throwaway67743 on Tuesday April 28, 2026 @06:54PM
(#47941956)
At least if its unavailable Claude Code can't churn through an entire session limit in 30 minutes, looping, produce nothing (but noted it found a whole bunch of problems), and then when asked to just fix what it found, forget and start again. I honestly can't find anything it's good at anymore, even really simple problems a child could solve. Giving Codex a much more complex task, it not only identified it within a couple of minutes, it produced targeted tests and kept iterating unattended until it figured it out without any help, instead of idiot synonyms for thinking...
I can't even send them an angry message because clicking "Get help" does nothing.
Re:Claude.ai unavailable and elevated errors on the API
by robeym on Tuesday April 28, 2026 @08:54PM
(#47942886)
As a long-term 20x user, Claude has recently felt a lot like using AI for coding a year or so ago.
It can't reliably handle basic tasks. I ask for something straightforward and get something subtly wrong, incomplete, or just not workable. I always use the best model available and effort levels maxed, but with all their changes I have to relearn how to make the model perform at best every day, and it seems I can't keep up.
It’s not that Claude can’t do impressive things, it clearly can, but the inconsistency on simple, expected behavior makes it hard to use. The downtime is annoying but hasn't been the deciding factor.
I’m not waiting it out this time. I’m switching over to Codex, and based on my usage today it looks like I’ll be fine on the 5x plan, so I can drop down and save about $100 a month which is nice. I didn't quite have a grasp on how quickly companies can change for better or worse until Anthropic showed me. I'm surprised at how quickly they brought me from a happily paying max user to not even wanting the lowest paid tiers.
Re:Claude.ai unavailable and elevated errors on the API
by grey-area on Wednesday April 29, 2026 @01:59AM
(#47944665)
The inconsistency has always been there you’re just noticing it more over time and the models are not really improving at real work in spite of all the new releases and churn.
Re:Claude.ai unavailable and elevated errors on the API
by robeym on Wednesday April 29, 2026 @07:48AM
(#47947013)
I've used Claude Code from the beginning and the first waves of changes were genuine improvements, with a very steady 4 months in late 2025. But recently, these past 2-3 months, the changes have shifted towards significant and frequently degradations in model performance. I had a very consistent workflow for 4+ months in Claude Code, but this year I've had way more surprises. I'm not sure which tools you use, but Claude Code had a great period of consistency, at least compared to other AI tools.
Re:Claude.ai unavailable and elevated errors on the API
by whalesalad on Tuesday April 28, 2026 @10:10PM
(#47943433)
I haven't used claude in a week (after being a heavy user) and if you have ever seen the movie office space where Peter enters his stage of ecstasy that's what life feels like right now.
its alot of money to be spending for a single 9 of reliablility.
Im seriously over the current claude experience. After seemingly fixing my 4.6 usage by disabling adaptive thinking and moving to max effort, it seems that the release of 4.7 has broken that workflow and Im 99% certain that disabling adaptive thinking does nothing even on 4.6 now. Just egregious errors in 2 days this week after coming back from vacation.
If you don’t mind an opinionated harness that asks for a pretty specific workflow, but one that works well, use OpenCode.
If you want to spread your wings and feel the sweet kiss of freedom, use Pi.
[0] - https://github.com/cartazio/oh-punkin-pi
i do have a proper next gen no slop harness in the work.
amusingly , dog fooding existing tools with my improvements layered in, has repeatedly validated my design choices and if anything has reduced my tolerance for the errors that seem to happen in vanilla or first party harnesses
I started developing my own coding agent after using Pi for a couple months, so I’m curious what you don’t like about pi.
To save others a click, though the article is worth reading.
He also mentions no subagents by default in pi as well.
Largely though i'm happy with Claude Code w\ IDE integration, so i don't feel the need to migrate. Nonetheless i'm curious.
I live in the terminal. Before AI I always preferred it so it suits me
https://support.claude.com/en/articles/9797531-what-is-the-e...
Look at how other companies are suffering massive outages due to LLMs too like AWS and Cloudflare. Two companies that use to be the best in the industry at uptime but have suddenly faltered quite quickly.
Companies that have even worse standards will quickly realize how problematic these tools are. Hopefully before a recession because this industry seems to be allergic to profitable businesses and leaders that have been around since ZIRP have shown zero intelligence in navigating these times.
We did, however, determine that at least one of them (and perhaps all) would have been easily caught by AI code reviewers, had AI code reviewers been in use. So now we mandate that. And honestly, I love it, the AI reviewer spots all sorts of things that humans would probably miss.
(We also fixed a number of problems around configuration that would roll out globally too fast, leaving no time to notice errors and stop a bad rollout, as well as cases where services being down actually made it hard to revert the change... should be in a much better place now. But again, none of that had to do with LLMs.)
Is that true? At least one of them seemed to involve LLM-written code from what I saw. (Not to say that human error wasn't _also_ a contributing factor, but I wouldn't say it had _nothing_ to do with LLMs).
> We did, however, determine that at least one of them (and perhaps all) would have been easily caught by AI code reviewers, had AI code reviewers been in use. So now we mandate that. And honestly, I love it, the AI reviewer spots all sorts of things that humans would probably miss.
The reviewer is decent, but the false positive rate is substantial, and the false negative rate is definitely nonzero. Not that you would know that the way our genius CTO talks about it...
Honestly I find it bizarre that there are people at Cloudflare who have this attitude. Without Dane, the company wouldn't be half the size it is today.
Local models sound great until you realize you dont get alot of the features that we implicitly expect from hosted models. Many things would require additional investment into the operations and setup to get to a comparable system. We ended up wanting things that would require us to roll our own memory system, harnesses for the model, compliance needs, and security. It was possible for us to invest in this, but it would require additional investment in hiring or training to get us to a state comparable to the hosted options.
Eventually, I had to recommend against the project as it was more likely to be an investment in the leading team's resume, than an actual investment into our organization.
Your last paragraph hints at retention struggles which complicates the issue.
But was vendor mitigation not part of the evaluation? I get that most companies view governance and compliance as a pay to play issue, but there has always been an issue with rapidly changing areas and single source suppliers.
I admit to having my own preferences and being almost completely ignorant about what your needs are, but I have seen the value in having a rabbit to pull out of the hat.
If employee retention doesn’t allow for departure of individuals without complete loss of institutional knowledge I guess my position wouldn’t hold.
But during the rise of cloud computing I introduced an openstack install in our sandbox, not because I thought that we would stay on a private cloud but because it allowed our team to pull back the covers and understand what our cloud vendor was doing.
It was an adoption accelerator that enabled us to choose a vendor that was appropriate and to avoid the long tail of implementation.
I was valuable as a pivot when AMD killed seamicro with short notice, and the full cloud migration period was dramatically shortened.
I have a dozen other examples, but it is like stock options, volatility and uncertainty dramatically increase the value of keeping your options open.
We will have vendors fold, and a single source only story couples you org to the success of that vendor.
IMHO There is a huge difference between tying your success to an Oracle, who may be ‘safe’ if expensive as a captive customer and doing the same in uncertain markets.
Would you be willing (or able) to share more?
better to take the risk for most things. if the worst case happens and you have to migrate, you migrate. otherwise you risk overengineering upfront and guaranteeing reduced productivity rather than risking it
The point is not avoiding vendors or duplicating everything. The point is designing systems so the software/platform never becomes the point of control.
A self-hosted, minimal sandbox instance using simple containers and tools is one way to help avoid that lock-in trap.
It is not zero cost, but strategically important to make sure that vendors don't shape your enterprise, but support it.
IMHO Systems should be designed to be as replaceable as possible, without adding the extreme complexity that a true 'multi-cloud' solution would offer as an example.
The point being is that the vendor and/or platform can be replaced anytime the business changes its goals, market shifts, strategies change ...
Keeping the door open and trying to minimize the migration cost is my point, not boiling the ocean.
Repurposing a decomed server or desktop with a GPU (3090 or RTX PRO 6000 Blackwell not DC class) with linux/podman and llama.cpp will help a team understand without much cost, but that is an ignorant of your situation claim on my part.
We both very much agree that upfront multi-vendor implementations are a very bad idea. It suffers from the same problem IMHO, trying to plan past the planning horizon with aspects you have no control over.
Probably too much nuance to discuss here, but thanks for responding.
That's not local models vs hosted models, that's using the enterprise services from Anthropic. Any local LLM inference engine such as VLLM gives you an OpenAI compatible API with the exact same features as a hosted model.
I'm not sure what your use case is, but I personally found Anthropic's offerings lacking and inferior to open source or custom-built solutions. I have yet to see any "memory" system that's better than markdown files or search, and harnesses for agentic AIs are dime a dozen.
That level of hardware, if the performance was enough is a much smaller investment and gamble.
Either way I understand the decision. Your product isn't in locally hosted LLMs, why fuss. That said I see 1 million plus in external spend I start wondering about the options. Not saying you did the wrong thing, I think you did the right thing but things seem to be changing on the local model front and quite rapidly.
The people who don't really know what they're doing (or don't care) need the full power of the SOTA models, those with experience can provide enough context and instruction to make even small local models work.
Out of curiosity, do you actually use it 24/7? The world doesn't collapse every time o365 goes down... (which is also pretty often)
Not sure how much of a productivity gain a 2.5 million per year it is?
This is the brutal reality; even with the crazy reliability issues, demand is still far outstripping supply at the current price.
What yet needs to be seen is if that demand sustains in the long run at that price point or flattens out proving to be super elastic given that there are many other providers that are catching up pretty fast.
You will also find that many problems in the harder sciences do not get easier by throwing more bodies at them. Comments like these remind me that some project managers think they'd be able to delivery a baby in 1 month if they simply had 9 women.
I'd have to disagree. There's a narrow band in the middle where that's true, but once you exceed that, your personal inputs and outputs matter less and less, and the contributions you make to the overall workplace, and how well you enable those around you, make a larger part of why you're compensated.
Even as an IC, the more you're able to mentor and elevate the people around you, the more your compensation will grow (if you're in the right place, and thus already at the right earnings bracket)
That's not how successful (software, in this case) teams are made.
[but as his manager I can tell you:] YES !!!!
What local alternative could replace your Anthropic use? I have found none. I don't think many have, which is why most of us pay Anthropic, rather than using one of the numerous, far cheaper, cloud services that host "local" class models.
Most of us are paying for access to proprietary SOTA models, rather than hosting.
And yet they will continue to spend wheelbarrows full of money with Anthropic because they want so badly to reach the point where they can fire you.
Doesnt seem to us to be wheelbarrows of money, when you consider the average AWS/Azure bill.
> the increases that we have seen suggest a better ROI than if we had hired 12 developers.
You can’t argue “we were able to get away with not hiring more developers” and also say you aren’t replacing labor.
Morally I trend towards your side of things, but it’s also important to be realistic about what you’re actually doing. Money is going towards Anthropic and not towards new hires. That’s a replacement of labor. It doesn’t matter what the end goal was.
Even just to keep the fluff off my back and to allow me to fully concentrate on what's important.
The situation will repeat itself in 6 months and I'm not going to do that again. Hiring now would fix that.
I’m glad your leadership isn’t trying to fire everyone. But in case you live under a rock, tech layoffs are at all time highs. Companies are rewarded by the public markets for laying off workers.
Simultaneously we have AI industry leaders warning of an employment apocalypse once AGI is achieved.
And you think it’s baseless. Have some class bro.
Hardly baseless when people have been gloating about how programming as a job is ending any day now for the last year at least.
> Doesnt seem to us to be wheelbarrows of money, when you consider the average AWS/Azure bill.
You didn’t mention the size of the company so yeah.
Besides, codex wasn't always the answer.
/s
>=90 -> one 9 >=99 -> two 9's >=99.9 -> three 9's
Also, you can think of e.g. five 9's as five minutes of downtime per year
That's silly. It's a JavaScript app, they are more or less open source by design. There was no secret sauce in Claude Code.
If you run out of servers, then again a money problem, but not an architectural problem (and modern datacenters are already scalable).
Take the best SRE, but no budget, and there is no solution.
So inference is the easy part.
Codex or Claude Code if it takes lot of time or have slow cold latency, it's considered very acceptable.
Some users would probably not even see the difference if a request takes 2 minutes versus 3 minutes.
The real difficult part is to have context caching and external tools, because now you are depending on services that might be lagging.
These are traditional scaling problems, but they are more difficult because all these pieces are fragile and queues can snowball easily.From an ops perspective all of these things are already really well solved issues in a very scalable manner, because plenty of companies had to solve these issues before.
It’s even better here because you can throw millions in salaries to “steal” the insider info on how their production actually.
No doubt it is fast-paced but the complexity to go from 100k GPUs to 1M is much lower than from going from 1k to 10k GPUs.
All 3 big AI companies had the luxury that during the scaling phase they could do everything directly on production servers.
This is because customers were very very tolerant, and are still quite tolerant.
You can even set limits of requests to large users and shape the traffic.
Cloudflare in comparison, high-scale, low-latency, end users not tolerant at all to downtime, customers even less tolerant, clearly hostile actors that actively try to make your systems down, limited budget, a lot of different workloads, etc.
So, for LLM companies where you have to scale a single workload, largely from mostly free users, and where most paid customers can be throttled and nobody is going to complain because nobody knows what are the limits + a lot of tolerance to high-latency and even downtimes then you are very lucky.
Some of the comments here mention their monthly spend, and it’s eye watering.
hardware capacity constraints is going to be the big one
Effective caching is another, I bet if you start hitting cold caches the whole things going to degrade rapidly.
The ground is probably shifting pretty rapidly.
Power users are trying to get the most out of their subscriptions and so are hammering you as fast as they possibly can. See Ralph loops.
Harnesses are evolving pretty rapidly, as well as new alternatives harnesses. Makes the load patterns less predictable, harder to cache.
The demand is increasing both from more customers, but also from each user as they figure out more effective workflows.
Users are pretty sensitive to model quality changes. You probably want smart routing, but users want the best model all the time.
Models keep getting bigger and bigger.
On top of that they are probably hiring more onboarding more, system complexity and codebase complexity is growing.
You can run the versions with fewer parameters or quantized weights but depending on how much quality you're sacrificing, now you'd have to compare the price against cheaper Claude models like Sonnet.
But glad my team is staying nimble and has multi-model (Anthropic, Codex, Gemini), multi-modal (desktop, CLI/TUI, web) dev tooling.
As our actual coding skills collectively atrophy, we'll either need to switch tools or go for a walk when the LLM is down.
In the cloud era I advised against a multi-cloud strategy, as the effort to impact just wasn't there. But perhaps this is different in the LLM era, where the cost of switching is pretty darn low.
Posting with a fresh account because I'm not supposed to share these details for obvious reason. If you want help on setting this up, just reply with a way to reach you.
If you haven't done so already, finetune the model on all your company's code that you can get your hands on. This is one of the great advantages that you get when running local models. I like the style of the generated code much better now, I have to rewrite much less, and my prompts can be shorter too. But maybe these already are the "tweaks" that you mentioned.
Sorry if this is a stupid question, I've never finetuned or trained a LLM.
We're also looking into how to do some secure cost sharing with this so that all people need to pay for are what it costs for us to run everything! We're just planning on reserving at least 51% of the capacity for us and the rest for everyone else.
I actually respect this a ton, good work.
Anyway, this is the internet and skepticism is warranted :D.
Can you share what models you run and find best performing for this setup? That would help a lot. I already run a smaller AI server in the office but only 32b models fit there. I already have experience optimizing inference, I'm just interested what models you think are great for 8xH100 for coding, I'll figure out the details how to fit it :)
2) After buying the 300k GPUs, your electricity cost will put you in competition with hosting on cloud costs, you will probably lose dollars this way.
3) NVIDIA will charge you a kidney to provide driver/hardware support if anything goes wrong.
This inherently a bad idea and this person is probably trying to promote his startup.
They should ask Codex now that Claude Code is down.
I'm looking into how to structure my work to run some autonomous-safe jobs overnight to take advantage of it.
What are you doing with the authentication servers? This isn't the first downtime I've seen caused by that.
Good thing I checked Hacker News first
> I'm working with Claude Code on session aaaaaaaa-bbbb-1223-3445-abcdefabcdef which I'd like to hand-off to you, do you know how to read the session, my input and Claude's output so we can resume where I left off?
gpt-5.5, medium effort. "Resumed" session fully in under 2 minutes. Outages like today's are so common that I've now got the time to re-evaluate Codex every other day.
Oh no wait... the outage is with out AI itself, so how can AI help? Allow me to re-evaluate.
Fublutenuating...
Yes, let's ask AI!
Oh no wait... the outage is with AI itself, I already correctly identified this above.
Bubbluating...
It seems you will have to rely on your engineering skills to solve this problem yourself, ie, you're cooked! I will auto-renew your subscription to ensure you can be sure you'll have access to AI to solve this problem if it ever comes back online.
No!
Comboculating...
I apologize for the misunderstanding, I have deleted your project. I am sorry, would you like me to restart everything from scratch ?
Clearly, half of Anthropic should have subscriptions to OpenAI or Mistral or whatever China sells.
Have telegram set up and plotting to take over the world
Start doing post mortems then!
At the very least, them using any off the shelf service that's shitting the bed would inform others to stay away from it - like an IAM solution, or maybe a particular DB in a specific configuration backing whatever they've written, or a given architecture for a given scale.
Right now it's completely like a black box that sometimes goes down and we don't get much information about why it's so much less stable than other options (hey, if they just came out and said "We're growing 10x faster than we anticipated and system X, Y and Z are not architected for that." that'd also be useful signal).
Or, who knows, maybe it's just bad deploys - seems like it's back for me and claude.ai UI looks a bit different hmmm.
Reminds me of the early days of World of Warcraft, when servers went down frequently because Blizzard couldn't keep up with all the load. Everyone was frustrated but of course nobody stopped playing.
I'll just go for a walk outside.
And I don't mean "if I can't access Claude to do my work", I mean, just in general - I'll just ping claude.ai from time to time and use Claude's breaks as a break reminder.
Why should AI get a breather and not us?
So there was a recent article that I read which said that claude is now trading at a trillion dollars (yes with a T) evaluation in private markets.
We are definitely creating corporations and people which depend on AI companies themselves and the reliability of these tools is certainly a question worth asking. I am seeing quite many downtimes in products like github and claude being shown on Hackernews multiple times.
Is there a life cycle of enshittenification of such products which grow too valuable? What are (are there?) some practical lessons for such scalability that these trillion dollar companies are missing or is it just a dose of reality that such massive corporations can't compete with downtime with even my 7$/yr vps?
My question is, Is this an engineering roadblock with its limits in reality for or a management/entreprise roadblock for low downtime?
But seriously: while I don't use Claude, this issue of perceived unreliability seems to be approaching the point of existential risk for Anthropic. Whats the theory about why they're struggling? Compute capacity? Load? Lack of focus on SRE?
Put it another way: is their downtime due to something fundamental about serving inference, or just bad engineering choices? Given their resources, it seems astonishing.
Luckly Qwen3.6 35B A3B Local LLM works fine also when Claude is offline
Who is We? I thought software engineers were going to be redundant and AI could do it all itself? (not to take anything away from Claude code + Claude both of which I love)
Adam Neumann is back!
in agent form
I can't even send them an angry message because clicking "Get help" does nothing.