For years, the machine learning community has operated under a simple assumption: if you want a better model, give it more data. This logic has driven the field from ImageNet to GPT-4, and it's not wrong—at scale, more data has consistently produced better results. But there's a catch that researchers are starting to hit across domains: not all data is created equal.
This is especially true when training AI agents on complex, multi-step tasks. Unlike training a classifier on static images, training an agent involves trajectories—the full sequences of actions, observations, and outcomes that occur as the agent attempts a task. And here's the uncomfortable truth: most trajectories are bad.
SWE-Prime challenges the "more is better" mantra by doing something that sounds almost wrong: it throws away most of your training data. Specifically, it filters trajectories down to a small subset of "prime" examples—those that are successful, efficient, and diverse—and trains exclusively on them.
The results are striking. Models trained on just 20% of available trajectories consistently match or exceed models trained on 100%. On SWE-bench, a benchmark for real-world software engineering tasks, SWE-Prime achieves a 12% relative improvement in pass@1 over baseline methods that use everything. It also cuts training costs by roughly 80%.
This explainer walks through what trajectories are, why using all of them is a problem, how SWE-Prime selects its prime subset, and what the evidence actually shows. We'll also address common misconceptions and answer the questions practitioners are asking. By the end, you'll understand why data quality is becoming the new frontier in AI agent training—and how to apply this thinking to your own work.
A trajectory is a complete record of an agent's attempt at a task. For a software engineering agent, this means:
Think of it as a transcript of everything the agent did, from start to finish. When you train an agent, you're essentially teaching it to imitate good trajectories and avoid bad ones. The problem is that most datasets contain a mix of both—and often, the bad ones outnumber the good.
SWE-bench has become the standard testbed for evaluating AI agents that fix bugs and implement features in real codebases. It uses actual issues from popular open-source Python projects like Django, SymPy, and scikit-learn. Each task presents the agent with a repository state and an issue description; the agent must produce a patch that passes hidden tests.
What makes SWE-bench particularly useful is that it's real. These aren't toy problems or synthetic tasks. The issues are messy, the codebases are large, and the solutions require genuine reasoning. This makes it an ideal environment for testing whether a training method actually works in practice.
When evaluating SWE agents, two metrics dominate:
SWE-Prime improves both metrics, but the pass@1 improvement is particularly notable because it indicates that the agent is not just getting lucky with random sampling—it's actually better at solving problems.
Here's the key insight that SWE-Prime builds on: when you train an agent, you're shaping its behavior. Every trajectory you feed it teaches something. But here's what most people miss:
The quality of the signal matters more than the quantity of the data.
A single trajectory that demonstrates a clean, efficient, correct solution teaches more than a hundred trajectories that meander, fail, and recover through luck. SWE-Prime operationalizes this insight into a concrete method.
Key Takeaway: Trajectories are the training currency for AI agents. But most trajectories in any dataset are noisy, redundant, or simply bad. Quality beats quantity.
When an agent runs on a task, it often fails. It makes wrong edits, runs commands that error out, and produces patches that don't pass tests. Yet many training pipelines include these failed trajectories anyway—sometimes because researchers don't filter, sometimes because they think the agent can learn from mistakes.
The problem is that agents learn from all the data you give them. If you train on a trajectory where the agent flails for 50 steps before accidentally fixing a bug, the agent learns that flailing is acceptable. If you train on a trajectory where the agent gives up, the agent learns that giving up is an option.
SWE-Prime's stance is clear: failed and noisy trajectories actively hurt performance. They teach the agent bad habits that must be unlearned later.
Even among successful trajectories, there's a redundancy problem. If 80% of your successful trajectories involve fixing the same type of bug (say, a missing import statement), your agent will become excellent at that one bug type and terrible at everything else.
Diversity matters. A dataset with 50 diverse, successful trajectories is more valuable than a dataset with 500 successful trajectories all covering the same narrow slice of tasks. SWE-Prime explicitly optimizes for this diversity during selection.
This is the practical problem that most practitioners feel first. Training on 10,000 trajectories takes roughly 10 times longer than training on 1,000. That means more GPU hours, more electricity, more time waiting for experiments to finish.
When you consider that most of those 10,000 trajectories are redundant or low-quality, you're paying a massive computational premium for worse results. SWE-Prime reduces the dataset size by 80%, which means you get better performance and significantly lower training costs.
The "more data" heuristic works when data is independent and identically distributed—like random images downloaded from the internet. But trajectories are not independent. They're generated by the agent itself, which means they reflect the agent's current strengths and weaknesses.
If your agent is bad at a certain type of task, it will generate bad trajectories for that task. Adding those bad trajectories to the training set reinforces the bad behavior. This creates a feedback loop where more data makes the agent worse at the things it already struggles with.
Key Takeaway: Training on all trajectories is not just wasteful—it's actively harmful. Noise and redundancy teach bad habits, and the computational cost is enormous.
SWE-Prime's name isn't just marketing. The method selects trajectories that are "prime" in the mathematical sense: fundamental, indivisible, and irreplaceable. Each selected trajectory should be the best example of its kind, and the set as a whole should cover the full space of tasks without unnecessary overlap.
This is a fundamentally different philosophy from "train on everything." Instead of asking "what data do I have?", SWE-Prime asks "what data do I need?"
SWE-Prime uses three criteria to evaluate each trajectory:
Success: Did the agent actually solve the task? This is the most basic filter. Failed trajectories are almost always excluded.
Efficiency: How many steps did the agent take? A trajectory that solves the task in 10 steps is more valuable than one that solves it in 50 steps—even if both succeed. Efficient trajectories teach the agent to be direct and decisive.
Diversity: Does this trajectory cover a task type that's already represented? If you already have 10 trajectories for "fixing import errors," the 11th adds almost nothing. SWE-Prime ensures each selected trajectory covers new ground.
The SWE-Prime selection process works like this:
Generate a large set of trajectories by running your agent on a diverse set of tasks. This is the raw material—the full dataset.
Filter by success: Remove all trajectories where the agent failed. This typically eliminates 50-70% of the data.
Score by efficiency: Among successful trajectories, rank by number of steps taken. Shorter is better, but with a caveat—extremely short trajectories might indicate the task was trivial, so there's a minimum threshold.
Cluster by task similarity: Group trajectories by the type of task they solve. This can be done using code embeddings, repository structure, or simple category labels.
Select the best from each cluster: From each cluster, pick the most efficient successful trajectory. If a cluster has multiple similar trajectories, keep only the best one or two.
Balance the final set: Ensure the selected trajectories cover all task types and programming languages proportionally. Prevent bias toward any single category.
The result is a small, high-quality training set—typically 15-25% of the original dataset—that contains the most instructive examples available.
SWE-Prime is related to data pruning and curriculum learning, but it's not the same thing:
Data pruning typically removes low-quality examples from a static dataset. SWE-Prime does this, but it also actively selects for diversity and efficiency, not just quality.
Curriculum learning orders training examples from easy to hard. SWE-Prime doesn't order—it selects. The chosen trajectories are trained on in a standard order.
Active learning involves the model choosing what to learn next. SWE-Prime is a one-time offline selection process that happens before training.
SWE-Prime is best described as quality-focused trajectory selection with diversity constraints.
Key Takeaway: SWE-Prime is a selection method, not a training method. It filters, scores, and curates trajectories before training begins. The result is a smaller, better dataset.
The most direct evidence for SWE-Prime comes from experiments on SWE-bench. When comparing models trained on all available trajectories versus models trained on SWE-Prime's selected subset:
These improvements are consistent across different model architectures, including GPT-4-based agents and smaller open-source models.
The efficiency gains are dramatic. By using only 20% of the original trajectories, SWE-Prime reduces training time and compute by approximately 80%.
To put this in concrete terms: if your original training run took 100 GPU-hours, SWE-Prime brings it down to 20 GPU-hours. And you get better performance. This is the rare case where you can have your cake and eat it too.
SWE-Prime has been compared against several baselines:
While SWE-bench is the primary testbed, SWE-Prime's principles apply to other agent benchmarks. Early experiments on code generation tasks and multi-language repositories show similar patterns: quality and diversity beat raw quantity.
The method is architecture-agnostic. It works for any agent that generates trajectories during exploration, regardless of the underlying model.
Key Takeaway: The evidence is clear: SWE-Prime improves performance, reduces cost, and generalizes across tasks and architectures.
If you're training SWE agents, SWE-Prime offers immediate practical benefits:
SWE-Prime is designed to be a drop-in addition to existing pipelines. The selection process happens once, offline, before training. You don't need to modify your model architecture or change your training loop.
The typical integration looks like:
That's it. No new infrastructure, no complex changes.
SWE-Prime isn't a silver bullet. Some limitations to be aware of:
SWE-Prime opens up several research directions:
Key Takeaway: SWE-Prime is practical and easy to integrate, but it requires enough initial data and a reasonable task similarity measure.
This is the most persistent myth in machine learning. It's true for some domains (especially with massive models), but it's not a universal law. For agent training, where data is generated by the agent itself, more data often means more reinforcement of bad behavior.
They're not. A trajectory where the agent solves a task in 5 clean steps is fundamentally more valuable than one where it stumbles through 40 steps. A trajectory that solves a rare task type is more valuable than a duplicate of a common one. SWE-Prime quantifies this intuition.
It's not. SWE-Prime doesn't change the model, the training algorithm, or the inference procedure. It's purely a data selection method. You can apply it to any agent architecture.
Actually, SWE-Prime works best when you have a surplus of data—because it can select the best examples. But it doesn't require massive datasets. Even with a few hundred trajectories, the selection process can yield benefits.
SWE-Prime works with any training paradigm that uses trajectories as training data—including supervised fine-tuning on expert demonstrations, imitation learning, and reinforcement learning. The selection process is agnostic to how you train afterward.
Key Takeaway: SWE-Prime is a data selection method, not a model or training algorithm. It's broadly applicable and doesn't require massive datasets.
SWE-Prime is a trajectory selection method for training software engineering agents. It filters a large set of agent trajectories down to a small subset of "prime" examples—those that are successful, efficient, and diverse—and trains exclusively on that subset. This improves performance while reducing training cost.
Because most trajectories in any agent-generated dataset are noisy, redundant, or low-quality. Training on them teaches the agent bad habits. By selecting only the best examples, SWE-Prime provides a cleaner, stronger training signal.
It uses three criteria: success (the agent solved the task), efficiency (the solution used few steps), and diversity (the trajectory covers a task type not already represented). Trajectories are filtered, scored, clustered, and then selected to maximize coverage.
No. SWE-Prime is architecture-agnostic. It works with GPT-4-based agents, open-source models, and any other agent that generates trajectories through interaction.
Three main benefits: better performance (12% improvement in pass@1 on SWE-bench), lower training cost (80% reduction in compute), and faster iteration (shorter training runs mean more experiments per day).
The principles apply broadly to any agent benchmark where trajectories are used for training. Early experiments on other code-related benchmarks show similar benefits.
SWE-Prime outperforms random selection and simple success-only filtering. The diversity constraint is a key differentiator—it ensures the selected trajectories cover the full range of tasks.
It requires a reasonable way to measure task similarity, and it needs enough initial data to select from. For very small datasets, the benefits may be limited.
Yes. SWE-Prime is orthogonal to other techniques like curriculum learning, reinforcement learning, or data augmentation. You can use it as a preprocessing step before any training method.
The original paper provides full experimental details. Additional resources include the code repository (if publicly released) and community discussions in ML forums.
SWE-Prime overturns a deeply held assumption in AI training: that more data is always better. By carefully selecting a small subset of high-quality, diverse trajectories, it achieves:
The method is simple to understand, easy to implement, and broadly applicable.
SWE-Prime is part of a larger movement in AI research away from "just add more data" and toward "add the right data." This data-centric approach recognizes that the quality of training data is often the binding constraint on model performance—not model architecture or training algorithm.
This shift has practical implications: paying attention to your data curation process can yield bigger gains than upgrading your model. And it's a shift that's accessible to everyone, not just researchers at large labs.
If you're training software engineering agents, try SWE-Prime in your own pipeline. The implementation is straightforward: filter by success, score by efficiency, cluster by task type, and select the best from each cluster. You might be surprised at how much better your agent performs with less data.
Ready to improve your AI agent's performance with fewer data? Dive deeper into SWE-Prime and start experimenting with trajectory selection in your own projects today!