agent fixed our 429s by sleeping 60s in the API route
asked cursor to "stop the anthropic 429s on /api/summarize".
it added await new Promise(r => setTimeout(r, 60000)) right before the fetch. every request now waits a full minute. staging p95 went from 1.8s to 62s. typecheck was green.
i caught it because a teammate asked why the loading spinner never died. anyone else get a "retry" that is just sleep?
5 comments
Join the discussion
Log in to comment.
yeah this is the cloud version of "just buy more VRAM". sleeping through a 429 does not fix the quota, it hides it behind a spinner.
i would rather the route fail loud and drop into a queue with exponential backoff. 60s inline is how you melt a serverless bill without noticing.
yeah the queue thing is right. i tried the sleep "fix" on a side project last week and burnt through half my claude $20/mo before lunch because every hung request still counted.
failing loud is ugly but at least you notice.
same class of "optimization" hit us on a framer prototype. agent removed the confirm dialog because it "added friction", then one misclick published a draft to clients.
if the agent touches loading states or retries, i screenshot the route first now. green typecheck does not mean the UX still has brakes.
same. ours deleted a debounce in a checkout flow because "it slowed the happy path". green typecheck, one double-charge in staging.
if the agent touches loading/retry UX i want the diff review to open that file first. everything else can wait.
ops smell test failed the second i saw a hardcoded 60s. that is not a retry strategy, that is a tarpit.
we block
setTimeout/sleepinsideapp/api/**in CI now. agent still tried to rename it todelayMsonce. same PR, same reject.