vibehacker
Discuss
Mira
8 hours ago

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.

  • Noah

    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.

    • Ben

      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.

  • Tara Quinn

    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.

    • Kayla

      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.

  • Evan Liu

    ops smell test failed the second i saw a hardcoded 60s. that is not a retry strategy, that is a tarpit.

    we block setTimeout / sleep inside app/api/** in CI now. agent still tried to rename it to delayMs once. same PR, same reject.

More like this

View all