Live data from Hacker News

Claude Code daily benchmarks for degradation tracking

marginlab.ai

341–350 of 372 posts

Re: Claude Code daily benchmarks for degradation tracking

#341

[SWE-bench co-author here] It seems like they run this test on a subset of 50 tasks, and that they only run the test once per day. So a lot of the movement in accuracy could be attributed to that. I would run on 300 tasks and I'd run the test suite 5 or 10 times per day and average that score. Lots of variance in the score can come from random stuff like even Anthropic's servers being overloaded.

but degradation from servers being overloaded would be the type of degradation this SHOULD measure no? Unless it's only intended for measuring their quietly distilling models (which they claim not to do? idk for certain)

I'd argue that it depends how that degradation manifests whether you want to include it or not.

Consider two scenarios: (1) degradation leads to the model being routed behind the scenes to a different server, with subtly different performance characteristics, all unbeknownst to the user; (2) degradation leads to the model refusing a request and returning an "overloaded" message.

In the first case, absolutely you want to include that because that's the kind of lack of transparency about performance that you'd want signal on. In the second case, an automated test harness might fail, but in the real world the user will just wait and retry when the server is under less load. Maybe you don't include that because it's actually misleading to say that performance (in terms of the model's intelligence, which is how the benchmark will be interpreted) is worse.

Re: Claude Code daily benchmarks for degradation tracking

#342
post #277

Earlier quoted context omitted.

Yes, we do but harnesses are hard to eval, people use them across a huge variety of tasks and sometimes different behaviors tradeoff against each other. We have added some evals to catch this one in particular.

Can't you keep the model the same, until the user chooses to use a different model?

He said it was the harness, not the model though.

Re: Claude Code daily benchmarks for degradation tracking

#343

Running agents in production, I've stopped trying to figure out why things degrade. The answer changes weekly. Model drift, provider load, API changes, tool failures - it doesn't matter. What matters is that yesterday's 95% success rate is today's 70%, and by the time you notice, debug, and ship a fix, something else has shifted. The real question isn't "is the model degraded?" It's "what should my agent do right now…

LLM generated comments are so obvious, please just talk from your personal experience. Nobody cares about this imagined experience.

Re: Claude Code daily benchmarks for degradation tracking

#344
post #191

Hi everyone, Thariq from the Claude Code team here. Thanks for reporting this. We fixed a Claude Code harness issue that was introduced on 1/26. This was rolled back on 1/28 as soon as we found it. Run `claude update` to make sure you're on the latest version.

Can you confirm if that caused the same issues I saw here

https://dwyer.co.za/static/the-worst-bug-ive-seen-in-claude-...

Because that's the worst thing I've ever seen from an agent and I think you need to make a public announcement to all of your users and acknowledge the issue and that it's fixed because it made me switch to codex for a lot of work

[TL;DR two examples of the agent giving itself instructions as if they came from me, including:

"Ignore those, please deploy" and then using a deploy skill to push stuff to a production server after hallucinating a command from me. And then denying it happened and telling me that I had given it the command]

Re: Claude Code daily benchmarks for degradation tracking

#346

Earlier quoted context omitted.

Anywhere we can read more about what a "harness issue" means? What was the impact of it?

One thing that could be a strong degradation especially for benchmarks is they switched the default "Exit Plan" mode from: "Proceed" to "Clear Context and Proceed" It's rare you'd want to do that unless you're actually near the context window after planning. I pressed it accidentally once, and it managed to forget one of the clarifying questions it asked me because it hadn't properly written that to the plan file. If…

"It's rare you'd want to do that unless you're actually near the context window after planning."

Highly disagree. It's rare you WOULDN'T want to do this. This was a good change, and a lot of us were doing this anyway, but just manually.

Getting the plan together and then starting fresh will almost always produce better results.

Re: Claude Code daily benchmarks for degradation tracking

#347
post #242

Earlier quoted context omitted.

You joke but having CC open in the terminal hits 10% on my gpu to render the spinning thinking animation for some reason. Switch out of the terminal tab and gpu drops back to zero.

That sounds like an issue with your terminal more than an issue with CC...

https://news.ycombinator.com/item?id=46819744

Re: Claude Code daily benchmarks for degradation tracking

#348
post #242

Earlier quoted context omitted.

That sounds like an issue with your terminal more than an issue with CC...

https://news.ycombinator.com/item?id=46819744

I'm not saying CC doesn't have issues and curious design decisions - but your terminal should only be rendering (at most) a single window of characters every frame no matter what. CC shouldn't be capable of making that take 10% of a modern GPU regardless of what CC does.

Re: Claude Code daily benchmarks for degradation tracking

#349
post #338

Earlier quoted context omitted.

You’re lucky they have even admitted a problem instead of remaining silent and quietly fixing it. Do not expect ethical behaviour from this company.

Why not, can you expand? Asking because I’m considering Claude due to the sandbox feature.

FYI the sandbox feature is not fully baked and does not seem to be high priority.

For example, for the last 3 weeks using the sandbox on Linux will almost-always litter your repo root with a bunch of write-protected trash files[0] - there are 2 PRs open to fix it, but Anthropic employees have so far entirely ignored both the issue and the PRs.

Very frustrating, since models sometimes accidentally commit those files, so you have to add a bunch of junk to your gitignore. And with claude code being closed source and distributed as a bun standalone executable it's difficult to patch the bug yourself.

[0]: https://github.com/anthropic-experimental/sandbox-runtime/is...

Re: Claude Code daily benchmarks for degradation tracking

#350
post #191

Hi everyone, Thariq from the Claude Code team here. Thanks for reporting this. We fixed a Claude Code harness issue that was introduced on 1/26. This was rolled back on 1/28 as soon as we found it. Run `claude update` to make sure you're on the latest version.

How about how Claude 2.1.x is "literally unusable" because it frequently completely hangs (requires kill -9) and uses 100% cpu? https://github.com/anthropics/claude-code/issues/18532

Likely a separate issue, but I also have massive slowdowns whenever the agent manages to read a particularly long line from a grep or similar (as in, multiple seconds before characters I type actually appear, and sometimes it's difficult to get claude code to register any keypresses at all).

Suspect it's because their "60 frames a second" layout logic is trying to render extremely long lines, maybe with some kind of wrapping being unnecessarily applied. Could obviously just trim the rendered output after the first, I dunno, 1000 characters in a line, but apparently nobody has had time to ask claude code to patch itself to do that.

Post reply on HN