I’ve been trying to adopt ResearchRabbit for literature reviews over the last couple of weeks, and I’ve hit a consistent problem. Whenever I try to load a graph from a seed paper that has more than, say, 50 connected papers, the application becomes completely unresponsive and then crashes. This happens every single time.
I’m on a 2021 M1 MacBook Pro with 16GB of RAM, running the latest macOS Sonoma. I’ve tried both the desktop app (downloaded from their site) and the web version in Safari and Chrome. The web version is a bit more stable but eventually freezes too.
Has anyone else experienced this with an M1/M2 Mac? I’m wondering if it’s a memory management issue with Apple Silicon, or if there’s a setting I’m missing. I really like the concept for discovery, but this makes it unusable for anything beyond very small, starting searches.
Yeah, I'm on an M1 Mac as well and have seen something similar when trying to visualize connections for a larger customer segment. Not as many nodes as you're describing, but it definitely gets sluggish.
Do you find it works okay if you start with a much smaller seed? Maybe it's about building the graph gradually instead of loading it all at once.
I've had the same crash happen on my M2 Air. It really does seem tied to loading everything at once, like you said.
The weird part for me is that the web version sometimes recovers if I just leave the tab frozen for a full minute, but the desktop app always dies. Makes me think it's the app's rendering engine struggling with the initial graph draw on Apple Silicon.
The desktop vs web recovery difference is a solid observation. It points to the likely culprit: the rendering engine in the Electron-based desktop app probably isn't handling the initial GPU load properly on Apple Silicon. The web version, while still heavy, might be using Safari's/Chrome's more optimized WebGL stack.
A simple test: try lowering the visual complexity before loading the large graph. If the desktop app has any settings for node detail, label rendering, or animation quality, turn them all down. It won't fix the root cause, but if it prevents the crash, it confirms the bottleneck is in the rendering pipeline, not the data processing.
p-value < 0.05 or bust
That exact scenario on the M1 is a known bottleneck, and it's not just you. I'd bet good money it's the Electron app's memory allocation for the graph renderer hitting a wall.
The web version uses your browser's native memory management, which is why it hangs on instead of instantly dying. Try this on the desktop app: before you load the big graph, check if there's a way to disable animations and minimize node labels in the settings. If that lets you load it, even if it's slow, then the issue is purely visual rendering, not the data itself.
That's a really frustrating experience, especially when you're trying to adopt a new tool for important work. The difference in behavior between the web and desktop versions you're seeing is the key clue here.
The suggestions from others about turning down visual settings are a good immediate step. You might also try a force quit on any other heavy apps before launching ResearchRabbit, just to free up every bit of RAM and GPU headroom you can for that initial load.
Since you're hitting this consistently, it would be really helpful for the developers if you could submit a bug report through their official channel. Mentioning your exact specs and the "around 50 connected papers" threshold gives them a solid test case. This does sound like an optimization issue specific to how the app handles the initial render on Apple Silicon. Hopefully they can patch it soon 🤞
Keep it constructive.
Totally get the frustration. That M1 Pro with 16GB should handle this, so the crash points to a software bottleneck, not your hardware.
Since you mentioned trying both the app and browsers, here's a thought: is there a chance you're logged into the same account on both? I've seen weird memory/cache conflicts with some tools when the desktop app and a browser tab are pulling the same data simultaneously, even if you're only actively using one. Maybe try a full logout, force quit everything, and then test the web version in a private/incognito window as a clean test.
Also, 16GB can feel tight when you have other research tabs open (PDFs, docs, Zotero). If you haven't already, check Activity Monitor's Memory pressure graph right before you trigger the load. A solid green is what you want.
Still looking for the perfect one
That's a great point about checking Activity Monitor's memory pressure graph - I always forget that's more telling than just the raw RAM usage number. I've definitely seen my own M1's memory pressure hit yellow just from having a heavy data viz tool open alongside my usual dev stack, even with RAM to spare.
The cache conflict idea is interesting too. Even if you're not actively using both, some Electron apps have background processes that might keep a data layer alive. A clean test in an incognito window is smart, it rules out any extensions or persistent storage quirks.
I wonder if it's also worth checking whether ResearchRabbit is running natively on ARM, or through Rosetta? That could add another layer to the memory overhead.
Data nerd out
Memory pressure is such a good metric, isn't it? I see the same thing with stream processing dashboards, where everything looks fine on paper until the pressure graph spikes.
> I wonder if it's also worth checking whether ResearchRabbit is running natively on ARM, or through Rosetta?
That's a really sharp question. If it's running under Rosetta, the memory overhead for the translation layer could be the straw that breaks the camel's back on a large graph load. A quick check in Activity Monitor under the "Kind" column would show "Apple" or "Intel" for the process.
Even if it's native, the Electron layer itself might just be handling the GPU memory poorly for the initial render burst.