VeriLoop E2 – A 27B Post-training Model Open-sourced by Tsinghua University

1. What is VeriLoop E2

VeriLoop E2 is a 27B post-training model open-sourced by the Robotics Lab at the Shenzhen International Graduate School of Tsinghua University. It is built upon the Qwen3.8-27B base model and is specifically designed for code, mathematical, and physics reasoning scenarios. The model's weights and tokenizer are released under the Apache-2.0 license, and it natively supports a context window of up to 262,144 tokens. Its core innovation lies in the VGR (VeriLoop-Governed Recurrence) mechanism, which completely separates "model proposal" from "external verification/persistence." Candidate states are only atomically submitted when the protected evidence coordinates do not degrade and there is at least one strict improvement; otherwise, a full rollback occurs, eliminating the possibility of the model self-verifying its success at the mechanism level.

Technical positioning and domain: Belongs to the field of large language model post-training and verifiable reasoning, focusing on three high-difficulty tasks: code agents, mathematical reasoning, and scientific computing. Unlike traditional RLHF or SFT post-training paradigms, VeriLoop E2 models task-solving as a state transition process on a protected state machine, ensuring that model behavior is strictly constrained by an external verifier. This opens up a niche track for "verifiable intelligence" within open-source models.

Development background: Developed by the Robotics Lab at Tsinghua University's Shenzhen International Graduate School, a team with long-term expertise in robotic control, embodied intelligence, and formal verification. VeriLoop E2 is an extension and evolution of its previous work, VeriLoop Coder-E1, expanding from a single code generation scenario to a cross-domain, auditable general reasoning framework. This reflects the team's ongoing exploration of the core issue of "AI system reliability."

Core value: Addresses two major pain points in large models for long-cycle tasks: "self-verification of success" and "inauditability." Traditional models often lack external verification mechanisms in code fixing or mathematical reasoning, leading to error accumulation and difficulty in tracing. VeriLoop E2 introduces protected partial order and atomic submission semantics through the VGR mechanism, ensuring that every state update is strictly validated by an external verifier, making each step of the model's progress traceable, rollable back, and replayable.

Technical features: Utilizes 1,841,831 structured post-training records, combining paired preference logistic terms, action NLL, and generation NLL into a multi-objective loss function. It is trained using QLoRA-4/bfloat16 quantization and a routing strategy based on capability dimensions. Nine benchmark frozen scores are published, including 76.2% on SWE-bench Pro, 98.3% on AIME 2026, and 93.9% on GPQA Diamond, along with an auditable evaluation evidence package.

2. Key Features

• VGR Protected State Transition Mechanism: The core innovation lies in modeling task solving as a candidate state transition process. The model acts as a proposer, generating candidate latent displacement, while a fixed decoder materializes it into output. An external verifier returns the protected evidence rank under a fixed contract. The candidate rank is only atomically committed if it weakly dominates the current rank and strictly improves in at least one coordinate; otherwise, the current bundle is fully retained, eliminating from an algorithmic perspective the possibility of aggregated scores masking single-point regressions.

• Code and Agent Capabilities: Covers tasks such as repository-level software repair and terminal/tool execution, achieving 76.2% on SWE-bench Pro, 88.8% on Terminal-Bench 2.1, and 64.6% on DeepSWE v1.1. The model can generate patches, diagnose regressions, and decide whether to retain modifications based on external testing/evaluation, making it suitable for maintenance scenarios where modifications must be verifiable.

• Math and Science Reasoning: Designed for competition mathematics and high-difficulty science questions, achieving 98.3% on AIME 2026, 100% on ArXivMath, 93.9% on GPQA Diamond, and 89.6% on Apex 2025. After multiple rounds of sampling, external judgment determines whether to retain reproducible solutions, reducing the randomness of relying on a single answer. This is ideal for mathematical tasks requiring rigorous derivation chains.

• Evidence-Closed Scientific Demonstration: Publishes a strict finite-dimensional certificate with 67.350003708785593% of the Riemann ζ zeros, along with the asymptotic graviton tomography T1–T9 framework and an executable certificate suite that passed all 6/6 tests. These artifacts demonstrate the model's practical ability to assist in proposing constructions and identifying gaps in proofs within theoretical physics and mathematical research.

• Auditable Engineering Contracts: Publishes 14 Golden Rules that constrain long-term tasks to remain bounded, testable, and traceable. It explicitly prohibits fabricating success, post-hoc resource budgeting, or overriding local agreements. Evidence packages are bound to task-specific identity, output, native execution/evaluation logs, pass/fail status, and integrity metadata, enabling full auditability of model behavior throughout.

