New LLM Model Release April 2026: What Actually Happens Inside a Running Mac Chat When You Swap to Opus 4.7 Mid-Conversation

In Fazm, clicking a new model button changes ShortcutSettings.selectedModel in UserDefaults. On the next handleQuery call, acp-bridge/src/index.ts line 1449 looks up the existing ACP session by its role key (main, floating, or observer). Because the session is found and the requested model differs from the session's cached model, line 1502 fires a single condition check (requestedModel !== existingModel) and line 1503 calls acpRequest('session/set_model', { sessionId, modelId: requestedModel }). No session/new. The sessionId is the same UUID that served every prior message. The ACP SDK swaps the model behind that ID server-side; Fazm's local conversation array in ChatProvider.swift keeps every message it had.

ChatProvider.swift lines 1047 to 1051 warm three sessions at app startup: ('main', claude-sonnet-4-6, main system prompt, resume), ('floating', claude-sonnet-4-6, floating prefix + main prompt, resume), ('observer', claude-sonnet-4-6, chat observer prompt). Each key is a role string, not a model name. The observer is a background summarizer that watches chat activity and does not want to follow whatever shiny model the user picked in the floating bar. The main window and floating bar are two foreground surfaces with different system prompts. Role keying means the three can diverge on model independently: the user can push floating to Opus 4.7 for one hard question while main stays on Sonnet and observer continues its cost-gated Sonnet loop.

session/set_model is a JSON-RPC method on the Anthropic Claude Agent SDK's ACP protocol. It takes { sessionId, modelId } and mutates the model bound to that server-side session without tearing down the conversation. Inside the Fazm bridge it is called in six places: line 1341 (pre-warm after resume), line 1366 (pre-warm after new session), line 1475 (mid-flight resume), line 1495 (mid-flight new session), line 1503 (mid-flight model swap on an existing session), and line 1810 (cwd-change recovery). The mid-conversation swap case is the one at line 1503: it only fires when the session key already exists AND the requested model differs from the session's current cached model. Everything else on the line 1503 path is already bound, including the MCP tool servers and the running subprocess.

On next launch, the pre-warm path at index.ts lines 1296 to 1379 called session/new for each of the three role keys. The SDK returned result.models.availableModels with the new 'claude-opus-4-7' modelId. emitModelsIfChanged at line 1271 noticed the JSON differed from lastEmittedModelsJson and broadcast { type: 'models_available', models: [...] } over stdout. ACPBridge.swift line 1202 decoded it and ShortcutSettings.updateModels ran 'claude-opus-4-7' through the three-row modelFamilyMap substring match: 'opus-4-7'.contains('opus') is true, so the label became 'Smart (Opus, latest)'. The user opens Settings, sees the Opus 4.7 button, clicks it, and the next message they send runs through session/set_model. Conversation history stays intact.

session/new tears down the SDK's in-memory conversation state, creates a new sessionId, re-applies the system prompt, and reinitializes the MCP tool servers. It's ~2-4 seconds on first token because the SDK has to rebuild the tool manifest. session/set_model reuses the sessionId, keeps the conversation memory file under ~/.claude/projects/, keeps the MCP tool servers bound, and is one RPC round trip. When a user picks a new April 2026 model mid-chat, the difference between 'conversation resets and Fazm feels broken' and 'next message just uses the new model' is whether line 1503 or line 1488 fires. Fazm routes through line 1503 whenever the session key is already registered.

The observer is a background ACP session whose job is to summarize chat messages silently. It runs whenever the foreground chat pauses. Cost and latency matter more than peak intelligence for that loop. ChatProvider.swift line 1050 hardcodes its model to claude-sonnet-4-6. When the user switches floating to Opus 4.7, the floating session gets session/set_model (line 1503); the observer session is untouched because its session key 'observer' is different from 'floating' and its model never changed. This is a real consequence of role keying: the roles behave independently on cost, model, and system prompt.

Nothing destructive. The tool call abort path at index.ts lines 1391 to 1396 only aborts the previous query if its sessionKey matches the incoming one. A click on a new model button does not fire a query on its own; it only updates UserDefaults. The next message the user sends picks up the new model via line 1503 before the query runs. If a query is already in flight for the same sessionKey when the new message arrives, line 1393 aborts the old one (standard behavior for typing before a response finishes), then line 1503 sets the new model, then the new query runs. Tool-server subprocesses (playwright MCP, macos-use MCP, etc.) are not restarted because they are bound to the sessionId, not the model.

Yes. acp-bridge/src/index.ts line 1320 wraps the three warmup configs in Promise.all(toWarm.map(async cfg => {...})). Each cfg runs its own session/new (or session/resume) concurrently. The full cold-start cost is max(cfg time), not sum(cfg time). This matters on April-release day because the SDK's availableModels response is larger during active rollout periods (new + old + deprecated), and each session/new has to serialize it. Parallelism at line 1320 absorbs that cost.

ShortcutSettings.selectedModel at ShortcutSettings.swift line 139 is a @Published var, so the picker in SettingsPage.swift lines 2013 to 2031 and the floating bar's short label at FloatingControlBarWindow.swift line 1553 update on the same tick. The bridge gets the change only when the user's next message goes through handleQuery; the UI is already showing the new label by then. There is a brief window where the UI reflects the new model but the SDK is still running on the old one. For Fazm that window is bounded by the time between click and next send, typically under a second.

Any model that Anthropic's Claude Agent SDK or a user-configured custom endpoint reports back in result.models.availableModels. On April 2 that included Claude Opus 4.7 GA and Claude Haiku 4.5.2. On April 7 it included Claude Mythos Preview (for the ~50 Project Glasswing partners, gated server-side). For users pointing at custom Anthropic-compatible proxies (LiteLLM, Cloudflare AI Gateway), it also covered GPT-5 Turbo (April 7), Gemma 4 Apache 2.0 (April 2), GLM-5.1 (754B MoE), Qwen 3.6-Plus with 1M-token context, DeepSeek V3.2, and Grok 4.1. The bridge has no model allowlist; whatever comes through the pipe is forwarded to the Swift picker.

One RPC round trip between acp-bridge (Node) and the Claude Agent SDK subprocess, measured in Fazm dev builds at 40 to 80 ms locally when both are on the same machine. Plus the click-to-send delay. There is no UI blocking spinner for the swap itself; the user types, hits send, the bridge runs line 1503 before forwarding the prompt. Response latency on the first token after the swap is dominated by whichever model was selected, not by the swap mechanism.

Three warmup configs: /Users/matthewdi/fazm/Desktop/Sources/Providers/ChatProvider.swift lines 1047 to 1051. Parallel pre-warm: /Users/matthewdi/fazm/acp-bridge/src/index.ts lines 1296 to 1379, with the Promise.all at line 1320. Mid-conversation swap: index.ts lines 1498 to 1510, with the swap call at line 1503. Role-keyed lookup: index.ts lines 1449 to 1459. models_available broadcast: index.ts lines 1271 to 1281. Substring family map: /Users/matthewdi/fazm/Desktop/Sources/FloatingControlBar/ShortcutSettings.swift lines 159 to 163. Update pipe on the Swift side: ShortcutSettings.swift lines 178 to 212. Every one of these is a direct file:line anchor in the shipping codebase.