levi

ence: Code Optimization, and Prompt Optimization (sorry math, you got a less direct path; workable through the code route). The core thesis behind LEVI is that with the right search architecture, smaller models can substitute for or outperform larger ones. This means it’s much more economical to rely on smaller models for most of the work. That’s the entire takeaway. Making this work in practice is a different problem, but if you forget everything else from this post this is the only message I think I’m really trying to convey here. LEVI does it in three ways: 1) Invest in solution diversity from the start and ensure its maintained. We don’t want to converge to the same solution, especially with smaller models in the mix, and rely on large models to pull us out of the basin. 2) Use smarter routing across larger and smaller models (i.e. most mutations don’t require a Claude Opus X) 3) For prompt optimization not every rollout is as important. Build a proxy subset to approximate. I’ve tried LEVI on systems problems (like MoE scheduling or database transaction scheduling) and found that LEVI outperforms existing frameworks on almost every problem I threw at it while consistently using a smaller budget (unto 7x cheaper). For prompt optimization, across problems like IFBench and HotSpotQA, LEVI reaches a similar or better score as GEPA while using less than half the rollouts! Happy to answer any questions or take any suggestions! If there are unexpected or niche domains where this can be applied, I would love to hear. Technical Blog: https://ttanv.github.io/levi/ GitHub: https://github.com/ttanv/levi