This has been happening way too often of late. Doesn't matter if I'm using Opus 4.7 or 4.6 (though switching to the other when it happens seems to help) -- I just hate how much it interrupts a flow. Set up a long running task to go, building out a spec and come back to find 3 minutes in it chucked that error. AGAIN.
Do better amazon, you're literally hosting the models!
Now just gotta sell the Model X!
Maybe this is a personal thing, but one thing I *really* like in Cursor is the ability to start writing prompt while the agent works. If I have more than one agent tab/chat open, I sometimes am writing more than one prompt to different tasks. In Cursor, each agent tab has it's own input text box, so I can be writing them there and when I switch, so does the prompt. In Kiro, there is a shared/common input box, and switching between tabs just changes where it will go.
So since the last few updates, my claw was having spates of slowing right down, high cpu/ram, and eventually gateway restarts. Tried the latest update, no change. It would work great for periods of time though. Seen other posts on here just saying certain versions are broken.
I had it diagnose itself. Initially it pointed to the telegram integration (I run 3 bots so maybe more bots means more chance to crash?), but offered little.
Eventually, it did a deep dive and found it was occasionally getting ipv6 dns results for telegram. Since my stack isn’t ipv6 capable, it would fail, and this led to resource leaks.
> Night and day difference. The current PID (1843168) has been up for 5h 11m with:
> • 0 liveness warnings
> • 0 ERROR-level log entries
> • 0 restarts
> • 0 sendChatAction failures or stuck sessions
> Compared to the pattern before — crashing every few hours with 80-second event loop freezes, 52% CPU pinned, and ~9 crashes/day — it's running clean. CPU usage dropped from 52% to 4.4% too.
> The 10:46 restart happened because the previous session (my long reply to you) was the one that got stuck. It wasn't the IPv6 fix that caused it — that was the old process dying from the backlog the earlier crash created.
> Since the config took effect (10:46 restart), it's been rock solid. The fix is working.
—————
> Found it. The Telegram doc explicitly mentions this. On Node 22+, OpenClaw defaults to autoSelectFamily: true (tries IPv4 and IPv6 simultaneously), and dnsResultOrder defaults to ipv4first. The problem is autoSelectFamily: true means it attempts IPv6 connections — and when those fail with ENETUNREACH, it cascades into event loop chaos.
> I'll set both autoSelectFamily: false (forces IPv4 only) and dnsResultOrder: "ipv4first" (as a belt-and-suspenders)
Finally something to sell the 2017 Model X for! (PS, anyone want a model X?)