Other than that, I keep loosing connection to the backend and have to refresh. the linux slice it's running on is fine so it's not a resource or network issue. The most annoying issue is the agent switching profiles and using another LLM and me not realizing it. It can say opencode-Zen i the chat box selection and then on the agent in the left hand window say deepseek. I'v caught it twice now only by realizing how awful the code was and look over and it decided to use deepseek.

I think maybe this happens when I get the message that the back end connection is lost and then i do a refresh and it might change then. I'm not sure.

How ironic, I was working on my wiki app using opencode and the stupid thing switched again. I can confirm I did not refresh so this just happened during the agents normal routine.

Looks like this time that was due to me using all my tokens for the day over on zencode so the LLM was giving the rate limit error..so it just switched. I do not like this behavior. Had my eyes not caught this like they didn't before I'd be redoing a bunch of work cause DS sucks bad for coding but good enough for reading text files. But, it's done this before like I was saying when i get the lost connection with the back end and refresh. I've posted that error a day or two ago here.

I'll file an issue once my understanding is solid and maybe a PR to go with it if it doesn't involve decisions that belong internal

If the main LLM ran out of budget I'd guess it's the fallback mechanism 🤔

I've already got it cooking

maybe ask it about fallback LLMs in the sdk

And, thank you OH team for designing a professional product and allowing us to use it for free. I appreciate the time you guys put into this project. And, so far my experience with the guys in this channel is very positive.

I didn't want to change behavior from precedent but I think

off

would a better default. In theory, this could result in unexpected charges and angry users. pill sync: github.com/OpenHands/OpenHands/pull/16439 llm_switch: github.com/OpenHands/OpenHands/pull/16441

Check this out. I go so tired of the agent switching LLM on me that I just removed the deepseek llm account from the settings in OH. Deleted it. I had to create a bs test llm to get the agent to let go of the deepseek one as it kept using it even though it was gone. Ok, so now with the junk llm account i was able to get it to turn loose by switch to it and then back to opencode. This morning I used my token allowance on opencode and guess what happened. OH switch back to the deepseek account and started using it even though there's nothing in the llm settings having deepseek. It showed opencode in the chat box and deepseek on the agent. I thought no way...so I logged into my deep seek account and checked the api usage and sure enough there it was. To be clear the deepseek account was removed the night before. So, somehow this thing keeps the settings in a file somewhere.

> This morning I used my token allowance on opencode and guess what happened. OH switch back to the deepseek account and started using it even though there's nothing in the llm settings having deepseek. […] To be clear the deepseek account was removed the night before. So, somehow this thing keeps the settings in a file somewhere. It does… all conversation state, which includes active LLM, is saved in

base_state.json

in the conversations/ directory. That is the active LLM though. I don’t think it saves inactive profiles… so I don’t know how this happened but to note quickly: • it should be reproducible thanks to your detailed description of what you did • if I were to guess, we have a code design fault in the

agent-server

, which might lead to this: there are two sources of truth for the conversation state in agent-server, aside from

base_state.json

there’s also a

meta.json

which duplicates a lot of these settings, and this feels to me like a bug with what gets updated into one and not the other, then restored from the other.

I only even have it to do simple tasks

And, like I mentioned early the agent also just want to run off and start coding sometimes even when explicitly told not to do so.

@clean-postman-32056 Sorry, I do understand that, I think maybe we didn’t quite realize that the fallback might not be as helpful as it sounded… Pretty sure the thinking was like, well, the primary LLM has to stop in error, so maybe it’s better to continue working

Maybe not! But that was the hope with the fallback mechanism

Do you guys have a place for us to request features?

and then we can make it into an issue to work on

On another note: you can also: • ask the agent to summarize the conversation, and create a new one from the summary; it won’t have LLMs you don’t want • create a new conversation (if you’re local), and ask the agent to look up the logs for the old conversation, understand it, and continue it

Quick update: we sketched three fixes. (a) fully remove the agent from

meta.json

(clean, but changes the resume contract), (b) a smaller targeted fix that keeps both files but makes

base_state.json

win, and (c) — Engel's idea — stop `meta.json`'s record from inheriting the request shape at all, so the agent naturally only lives in

base_state.json

. Going with (c): it fixes the root modeling, not just the symptom. Writing it up now, then a PR.

Wrote it up for the Notebook — the three alternatives compared field by field, with the resume/reattach edge resolved: Three ways to end the meta.json / base_state.json split.

Another option actually, which we could choose, is to stop saving LLMs in conversations. Instead, save only the profile name. In this case, the answer to your question would become: • can’t possibly restore the old LLM (we don’t have it anymore since you deleted it) • we can ask the user what LLM profile to use, since it’s missing • or, fallback to the currently active profile (so switch to it) WDYT?

Also sent it upstream: OpenHands/software-agent-sdk#4439 (same change, non-draft).

I don't have a lot of experience in the AI stuff yet, just getting started but am thinking like a linux admin. On suse and debian I often pin kernels so I have have a lot of kernels throughout updates etc but the running one never changes until I unpin it. Then I test another kernel and pin it at a later date. I prefer to not live on the edge in prod.