VeriLoop Coder-E1 Quantization Acknowledgement and Invitation to VeriLoop Coder-E2
Dear Rodrigo,
I wanted to personally thank you for your work on the GGUF quantization of VeriLoop Coder-E1.
It has been a genuine pleasure to cross paths with you through the open-source community. Your work has made VeriLoop Coder-E1 considerably more accessible to users running local inference stacks, and we sincerely appreciate the engineering effort behind it. We were also very happy—and genuinely proud—to see your quantized release receive such encouraging download numbers. To us, this is one of the most meaningful parts of open source: an independently developed model can continue to evolve through the work of contributors we had never met before.
We have now formally decided on the direction of VeriLoop Coder-E2. Once Qwen 3.8 27B is officially released, we intend to begin planning and building E2 on top of it.
This time, one of our primary research objectives is more fundamental. We hope to make progress on a long-standing limitation of Transformer-based systems: more computation does not necessarily mean better computation. Longer reasoning, additional inference steps, or repeated refinement can still produce redundant work, accumulate errors, or continue without meaningful improvement. VeriLoop Coder-E2 will explore whether a code model can become better at distinguishing genuine progress from ineffective computation during complex problem solving.
Our goal is for VeriLoop Coder-E2 to demonstrate more reliable long-horizon reasoning, stronger recovery from unsuccessful solution paths, less redundant computation, and more dependable completion of complex software-engineering tasks. Rather than simply allowing the model to reason for longer, we hope E2 can make additional computation meaningfully improve the quality and reliability of its results. We intend to evaluate this objective on a capable real-world code model and determine whether it can produce measurable gains at practical model scale.
If this direction succeeds, E2 will not simply be a stronger successor to E1. We hope it can contribute evidence toward a more general question of how a Transformer can distinguish additional computation from actual computational progress.
When VeriLoop Coder-E2 is ready, we would be honored to work with you again and to support another quantized release in any way we can. We would be very happy to provide the appropriate model revision, tokenizer and configuration details, inference guidance, or any other technical information that could make your quantization work easier.
Thank you again for your contribution to VeriLoop Coder-E1. We greatly respect the work you have done, and we hope that with E2 we can once again contribute something valuable to your quantization work—and, together, bring better large-model technology to the broader open-source community.
Best regards,
Libo Wang
VeriLoop Coder
Hi @ConorWang (Libo),
Thank you for reaching out directly, it means a lot to hear this from the team behind the base model.
What struck me reading your note wasn't just the kindness, but how precisely you described the core problem for E2. The idea that a Transformer can learn to distinguish additional computation from actual computational progress is exactly the kind of fundamental question that gets overlooked when everyone is optimizing for pass@k or throughput. I've run into this constantly in my own work with multi-agent systems for security analysis, where you can easily spin up longer reasoning chains, larger context windows, or more refinement loops, and still watch the model chase its own tail or compound an early wrong assumption. More steps doesn't fix a wrong starting vector.
It's also closely related to some research I've been developing on how LLMs manage context structurally over long reasoning horizons, rather than just accumulating tokens. I've been looking at this from two angles: one is a framework for graph-based dynamic context management that treats context as a computational resource you can route and compress intentionally, not just a window you fill up. The other is a structural property I call sparse context coverage, which tries to characterize when a retrieval-augmented system is actually using its retrieved information efficiently versus just carrying dead weight in the context window. Both feel like they intersect with what you're describing for E2, especially the question of how to distinguish useful state from redundant computation during extended reasoning.
On the quantization side, I'm glad the release found an audience. For me it wasn't just a format conversion exercise, there was a fair bit of validation work involved in making sure the quantized variants didn't degrade on the longer-context code completion patterns that make E1 special. I tested across different local inference stacks and GPU configurations to make sure the quality held up, because I know how frustrating it is to download a quantized model and discover it silently breaks on the tasks you actually care about. Seeing the download numbers grow told me we got that balance right, which is honestly the best feedback loop open source can offer.
I'd absolutely love to collaborate again on E2. Whenever you have a timeline or even early thoughts on architecture, I'm happy to start the quantization pipeline, but also to stress-test early checkpoints and give feedback on how the model behaves under local inference constraints, sometimes those constraints surface interesting failure modes that don't show up in datacenter-scale evals.
If you're curious, I've written up some of this thinking in a couple of short papers, but I'd value your perspective if any of it resonates with the E2 direction:
Paper Repo: https://github.com/rodrigoramosrs/rodrigoramosrs/tree/main/my-papers
Linkedin: https://www.linkedin.com/in/rodrigoramosrs/
Looking forward to seeing where VeriLoop Coder-E2 goes. Thanks again for building something worth quantizing in the first place.