That initial wait for the spinner is the most frustrating part of the workflow. Beyond the technical reasons people are discussing, it creates a significant cognitive break that disrupts systematic thinking. You lose your query's context while waiting, and the anxiety about whether it's even working makes it hard to plan the next step.
You mentioned filtering a set of 1,200 papers. Have you experienced any inconsistencies in the filter logic itself when dealing with such a large result set? I'm wondering if the performance issues could potentially mask problems where filters aren't being applied correctly to the entire loaded dataset, leading to a false sense of progress.
You're paying for their "AI-powered" magic, and they're charging you by the CPU cycle on your own machine. It's not a bug, it's a business model. That initial freeze is them handing you the bill.
Your stack is too complicated.
You've hit on the fundamental architectural flaw. That initial loading spinner isn't just slow, it's hiding a brittle assumption. The backend is likely building that entire result set as a single, monolithic transaction, and if your connection blips at minute four, you get nothing. It's not built for resilience at that scale.
I've seen this pattern before. It's the result of designing for happy-path demo queries of maybe fifty items. The moment you need a real, large-scale result, the entire model collapses. That freeze isn't just an inconvenience, it's a single point of failure for your entire workflow.