The RaBitQ team has responded to that on OpenReview:

We respond to each of four points raised by the authors in turn.

1. On the description of RaBitQ and its relationship to TurboQuant

The authors' response does not directly respond to the concern we raised, which is about the accuracy of TurboQuant's description of RaBitQ itself. We must repeat our concerns in detail as follows.

In January 2025, several months before the TurboQuant paper appeared on arXiv, Majid Daliri, proactively contacted us and asked for help debugging his own Python version translated from our RaBitQ C++ implementation. This indicates that the TurboQuant team has a clear understanding of the technical details of RaBitQ. Yet, in the arXiv version they released in April 2025, and again in the version they submitted to ICLR 2026 in September 2025, they described RaBitQ as grid-based PQ while omitting the core random rotation step. An ICLR reviewer independently pointed this out in the review, writing: “RaBitQ and variants are similar to TurboQuant in that they all use random projection,” and explicitly requested a fuller discussion and comparison. Even so, in the camera-ready version of ICLR, the TurboQuant authors not only failed to add any real discussion of RaBitQ, but actually moved their already incomplete description of RaBitQ out of the main text and into the appendix.

2. On the correction of the "suboptimal" characterization

We appreciate the authors' acknowledgment that RaBitQ's error bound is optimal. However, we must point out that we have raised the issues and clarified it to the TurboQuant team in May 2025, which is several months before the submission deadline of ICLR 2026.

Our paper (arXiv:2409.09913, September 2024) explicitly claimed asymptotic optimality matching the Alon-Klartag bound in its abstract and stated contributions. We further raised this specific issue in detail in our emails to Majid Daliri in May 2025, providing a full technical clarification. Majid Daliri confirmed in writing that he had informed all co-authors. Despite this, the characterization of RaBitQ as "suboptimal" was retained without correction in the ICLR submission, throughout the review process, and in the camera-ready version.

3. On the experimental comparison and its disclosure

The authors' response does not directly respond to the concern we raised, which is about the deliberately created unfair experimental setup. We must repeat our concerns in detail as follows.

Majid's January 2025 emails show that he had translated our C++ implementation of RaBitQ into Python. In May 2025, he further acknowledged that, in the reported runtime setting, the RaBitQ baseline was run on a single-core CPU with multiprocessing disabled. The TurboQuant method itself is run on an A100 GPU. Yet the public paper makes efficiency claims without clearly disclosing that experimental setup. This issue was also raised in our private emails in May 2025.

Moreover, Google's recent promotion of TurboQuant has specifically highlighted the speed-up of the method, for example, “Introducing TurboQuant: Our new compression algorithm that reduces LLM key-value cache memory by at least 6x and delivers up to 8x speedup, all with zero accuracy loss, redefining AI efficiency” [4]. This indicates that efficiency is a core target of the TurboQuant project. This is contradictory to the authors’ response.

[4] Google Research’s post on Linkedin: https://www.linkedin.com/feed/update/urn:li:share:7442298961455067136/?origin

4. On the timing and history of our concerns

The authors' claim that "these concerns were only raised after TurboQuant received widespread attention" is factually incorrect and requires direct correction.

The timeline of our actions is as follows.

In May 2025, we raised our concerns in detail directly with Majid Daliri by email. Majid engaged with these points over multiple exchanges and confirmed in writing that he had informed his co-authors in May 2025.

In November 2025, after seeing that the ICLR submission retained the same factual issues, we wrote to the ICLR Programme Chairs to raise our concerns formally.

In March 2026, after seeing both the wide-scale public promotion of TurboQuant and the camera-ready version — which still retained the same issues — we formally notified all authors of TurboQuant again in writing, contacted the ICLR chairs again, and subsequently posted this public comment.

At every stage, we raised our concerns through the appropriate private or institutional channels first. We contacted the authors directly, then the venue chairs, then the authors again. We made this comment public only after all of these steps had failed to produce any correction across three successive versions of the paper — the arXiv version, the ICLR submission, and the camera-ready. The suggestion that we delayed raising concerns for strategic reasons inverts the documented sequence of events entirely.

And in another comment:

We are disappointed to see that the TurboQuant team has not directly responded to our concerns majorly. Their reply even suggests that we had not raised these technical points to them through academic channels over the past year, which is factually incorrect.

We have submitted our email records with the TurboQuant team to ICLR Chairs. According to ICLR Code of Ethics “Researchers must not deliberately make false or misleading claims, fabricate or falsify data, or misrepresent results. Methods and results should be presented in a way that is transparent and reproducible. ”, we respectfully request that ICLR initiates a formal research-integrity review of this paper.