Hi everybody! I am new to openhands, and I am experimenting it for local development. So far I was able to succeed creating a couple of sample apps, but I also found a few issues that are hard for me to understand. My setup is: 2 hosts running ollama, one is running qwen3.5:9B and the other is running qwen3.8:27B (heavily quantized, due to memory constraints; but still capable of developing the 2 apps I mentioned above), one host running openhands canvas UI through docker on Debian 13. Unfortunately from time to time I get stuck and I am not able to understand what is happening. 1. when running condenser, on large context (>100k), I see in ollama that the task is reset after 50s from the first request, and then is tried again after a while. I tried setting 900s timeout in the LLM configuration, but it does not seem to affect results. Moreover I wanted to try to use qwen3.5:9B for context condensation, but I was not able to convince the condenser to use this model, neither by setting it as default nor by switching conversation model; 2. I have a couple of conversations that, instead of trying to contact the external hosts, openhands tries to connect to localhost and so I always get errors like

litellm.APIConnectionError: Ollama_chatException - Cannot connect to host localhost:11434 ssl:<ssl.SSLContext object at 0x7f99c22d0f50> [Connect call failed ('127.0.0.1', 11434)]

. What can cause these issues?

Hey @flaky-dress-3505 1. Localhost:11434 errors in some conversations Each conversation saves a copy of its LLM settings when it's created, including the base URL. If a conversation started while the base URL was empty (for example before you set it, or the field was left blank), it has no address for Ollama. litellm then falls back to its default, localhost. Inside the Docker container, localhost is the container, not your Ollama hosts. Changing settings afterwards doesn't fix conversations that already exist. I think you could do: - Start a new conversation after checking the profile's base URL is `http//<ollama host ip>1143`4, or switch that conversation to a profile that has the URL set. - As a safety net, pass

-e OLLAMA_API_BASE=http://<ollama-host-ip>:11434

to the canvas container. litellm uses it whenever no base URL is set. 2. The 900s timeout doesn't seem to apply It's the same saved copy. The timeout does reach the Ollama call, but only in conversations created after you changed it, and the condenser uses the same copy. Please test with a new conversation. The default is 300s, and failed calls are retried up to 5 times with 8–64s waits, which is the "tried again after a while" you're seeing. A cutoff at ~50s isn't an OpenHands default, so something else is probably closing the connection. Can you check for something in this direction? 3. Using qwen3.5:9B for condensation This isn't possible from the UI right now. The condenser always uses the conversation's own model. Switching the conversation's model moves the condenser along with it, so that doesn't give you a separate model. A separate condenser model only works through the SDK, not canvas settings. Meanwhile, you can make condensation cheaper by lowering the condenser's max tokens in the settings so it runs on smaller chunks. Hope it helps 🙂

@modern-fireman-99755 indeed I did not specify neither OLLAMA_API_BASE, nor a base url for ollama, since I specified a provider connection instead. I checked the conversation directory and in

base_state.json

I see that no base url is set, but the

provider_connection_id

points to the correct connection. So it seems that

provider_connection_id

is ignored in some cases. Moreover it is weird that I started having this behavior after several successful interactions. BTW: I have only used the UI (i.e., no manual edit of any file) so far and in the

base_state.json

of one of the not-working conversations, I see that the condenser is set to qwen3.5 and the llm is set to qwen3.8... Probably due to using the LLM profile switch in the chat... I have investigated a little bit about the 50s timeout issue in the condenser... And what I found is that the culprit seems to be the fact that condenser forces

stream=False

and this triggers the 50s timeout directly in ollama (still do not know why). I was able to reproduce the behavior both with litellm and curl without involving openhands.

I have investigated a little bit about the 50s timeout issue in the condenser... And what I found is that the culprit seems to be the fact that condenser forces

stream=False

and this triggers the 50s timeout directly in ollama (still do not know why). I was able to reproduce the behavior both with litellm and curl without involving openhands.

This is interesting. So if you switch off the streaming than you get a timeout? Am I understanding this correctly?

curl -v -X POST <http://ollama:11434/api/chat>   -H "Content-Type: application/json"   -d '{
    "model": "smtek/Qwen3.8-27B:Q2_K_XL-16gb",
    "messages": [
      {
        "role": "user",
        "content": "Generate a long detailed essay. Continue for at least 5000 tokens."
      }
    ],
    "stream": false
  }'

This curl request is enough to get a timeout.

However, if I try manual context compaction through the UI, I still get a signal error (while in the Ollama logs I can see that the request succeeds after a while), and the compaction is aborted.

can you retrieve more logs about that?

From what I see in the browser console I see that a POST request to openhands/api/conversations/…/condense fails after exactly 1 min with no response. In ollama logs I see that the model successfully completes summarization after 1 min 57 sec (

[GIN] 2026/09/16 - 20:29:06 | 200 |         1m57s |      172.21.0.1 | POST     "/api/chat"

). By looking at the initiator information in browser, it seems that 60000 (

6e4

) is the default timeout for the client used by

condenseConversation()

. I did not check the actual frontend code though.

ah ok interesting. It could be a problem with openhands

I suspect a larger timeout (e.g., 5min) in the frontend call would make this issue disappear for me. I think the main question is if it is expected to take 1m57s to condense the context. In my case it is expected since I have >100k tokens context with 40-50 token/s generation rate... And probably I do not need such a large context.

mmm i checked and it seems there is also a problem in the code from our side: github.com/OpenHands/OpenHands/issues/17621