Hey everyone, can you guys hear me okay?
This is good? Yeah, my name is James. I'm one of the founding engineers at DataCurve. Unfortunately, Serena's been out with a fever for the past couple of days. She was supposed to be here giving this talk. So I'm just filling in her place. But I've been at DataCurve working on the research and engineering side of things, as well as DeepSuite, which is our frontier long-horizon coding benchmark, which you guys may be familiar with.
I'll just be going over some of the most important findings about DeepSuite, a brief overview of what it is for those of you who may not know, and then going deeper into our methodology and exactly how we came about this frontier coding benchmark. DeepSuite is a long-horizon software engineering benchmark comprised of 113 original software engineering tasks. So this means, unlike something like SuiteBench Pro, we didn't scrape this from existing PRs that have been closed. There's a variety of benefits for this. Namely, one of them is to resist contamination and agents being able to cheat through the course of their rollouts.
SuiteBench Pro pulls thousands of tasks from only 40 repositories. The median task per repository for us is one. So you can see across over 100 tasks, we pull from nearly 100 repositories. And the language spans across TypeScript, JavaScript, Python, Rust, and Go, and we have plans to add more languages later on. Since its release, we've received very positive reception. It's replaced SuiteBench Pro in the artificial analysis coding agent index, as well as being cited by numerous frontier model labs and us helping with them in tracking their models on our benchmark as well. So we've been really, really appreciative of that. A bit of context about us.
DataCurve works on building training data for high-ceiling domains, including coding as well as coding-adjacent fields. We also are trying to answer the very elusive question of what exactly makes good data. What is data quality? And how can we demonstrate that our training data, in fact, moves the needle? So DeepSuite is one in a long line of initiatives that we have toward answering this question. So why did we create DeepSuite? Well, it was very clear that the existing benchmarks are not hitting the mark. With ventures like SuiteBench Pro, top models are clustering at the top.
It's very hard to differentiate between which one is good because they all have overlapping confidence intervals. Contamination is also rampant because, again, all of these tasks are mined from public PRs. So all the solution tests, even the discussion around the PRs, are all available out in the wild for these agents to access. The verifiers are also very, very brittle because we're anchoring them to a specific implementation, often derived from the PR that was merged in. And oftentimes, you also have tests that check for private helpers and functions created by the task author, which is very opinionated, right?
And it's not something that models should have to adhere to. And finally, leakage. So one thing about SuiteBench Pro is for very insightful models such as Claude, they're able to directly run git log and then go through the commit hashes and cherry-pick the ones out that contain the golden patches, which, again, is a very, very serious issue. So this is DeepSuite. This is the updated leaderboard as of July 1st. You can see, I was mentioning before, the problem of differentiating. But you can see on DeepSuite here, there is a very clear difference. There is a very clear performance gap between the top-performing models versus, at 10th place, you have Gemini 3.1 Pro.
Also within the Claude and the GPT models as well, we're able to see some deviance. And yeah, if you go on DeepSuite.datacurve.ai, you'll also be able to see the token efficiency, costs, token usage, context window, peak context, all of that stuff on the DeepSuite site as well. But yeah, as of July 1st, Fable 5 is retaining the top spot on our leaderboard. So the ranking information is available online. Again, I wanted to talk about some of the qualitative insights into how these different models are performing, which I think is the most interesting part. Starting with the first one, we find Claude is generally a very, very thorough and exhaustive model.
It will try to explore everything, including going through all of the git logs. So one interesting insight was seeing that it becomes quite forgetful when it comes to multi-part prompts. So when you tell it within the scope of a task, let's say, to support both synchronous and async versions of calling a hook, it will go ahead and implement the synchronous part, but it may drop the asynchronous part.
We observed this in roughly two out of three Claude rollouts across all of the trials, all of the rollouts that we ran. So this was definitely quite interesting because from my experiences, and from developers I've talked to as well, Claude is generally very, very thorough and able to get at the developer's intent quite well. Another thing about Claude is it pays very close attention to its environment. So it will often run, this is taken from the trials we ran ourselves independently and also from examining SuiteBench Pro, it will attempt to run git log and recover the golden patch from the git history.
We found that for Opus 4.6 and 4.7, it did this 25% and 18% of the time respectively, compared to all the Gemini models averaging at roughly 1% of the time, and we found zero instances of this for the GPT models. So thankfully within DeepSuite 1.1, we safeguarded further against models being able to cheat by pulling from the git history. But this was something we observed quite frequently for Claude within the SuiteBench Pro rollouts. Third finding is that GPT is very good at implementing exactly what it is asked. Across our failure mode analysis, we found that it was the least likely model to miss requirements.
GPT 5.4 was the second best model of this ranking, only behind GPT 5.5. It always seems to read the prompts and the repository contract very literally and produce a patch that honors the existing conventions and signatures within the repository, which is very helpful. And we found that these traits converge across all rollouts. So these were not just lucky attempts, but on average, this was the favorable behavior exhibited by GPT. And finally, we found that on average, stronger models have a great tendency to want to test their own work, but with a caveat.
In SuiteBench Pro's template, they explicitly tell the model that the tests are handled, and therefore they do not need to write any new tests of their own. With that single line in the prompt, it will prevent the models, even 5.5 and Opus 4.8, from attempting to verify their own work through the course of the rollout. In DeepSuite, we do not have anything that says to write or not to write tests. And so we observe this divergence between the percentage of the time where these models are actually engaging and writing tests.
So this is quite an important behavior, as it can provide that the models are trying to obtain their own ways to verify and validate their work through the course of a rollout. We find on average that stronger models like 5.4 and 4.7 exhibit this the majority of the time, whereas models like 3 Flash and 3.1 Pro are far less frequently willing to test their own work. So, takeaways from the findings, I think it's very interesting how stronger models on average exhibit or converge on these behaviors. So moving on to the tasks, the methodology behind DeepSuite. We made a decision to want to have every task authored from scratch rather than being mined.
Aside from the issues with contamination that we mentioned previously, this also plays into one of our core strengths, which is that we offer a bespoke platform where we have software engineers and machine learning enthusiasts come on and create these challenges and compete against one another. This platform is called Shipt, and we have a version of this platform for every single domain that we're interested in. For example, for software engineering, it takes a lot after Code Forces or GitHub, and we're really looking for enthusiasts.
So these are oftentimes open source engineers who are core contributors or maintainers of the projects that they're actively making tasks for. So by creating these tasks from scratch, we know that the outputs are intrinsically aligned with our objective of providing a fair and comprehensive test to models. We also know that these people have very thorough understandings of the repository's philosophy and the existing conventions. So they can make tasks that are both realistic in terms of the prompt, but also realistic in the sense that this is an actual PR that you might see getting merged into the repositories.
Another very important design decision is we try as much as possible to make our prompts like real tasks. On average, the prompt length within SuiteBench Pro is over 4,500 characters, whereas for us, it's roughly half of that. And this is important because when you're prompting, say, a junior engineer or you're prompting a model to solve a very high-ceiling, ambiguous task, you're not going to be coming in there with a to-do list telling it, oh, first do this and then do this and then write this function signature in exactly this way that I've prescribed onto you.
Oftentimes, you're going to give it the high-level objective, get it to explore, and get it to reason about the list of to-dos and ultimately to the solution on its own. So this was not the case in SuiteBench Pro. It's very overly verbose and tries to prescribe a certain solution method onto agents. As much as we could, we try and make DeepSuite prompts as terse and as high level as possible, mirroring what you might see in the real world if you were to prompt, say, another engineer or one of your agents to go and solve an engineering task.
So even though our prompts are short, we still are able to maintain the long-horizon nature of these tasks, even with our prompts again being roughly half the size of SuiteBench Pro's. We find that the average size of our solution is five times the lines of code compared to SuiteBench Pro's. We also verify that there are on average seven files being touched in the agent's solution. And across the course of a rollout, we have two times more output tokens being emitted. And finally, verifier design is, of course, one of the most important and tricky parts of building good environments.
In SuiteBench Pro, we have these verifiers that are testing, again, for specific implementations.
It will fail the model if it produces a function that may address the objective but is not named or is not defined within a specific module, or if there is the absence of specific helpers or other private functions. Because again, these are derived from the solutions that were merged in the actual PR. So for us, we want to emphasize observable behavior as much as possible. We want to ensure that any correct implementation, anything that correctly solves the problem, is rewarded, and this will prevent false negatives. We also make sure that there is the absence of these PR-derived tests that rely on naming, relying on specific implementations.
And so this will prevent, again, false negatives as well. We observed through a combination of these considerations, we're able to drastically reduce the false negative as well as the false positive rates when we analyzed our rollouts compared to SuiteBench Pro's using both human experts as a result of the results.
and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and and can field real-world and realistic software engineering tasks.
But with all that said, there's still a lot of work to be done for DeepSuite and for benchmarks in general. One of the things that we outlined in our blog is our choice to use MiniSuite Agent, which is an agent-agnostic harness. The reason why here is we really want to be focusing on the model's base performance, and so we use MiniSuite Agent.
We also ran rollouts to test that the performance is comparable, both using MiniSuite and against each model's native harness. But I think there's a lot of work to be done in the future for benchmarks that focus solely, or more so, on harnesses and comparing the effects that these harnesses, whether native or third-party ones like MiniSuite, have on the efficiency and the output of these models. Another thing we want to improve on is task mix. So given that we are targeting long-horizon tasks, naturally this meant that there's less emphasis on bug localization and refactoring.
These are obviously very representative of real work that software engineers are doing, underrepresented in our current taxonomy for DeepSuite. And finally, repository pool. We put an emphasis on trying to field as many diverse repositories as possible, keeping the median task per repository to a very low count. But further work here, just to pull in more repos, more tasks that software engineers find interesting and find to be good, and maybe also more niche tests of model performance, would also be a great addition here. So we've already released DeepSuite V1.1.
So in here, we've taken some additional measures to guard against cheating and reward hacking by ensuring the verifier runtime is fully separate now from the agent runtime. Also making sure the test reports are in a more standardized format. And also making sure that we've trimmed all of the git refs and the commits besides the base commit that our agents are working on. So all of this is in service of just making the environments more robust and more cheat-proof.
But as I mentioned, looking ahead, we want to support an even greater diversity of task corpus. We also want to look into hybrid verification, because if we're able to use LLM as judge or other methodologies, it's possible for us to make our prompts even more terse and even more high level and focus on the objective, rather than prescribing anything onto the agent. There is, of course, a certain degree that we have to, in our current prompts, hint to the agents, steering them toward a current methodology, just because otherwise they may not be well positioned at all to make meaningful progress toward the task.
But something like LLM as judges and hybrid verifiers would potentially help us toward that. And beyond DeepSuite, we're also working on new benchmarks that are in the works. These are, again, focused on the high-value domains that DataCurve reprioritize as being the domains where we want to be most meaningfully advancing model capabilities. But with that said, we're actively hiring both researchers and engineers, helping us with these new benchmarks, new training data pipelines, in service of advancing these capabilities. So definitely reach out at datacurve.ai slash careers.
And yeah, if you're interested about any of this research benchmark or any of our work, come find me after. Thank you very much. Thank you. Thank you. So given that we are targeting long-horizon tasks, naturally this meant that there's less emphasis on bug localization and refactoring. These are obviously very representative of real work that software engineers are doing, underrepresented in our current taxonomy for DeepSuite. And finally, repository pool. We put an emphasis on trying to field as many diverse repositories as possible, keeping the median task per repository to a very low count.
But further work here, just to pull in more repos, more tasks that software engineers find interesting and find them to be good, and maybe also more niche tests of model's performance would also be a great addition here. So we've already released DeepSuite V1.1. So in here, we've taken some additional measures to guard against cheating, reward hacking, by ensuring the verifier runtime is fully separate now from the agent runtime. Also making sure the test reports are in a more standardized format. And also making sure that we've trimmed all of the git refs and the commits besides the base commit that our agents are working on.
So all of this in service of just making the environments more robust and more cheating proof. But as I mentioned, looking ahead, we want to support an even greater diversity of tasks corpus. We also want to look into hybrid verification, because if we're able to use LLM as judge or other methodologies, it's possible for us to make our prompts even more terse and even more high level and focus on the objective, rather than prescribing anything onto the agent. There is, of course, like a certain degree that we have to, in our current prompts, like hint the agents steering them towards a current methodology,
just because otherwise they may not be well positioned at all to make meaningful progress towards the task. But something like LLM as judges and hybrid verifiers would potentially help us towards that. And beyond DeepSuite, we're also working on new benchmarks that are in the works. These are, again, focused on the high value domains that DataCurve reprioritize. As being the domains where we want to be most meaningfully advancing model capabilities. But with that said, we're actively hiring both researchers, engineers, helping us with these new benchmarks, new trading data pipelines, in service of advancing these capabilities.
So definitely reach out at datacurve.ai slash careers. And yeah, if you're interested about any of this research benchmark or any of our works, come find me after. Thank you very much. Thank you. Thank you.