We released VeriLoop E2 (27B, Apache-2.0). The design question behind it: should an LLM be allowed to commit its own state?

Disclosure: I’m one of the authors of VeriLoop E2, a 27B model post-trained from Qwen3.8-27B. The weights are Apache-2.0; the harness we evaluate it in is not open source (details at the bottom). This is a release post, but rather than a benchmark dump I want to talk about the design rule we built the model around, because I think it’s the more interesting part. The question came up while we were building long-horizon code and research workflows: When a model proposes a “better” state, what gives that state the right to replace the one we already verified? The obvious answer is “run a verifier.” But that still leaves a state-management problem. Suppose the incumbent’s rank over three protected obligations (0 = satisfied) is r_t = (0, 1, 1) and the model proposes: A = (0, 0, 1) B = (1, 0, 0) C = (0, 1, 1) If you reduce these to a scalar, B can look attractive because the total error count drops from 2 to 1. But B also breaks the first obligation, which was already satisfied. The rule we ended up using in VeriLoop-Governed Recurrence (VGR) is deliberately stricter: commit r'_t only if for every j: r'_t[j] <= r_t[j] and for at least one j: r'_t[j] < r_t[j] So A commits. B and C do not. The model gets proposal authority . The verifier/controller gets persistence authority . That sounds like a small distinction, but it changed how we think about agent state. A rejected candidate is not “mostly accepted” or allowed to leak into the retained state. The retained bundle stays unchanged: artifact controlled state verification result binding / identity metadata The failed proposal can still be used as evidence for the next attempt, but it does not become the new incumbent. This is basically a protected partial order over task state rather than a scalar “looks better” score. --- The part I find more interesting is that the same rule gives you a training signal. For the same incumbent , externally checked candidates can be separated into: strict progress no progress protected regression incomparable zero-rank completion That is a much richer label than “good/bad answer.” A verified strict-progress candidate can become correction supervision. A zero-rank artifact can become a final-generation target. A regressing or incomparable candidate can become a negative example. The verifier itself stays outside the gradient path. Training changes which proposals the model is likely to make; it does not teach the model to self-authorize state transitions. That is the part of VGR we are actually using with VeriLoop E2 . E2 is the model-side reasoner/proposer in the current system: proposal generation, abstraction, diagnosis, route selection, replanning. The external Harness/verifier still owns execution, protected comparison, rollback, and certification. One claim boundary is important here: the current E2 evidence supports the trajectory-supervised realization of VGR. In other words, the model is post-trained from verifier-governed state transitions. That is not the same thing as claiming that the full latent-state VGR operator described in our report is already integrated end-to-end inside the Qwen backbone. A true latent realization needs its own evidence: controlled activation location, decoder/cache consistency, gradient path, and inference traces. We keep those claims separate. --- There are two deterministic properties of the commit rule that I think are useful: Protected non-regression: a committed state cannot worsen any protected coordinate. Finite strict commitment: if the rank coordinates are non-negative integers, each commit reduces their sum by at least 1, so the number of strict commits is bounded by the initial rank sum. But neither property means “the model will solve the task.” If the proposer cannot reach an admissible improvement, the run can stall. And rank zero only means “complete under this verifier contract.” It says nothing beyond the verifier’s coverage. So VGR is not a proof system by itself. It is a rule for deciding what is allowed to persist. --- I’m curious how people here would handle the cases where this rule is too conservative. For example, some real agent tasks may require temporarily breaking one thing to unlock a much better state later. Would you: - keep the protected order hard and force the proposer to find a non-regressing path; - allow temporary regressions inside an isolated sandbox but never commit them; - or make the commit relation probabilistic / budgeted? I’m also interested in where people would place the state boundary in a local agent: token prefix? tool-call result? filesystem snapshot? test-validated patch? entire workspace state? My current bias is to keep persistence rules boring and deterministic, and put the learned complexity into proposal quality. But I’m not convinced that scales to every domain. --- What’s released and what isn’t - Open (Apache-2.0): weights, tokenizer, config, and the public vLLM inference utilities. We validated serving on vLLM 0.17.0 in BF16 at 131K context; the tokenizer’s native max is 262K. - GGUF (official, link below): BF16 down to IQ1_M, with each tier measured against the BF16 GGUF on PPL ratio, KLD and same-top-p. Those are retention numbers, not downstream benchmark reruns. Q6_K (20.6 GiB) is our recommended balance, and MTP heads ship as separate files for optional speculative decoding. - Heads-up on quant names: below Q6_K we keep more tensors at higher precision than standard llama.cpp quants, so our Q4_K_M is 5.84 effective BPW and the three smallest tiers (Q3_K_M, IQ2_S, IQ1_M) all land around 5.4. Compare by file size, not by name. The smallest main file is 16.8 GiB before KV cache, so nothing fully fits on a 16 GB card. - Chat template: use the one that ships with the model; changing role delimiters or tool-call syntax can change behavior. - Hardware we’ve tested: [FILL IN: GPU(s) and tok/s] - Not open: our production VeriLoop Harness. The commit rule above is easy to reproduce around your own verifiers (the formal version is in the report), but our implementation isn’t released. The benchmark numbers on the model card come from our evaluation setup, which uses that harness for agentic tasks where needed, so E2 on its own won’t necessarily reproduce them. Per-task evaluation records are public: huggingface.co/datasets/tsinghua-sigs-robot-lab/VeriLoop-E2-Evaluation-Evidence - Standalone performance: [FILL IN, pick one: “Without the harness, E2 vs. base Qwen3.8-27B: …” OR “We haven’t published standalone numbers yet. If you run it without the harness, I’d like to hear how it does.”] Links: VeriLoop E2: huggingface.co/tsinghua-sigs-robot-lab/VeriLoop-E2 GGUF: huggingface.co/tsinghua-sigs-robot-lab/VeriLoop-E2-GGUF Technical report (the exact formalization, if you want more than my Reddit summary): openreview.net/forum