What does it mean when Fable 5 is 1st place and Opus 5 is 3rd place, while Claude code is 7th place? Which model and effort is used for Claude in 7th place, compared to 1st and 3rd?
They are all different problems for the different languages. I was hoping this was a benchmark that attempted to see which languages were more efficient to use with which models.
Exactly. I was wondering what language would be better for heavy agentic workflow. Due to a recent blog post, Clojure seem to be the most terse [1]. But some people are suggesting static types would help in this workflow.
I'm curious about this as well. I use Java quite a bit and I feel like my results are excellent, but colleagues who use other languages are less impressed. I wonder if this is because Java is more amenable to agentic workflows, or there is a large corpus of example code, or some other reason.
Some agents have specific tools that the models have been trained to use. E.g. diff formats for editing that aren't the same as the standard unified diff format. Access to specific thread / subagent / etc. tooling or the base prompt can perhaps also impact how the tasks are completed.
I've had much better experiences with the "budget" tier models than this test suggests I should. I rarely even consider the higher models due to price/use. Perhaps I'm just more vigilant about spec'ing my prompts out before submitting them? Am I just doing too pleb of work? I'm not trying to write custom cuda kernels or hardware integration.
> Potential data contamination: The SWE-bench dataset, comprising a collection of GitHub issues, has been publicly available since the end of 2023. As a result, models released after this date may have seen these exact issues or highly similar data during training. This raises the risk of inflated performance metrics and makes it harder to distinguish genuine generalization from memorization.
13 comments:
Call me biased, but if Grok 4.5 is above GPT-5.6 Sol, I don’t trust this benchmark.
What does it mean when Fable 5 is 1st place and Opus 5 is 3rd place, while Claude code is 7th place? Which model and effort is used for Claude in 7th place, compared to 1st and 3rd?
They are all different problems for the different languages. I was hoping this was a benchmark that attempted to see which languages were more efficient to use with which models.
Exactly. I was wondering what language would be better for heavy agentic workflow. Due to a recent blog post, Clojure seem to be the most terse [1]. But some people are suggesting static types would help in this workflow.
[1] : https://martinalderson.com/posts/which-programming-languages...
I'm curious about this as well. I use Java quite a bit and I feel like my results are excellent, but colleagues who use other languages are less impressed. I wonder if this is because Java is more amenable to agentic workflows, or there is a large corpus of example code, or some other reason.
Why test Fable high effort vs Sol medium? Especially when Sol comes out 4-5x cheaper in their tests at those effort levels.
I think you just answered your own question.
Edit: In DeepSWE Sol High scores the same as Fable High for ~1/3 of the cost.
What happened in July 2025 and January 2026? If that can't be explained in a concise way this entire dataset is vibes at best.
Why are models better than agents, isn't it supposed to be the opposite? I don't understand the difference and what you are measuring.
Some agents have specific tools that the models have been trained to use. E.g. diff formats for editing that aren't the same as the standard unified diff format. Access to specific thread / subagent / etc. tooling or the base prompt can perhaps also impact how the tasks are completed.
Weird
I've had much better experiences with the "budget" tier models than this test suggests I should. I rarely even consider the higher models due to price/use. Perhaps I'm just more vigilant about spec'ing my prompts out before submitting them? Am I just doing too pleb of work? I'm not trying to write custom cuda kernels or hardware integration.
https://swe-rebench.com/about
> Potential data contamination: The SWE-bench dataset, comprising a collection of GitHub issues, has been publicly available since the end of 2023. As a result, models released after this date may have seen these exact issues or highly similar data during training. This raises the risk of inflated performance metrics and makes it harder to distinguish genuine generalization from memorization.