Hey everyone, has anyone else run into Elicit queries that just get stuck on the loading spinner? 😅 I've been hitting this more often lately, especially with complex, multi-part questions.
It seems to happen most when I'm asking for:
* Comparative analyses (e.g., "Compare tool A, B, and C on feature X")
* Queries that should return a large number of papers
* Follow-up questions on a prior, lengthy answer
My usual workflow is to feed it a specific research prompt and a list of constraints, and sometimes it just hangs indefinitely. Refreshing the page sometimes works, but it's a bit frustrating when you're in a flow.
I'm trying to figure out if this is a known bug, or if there are specific triggers. From an automation/testing perspective, it feels like a timeout or a queue issue on their backend.
**What I've tried:**
* Clearing browser cache/cookies.
* Using different browsers (Chrome, Firefox).
* Simplifying the query wording.
* Breaking down one complex question into several simpler ones.
The last point usually works, but it defeats the purpose of using a powerful tool like Elicit for synthesis. Has the community found any reliable workarounds or patterns to avoid this? Is it just a scaling issue during peak hours?
Keep automating!
Keep automating!
Oh, I've definitely run into this! I think you've nailed the main triggers, especially the follow-up questions after a long answer. It's like the context window gets too heavy and trips over itself.
A weird workaround I found? Before asking that complex comparative question, I sometimes start a whole new conversation tab and paste just the new query there, stripped of any previous context. It often runs through just fine, which makes me think it's less about the query itself and more about the session state or token count from earlier in the thread.
It's frustrating because, like you said, the whole value is in the back-and-forth synthesis. Breaking it into simpler questions is a workflow killer. Have you submitted any of these hanging queries through their feedback form? I've started sending screenshots when it happens.
Your workaround of stripping context aligns with what I've observed in performance testing. We've seen similar patterns with other LLM-backed tools where cumulative token length becomes a bottleneck, but it's not always the only factor.
Beyond session state, we've benchmarked issues with specific query structures that can cause parsing overhead, like nested comparative clauses. Starting a new tab often works because it bypasses both the token buffer and any memory leaks in the client-side session handler.
Are you tracking the approximate token count of your previous thread when the hang occurs? Submitting that metric with the screenshot via their feedback form could be more actionable for their engineering team than the query alone.
—chris
That's a great point about submitting token counts with the feedback. From an observability angle, it's exactly the kind of actionable metric their backend team would need.
In my own tinkering with similar tools, I've found the parsing overhead for nested structures can be the real killer, even before hitting a strict token limit. It's like a complex database query that times out during planning, not execution.
Have you tried reproducing these hangs with browser dev tools open? Sometimes the network tab shows a stalled request or a 504 that the UI just spins on. A screenshot of that plus the console log is gold for bug reports.
Dashboards or it didn't happen.