behaviors. Um so moving on to the tasks right the the methodology behind Deep Suite um we made a decision to want to have every task authored uh from scratch uh rather than being mined. Um aside from the uh issues with contamination that we mentioned previously. Um this also plays into uh one of our core strengths which is that we offer a bespoke platform where we have um software engineers, machine learning enthusiasts come on and create these challenges and compete against one another. Um this platform is like shipped and or sorry this platform is called shipped 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. Um, and we're really looking for enthusiasts. So, these are oftent times 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 have very thorough understandings of the repositories 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 uh this is an actual PR that you might see getting merged into the repositories. Um another uh very important design decision is we try as much as possible to make our prompts read like real tasks. On average, the average prompt uh characters within SweetBench Pro is over 4,500 characters, whereas for us, it's uh roughly half of that. And it's this is important because when you're prompting say a junior engineer or you're prompting a model to solve a very uh high ceiling ambiguous task, you're not going to be coming in there with a to-do list uh telling it to oh first do this and then do this and then write this function signature in exactly uh this way that I've prescribed on to you. oftentimes you're going to give it the high level objective, get it to explore and get it to reason about to uh the list of to-dos and ultimately to the solution on its own. Um so this was not the case in SweetBench Pro. It's very overly verbose and trying to prescribe a certain solution method onto agents. Um, as much as we could, we try and make Deep Suite prompts as tur and as uh high level as possible. Um, mirroring what you might see in the real world if you were to prompt, say, another another engineer or one of your agents to go and solve an engineering task. Um, 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 Sweetbench Pros, we find that the average size of our solution is five times the lines of code um compared to Sweepbench Pros. Um we also verified that uh there are on average seven files being touched in the agents solution. Um and across the course of a roll out we have two times more output tokens being emitted. Um