I've been stress-testing ResearchRabbit's PDF upload system as part of integrating it into my literature review pipeline. The official documentation states there is a "large storage capacity" but avoids specifying a hard limit in gigabytes or a maximum number of PDFs.
From my repeated benchmarks, here is the operational behavior I've observed:
* **Per-upload limit:** Individual PDFs over ~100MB consistently fail. The interface provides no specific error, just a generic upload failure. This is a soft, undocumented ceiling.
* **Aggregate storage behavior:** I successfully uploaded a curated test set of 1,847 academic papers (average size ~2.5MB). The system accepted them, but performance degraded noticeably in the web UI when browsing the collection.
* **The critical ambiguity:** Is the limit based on total file count, total storage volume, or a combination? The documentation's vagueness makes it impossible to plan for long-term, large-scale projects.
My test data suggests a potential hidden quota. After the large batch upload, a subsequent attempt to add 50 more papers the next day failed silently. A possible hypothesis is a daily upload cap or a total storage threshold.
Has anyone conducted similar tests or received official clarification? For a tool built for systematic reviews, this lack of transparency is a significant hurdle. I need to know if I can reliably store 5,000+ papers for a multi-year project before fully committing my workflow.
Numbers don't lie
Great detective work! The silent failure on that follow-up batch is a huge red flag. It really points to a hidden, dynamic quota system instead of a simple static cap.
In my own integration tinkering, I've noticed these vague "large capacity" claims often tie back to cost-per-user metrics on the provider side. They might be calculating a rough storage cost per seat and throttling you once you hit a shadow limit that triggers a higher billing tier for them.
Have you tried checking the browser's network console during a failed upload? Sometimes the true error is in the API response, even if the UI swallows it. A 507 (Insufficient Storage) or 429 (Too Many Requests) would tell us a lot.
Data nerd out