The math is obvious on this one. It's super well-documented that model performance on complex tasks scales (to some asymptote) with the amount of inference-time compute allocated. LLM providers must dynamically scale inference-time compute based on current load because they have limited compute. Thus it's impossible for traffic spikes _not_ to cause some degradations in model performance (at least until/unless they a…
Umm. I run multiple benchmark using APIs for my work and the inference time compute allotted has clear correlation with the metrics. But time of the day certainly isn't. If it is that straightforward people can prove very easily rather than relying on the anecdotes. They either overprovision the server during low demand or they might dynamically provision servers based on load.
Ask HN: Claude Opus performance affected by time of day?
41–45 of 45 posts
Re: Ask HN: Claude Opus performance affected by time of day?
#42Re: Ask HN: Claude Opus performance affected by time of day?
#43My working theory is that under higher load, the model is more likely to: - take broader interpretive leaps - attempt larger refactors instead of minimal diffs - “explain its way forward” after a wrong turn rather than reset cleanly
That shows up as rabbit holes and self-reinforcing iterations, especially on codebases where local consistency matters more than global cleverness.
What’s helped a bit for me: - explicitly asking for minimal, localized changes - telling it not to refactor unless necessary - breaking requests into smaller steps and locking earlier decisions
It could also be variance from routing, context window pressure, or subtle prompt drift rather than a predictable nightly degradation, but the pattern of “overconfident refactor spirals” feels real.
A like-for-like experiment with the same prompt and context at different times would be interesting, though hard to fully control.