• Long Context and Open Service: Natively supports a context window of up to 262,144 tokens, with model weights released under the Apache-2.0 license. Provides an OpenAI-compatible service endpoint validated by vLLM 0.17.0, with a publicly verified service length of 131,072 tokens. Developers can quickly integrate using standard OpenAI protocols.

3. How to Use

1. Obtain the Model: Pull tsinghua-sigs-robot-lab/VeriLoop-E2 from Hugging Face, keeping the tokenizer, chat template, and configuration files provided in the repository. Do not replace or modify these components on your own.

2. Set Up the Environment: Install Python 3.12.x, PyTorch 2.10.0 + CUDA 12.9, Transformers 4.57.6, and Triton 3.6.0. Run python -m pip install "vllm==0.17.0" to install the inference engine.

3. Start the Service: Execute VLLM_USE_MODELSCOPE=true vllm serve <MODEL_PATH_OR_HF_ID> --served-model-name veriloop-e2 --dtype bfloat16 --model-impl vllm --language-model-only --max-model-len 131072 --max-num-seqs 16 --gpu-memory-utilization 0.92 --generation-config vllm --host 127.0.0.1 --port 8001. Note that --max-model-len is set to 131072, which is the maximum length limit for the public verification service.

4. Perform a Smoke Test First: Send a small request with temperature: 0 to http://127.0.0.1:8001/v1/chat/completions, and confirm that the response is 8001_OK before routing actual traffic. This helps prevent configuration errors from affecting the production environment.

5. Call According to the OpenAI Protocol: Use the /v1/chat/completions endpoint with model="veriloop-e2". On the Python side, create a client using OpenAI(base_url="http://127.0.0.1:8001/v1", api_key="EMPTY") to seamlessly integrate with existing applications.

6. Treat the Template as Part of the Protocol: Do not replace the role separator, tool calling syntax, stop semantics, or the format of the inference history. Even if the weights remain unchanged, modifying the template may alter tool usage and system behavior.

7. Plan for Long Context Resources: The tokenizer natively supports up to 262,144 tokens, but the public verification service limits the context length to 131,072 tokens. For longer context windows, you must independently evaluate the GPU memory and KV cache usage.

8. Differentiate Model and Harness Permissions: E2 is responsible only for proposing, abstracting, diagnosing, and repairing. Evidence acceptance, deterministic checks, commit/rollback, termination, and persistence should be implemented by your own verifier/Harness. In production environments, you must build your own verification loop independently.

4. Pros and Cons Analysis

5. Comparative Analysis with Similar Tools

Selection Recommendations: For long-term tasks requiring strict verifiability (such as repository-level code repair or scientific computing assistance), VeriLoop E2's VGR mechanism provides unique protected state transition semantics, making it suitable for teams with strict requirements for system trustworthiness. Its evaluation evidence package and Golden Rules significantly reduce audit costs, but the Harness layer must be built internally. If only general-purpose code generation is needed and external verification is not required, specialized code models such as Qwen3.8-27B base or DeepSeek-Coder-V2 offer greater advantages in deployment simplicity and ecosystem maturity. VeriLoop Coder-E1 is ideal for developers already familiar with the evidence governance paradigm who wish to iterate upon previous frameworks.

6. Editor's Summary

The release of VeriLoop E2 marks a significant shift in post-training for open-source large models, moving from a focus on "pursuing scores" to "pursuing verifiability." Its VGR mechanism models task solving as a state transition process on a protected state machine, ensuring the audibility and rollback capability of model behavior through protected partial order and atomic commit semantics. This design demonstrates clear technical innovation: it no longer relies on model self-assessment or improvements in aggregated scores to determine progress, but instead requires each state update to pass rigorous validation by an external verifier and meet submission criteria that ensure no coordinate degradation and at least one strict improvement. With 1,841,831 structured post-training records and a multi-objective loss design, the model internalizes the judgment standard of "which actions constitute strict progress," rather than merely fitting the final answer.

