Problem
Web UI model/profile state can drift from the active Hermes profile config.
Observed while wiring edutech profile:
- Active Hermes profile config had
model.default: gpt-5.5 and provider: openai-codex.
- Web UI Settings still showed
openai/gpt-5.4-mini from WebUI settings state.
/api/models initially reported the default profile's OpenRouter model because config was loaded before init_profile_state() switched to the sticky profile.
Why it matters
Users expect the selected Web UI profile, Hermes CLI profile, Settings default model, new session model, and provider routing to agree. Drift causes confusing failures such as a visible model label not matching the provider actually used by AIAgent.
Current mitigation
Commit 69f40a9 adds gpt-5.5 to Web UI model lists and reloads config after profile initialization. A live smoke test succeeded:
- session model:
gpt-5.5
- resolved provider:
openai-codex
- resolved base URL:
https://chatgpt.com/backend-api/codex
- assistant response:
OK
Proposed follow-up
Unify model resolution around one source of truth:
- On profile switch/startup, derive Web UI default model from active profile config unless the user explicitly overrides it in Web UI settings.
- Store provider-qualified model selections consistently, or store
{model, provider} as separate fields.
- Show the effective provider in Settings and session header, not only the display label.
- Add a regression test for startup with
active_profile=edutech and config model gpt-5.5/openai-codex.
- Add a regression test for
/api/chat/start ensuring selected gpt-5.5 resolves to openai-codex when Codex auth is available.
Acceptance criteria
/api/models.default_model matches the active profile config after startup.
- Settings default model does not silently override profile config unless intentionally saved by the user.
- New sessions use the same effective model/provider shown in the UI.
- The UI can display
GPT-5.5 under OpenAI Codex.
- Provider resolution has test coverage for
gpt-5.5.
Problem
Web UI model/profile state can drift from the active Hermes profile config.
Observed while wiring
edutechprofile:model.default: gpt-5.5andprovider: openai-codex.openai/gpt-5.4-minifrom WebUI settings state./api/modelsinitially reported the default profile's OpenRouter model because config was loaded beforeinit_profile_state()switched to the sticky profile.Why it matters
Users expect the selected Web UI profile, Hermes CLI profile, Settings default model, new session model, and provider routing to agree. Drift causes confusing failures such as a visible model label not matching the provider actually used by
AIAgent.Current mitigation
Commit
69f40a9addsgpt-5.5to Web UI model lists and reloads config after profile initialization. A live smoke test succeeded:gpt-5.5openai-codexhttps://chatgpt.com/backend-api/codexOKProposed follow-up
Unify model resolution around one source of truth:
{model, provider}as separate fields.active_profile=edutechand config modelgpt-5.5/openai-codex./api/chat/startensuring selectedgpt-5.5resolves toopenai-codexwhen Codex auth is available.Acceptance criteria
/api/models.default_modelmatches the active profile config after startup.GPT-5.5under OpenAI Codex.gpt-5.5.