fix(agent-server): persist LLM/profile switch to meta.json so it survives restart

[VascoSch92]

HUMAN:

Fix bug with restart.

---

AGENT:

Why

When the agent-server restarts (e.g. the container is stopped and the conversation is reopened), a conversation's LLM config — including timeout — silently reverts to the values captured at conversation creation. Switching the LLM profile appears to fix it, but the fix is lost again on the next restart.

Root cause: switching the LLM updates only the live ConversationState (persisted to base_state.json). On resume, EventService.start() rebuilds the agent from meta.json (self.stored.agent) and ConversationState.create() overwrites the just-loaded base_state.json agent with it (state.agent = agent). Because the switch was never mirrored into meta.json, the creation-time LLM wins on every restart.

There are three ways the live LLM changes, and all three were affected: the /switch_llm endpoint (app-servers, #3017), the /switch_profile endpoint (agent-canvas), and the agent's own built-in switch_llm tool (SwitchLLMExecutor → conversation.switch_profile, which bypasses the HTTP layer entirely). The ACP model-switch path (switch_acp_model) already handles exactly this by writing the change back to meta.json; the LLM/profile paths were missing it.

Summary

• Add a single EventService._sync_llm_to_meta() helper that writes a swapped LLM back into meta.json (save_meta), matching the existing switch_acp_model precedent.
• Route the /switch_llm and /switch_profile endpoints through new EventService methods that call the helper, and call it from the post-run hook so the agent's in-run switch_llm tool is covered too — all three switch paths now survive a restart.
• Only the stored agent's llm/condenser are updated (not the whole live agent), keyed on LLM object identity. This keeps the stored agent plugin-unmerged — _ensure_plugins_loaded merges plugin agent_context/mcp_config into the live agent on first run, and persisting that would double-merge on resume — and makes the post-run hook a no-op for ordinary/plugin-loading runs.

Issue Number

Fix #4032
Addresses the report: "agent-server sets wrong LLM timeouts when it starts; switching the LLM profile sets the correct values." Reproduction below.

How to Test

Automated (real resume from disk / real agent run, not just unit mocks):

uv run pytest \
  tests/agent_server/test_conversation_service.py::test_switch_llm_survives_restart \
  "tests/agent_server/test_event_service.py::TestEventServiceSaveMeta" \
  tests/agent_server/test_conversation_router.py -k switch

• test_switch_llm_survives_restart (endpoint path) starts a real ConversationService, creates a conversation whose LLM has timeout=300, switches to an LLM with timeout=600, tears the service down, then starts a fresh ConversationService on the same directory (a genuine resume from disk) and asserts the resumed conversation still reports timeout=600.
• test_in_run_switch_llm_persists_to_meta (tool path) starts a real EventService, swaps the live LLM directly on the conversation (simulating the agent's switch_llm tool, bypassing the endpoints), drives a real run to completion with a scripted TestLLM, and asserts the post-run hook wrote timeout=600 into meta.json.
• test_sync_llm_to_meta_ignores_plugin_merge guards the plugin case: a plugin-style agent swap (new agent object, same LLM) must not be persisted, so the stored agent stays unmerged. (Verified it fails if the whole live agent is mirrored instead.)

Manual reproduction (matches the report):

1. Give a conversation an active LLM profile with a non-default timeout.
2. Stop the agent-server / container, reopen the conversation so it restarts and reconnects.
3. cat /workspace/conversations/<SESSION>/*.json | jq '.. | .timeout? // empty' — before this change the timeout reverts to the creation-time value; after it, the switched value persists.

Video/Screenshots

End-to-end evidence that the fix is exercised (not unit-mocked): each regression test fails when its persistence hook is removed (pre-fix behavior) and passes with the fix.

Endpoint path — pre-fix (mirror step reverted):

$ uv run pytest tests/agent_server/test_conversation_service.py::test_switch_llm_survives_restart -q --tb=line
tests/agent_server/test_conversation_service.py:582: AssertionError: assert 300 == 600
FAILED ...::test_switch_llm_survives_restart

Tool path — pre-fix (post-run hook removed):

$ uv run pytest "...::test_in_run_switch_llm_persists_to_meta" -q
FAILED ...::test_in_run_switch_llm_persists_to_meta

Both pass with the fix. Full suites for the touched files pass locally (test_event_service.py, test_conversation_service.py, test_conversation_router.py, test_goal_loop.py — 306 total). ruff check, ruff format, and pyright are clean (all pre-commit hooks pass).

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

Notes

• Updates llm and condenser (the fields a switch_llm changes: condenser is disabled for subscription LLMs / rebuilt for the new model), so the condenser LLM's timeout is fixed on resume too — not just the primary LLM. save_meta serializes with the cipher context, so at-rest secret encryption is unchanged.
• The post-run hook is best-effort (failures logged, never break run completion) and a no-op unless the LLM object actually changed, so ordinary and plugin-loading runs don't rewrite meta.json.
• ACP model switches keep their existing dedicated mirroring (switch_acp_model) — untouched.
• No API/schema changes: both endpoints keep their request/response shapes and status codes (404 unknown conversation, 404 unknown profile, 400 corrupted profile).

[enyst]

Are we sure this is the best code design? The tool firing is an event we could capture with a hook or maybe a new listener, rather than attempting to always save 🤔

Could we analyze the options a bit here?

[enyst]

Issue #4032 notes:

The agent should continue using the LLM profile timeout value configured before the restart (1234) or the one of the active profile.

I see from this PR that what happened is that the entire profile switch may have not been persisted as expanded LLM. That makes me wonder, could we maybe save the profile, rather than the expanded LLM? And load it on restore.

Alternatively, since that is quite involving, for the bug fix maybe we could read the active profile at restore time?

Please consider it just quick thoughts, open for discussion.

[VascoSch92]

Issue #4032 notes:

The agent should continue using the LLM profile timeout value configured before the restart (1234) or the one of the active profile.

I see from this PR that what happened is that the entire profile switch may have not been persisted as expanded LLM. That makes me wonder, could we maybe save the profile, rather than the expanded LLM? And load it on restore.

Alternatively, since that is quite involving, for the bug fix maybe we could read the active profile at restore time?

Please consider it just quick thoughts, open for discussion.

@enyst I did consider it.

Two reasons I went with persisting the expanded LLM instead:

1. The /switch_llm endpoint passes an inline LLM with no profile on disk to reload, so a profile-reference scheme can't cover all three switch paths uniformly. It'd need two persistence formats. (which is not so nice)
2. More importantly, a running conversation already freezes the profile at switch time (the expanded LLM is cached in the registry, first-write-wins, later edits to the profile file aren't picked up until an explicit re-switch). Persisting the expanded LLM keeps a restarted conversation behaving identically to one that was never restarted. Reloading the profile at restore would instead make a restart silently pull in profile edits the live process was ignoring.

Make it sense, or?