In terms of practical value, VeriLoop E2's performance on nine benchmarks, including SWE-bench Pro, AIME 2026, and GPQA Diamond, demonstrates its cross-domain capabilities. The release of evaluation evidence packages and 14 Golden Rules provides engineering teams with an actionable audit framework. The model weights are released under the Apache-2.0 license, and combined with the OpenAI-compatible service path provided by vLLM 0.17.0, it reduces integration barriers. The primary users include: software engineering teams requiring a strict verification loop, researchers in mathematics and theoretical physics, and enterprise developers with hard requirements for the trustworthiness of AI systems. It is important to note that the production version of Harness is not open-sourced, and scientific achievements cannot be extrapolated to imply that related conjectures have been resolved; these boundaries must be strictly defined in practical applications. As the paradigm of verifiable reasoning continues to evolve, the "model proposal—external verification—atomic commit" framework established by VeriLoop E2 may provide a new reference point for the post-training design of future open-source models.

7. Application Scenarios

• Warehouse-level Code Repair: Used in SWE tasks to generate patches, diagnose regressions, and determine whether to retain them based on testing/evaluator results. The model is responsible for proposing and fixing issues, while an external validator performs tests and returns evidence ranks. Only modifications that pass validation are submitted, making it suitable for maintenance scenarios where "modifications must be verifiable," significantly reducing the risk of regression.

• Terminal and Tool Agents: Executes commands, calls tools, and triggers the next step based on evidence in Terminal-Bench-like environments. The model generates a sequence of operations, and an external verifier controls whether to proceed using pass/fail credentials, ensuring that every operation is traceable and verifiable. This is ideal for automated operations scenarios requiring strict operational auditing.

• Mathematical Reasoning and Competition Problem Solving: Designed for high-level derivations in AIME/ArXivMath-like problems, retaining reproducible solutions through external judgment after multiple rounds of sampling. The model proposes proof paths, and the verifier checks the validity of each derivation step, reducing the chance of relying on a single answer. This is suitable for mathematical research scenarios requiring rigorous derivation chains.

• Scientific Computing and Theoretical Physics Exploration: Assists in proposing constructions and identifying gaps in proofs during research on topics such as the Riemann ζ function, quantum field theory, and asymptotic gravitons. The model generates candidate constructions, and an external certification suite verifies their validity. The released T1–T9 framework demonstrates its potential as a "verifiable assistant" in theoretical physics research.

8. FAQ

Q: What is the core difference between VeriLoop E2 and VeriLoop Coder-E1?
A: E1 focuses on code generation and software engineering repair, with its verification mechanism operating in a system-coupled loop manner; E2 extends the VGR framework to multiple domains, including code, mathematics, and scientific reasoning, abstracting verification rules into protected state machines. It uses 1,841,831 structured records for post-training, elevating "verifiability" from engineering practice to an internalized behavioral guideline within the model.

Q: What is the actual context window size for VeriLoop E2?
A: The tokenizer's native limit is 262,144 tokens, but the publicly available verification service operates with a length of 131,072 tokens. If a longer window is required, users must independently evaluate the GPU memory and KV cache usage. The official service does not support verification beyond 131,072 tokens.

Q: How can the verification mechanism of VeriLoop E2 be used in production environments?
A: E2 is responsible only for proposing, abstracting, diagnosing, and repairing; the acceptance of evidence, deterministic checks, commit/rollback, termination, and persistence must be implemented by the user's own verifier/Harness. The production version of VeriLoop Harness is not open-sourced, and users must build their own verification loop based on the 14 Golden Rules.

Q: What is the difference in licensing between model weights and scientific artifacts (such as Riemann ζ certificates)?
A: Model weights are licensed under the Apache-2.0 protocol; scientific artifacts are separately licensed from the model. The report explicitly states that results cannot be extrapolated to imply that the Riemann Hypothesis or the black hole information paradox have been resolved. Users must be careful to distinguish the licensing boundaries of these two types of resources.

Q: Can VeriLoop E2 be directly used in commercial projects?
A: Yes. The model weights are licensed under the Apache-2.0 protocol, allowing commercial use and modification. However, the production version of Harness, private orchestration, and training data are not included in the released content. Commercial deployment requires users to independently implement the verification layer and comply with the separate licensing terms for scientific artifacts.

Q: How can the benchmark scores in the report be reproduced?
A: The official has released an evaluation evidence package, which includes task-bound identities, outputs, native execution/evaluation records, pass/fail status, and integrity metadata. It is recommended to use vLLM 0.17.0 and configure the service with the official launch parameters. Other inference engines or versions may not fully reproduce the performance metrics presented in the report.

9. Project Links

• Hugging Face Model Library: https://huggingface.co/tsinghua-sigs-robot-lab/VeriLoop-E2
• Technical Paper: https://openreview.net/pdf?id=P6FIQILHwX