This page is Why the 100 most recent chats run slow. It is one of the projects Brandon built and put online. The grown-up details are below, tap Grown-up mode to read them the normal way.
Why the 100 most recent chats run slow
Scope: the 100 newest sessions on drwu-htmls.vercel.app/chats · measured 2026-06-07 13:52
Verdict. The recent chats are not slow because they do a lot of work — median is just
5 turns. They are slow for two measured reasons: (1) three sessions are
live but idle — a claude --resume process sits open for ~a day at ~0% CPU, so the
board calls them "running" while nothing advances; and (2) the chats that are moving carry a
huge inherited transcript, so every turn re-processes megabytes of context. A 2-turn fork can
already be 17 MB. That, on Opus, with a stack of per-turn hooks, is the whole story.
6
live processes
3
idle >2h (zombie)
32MB
biggest transcript
308
watchdog wakes
1"Running" means a process is open, not that work is happening
The board sets running=true when ps ax shows a live
claude --resume <id>. It is a liveness check, never a progress check. Three sessions
have been parked open for the better part of a day:
chat
last turn
process alive
turns
transcript
KATE TERO VOICE CARD
21.6h idle
23:06:13
4
1.4 MB
HOORAY EARTH RACY FORK
21.4h idle
21:58:08
5
3.5 MB
SKILLS EVALUATION USAGE
17.3h idle
01-00:37:42
16
9.5 MB
For contrast, the genuinely-advancing live chats:
chat
last turn
process alive
turns
transcript
Pickup mode workflow review
0m ago
39:09
6
1.9 MB
COLOR CODING DUPLICATE CHATS
3m ago
01-00:37:45
4
3.2 MB
RULES
9m ago
22:02:21
66
3.0 MB
2Transcript size is decoupled from turn count — forks inherit the weight
Per-turn latency tracks context size, not how much this chat has done. A resumed or
forked session starts at its parent's full size, so a brand-new 2-turn chat is already slow on turn one.
"MB/turn" below shows how much context each turn must chew:
chat
transcript
turns
weight per turn
BELIEVEYOUME ALBUM MUSIC THEORY
32.3 MB
14t
2.3 MB/turn
BANDBOOKS MAP
17.8 MB
36t
0.5 MB/turn
BANDBOOKS MAP FORK
17.0 MB
2t
8.5 MB/turn
PUTTING CHORD CHARTS INBOOKS
14.3 MB
15t
1.0 MB/turn
BELIEVEYOUME MODEL REBUILD HANDOFF
11.7 MB
26t
0.4 MB/turn
SKILLS EVALUATION USAGE
9.5 MB
16t
0.6 MB/turn
live
IXIMUSIC SUPRISES MUSIC THEORY
9.2 MB
18t
0.5 MB/turn
MODEL REBUILD RESUME
9.0 MB
10t
0.9 MB/turn
3Background churn + fixed per-turn tax
The Render Watchdog automation has woken 308 times
(320 total wake cycles across the window), each re-entering a session and running turns in the
background. On top of that, every single user turn prepends a stack of UserPromptSubmit hooks
(no-quit-shift queue dump, chat-conductor cheat sheet, ultracode, paths, honesty gate) plus the full
CLAUDE.md + MEMORY index — hundreds of fixed input tokens before the first real word. On Opus 4.8 (the
slowest tier, and the default these run on) that fixed tax is paid at maximum latency every turn.
4What to actually do
Close the 3 zombie tabs. They are live --resume processes idle ~21h.
They hold "running" forever and may hold the fleet arm-lock. Quit those terminal tabs (or kill the PIDs).
Stop forking big chats. A fork inherits the parent's multi-MB transcript and is slow
from turn one. Start a fresh session for new work and hand it only the handoff doc.
Retire the giants. The 14–36 MB sessions should be archived, not resumed. Each
resume re-loads the whole thing.
Throttle the watchdog. 308 wakes is a runaway loop — widen its
interval or gate it on real work.
Don't default these to Opus. Routing memory already says so; long resumed chats on
Opus pay the worst per-turn latency.