Setting model on startup

[giuli007]

First of all thanks for the changes in #3

There is another potential nuance to consider about the use of the LLM_MODEL env variable supported by llm that I think could be considered as a further enhancement. (I opted for opening a separate issue instead of continuing the conversation on the closed one)

Currently sidechat starts up using the default model configured in llm.

I think it would be useful if sidechat could also take into account if the LLM_MODEL variable is already set on the shell where it is being started from and use that one instead of the llm default.

This is a minor thing and not a big problem so mostly wanted to suggest it here for consideration

[kristopolous]

LLM_MODEL is pretty poorly scoped. SIDECHAT_LLM_MODEL sure, but what are we doing then? I don't see the advantage any more - are you going to tweak it manually and then start a session? Sounds inconvenient.

Can you tell me your use-case a bit better? There's quite a few options we can do here, including wrappers, hooks, evals, whatever ...

[giuli007]

Thank you for for considering this suggestion.

To clarify my use case a bit more: In my typical workflow, most of the times, I don't actually rely on the llm default model at all. I often set (and export) LLM_MODEL in specific terminal sessions, depending on which model I want to use for different tasks. I frequently interact with llm directly in these sessions, and occasionally I’ll also start sidechat from the same environment.

In these instances, it feels intuitive and consistent to me that sidechat would pick up and use the LLM_MODEL I've already set in the current terminal session, rather than reverting to the global llm default. Since I tend to view sidechat as a helpful wrapper around llm, having it inherit the same model setting from my terminal would make the experience feel more seamless.

I agree this is a relatively minor enhancement to what is potentially a niche workflow, but I think it could improve usability for users that rely on this env variables in similar ways.

Thanks again for taking the time to discuss this!

[kristopolous]

I understand the mental model but I don't know if it can really work like that. You feel like you invoke it from the thing you are working on but that's really illusory, it invokes it from the tmux server process and then uses the current pane focus to capture the screen.

What I mean by that is if you do export N=1 in tmux, then do a split, that's not a child, it doesn't inherit the environment of where you split from. There's a set-environment and a way to do it with an -e flag but what are we doing now? it's inconvenient territory once again...

What we can maybe do is make it so if you manually invoke sidechat from the shell it will inherit it. Then you can use bindkey or your shell equivalent and then bind it to something new.

Then you get effectively the same behavior so long as you're at a prompt - thus you have two models of invocation - the primary inherited shell way and the tmux way.

It's certainly bad UX because it's a baffling abstraction, but it might be the only way

[kristopolous]

This is now moot. I don't use simon's tool anymore, it's been moved to llcat