DSPy Lets GEPA Rewrite a Module's Code

DSPy 3.3.0 shipped August 3 with an experimental mode called Flex that lets its GEPA optimizer rewrite a module's code, per the release notes.

That matters because GEPA-authored code now runs without a person reviewing it first. The only guardrails are a CodeInterpreter sandbox and a hard cap called max_predictor_calls, meant to stop a rewritten program from running away with LM calls.

Until now, GEPA could only reword a module's prompts. It couldn't touch how the program was built. Flex changes that. Given a signature, GEPA can rewrite predictors and control flow, judged against whatever metric you set. It can also shift how much of the program runs as Python versus LM calls.

The optimizer's code changes aren't thrown away after a scoring run. DSPy saves the winning structure as module_src alongside the rest of the program state. A decomposition GEPA finds during optimization survives a save and reload.

The same release adds dspy.ReActV2, a rebuild of DSPy's agent loop for native tool calling. It replaces the old flat trajectory string with dspy.History message groups. DSPy reports cost cuts up to 50%, from better reuse of cached prompt prefixes.

Flex won't earn trust until someone publishes a GEPA-discovered program structure that beats a hand-written one on cost or accuracy, outside DSPy's own benchmarks.

Both features shipped in the same DSPy 3.3.0 release, on August 3.