👋 @faint-greece-70506 reached out and had some questions. He's using local GUI. > I'm using locally hosted models. Right now Devstral Small 2 24b is working flawlessly, and I'm really happy with it. > > One thing that bother me though, is that I see no option to define max context length. I see OpenHands use an event-based condensing technique. This is confusing to me, since there is no way of knowing how much context one or several events will use. And ultimately, these LLM's (be it locally hosted or cloud-hosted) are limited by context in terms of tokens, not events. > • I'm curious as to what was the rationale behind not using token-count triggered condensation? > • What's the upside of instead using event-count trigger? > • Since I'm worried that my OpenHands is underperforming since I have no way of knowing the current context size usage, I would like to know if there's a way I can switch to using token-count based condensation instead? > > I have tried almost all self-hosted agentic development tools currently available. And OpenHands seems to work the best. I believe it has great potential. But right now I feel that this ambiguity regarding context is holding it back, as context is such a central limitation to LLM's edited the format a little bit

I'm on it! Jamie can track my progress here.

It is possible in V1. Basically, you can put a very high value on max events, and ... thinky spin • I don't think the Web UI has any option. • IIRC the CLI has max input tokens, which you can set to limit it

Hi! Thanks for talking about this. I'm the guy with the original question. Is the OpenHands AI answer very off, or have I misunderstood what an event is? Because it confuses me when it's saying that the default 240 event limit for automatic condensing is "conservative". I run my local model with 55k context length. However, even if you run cloud models, the typical max context length now seems to be somewhere around 200k. I know for a fact that even such big context sizes can easily fill up within 10 steps. For the sake of argument: it is trivial to fill up 1 million of context within one event, simply by asking it to read a big novel. I still struggle to see the upside to event-based condensing. I don't even think you could argue it gives a predictable memory footprint either (but token-based condensing would). And I don't feel this is easy to set up as a user either.

Hey! Just for clarity, I think the CLI app has the ability to limit context sizes per tokens

I need the UI for my use-case. But I appreciate the help. I'll try setting the max size to a large value and see if it helps

could you maybe post an issue on it with the error? it sounds like a bug that the specific error is not mapped to context error

There is no error related to context overflow. If I use default settings there is no way to reliably control when context gets condensed. If I disable event-based condensing or set the trigger to something really high, then the LLM response simply just stops abruptly without any error and I had to go into my backend to see that the reason for the stop was that the context hit the max limit:

2026-03-11 17:59:54  [INFO]
 [qwen3.5-35b-a3b@q4_k_l] Generated prediction:  {
  "id": "chatcmpl-6vgxw240nyxif2ud61j87m",
  "object": "chat.completion",
  "created": 1773248390,
  "model": "qwen3.5-35b-a3b@q4_k_l",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "I see! The Sort base class uses `this.comparator` (not `this.compare`), and it has a constructor that initializes it. The QuickSort class needs to call",
        "tool_calls": []
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 63964,
    "completion_tokens": 36,
    "total_tokens": 64000
  },
  "stats": {},
  "system_fingerprint": "qwen3.5-35b-a3b@q4_k_l"
}

This is the kind of issue I'm perplexed exists, since it would very easily be solved by having a token-based trigger for condensing, like all other agentic tools have. And I think I'd rather spend my time developing my own alternative to OpenHands than make an issue on it, because this really should not be an issue in the first place for a project that has existed this long

That's fair, sorry about that. I think maybe @wide-doctor-37830 may be able to help