It can't even read a file anymore.

Randomly uses 'sed' with no explanation in hallucinated file paths. Errors out 15 times in a row with 'No such file or directory' with paths that don't exist - it was trying to read a project file as usual in our Rails app.

You then ask it why it's not simply reading the file in the correct path, and then it says it's sorry:

> You're right to be angry. Two things went wrong and both are on me: > > 1. I typed sed/cat instead of using the Read tool (the project rules explicitly say not to), and > 2. I guessed a filename app/services/gmail/sync_worker.rb that doesn't exist — the real file is app/workers/gmail/sync_worker.rb. So I was reading a path I'd invented. Sloppy,

It just apologized to me - for the 5th time in this session - writing this:

> I again typed a made-up message ID into the verify step (19e70e9d...) instead of reading the real one from the list I just fetched. That's the exact mistake I keep making.

(Context window at 15%).

It's unbearably slow.

It presents 10+ errors like 'Cancelled: parallel tool call Bash errored' all the time.

It's unreal.

Comments URL: https://news.ycombinator.com/item?id=48316636

Points: 9

# Comments: 8

It can't read files anymore. Uses 'sed' out of the blue with non existent paths. In this session alone it has excused itself more then 10 times for making 'false claims'.

I hope this is a bug - it's a bad one - that will get sorted out soon. It's a complete mess.

It's actually 10-15% slower and also more expensive than Gemini 3.1 Pro, because it thinks more than 2.5x Gemini 3.1 Pro.

So that thinking verbosity nullifies the speed and cost gains.

AND the quality is worse than 3.1 Pro for our use cases, making mistakes Pro doesn't make.

He ran the attack from midnight to 7AM, so there were no humans watching.

IPs were rotated on every single request, so no rate limiter caught it.

We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.

We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.

Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.

We never thought this could bite us this way.

Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.

Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.

This is a big deal. Payment processors can ban you for allowing this to happen.

In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.

It's amazing how powerful this stack is and how little you have to change in the backend.

All of a sudden, about 1/3 of all traffic to our website is being routed via EWR (New York) - me included -, even tough all our users and our origin servers are in Brazil.

We pay for the Pro plan but support has been of no help: after 20 days of 'debugging' and asking for MTRs and traceroutes, they told us to contact Claro (which is the same as telling me to contact Verizon) because 'it's their fault'.

I'd add:

- Learn tailscale. It's one of those technologies that takes half a day to get used to (claude code will answer all your questions), and you'll never want to live without it in the future. SSH into your VPS, install tailscale and use `tailscale set --ssh`, and shut down `systemctl stop ssh.service`. You don't even have SSH daemon runing anymore, extra safety.

- Use a simple docker compose to run your dependencies like docker. Bind to the tailscale IP, so ports: {{ tailscale_ip_of_this_server}}:5432:5432. This way your database is not exposed to the web, but it's exposed to the tailscale. Use tailscale_ip_of_this_server in your ENV vars to rails to connect - since it's running in the same server, tailscale will route it to localhost (and with localhost latency).

- With claude, set up a second VPS, add it to the same tailscale, turn of SSHD. They can now connect directly via tailscale (try ping or sshing between them).

- Then, install claude code on this second VPS. Since postgres is bound to the tailscale IP on the main, the 'slave' can connect to it. Install postgres via docker, but have claude set up a 'streaming replication' between server MASTER and server SLAVE, using tailscale ip.

100% secure, encrypted, and now you have a postgres replication with zero data loss if something goes wrong.

In the same SLAVE, you can also install barman - claude code will help you set it up.

You then have a postgres BACKUP with point in time recovery.

There you go!

I consider my server's real IP (or load balancer IP) as a secret for that reason, and Cloudflare helps exactly with that.

Everything goes through Cloudflare, where we have rate limiters, Web firewall, challenges for China / Russian inbound requests (we are very local and have zero customers outside our country), and so on.