The expense of context
Managing the expense of a proof-search agent by inspecting only the length of its final answer is difficult. The LEVER preprint compares proof searches using the same DeepSeek-V4-Flash-0731 model. On 80 Putnam problems reserved for evaluation, LEVER solves 96.3%, against 80% for the comparison method. Under the same pricing calculation, average expense is 0.95 dollars versus 1.44 dollars. Attempts have a budget of 3 dollars and failures are charged the full budget. These are research results on selected mathematics problems.[1]
The interesting detail is that LEVER produces more output tokens while consuming fewer input tokens. The authors reprice expense assuming a 90% cache hit rate and include planning calls. Efficiency here therefore does not mean shortening the reasoning text. My inference is that repeatedly transporting history becomes a significant architectural budget choice. An alternative explanation is that the selected problem set and cache pricing favor the method’s strengths; this difference cannot simply be extended to every coding task.[1]
LEVER builds an AND/OR graph that decomposes proofs into subgoals. A node can require several conditions together or allow one of several alternative routes. Values from completed partial proofs influence search. Each new call sees context from local parent nodes instead of the entire history. This connects decomposition with budget: splitting the task also changes the context that subsequent steps must carry.[1]
Accepting the assembled pieces
The useful feature is that Lean can check the assembled proof. Solving subgoals separately is insufficient; their combined proof must be valid. The checker supplies a concrete acceptance criterion that permits experimentation with search structure. For software builders, my interpretation is to define how the pieces are accepted together before increasing the number of agent components. Which tests can fill the mathematical checker’s role in an ordinary coding task is an equally significant design question.[1]
Local context also has a trade-off: dependencies between distant subgoals need an adequate representation. LEVER’s graph is designed for proof search, so I do not infer automatic success for general-purpose agents. The narrow scope does not diminish its usefulness. A fixed model, a defined budget and an explicit correctness check instead make it easier to discuss what an architectural change actually affects.[1]
The comparison I would examine holds the model and prices fixed on the same tasks, then runs full history and local context separately. As an observable signal, accepted completed work, input expense and the budget consumed by failures should be visible together. This directly tests the expense of transporting context without treating a shorter answer as success. LEVER’s concrete contribution is to turn a different division of work around the same model into a measurable engineering question.[1]