Hello! I have created a couple draft PRs to make a consolidated settings object in the SDK, and use it to render the frontend settings page. • SDK PR: https://github.com/OpenHands/software-agent-sdk/pull/2361 • GUI PR: https://github.com/OpenHands/OpenHands/pull/13306 It has a few important features: 1. Settings are pydantic objects, serializable, deserializable, and migratable from old versions to new versions 2. The agent can be created entirely from the settings object 3. The fields to be displayed in the GUI can be derived from the SDK settings object so SDK upgrade = GUI upgrade 4. It is possible to override the default display behavior (see the LLM display in the frontend) Here’s a video of how it renders now (details will be fixed later of course). I’d love to have architectural comments from people like @chilly-france-44439 @calm-artist-7206 @quick-window-91705 @straight-sundown-84319 @millions-afternoon-47582 @wooden-umbrella-84098. It’s a big PR so just high-level directional feedback is good for now, and if this direction is good I’ll do: 1. More intensive testing to see what this breaks 2. Making sure it works on SaaS and doesn’t break backward compatibility

how customizable is the GUI display? Looks pretty good from the above 🙂

Basically the way to customize the GUI display is to exclude items from the default display and implement in typescript. So if you exclude all items in the defaults then you can fully customize

Does this way of working with settings still allow for this use case? • from the client, send an /llm_profiles request to set some LLM profile • then start a conversation referencing a profile • that is, don't require the client to send LLM API key again. From the other conversation, re: > Really just new endpoints like POST /secrets, POST /llm-profiles, etc, and then in POST /conversations being able to reference those I think what’s interesting about this need, is I think maybe this implies accepting a

ConversationStartRequest

which serializes an 'agent' with a profile id, that is, a reference. And references one or more secret names, instead of full dicts. —- Secrets are not directly involved in this PR, though maybe the same concept applies, I feel. (I think Xingyao is meeting it in the automations PRs) Maybe that’s like: • client called /secrets to set them • client chooses 2 secret names and sends a /start_conversation with them Current shapes (OpenHands-GPT-5.4 trained its human to like the term 'shapes' 😅) https://gist.github.com/enyst/76447ea0813d502a3c0c72dbc790a725

Thanks @calm-artist-7206, I don’t understand the use case very well, could you elaborate when this would be necessary and from which code this workflow is called?

I looked at the backend changes earlier this morning and they seemed reasonable - I didn't look at the frontend

OK, thanks!

I think maybe every client code that wants to use LLM profiles via

agent-server

, has to do something like: • send a profile from the user to the SDK profile store ◦

/llm-profiles

endpoint • let the user start a conversation with a profile id So my question becomes, how do we let the user start a conversation with a profile id, in the SDK? It seems that the

ConversationStartRequest

has to specify the profile id, instead of the full LLM dict.

Do you have an example where we currently use this pattern? In the CLI?

I think there’s an argument to say so. Vasco’s PR on

/model profile_id

control command was merged in the SDK. It allows to switch profile by profile id. I think maybe the CLI still has to expose it to the user. Robert proposed in the other thread to expose LLM profiles via the REST interface too.

Thanks, I think the problem I have right now is I don’t fully understand what the client code would look like, or when we’d need to use it. If I could get a reference I could think about what to do, though

Please take a look at this, in relation to immutability: https://github.com/OpenHands/software-agent-sdk/issues/1451

OK, thanks, this is much clearer, I’ll think on this