[GH-ISSUE #3103] [BUG]: Error: Engine instance could not be reached or is not responding #1988

New Issue

terminal_debug_output.txt

Originally created by @forgot on GitHub (Feb 3, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3103

Originally assigned to: @timothycarambat on GitHub.

How are you running AnythingLLM?

AnythingLLM desktop app

What happened?

Switching to another app for a while, or leaving the AnythingLLM app focused but idle, causes chat to stop responding. After sending a new message, the reply chat bubble will "think" for a while, then eventually throw this error:

Error: The AnythingLLM LLM engine instance could not be reached or is not responding. You may need to reboot the app or check the logs for more information.

My expectation is that it would respond normally, but I'm pretty sure that's everyone's expection 😂

Are there known steps to reproduce?

Steps To Reproduce:

Launch the desktop app
Chat like usual, waiting for the full response before moving to step 3
Let the app idle by doing one of the following:
1. Switch to a different app or apps for a while
2. Leave AnythingLLM focused but do not interact with it
Return to the app if needed, and send a message in chat
Chat UI "thinks" for a while, then stops responding and throws error
Restart app
Repeat steps 1-6

Additional Info:

Hardware:
- Device: MacBook Pro 16-inch, Nov 2024
- Chip: Apple M4 Max
- Memory: 128G
- OS: macOS Sequoia 15.2
Installation Method: Homebrew (for updates as well)
App Version: AnythingLLM 1.7.3

This has occurred since the first time I installed the app on this machine, and I believe it happened on my older Intel based MBP as well. I can't remember what the version was when I first installed it, but it has occurred from at least desktop v1.7.1, possibly before. My terminal history shows a date of Mon Nov 11 2024 05:05:16 GMT+0000 for the command brew install --cask anythingllm on this machine.

I ran the app in debug mode via the terminal, and I've attached both the terminal output and the standard log file. In both files you can see a log message for the first chat I sent ([Event Logged] - sent_chat), but there is no log for the next message I sent. I was paying pretty close attention to the logs as they streamed in, and my last message was sent sometime after the line [backend] info: [fillSourceWindow] Need to backfill 4 chunks to fill in the source window for RAG!. (Looking through the logs, that seems to be a fairly common message so it's probably just coincidence.) After sending the next message, the UI displayed the chat bubble containing my message as well as the response chat bubble, which hung on its "thinking" animation for a while before displaying the error. The log did not receive a second sent_chat event like I expected, and instead the next log message is the error.

Hopefully all this points someone in the right direction, and I'm happy to provide any additional information you might need.

collector-2025-02-03.log

backend-2025-02-03.log

Models Tested

Model Name	Idle Time	Error	Success	Terminal Output	Collector Log	Backend Log
llama-3.1-8B (GUI)	10 min	✅	❌	terminal_debug_output_llama_3.1_8B.txt	collector-2025-02-14-llama-3.1-8B.log	backend-2025-02-14-llama-3.1-8B.log
llama-3.2-3B (GUI)	10 min	✅	❌	terminal_debug_output_llama_3.2_3B.txt	collector-2025-02-14-llama-3.2-3B.log	backend-2025-02-14-llama-3.2-3B.log
llama-3.1-8B (Direct)	10 min	✅	❌	terminal_debug_output_llama_3.1_8B-direct.txt	collector-2025-02-19-llama-3.1-8B-direct.log	backend-2025-02-19-llama-3.1-8B-direct.log
llama-3.2-3B (Direct)	10 min	✅	❌	terminal_debug_output_llama_3.2_3B_direct.txt	collector-2025-02-19-llama-3.2-3B-direct.log	backend-2025-02-19-llama-3.2-3B-direct.log

Process Used

This is probably overkill, but I’m documenting everything for clarity and consistency. If you’ve experienced the same issue, please follow the process below and report your findings.

Base Setup For All Tests:

Prior to running any tests, I created a dedicated workspace. It contains only the default thread, an empty chat, and has no documents attached. The LLM Provider is set to AnythingLLM, and the Workspace LLM Provider is set to System default. The model will be set in the steps below. This dedicated workspace was reused for each test.

For my own convenience, I also had two terminal tabs open to the following paths:

~/Applications/AnythingLLM.app/Contents/MacOS
~/Library/Application Support/anythingllm-desktop/storage/logs

Steps Performed For Each Model:

Open app normally
Open Settings -> AI Providers -> LLM, then select the model to use, ensure changes are saved, and close the settings menu
From the main menu, select the default thread in the dedicated workspace and reset it by using /reset
Close app normally
Cleared both the backend and collector logs by calling cat /dev/null > backend-<your>-<date>-<here>.log && cat /dev/null > collector-<your>-<date>-<here>.log
Launch the app in debug mode from the terminal by calling ./AnythingLLM
Select the default thread of the dedicated workspace
Send a message (I just sent “hello!”), and wait for the full response
Leave the app focused, and do something else for 10 minutes (I made coffee)
Send another message (I sent “hello!” again)
Wait for a response:
1. If you get a response, move to the next step
2. If the UI appears stuck on the “thinking” animation, keep waiting until you get an error. (This took approximately 5 minutes in my tests)
Kill the app from the terminal (⌃ + C on the keyboard)
Copy everything that was output in the terminal, and paste it in a .txt file called terminal_debug_output_<model>_<you>_<used>.txt. (Ex: terminal_debug_output_llama_3.1_8B.txt)
Make copies of both the backend and collector log files, and rename them to collector-<your>-<date>-<here>-<your>-<model>-<here>.log and backend-<your>-<date>-<here>-<your>-<model>-<here>.log (Ex: collector-2025-02-14-llama-3.2-3B.log or backend-2025-02-14-llama-3.1-8B.log)

If you’re still with me, and you’ve followed the above steps, add a comment with the models you used in testing and the files that were created.

Originally created by @forgot on GitHub (Feb 3, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3103 Originally assigned to: @timothycarambat on GitHub. ## How are you running AnythingLLM? AnythingLLM desktop app ## What happened? Switching to another app for a while, or leaving the AnythingLLM app focused but idle, causes chat to stop responding. After sending a new message, the reply chat bubble will "think" for a while, then eventually throw this error: >Error: The AnythingLLM LLM engine instance could not be reached or is not responding. You may need to reboot the app or check the logs for more information. My expectation is that it would respond normally, but I'm pretty sure that's everyone's expection 😂 ## Are there known steps to reproduce? Steps To Reproduce: 1. Launch the desktop app 2. Chat like usual, waiting for the full response before moving to step 3 3. Let the app idle by doing one of the following: 1. Switch to a different app or apps for a while 2. Leave AnythingLLM focused but do not interact with it 4. Return to the app if needed, and send a message in chat 5. Chat UI "thinks" for a while, then stops responding and throws error 6. Restart app 7. Repeat steps 1-6 Additional Info: - Hardware: - Device: MacBook Pro 16-inch, Nov 2024 - Chip: Apple M4 Max - Memory: 128G - OS: macOS Sequoia 15.2 - Installation Method: Homebrew (for updates as well) - App Version: AnythingLLM 1.7.3 This has occurred since the first time I installed the app on this machine, and I believe it happened on my older Intel based MBP as well. I can't remember what the version was when I first installed it, but it has occurred from at least desktop v1.7.1, possibly before. My terminal history shows a date of `Mon Nov 11 2024 05:05:16 GMT+0000` for the command `brew install --cask anythingllm` on this machine. I ran the app in [debug mode](https://docs.anythingllm.com/installation-desktop/debug#anythingllm-debug-mode-on-macos) via the terminal, and I've attached both the terminal output and the standard log file. In both files you can see a log message for the first chat I sent (`[Event Logged] - sent_chat`), but there is no log for the next message I sent. I was paying pretty close attention to the logs as they streamed in, and my last message was sent sometime after the line `[backend] info: [fillSourceWindow] Need to backfill 4 chunks to fill in the source window for RAG!`. (Looking through the logs, that seems to be a fairly common message so it's probably just coincidence.) After sending the next message, the UI displayed the chat bubble containing my message as well as the response chat bubble, which hung on its "thinking" animation for a while before displaying the error. The log did not receive a second `sent_chat` event like I expected, and instead the next log message is the error. Hopefully all this points someone in the right direction, and I'm happy to provide any additional information you might need. [terminal_debug_output.txt](https://github.com/user-attachments/files/18651524/terminal_debug_output.txt) [collector-2025-02-03.log](https://github.com/user-attachments/files/18651531/collector-2025-02-03.log) [backend-2025-02-03.log](https://github.com/user-attachments/files/18651532/backend-2025-02-03.log) ## Models Tested Model Name | Idle Time | Error | Success | Terminal Output | Collector Log | Backend Log -|-|-|-|-|-|- llama-3.1-8B (GUI) | 10 min | ✅ | ❌ | [terminal_debug_output_llama_3.1_8B.txt](https://github.com/user-attachments/files/18809078/terminal_debug_output_llama_3.1_8B.txt) | [collector-2025-02-14-llama-3.1-8B.log](https://github.com/user-attachments/files/18809079/collector-2025-02-14-llama-3.1-8B.log) | [backend-2025-02-14-llama-3.1-8B.log](https://github.com/user-attachments/files/18809080/backend-2025-02-14-llama-3.1-8B.log) llama-3.2-3B (GUI) | 10 min | ✅ | ❌ | [terminal_debug_output_llama_3.2_3B.txt](https://github.com/user-attachments/files/18809093/terminal_debug_output_llama_3.2_3B.txt) | [collector-2025-02-14-llama-3.2-3B.log](https://github.com/user-attachments/files/18809092/collector-2025-02-14-llama-3.2-3B.log) | [backend-2025-02-14-llama-3.2-3B.log](https://github.com/user-attachments/files/18809094/backend-2025-02-14-llama-3.2-3B.log) [llama-3.1-8B (Direct)](https://ollama.com/library/llama3.1) | 10 min | ✅ | ❌ | [terminal_debug_output_llama_3.1_8B-direct.txt](https://github.com/user-attachments/files/18874440/terminal_debug_output_llama_3.1_8B-direct.txt) | [collector-2025-02-19-llama-3.1-8B-direct.log](https://github.com/user-attachments/files/18874441/collector-2025-02-19-llama-3.1-8B-direct.log) | [backend-2025-02-19-llama-3.1-8B-direct.log](https://github.com/user-attachments/files/18874442/backend-2025-02-19-llama-3.1-8B-direct.log) [llama-3.2-3B (Direct)](https://ollama.com/library/llama3.2:3b) | 10 min | ✅ | ❌ | [terminal_debug_output_llama_3.2_3B_direct.txt](https://github.com/user-attachments/files/18874469/terminal_debug_output_llama_3.2_3B_direct.txt) | [collector-2025-02-19-llama-3.2-3B-direct.log](https://github.com/user-attachments/files/18874468/collector-2025-02-19-llama-3.2-3B-direct.log) | [backend-2025-02-19-llama-3.2-3B-direct.log](https://github.com/user-attachments/files/18874470/backend-2025-02-19-llama-3.2-3B-direct.log) ----- ## Process Used This is probably overkill, but I’m documenting everything for clarity and consistency. If you’ve experienced the same issue, please follow the process below and report your findings. ### Base Setup For All Tests: Prior to running any tests, I created a dedicated workspace. It contains only the default thread, an empty chat, and has no documents attached. The LLM Provider is set to AnythingLLM, and the Workspace LLM Provider is set to System default. The model will be set in the steps below. This dedicated workspace was reused for each test. For my own convenience, I also had two terminal tabs open to the following paths: - `~/Applications/AnythingLLM.app/Contents/MacOS` - `~/Library/Application Support/anythingllm-desktop/storage/logs` ### Steps Performed For Each Model: 1. Open app normally 2. Open Settings -> AI Providers -> LLM, then select the model to use, ensure changes are saved, and close the settings menu 3. From the main menu, select the default thread in the dedicated workspace and reset it by using `/reset` 4. Close app normally 5. Cleared both the backend and collector logs by calling `cat /dev/null > backend-<your>-<date>-<here>.log && cat /dev/null > collector-<your>-<date>-<here>.log` 6. Launch the app in debug mode from the terminal by calling `./AnythingLLM` 7. Select the default thread of the dedicated workspace 8. Send a message (I just sent “hello!”), and wait for the full response 9. Leave the app focused, and do something else for 10 minutes (I made coffee) 10. Send another message (I sent “hello!” again) 11. Wait for a response: 1. If you get a response, move to the next step 2. If the UI appears stuck on the “thinking” animation, keep waiting until you get an error. (This took approximately 5 minutes in my tests) 12. Kill the app from the terminal (`⌃ + C` on the keyboard) 13. Copy everything that was output in the terminal, and paste it in a .txt file called `terminal_debug_output_<model>_<you>_<used>.txt`. (Ex: `terminal_debug_output_llama_3.1_8B.txt`) 14. Make copies of both the backend and collector log files, and rename them to `collector-<your>-<date>-<here>-<your>-<model>-<here>.log` and `backend-<your>-<date>-<here>-<your>-<model>-<here>.log` (Ex: `collector-2025-02-14-llama-3.2-3B.log` or `backend-2025-02-14-llama-3.1-8B.log`) If you’re still with me, and you’ve followed the above steps, add a comment with the models you used in testing and the files that were created.

yindo added the bug Desktop labels 2026-02-22 18:27:35 -05:00

yindo closed this issue

yindo commented

@forgot commented on GitHub (Feb 4, 2025):

Here's a screenshot of the error as it appears in the chat UI:

@forgot commented on GitHub (Feb 4, 2025): Here's a screenshot of the error as it appears in the chat UI: ![Image](https://github.com/user-attachments/assets/4c336e98-054b-463c-a8ad-2573da7d7290)

yindo commented

@timothycarambat commented on GitHub (Feb 4, 2025):

Excellent write up. Thank you for being so descriptive you cannot imagine how rare that is 😆.

A hunch tells me this would have to do with m_lock for the ollama runner. This would keep the model in memory, which over time could be pushed out by a priority process, making the m_lock invalid and likely to fail an inference.

I think we can address this by using m_lock but moving the keep_alive to something like 5 minutes (or configurable under advanced settings) so that the model can free and reload on demand. Will try to repro

@timothycarambat commented on GitHub (Feb 4, 2025): Excellent write up. Thank you for being so descriptive you cannot imagine how rare that is 😆. A hunch tells me this would have to do with `m_lock` for the ollama runner. This would keep the model in memory, which over time could be pushed out by a priority process, making the `m_lock` invalid and likely to fail an inference. I think we can address this by using `m_lock` but moving the `keep_alive` to something like 5 minutes (or configurable under advanced settings) so that the model can `free` and reload on demand. Will try to repro

yindo commented

@shameez-struggles-to-commit commented on GitHub (Feb 5, 2025):

same thing happening to me - glad I found this issue already posted!

@shameez-struggles-to-commit commented on GitHub (Feb 5, 2025): same thing happening to me - glad I found this issue already posted!

yindo commented

@gwtest commented on GitHub (Feb 7, 2025):

same thing happening to me
Chip: Apple M2 Max
Memory: 32G
OS: macOS Sequoia 15.3

@gwtest commented on GitHub (Feb 7, 2025): same thing happening to me Chip: Apple M2 Max Memory: 32G OS: macOS Sequoia 15.3

yindo commented

@timothycarambat commented on GitHub (Feb 11, 2025):

Anyone this is happening to please report the model and param size you are running on device alongside machine specs. Thinking this may be model related as small models (<3B) seem to not have this issue

@timothycarambat commented on GitHub (Feb 11, 2025): Anyone this is happening to please report the model **and param size** you are running on device alongside machine specs. Thinking this may be model related as small models (<3B) seem to not have this issue

yindo commented

@forgot commented on GitHub (Feb 13, 2025):

I'll play with some models and update the original issue with any findings.

Are there any models in particular you would like to use as "control" models? Also, are there any flags that can be passed to the executable that can provide additional information?

@forgot commented on GitHub (Feb 13, 2025): I'll play with some models and update the original issue with any findings. Are there any models in particular you would like to use as "control" models? Also, are there any flags that can be passed to the executable that can provide additional information?

yindo commented

@timothycarambat commented on GitHub (Feb 13, 2025):

No flags, but the one I was trying to replicate with and could was llama 3.1 8B Q4 and couldnt was llama 3.1 3B

@timothycarambat commented on GitHub (Feb 13, 2025): No flags, but the one I was trying to replicate with and _could_ was llama 3.1 8B Q4 and _couldnt_ was llama 3.1 3B

yindo commented

@forgot commented on GitHub (Feb 14, 2025):

I'm new to running LLMs locally, which is how I came across this project in the first place, so a bit of hand holding may be necessary here. I've mostly been running models provided by the GUI when using AnythingLLM as the provider, and only recently started to download them from HuggingFace directly within the app.

Searching HF for llama 3.1 3B currently gives me 4 options, and llama 3.1 8B Q4 gives a staggering 303 options. Add the hieroglyphics involved in model file naming and I started getting dizzy. (It's all starting to make sense though.)

So my question is: Do you have links to the ones you're referring to, or is it ok to just pick one from the list that doesn't seem too altered from the original model?

_{Side question: Are the models provided in the GUI loaded from somewhere like HF as well? Or do y'all host those directly?}

@forgot commented on GitHub (Feb 14, 2025): I'm new to running LLMs locally, which is how I came across this project in the first place, so a bit of hand holding may be necessary here. I've mostly been running models provided by the GUI when using AnythingLLM as the provider, and only recently started to download them from HuggingFace directly within the app. Searching HF for [llama 3.1 3B](https://huggingface.co/models?library=gguf&sort=trending&search=llama+3.1+3B) currently gives me 4 options, and [llama 3.1 8B Q4](https://huggingface.co/models?library=gguf&sort=trending&search=llama+3.1+8B+Q4) gives a staggering 303 options. Add the hieroglyphics involved in model file naming and I started getting dizzy. (It's all starting to make sense though.) So my question is: Do you have links to the ones you're referring to, or is it ok to just pick one from the list that doesn't seem too altered from the original model? <sub>Side question: Are the models provided in the GUI loaded from somewhere like HF as well? Or do y'all host those directly?</sub>

yindo commented

@timothycarambat commented on GitHub (Feb 14, 2025):

Oh, haha yeah the amount of replicated models on HF is crazy. In this case, i was using the official ollama tags
For 3B: https://ollama.com/library/llama3.2:3b
For 8B: https://ollama.com/library/llama3.1

Ollama default is always Q4 - which is middle of the road in size vs performance. For "common" models I use the ollama tags. Only for more niche models do I try to import a GGUF from huggingface.

@timothycarambat commented on GitHub (Feb 14, 2025): Oh, haha yeah the amount of replicated models on HF is crazy. In this case, i was using the official ollama tags For 3B: https://ollama.com/library/llama3.2:3b For 8B: https://ollama.com/library/llama3.1 Ollama default is _always Q4_ - which is middle of the road in size vs performance. For "common" models I use the ollama tags. Only for more niche models do I try to import a GGUF from huggingface.

yindo commented

@forgot commented on GitHub (Feb 15, 2025):

Ok, for now I ran the tests with the GUI provided versions of those models. If they are different than the direct downloads you linked, I'll run them again with linked ones when I get a chance. If you have any other ones you'd like me to use, just let me know.

I also edited my initial issue to add a list of models I've tested with, and the specific steps I took.

@forgot commented on GitHub (Feb 15, 2025): Ok, for now I ran the tests with the GUI provided versions of those models. If they are different than the direct downloads you linked, I'll run them again with linked ones when I get a chance. If you have any other ones you'd like me to use, just let me know. I also edited my initial issue to add a list of models I've tested with, and the specific steps I took.

yindo commented

@echomirage01 commented on GitHub (Feb 19, 2025):

Also running into this issue.

Chipset: Apple M1 Max
Memory: 32GB
OS: 15.3

I have used the Llama3.2, Llama3.2 Vision, Phi-4, and Phi-3.3 with the same results each time. So, none of the models I have run have maintained a connection to the engine after losing app focus for a period of time or the with the computer waking from sleep. Switching to another model or trying to reload does not restore the connection. Restarting the application does correct the issue.

@echomirage01 commented on GitHub (Feb 19, 2025): Also running into this issue. Chipset: Apple M1 Max Memory: 32GB OS: 15.3 I have used the Llama3.2, Llama3.2 Vision, Phi-4, and Phi-3.3 with the same results each time. So, none of the models I have run have maintained a connection to the engine after losing app focus for a period of time or the with the computer waking from sleep. Switching to another model or trying to reload does not restore the connection. Restarting the application does correct the issue.

yindo commented

@timothycarambat commented on GitHub (Feb 19, 2025):

I wonder if a repeatable process is to run a few chats, sleep the machine, and see if that makes a crash more probable to occur. @echomirage01 What parm sizes were those models?

@timothycarambat commented on GitHub (Feb 19, 2025): I wonder if a repeatable process is to run a few chats, sleep the machine, and see if that makes a crash more probable to occur. @echomirage01 What parm sizes were those models?

yindo commented

@echomirage01 commented on GitHub (Feb 19, 2025):

I wonder if a repeatable process is to run a few chats, sleep the machine, and see if that makes a crash more probable to occur. @echomirage01 What parm sizes were those models?

They were:
Llama 3.2 3B
Llama3.2 Vis. 11B
Phi-4 14B
Phi-3.3 8B

These are some of the ones included in the preference settings. I don't see one with less than 3B parameters listed in the preferences. I will try to run the chat, sleep, test sequence more tonight.

@echomirage01 commented on GitHub (Feb 19, 2025): > I wonder if a repeatable process is to run a few chats, sleep the machine, and see if that makes a crash more probable to occur. [@echomirage01](https://github.com/echomirage01) What parm sizes were those models? They were: Llama 3.2 3B Llama3.2 Vis. 11B Phi-4 14B Phi-3.3 8B These are some of the ones included in the preference settings. I don't see one with less than 3B parameters listed in the preferences. I will try to run the chat, sleep, test sequence more tonight.

yindo commented

@forgot commented on GitHub (Feb 19, 2025):

Updated the table in my original post with additional results, this time using models loaded with ollama run ....

I've just been using these models as a "control", and I'm happy to test it with any others, but it's happened consistently with every model I've run using the built in provider.

@forgot commented on GitHub (Feb 19, 2025): Updated the table in my original post with additional results, this time using models loaded with `ollama run ...`. I've just been using these models as a "control", and I'm happy to test it with any others, but it's happened consistently with every model I've run using the built in provider.

yindo commented

@forgot commented on GitHub (Feb 26, 2025):

@timothycarambat Are there any other models you want data for, parameters to try and test with, or anything else I can provide?

@forgot commented on GitHub (Feb 26, 2025): @timothycarambat Are there any other models you want data for, parameters to try and test with, or anything else I can provide?

yindo commented

@SilverServer34 commented on GitHub (Mar 13, 2025):

Hello, same thing happen to me:

Mac mini m4
16gb ram
macos 15.3.1

llm
Deepseek r1 8b
ollama run privacydied/NousResearch-DeepHermes-3-Llama-3-8B-Preview-GGUF-Q8
ollama run hf.co/bartowski/OpenThinker-7B-GGUF:Q6_K

I also add of context, in addition to the behavior already discussed the same thing happens by changing models.
I set up different workspaces each with its own llm, if I use the same model with different prompts (e.g. deephermes without reasoning in one workspace and with reasoning in another) I get no errors, if I change model instead I get the same error. It would also be helpful to have pointers to the loaded model

@SilverServer34 commented on GitHub (Mar 13, 2025): Hello, same thing happen to me: Mac mini m4 16gb ram macos 15.3.1 llm Deepseek r1 8b ollama run privacydied/NousResearch-DeepHermes-3-Llama-3-8B-Preview-GGUF-Q8 ollama run hf.co/bartowski/OpenThinker-7B-GGUF:Q6_K I also add of context, in addition to the behavior already discussed the same thing happens by changing models. I set up different workspaces each with its own llm, if I use the same model with different prompts (e.g. deephermes without reasoning in one workspace and with reasoning in another) I get no errors, if I change model instead I get the same error. It would also be helpful to have pointers to the loaded model

yindo commented

@timothycarambat commented on GitHub (Mar 19, 2025):

Is everyone in this thread installing AnythingLLM via Homebrew or by clicking on the .dmg installer after downloading via browser?

@timothycarambat commented on GitHub (Mar 19, 2025): Is everyone in this thread installing AnythingLLM via `Homebrew` or by clicking on the `.dmg` installer after downloading via browser?

yindo commented

@SilverServer34 commented on GitHub (Mar 20, 2025):

Is everyone in this thread installing AnythingLLM via Homebrew or by clicking on the .dmg installer after downloading via browser?

dmg user here

@SilverServer34 commented on GitHub (Mar 20, 2025): > Is everyone in this thread installing AnythingLLM via `Homebrew` or by clicking on the `.dmg` installer after downloading via browser? dmg user here

yindo commented

@Mode-108 commented on GitHub (Mar 20, 2025):

Installed via downloaded clickable file from anythingllm website.
Machine: Win11 offline, i5-12400k, 16gb, rtx3060.
Error reproducable in all cases, big or small llm, llm model provider, no difference, llm works normal about 20-30 minutes. once crashed, anythingllm task is at full speed in taskmanager. once crashed, threads cannot be revived, picked up again or reused, same error after about 5 minutes of "thinking". opening a new thread works until app crashes again. no exception.

@Mode-108 commented on GitHub (Mar 20, 2025): Installed via downloaded clickable file from anythingllm website. Machine: Win11 offline, i5-12400k, 16gb, rtx3060. Error reproducable in all cases, big or small llm, llm model provider, no difference, llm works normal about 20-30 minutes. once crashed, anythingllm task is at full speed in taskmanager. once crashed, threads cannot be revived, picked up again or reused, same error after about 5 minutes of "thinking". opening a new thread works until app crashes again. no exception.

yindo commented

@timothycarambat commented on GitHub (Mar 20, 2025):

The root cause has been identified and will be resolved in the next desktop release (1.7.7). Closing the issue as resolved now and will unpin the issue from Github once the new release is live.

Planning to release this patch this week

@timothycarambat commented on GitHub (Mar 20, 2025): The root cause has been identified and will be resolved in the next desktop release (1.7.7). Closing the issue as resolved now and will unpin the issue from Github once the new release is live. Planning to release this patch this week

yindo commented

@timothycarambat commented on GitHub (Mar 20, 2025):

Live in 1.7.7 (out now) - confirmed fix. Please let me know if not the case. Thank you all here for your help tracing this very tedious bug.

@timothycarambat commented on GitHub (Mar 20, 2025): Live in 1.7.7 (out now) - confirmed fix. Please let me know if not the case. Thank you all here for your help tracing this very tedious bug.

yindo commented

@Bart-A1990 commented on GitHub (Mar 28, 2025):

Hello, i have the same issue.
To give more context: I was still working on version 1.7.2 (Windows X64 desktop version). I tought that the app would automatically being updated... I changed the model from "Llama3.2 Vision 11B 7.9GB" to "Mixtral 8x7B 26GB" First i got an error that i do not have enough ram, so i changed it from 16 to +24 gb (adding virtual memory). I run a a chat and it took over 5 minutes, after waiting a time, i got the same issue as mentioned.

After google search i came here and saw that it must be fixed in version 1.7.7, so i updated today my installation to V1.7.8, but after the update the issue is still there.... I am now trying to figure out that the issue is also on deepseek or other LLM modals...

Technical information about my pc:

WINDOWS 11 X64
Processor Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz
installed RAM 16,0 GB (15,7 GB beschikbaar)
Type systeem 64-bits besturingssysteem, x64-processor

I think that anythingLLM has not enough time to answer my question. I wanted to ask AnythingLLM to write a complete set of testcases, based on a word document as base.

Question: How can i give more resources / time to anythingLLM? Can i give AnythingLLM for example 1 hour or more to answer my question? For me it is no issue that it take some time to answer... I just want to have a "good" answer. And i think, the more it has, the better the answer can be?

Thanks,

Gr

@Bart-A1990 commented on GitHub (Mar 28, 2025): Hello, i have the same issue. To give more context: I was still working on version 1.7.2 (Windows X64 desktop version). I tought that the app would automatically being updated... I changed the model from "Llama3.2 Vision 11B 7.9GB" to "Mixtral 8x7B 26GB" First i got an error that i do not have enough ram, so i changed it from 16 to +24 gb (adding virtual memory). I run a a chat and it took over 5 minutes, after waiting a time, i got the same issue as mentioned. After google search i came here and saw that it must be fixed in version 1.7.7, so i updated today my installation to V1.7.8, but after the update the issue is still there.... I am now trying to figure out that the issue is also on deepseek or other LLM modals... Technical information about my pc: WINDOWS 11 X64 Processor Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz installed RAM 16,0 GB (15,7 GB beschikbaar) Type systeem 64-bits besturingssysteem, x64-processor I think that anythingLLM has not enough time to answer my question. I wanted to ask AnythingLLM to write a complete set of testcases, based on a word document as base. Question: How can i give more resources / time to anythingLLM? Can i give AnythingLLM for example 1 hour or more to answer my question? For me it is no issue that it take some time to answer... I just want to have a "good" answer. And i think, the more it has, the better the answer can be? Thanks, Gr

yindo commented