GEPA: Reflective Prompt Evolution vs Reinforcement Learning

Group Relative Policy Optimization, the reinforcement learning method behind many recent reasoning models, often needs thousands of rollouts to teach an LLM a single new task. GEPA, a prompt optimizer accepted as an oral at ICLR 2026, reaches higher accuracy on six benchmarks while using up to 35x fewer rollouts, and it gets there by rewriting prompts rather than model weights (Agrawal et al., 2025). For anyone deciding how to make an agent more reliable, that reorders what you try first. This piece covers how reflective prompt evolution works, what the numbers actually claim, and when it should replace fine-tuning.

Key takeaways

GEPA (Genetic-Pareto) outperforms GRPO by 6% on average and by up to 20% across six tasks, using up to 35x fewer rollouts, per the ICLR 2026 paper.
It also beats MIPROv2, the prior leading DSPy prompt optimizer, by more than 10%, including a 12% accuracy gain on AIME 2025.
The optimizer learns by reflecting on execution traces in natural language, then evolving a Pareto frontier of candidate prompts, instead of following a scalar reward gradient.
Decagon's production study found 20 to 100 training examples beat 500, and a 1,500-character prompt cap delivered 4x compression for a 0.8% accuracy loss.
The reflection model has to be a frontier LLM; smaller models like GPT-4o-mini fail the diagnosis step, yet reflection accounts for only 5%-10% of total optimization cost.
GEPA changes no weights, so an optimized prompt ports across model versions but cannot add a capability the base model lacks.

What problem does GEPA solve for teams tuning agents?

GEPA gives you a way to raise an agent's accuracy without an RL training loop, by treating the prompt itself as the thing to optimize. The team behind it, led by Lakshya A. Agrawal with co-authors from the DSPy group, start from a simple argument: natural language is a richer learning signal than a sparse scalar reward.

Reinforcement learning methods like GRPO derive their updates from a single number per rollout, which is why they need so many. A failed trajectory tells the model almost nothing about why it failed. GEPA reads the same trajectory in words, names the mistake, and proposes a concrete edit.

The practical consequence is that the cheapest and most portable lever, the prompt, becomes the first one you pull, while you keep the option to fine-tune later if the ceiling really is the model.

How does reflective prompt evolution actually work?

GEPA runs your system on a handful of examples and captures the full trajectory: the model's reasoning, its tool calls, the tool outputs, and the evaluator's feedback. A separate reflection model then reads one of those traces, diagnoses what went wrong in plain language, and writes a revised prompt aimed at that specific failure.

The evolution part matters. Rather than keeping only the single best prompt by average score, GEPA maintains a Pareto frontier of candidates, prompts that each win on a different slice of the data. It samples parents from that frontier and merges their complementary lessons, which is where the "genetic" in Genetic-Pareto comes from.

Because each round works from written feedback, one informative failure can produce a targeted fix instead of a faint gradient nudge. That also shifts a design burden onto you. The quality of your evaluator's textual feedback now shapes results as much as the model does, and a metric that returns only pass or fail starves the reflection step.

How much better is GEPA than GRPO and MIPROv2?

Across six tasks, including HotpotQA, IFBench, HoVer, and AIME 2025, GEPA beat GRPO by 6% on average and by as much as 20%, while spending up to 35x fewer rollouts. The reported runs used Qwen3-8B as the target model and GPT-4.1 as the reflection model.

Against MIPROv2, the strongest prior DSPy optimizer, GEPA gained more than 10% overall and 12% on AIME 2025. The table below sets the three approaches side by side.

Method	How it learns	Reported result	Rollout cost
GEPA	Natural-language reflection on traces, Pareto evolution of prompts	Baseline for this comparison	Lowest; up to 35x fewer than GRPO
GRPO	Policy-gradient RL from scalar rewards, updates weights	6% lower on average, up to 20% lower than GEPA	Highest; thousands of rollouts
MIPROv2	Bayesian search over instructions and few-shot demos	More than 10% lower than GEPA; 12% on AIME 2025	Moderate

Two caveats keep this honest. These are the authors' own benchmarks, and a 6% average with a wide spread means the gain is task-dependent, not guaranteed. The result to internalize is directional: on tasks where the base model can already do the work, reflection converts a few rollouts into most of the win that RL would take thousands to find.

When should you reach for GEPA instead of fine-tuning?

Reach for prompt optimization first whenever the base model can plausibly do the task but does it inconsistently. That describes most agent reliability problems in practice: the model has the capability, and the job is to elicit it reliably. GEPA fits when you have a checkable metric, a limited RL budget, and a need to survive model upgrades without retraining.

Fine-tuning earns its cost in the opposite cases. If the base model genuinely lacks a skill, if the prompt is already long and saturated, or if a latency budget rules out a large instruction block, a weight-level method such as reinforcement fine-tuning becomes the right tool. I've written separately on when reinforcement fine-tuning an agent beats prompting, and GEPA is the natural thing to exhaust first.

The trade-off is concrete. Prompt optimization ports cleanly and costs little, but it inherits the base model's ceiling. Fine-tuning can lift that ceiling, at the price of an RL pipeline, a training budget, and a model artifact you re-tune every time you upgrade.

What does it take to run GEPA in production?

Running GEPA well is closer to test-driven engineering than to prompt tinkering, and a production study from Decagon spells out the specifics. Their strongest single finding: small, curated training sets of 20 to 100 examples consistently beat runs on 500 samples, because a tight set keeps the optimizer from encoding noise.

A few rules earn their place:

Give the metric a voice. The evaluator should return text that explains the failure, not just a score. That feedback is what the reflection model reasons over.
Use a frontier reflection model. Decagon found GPT-4o-mini could not perform the diagnosis step at all, while stronger models could. Reflection is only 5%-10% of total optimization cost, so this is a cheap place to spend.
Cap prompt length. A 1,500-character limit acted as regularization, giving 4x compression for a 0.8% accuracy loss and blocking the slow bloat that overfits training edge cases.
Judge on a fixed holdout. Track generalization on data the optimizer never sees, not training accuracy, so you catch overfitting before it ships.

Structured extraction is a good first target, since predictor-level feedback maps directly onto the fields a schema requires. If you already validate model output against a schema, you have most of the feedback signal GEPA needs. See getting reliable JSON from an LLM with structured outputs for how that validation layer is built.

Where does GEPA fall short, and what should you watch?

The clearest limit is that GEPA optimizes prompts, not weights, so it can never teach the model a capability it lacks. When accuracy plateaus well below your target and the failures look like missing knowledge rather than sloppy elicitation, more reflection won't help, and that plateau is your signal to consider fine-tuning.

Three failure modes deserve active monitoring:

Prompt bloat. Left unconstrained, the optimizer grows prompts past 5,000 characters by memorizing edge cases. That inflates per-call tokens and latency, so the run that raised accuracy can quietly raise your bill. Cap length and watch cost per call.
Gameable metrics. Reflection is only as good as the feedback it reads. A weak or exploitable evaluator produces confident, wrong prompts, which is why metric design, and honest reliability measurement, is the real work. My notes on measuring agent reliability beyond pass@1 apply directly here.
Fixed system boundaries. GEPA improves the prompts inside the system you hand it. A poor task decomposition or a missing tool won't be fixed by a better instruction, and no optimizer will tell you the architecture is the problem.

There's also a reproducibility wrinkle. Results depend on the reflection model, and swapping it changes the prompts you get, so pin the reflection model and version the optimized prompt like any other build artifact. Good evaluation discipline, the kind you'd apply with an eval harness like Promptfoo, is what keeps a GEPA run from producing a prompt that looks better and generalizes worse.