Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude.ai unavailable and elevated errors on the API

status.claude.com

Post reply on HN
Print view View original

261–270 of 277 posts

Re: Claude.ai unavailable and elevated errors on the API

#261

Post by throwaway277432 »

SimianSci wrote: post #141
protonbob wrote: post #131

Earlier quoted context omitted.

Not ever hiring juniors and eventually mids is just replacing labor with extra steps.

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.

Having just worked my behind off for the last months to deliver on an impossible deadline, successfully: more bodies definitely would have helped.

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.

Re: Claude.ai unavailable and elevated errors on the API

#262

Post by raffael_de »

ramon156 wrote: post #260
raffael_de wrote: post #222

Earlier quoted context omitted.

how is this counted? is 79% "one nine"?

Its a joke >=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

got the joke. but it drove home that i wasn't sure how it's counted. thx

Re: Claude.ai unavailable and elevated errors on the API

#263

Post by kakoni »

dools wrote: post #249
Havoc wrote: post #231

Earlier quoted context omitted.

Deepseek, GLM, Minimax or Kimi are the most likely contenders.

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 ne…

So are you running Kimi on Verda?

Re: Claude.ai unavailable and elevated errors on the API

#264

Post by plmpsu »

nzoschke wrote: post #87

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…

Going for a walk is a good idea even when there's no outage.

Re: Claude.ai unavailable and elevated errors on the API

#265

Post by threepts »

justrunitlocal wrote: post #89

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.

First of all 1) 8 H100S are NOT ENOUGH for today's premier models (500B+ tokens) and if you do run a obsolete model forget about memory.

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.

Re: Claude.ai unavailable and elevated errors on the API

#266

Post by robeym »

grey-area wrote: post #259
robeym wrote: post #239

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 kee…

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.

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

#267

Post by conception »

squeaky-clean wrote: post #256
conception wrote: post #213

Earlier quoted context omitted.

4.7 is the first opus model that’s had the 1 M context window available on Bedrock.

I've had Opus 4.6 1M and Sonnet 4.6 1M for months now on Bedrock.

Their docs may be lying but they say 200k for opus 4.6. And yes 1M was on sonnet for Claude enterprise.

Re: Claude.ai unavailable and elevated errors on the API

#268

Post by JamesSwift »

HDBaseT wrote: post #251
JamesSwift wrote: post #235

Earlier quoted context omitted.

Ummmmmm, how?

I searched his HackerNews username on Google. [0] - https://github.com/cartazio/oh-punkin-pi

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

#269

Post by JamesSwift »

canadiantim wrote: post #245
mattmanser wrote: post #221

Earlier quoted context omitted.

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.

oh-my-pi harness fixes many of these, like subagents

It seems to, but then also throws in the kitchen sink and a custom bath.

Re: Claude.ai unavailable and elevated errors on the API

#270

Post by nyrikki »

willsmith72 wrote: post #237
nyrikki wrote: post #209

Earlier quoted context omitted.

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 su…

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

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.

Post reply on HN