MaxxBench – "Nice DeepSWE score. But is it true?"
maxxbench.unlap.ai
maxxbench.unlap.ai
Which parameter to vary depends on the result of the test, but the MaxxBench route of varying the task spec seems like a good default, though not always the most informative.
In one of my private benchmarks I realised many of the less capable models didn't fail because they submitted the wrong answer, but because they exceeded their budget for number of tool calls they were allowed. The more capable models never got close to the tool call limit because they tended toward combining tool calls (e.g. chaining multiple shell commands in one Bash tool call).
Was my benchmark actually measuring ability to combine tool calls rather than reasoning ability on the problem at hand? Well, easy enough to find out: re-run under a different tool call budget and see how much the scores change.
(Next problem: is ability to combine tool calls a useful thing to measure, i.e. should it confer an advantage in the benchmark? It could be if it is a sign of planning multiple steps ahead.)
Yes, models are generally rewarded for this during RL. Not combining tool calls is an objective deficiency, even if not a major one.
Every turn forces you to pay $ for cached inputs and possibly gets you rate limited on TPM. At 500k context and $0.26/M-tok cache read price, every time it combines two tool calls instead of taking separate turns would save you $0.13. That could add up.
Maybe the provider sets a rate limit of 2 million TPM. That's just 4 turns in 1 minute before you start getting 429s. Cutting them in half by combining calls can save that.
All else equal, we definitely want models combining tool calls!
Asking for user permission before an action is pointless. it's not going to use a single `write`, it's going to run a 25 line perl script without even newlines.
At this point just completely remove permissions, and leave only one tool, a rust-like scripting language.
But this also drives usage up, because you rely less on yourself, and more on the increasingly black-box that is the subagent-of-subagent that you are not even going to check the result of.
So tool call limits during benchmaxxing is why they have gained this behavior, Goodhart strikes again...
I look forward to the near future when training is more accessible to more people and we can have more experimentation and diversity in models.
The practical takeaway, however, seems to be an interesting "don't use max mode". The passage about deepseeks weird API behavior dropping to pretty much zero the moment you used high says a lot.
Also, personally, even though Opus is clearly so much ahead of the Open Source models after the changes, I think the adjusted score is still very much competitive. I see other commenters using this as proof to justify why their opinions of the open source models - but a drop from 74% to ~50% is, while a big drop, still about a ~50% pass rate afterwards. That's far from useless for coding, especially since DeepSWE seems to be such a difficult benchmark. It simply seems to more accurately reflect the capabilities of these models.
All in all, I'd love to see more of such articles, and will probably keep an eye on this one - if they continue "benchmarking" these models this way.
That right there is the problem.
This is a scenario where the interest of the users and the labs actually align perfectly, since labs that have people actually paying for their product want benchmarks to align as close as possible to real life performance. Otherwise they can't actually easily tell whether the new model they are developing is any good or not, and so risk wasting literal billions of dollars on training runs for a product that people won't end up paying for. A failed major training run is an absolute disaster at the frontier, GPT-4.5 for instance was an almost existential failure for OpenAI at the time.
Case in point, the most popular coding model, Opus 5.5, also just happens to be the only one that avoided the benchmaxing impulse in this article. This is the result of years of Anthropic working very hard to avoid it.
DS used nearly twice the budget to accomplish the same thing.
Ideally, these tasks should be something you actually need day to day.
Astra does seem close.
I'd be curious to see Argon on there, since my experience is that Argon is also significantly behind Opus 5.5 and Astra despite the benchmarks (obviously much closer than Flash, though).
I've been meaning to take a closer look at what's behind the curtain of DeepSWE - since I built what I thought should be the easiest possible coding benchmark - and the models I tested it on scored roughly the same as they do on DeepSWE... Which is supposed to be hard...
Something seems amiss.
Especially since this benchmark is still mostly DeepSWE, and the only reason the open source models are doing decent is because much of the information hasn't changed. The open source models have been benchmaxxed to death.
Yes, this is true.
> You can not do real code work with open source models right now.
This is false, or you're using "real" as a loophole. You can absolutely do real coding work with open source models, right now, right this second.
I'm doing so today using Qwen 3.8 Flash Next running locally, and GLM 5.3 Flash hosted.
We could do real work with Opus 4.5, 4.6. These models (for coding) are more than good enough to do work that Opus 4.6 could do, and in some ways are superior.
uh-huh yeah, perhaps you can't
Look at GPT 5.6-Sol vs. GPT 5.6-Luna in particular.
(The GLM pair shouldn't be expected follow this pattern, because they're misnamed: GLM-5.3 and GLM-5.3-flash are distinct lineages. The -flash is an early release of a new pretrain on a new architecture).
If this *is* the main factor, I'd expect Kimi K3.1 and Gemini Carbon would also do well on this test (unlike Gemini-flash); while Haiku 6 would collapse (breaking the trend of the other recent Claude models). It's a falsifiable prediction.
It's not unreasonable to assume Kimi 3.1 is also a distilled model even though it's large (the difference being that it's a distilled from US models). I wouldn't be surprised if it also collapsed on this benchmark.
For instance, I had Qwen3.8 Flash Next reply with "I'm Kilo Code, a coding agent designed to ...".
That was in llama.cpp's UI - no harness whatsoever.
I run a lot of agents headless on tasks. They are pretty well sandboxed, but I would definitely suggest a regular audit script to go through the transcripts. Most of DeepSeek’s “creativity” has shown problems in my sandbox setup which get fixed (e.g. I had restricted something the agents actually needed), but some of it is actually worrying.
In an opposite turn, Kimi 3.1 follows rules much better (actually too literally sometimes). K3 was a real digger when trying to benchmark it if it got a sense it was being tested. 3.1 comments about 5x more that it thinks it’s being tested (and it’s right), but unlike K3 it doesn’t seem to do anything about it if it can’t get at something. I would love to see the authors do K3 and 3.1 in this because the 3rd party benchmark gains are large, but these two are behaving like different models for me rather than a point release.
They should be doing what this test did, and generalizing and significantly varying the training environments (and ensuring some of them are unexpectedly complex and unexpectedly simple).
Further I suspect the smaller models are especially overfitting to these sorts of simpler RL envs (benchmarks tend to be much simpler than the hardest RL env used today) because they are more likely to be scoring at ~20-40% success rate (which is sort of what you want to get good training signal when doing RL runs).
I care not so much about wrong answer, that's just another try and it gets it right eventually, but this cheating.
And several companies to do just this exist (eg Superconductor, Fullbeam) - does anyone use them and find them valuable? And curious if you’ve noticed an improved change in your agents work as a result, and if over time you see yourself switching models ? Or is it more of a one time realization that model family X is best for your code.
Example: I could barely induce K3 to use subagents. I had to force it via instructions and then, in my tests to try to get it to use Qwen, it didn’t work well. 3.1 lost 6 hours thrashing overnight because it voluntarily called subagents and the box can only run one Kimi at a time. My own fault for not looking up the new Moonshot system prompt (that they changed also because of this behavior), but one example of how different even point releases can be.
> Let me just do float64; the risk of a test with >2^53 numbers is minimal. > such cases are unlikely … Truncation toward zero is fine.
Apart from this, we also a scenario where the models tried to pass benchmark specific tests by believing a parameter that the model printed.
> Seven models reward-hacked a test that believed a metric from the program itself.
DeepSeek also resorted to making external model calls via OpenRouter instead of doing the work itself. This suggests that even though the SOTA models are smart enough to compute, they either have an inbuilt bias towards achieving scores or the low/medium effort gives them the freedom to fetch information instead of computing it. With high effort, the models focus on computing the values but the token calls get exhausted.
Difficult to find a balance amongst compute, calls and cost.
But I agree witih you an important piece of the generalisation puzzle is missing.
(1) An established framework for model evaluation runs the inference call with API key inside the isolated envionment the agent harness has full access to. Especially when it's intended to be an offline environment, that seems kinda... dumb. The language model itself is not dangerous -- it's only text. Inference is fine to do outside the isolated environment. It's only the harness' tools that can have effects on the enironment, so those need to be sent to the sandbox.
(2) Only a small set of language models exploited this! I run private benchmarks a lot and I know how much the language models try to anticipate grader behaviour when the task is bechmark-shaped. I would have thought more of them would request the answer from the web.
(3) It takes someone else to mutate the task specification. When I'm looking at an older iteration of one of my private benchmarks, the first thing I do is add a small twist to it to see how much of a passing grade is learned/anticipated. Seems like a cheap and easy coalmine canary that's in the interest of the evaluator.
(4) MaxxBench did not try to dress some DeepSWE tasks in clothes that make them look less benchmarky. Their purpose seems to be answering "how well does DeepSWE enchmark scores generalise?" Part of the generalisation error is memorised solutions, yes, but another part is that models emit different behaviour when they suspect they are in a benchmark. By being careful to not leak the benchmark nature of the task, models spend a lot less time reasoning about the behaviour of the grader and this is likely to produce different performance on the mutated task. It would be interesting to know in what direction that effect points, because that is the performance people get out of the model in real situations. (In my experience, hiding the benchmark nature of the task can produce improved performance on both the original and the mutated task, but particularly the latter.)
This is something I was thinking about, too. More than once I've observed a model note in a reasoning trace something along the lines of "this looks like a coding test" (could possibly also refer to leetcode style problems, but same difference). Models often also seem to behave differently in response to one-shot prompts.
On occasions where I let a model do autonomous work, I usually don't just give it a prompt for this reason. I write a CONCEPT.md file, then refine that interactively into a SPEC.md file to find and resolve ambitaskguities (and possibly also create an ARCHITECTURE.md file, if it isn't a one-off ). At this point, most models seem to no longer see it as a benchmark or competitive programming problem, but a proper software engineering task and are less prone to reward hacking (with the caveat that these are very subjective and unfalsifiable impressions).
Edit: I think that's the answer. This page lists the score as 53.3% which is close to the 54.4% reported here https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731 for the 0731 update. The original from April was called preview, doesn't list the score, but in the comparison with the update it scores 7.3%.
Every time a Chinese lab releases a new model, I give it a solid try that same weekend and drive it hard by giving it the exact same tasks that I give to Claude/Codex models. And the new releases all have the same issues: they start out strong, but start deviating after about ~30 minutes and I quickly find myself in a quagmire where the model makes mistake after mistake while fixing its previous mistakes. Sometimes these are minor. Occasionally they can be pretty bad. Like, would-cause-data-loss-if-merged bad.
Ultimately I also reject the notion that Chinese labs are only a few months behind US labs. We haven't had an actual Fable-level model come out of China. AFAIK only Kimi 3 was claimed to come close, and then it turned out that not only had they heavily distilled Anthropic models, but, unbeknownst to their users, they were routing some percentage of their requests to Fable.
Obviously these models are benchmaxxed, and it's frustrating to see not only so much attention on these benchmarks, from both users and the labs, but there is a difference between "The models are benchmaxxed" and "that means the open models are much worse than the closed ones"
A lot of users here seem to draw a correlation between these two, but what the article shows mostly is that the smaller models are more benchmaxxed than the bigger ones. That includes both open weights and closed weight models, as Luna seems to be among the worst benchmaxxed models. It's just that the open weights models are smaller than the closed weights ones.
Obviously though, every benchmark has to be taken with a grain of salt, including this one. But we have to be careful to not cherry pick the conclusions that prove our pre-existing notions
[0] https://news.ycombinator.com/item?id=50373961 [1] https://news.ycombinator.com/item?id=50374111
This is the same stupid argument trotted out repeatedly in the thread, and it doesn't hold up to reality. Would you care to explain how adding specifications helps a model that demonstrably ignores specifications? A model that cannot even handle the trivial specification of "the filename must be lowercase" is not going to get better when you add more specifications it ignores. I would guess that you're actually significantly underspecifying relative to me. Perhaps you're happy with whatever slop you get and don't notice Luna's overwhelming incapability to actually provide what one requires, because you don't have requirements.
Wrong. What I want Luna to be able to do is ~deterministically make small edits or generations of 1~10 LoC according to a specification, and it literally cannot even do that. It violates specifications no matter how small you aim.
> there is nothing deterministic about using llm's for codegen
And if you're okay with that, you're more like a farmer eating the slop meant for his pigs than an engineer. Using Sol Max, you can get near-deterministic output for a much wider range of tasks and specifications. Not all specifications; at a certain degree of sufficiently detailed specification it will begin failing again. But some, which is better than none.
again, you're expecting to use it without steering. that's not how you get the most out of the smaller models. i don't want to say you're using them wrong, but you clearly are. it could be deficiencies in your harness as well which the stronger models mask. try pi.
> you're expecting to use it without steering
If I have to manually "steer" every mistake it makes on every trivial task, instead of being able to deterministically eliminate classes of failures so that fixing the task one time ensures that failure never happens again on similar future tasks, it is in fact faster to just type the fucking code myself.
but your claim was about file name invariants when generating code, especially small amounts of code, which is not what they were doing with DeepSWE, so you've confused two different things.
anyways, this is a pointless argument. if you can't figure out how to effectively use smaller models in your workflow, fine. but don't come on here talking shit about people who can.
shhhhhhh, not so loud!
>When we read the trajectories, we saw that many models had figured out they were in a benchmark and started second-guessing the prompt. Instead of just building what we asked for, they started coding to the tests they thought the grader would run.
I ran into the same problem on my English exams.
But what really caugh my attention is DS4 calling the openrouter with it's key. That's pretty bad for both the model and the evaluation sandbox.
Alignment? What alignment lol
For my use case deepseek 4.1 flash is almost as dumb as haiku 5.5. Both are fast garbage producers.
Moreover, the months I've used anthropic/OAI exclusively my API token costs are in the hundreds (or sometimes thousands). With DS flash as the first agent I reach for, I rarely exceed $40/mo.
Every once in a while I come across comments that just hates DS. I wonder if it's a matter of how people use it or the prompt. I admit pre-v4.1 was pretty bad, hallucinating too much and not getting the abstractions right so I had to correct it often.
I also have $200 Claude subscription (now called "Ultra"). Fable gets abstractions right on highly complex problems (e.g. defining protocol that spans multiple services) that DS simply cannot do. However, DS is comparable to Opus 5.5, although less "intelligent", but DS excels at speed which is what I prefer than waiting minutes on Opus 5.5.
I have access to Claude Code at work (and use it quite a bit), so I feel I can honestly compare them.
You do have to plan things first a bit more with DS (than say Opus can (Opus will have more chance of one-shotting something, although I generally don't think that's a good idea), although it often over-engineers and tries to be too helpful in my experience) and be a bit more explicit at times, but I feel it's quite close to Sonnet in performance for implementing plans, debugging issues and explaining how codebases work.
When you see this your worldview will instantly become much clearer.
I've also been very happy playing around with qwen 3.8 27b running locally for personal projects. It sometimes can't quite get there, and that's when I'll reach for GPT.
Anyway, I use DSF v4.1 on max as much as I use Opus 5.5 on xhigh, Opus is definitely a more versatile model, but I’m not getting any value using it to implement well defined tasks that DSF v4.1 does just as well at for a fraction of the cost.
You see where GLM-5.3 is in this test down but respectable, but this model benches below DSF 4.1. TLDR basically nothing in this benchmark invalidates the Deepseek that everyone is using today.
I mean of course, the real world is messy, the models are only good for what they've been trained on, and post-training frequently takes benchmark scores into account too, leading to this sort of "Great score, sucks in the real world" syndrome that seemingly most models are affected by.
Edit: another comment pointed out it's probably not benchmaxxing due to the chronology.
https://news.ycombinator.com/item?id=50406948
But why should minor changes to the task cause catastrophic performance drops? How is that not evidence of benchmaxxing?