Pi keeps using previous model after model picker change until /compact

[iamhenry]

Summary

In a Pi thread, changing the model in BB did not change the model Pi actually used. BB recorded GPT or Claude for new turns, but Pi continued sending requests to the previous Grok model until manual compaction; the next response then used GPT as selected.

Versions and environment

• bb 0.39.1-nightly.32358956903.1 (packaged macOS app)
• macOS 15.6.1
• Built-in Pi provider with bundled Pi 0.84.0

Steps to reproduce

1. Start a Pi thread with an xAI/Grok model.

2. After the turn finishes, select an OpenAI/Codex model in BB's model picker.

3. Send several normal new-turn prompts.

4. Inspect only assistant metadata in the Pi bridge session:

   jq -r 'select(.type == "message" and .message.role == "assistant") | [.timestamp, .message.provider, .message.model] | @tsv' ~/.bb/pi-bridge-sessions/<thread-id>.jsonl | tail

5. Run /compact, then send another prompt and inspect the metadata again.

Expected vs actual

Expected: turns after the picker change use the selected OpenAI/Codex model.
Actual: BB recorded openai-codex/gpt-5.6-sol for multiple new turns, while Pi assistant records remained xai/grok-4.6. Immediately after /compact, Pi assistant records changed to openai-codex/gpt-5.6-sol.

Evidence

• BB client/turn/requested events repeatedly recorded the newly selected model.
• The Pi session had only the initial Grok model_change; actual assistant messages remained Grok across later new turns.
• Manual compaction was the synchronization boundary. The compaction itself appears to have used the stale Grok model, so it may also consume unintended quota.
• No prompts, credentials, account data, local paths, or private thread IDs are included here.

What you ruled out

• This was real Grok inference, not usage-dashboard polling; Pi persisted provider, model, and token usage on assistant messages.
• No matching open or closed issue was found. Does the pi provider persist per-turn records anywhere? BB-invoked pi sessions leave nothing in pi's own session store #2035 concerns session persistence, and pi provider: no way to manually compact a thread's context #1103/pi /compact on a small session surfaces as a failed turn and puts the thread in error state #1721 concern manual compaction behavior rather than model switching.

Suggested priority: High — users can unknowingly consume the wrong provider's quota. Starting a new thread is the safest workaround.

AGENT GENERATED: by GPT-5.6 Sol. Investigation report available from the reporter without private conversation content.

[iamhenry]

@ymichael @SawyerHood can y'all plz take a look at this when you get a chance?

Switching model within Pi was draining my grok usage after switching mid session from grok to as sol

[SawyerHood]

Reproduced the same bug on the ACP providers (Cursor confirmed; Grok Build takes the same path), and traced it to one commit. Full report with repro script, bridge wire recordings, and screenshots: https://get-bb.github.io/reports/issues/2160.html. I think this issue should cover both Pi and ACP; the fix sites differ, but the cause is one change.

Root cause

#1640 (c5b53caab, merged 2026-08-17, first in desktop 0.39.0) replaced the runtime's option-drift classification with () => "live" for both the Pi adapter and the ACP adapter, and moved reconciliation into the bridges. Neither bridge reads params.options on turn/start:

• Before Agent providers as a first-class plugin surface (provider bridge protocol) #1640 the ACP adapter used classifySessionExecutionSettingsChange, which returns session on any drift, so the runtime issued thread/resume and the agent relaunched with the new --model. The Pi adapter lost the same classification in the same commit.
• On main the bridge adapter always classifies drift as live and reconfigureThreadIfNeeded only records the new options.
• ACP bridge: the model is applied only in startAgentSession; for Cursor it is a --model launch flag. turn/start never reads params.options; turn/steer has the same shape.
• Pi bridge: handleTurnStart never reads params.options either. Your /compact boundary is a session rebuild picking up the recorded options.
• claude-code is unaffected because its bridge calls session.setModel per turn (verified: tell --model claude-sonnet-5 on a Haiku thread sent control_request set_model).

ACP repro (source 15f21ade7, 2026-08-21; cursor-agent 2026.08.11)

pnpm bb:dev thread spawn --project <proj> --provider acp-cursor --model gpt-5.4-mini-low --permission-mode accept-edits \
  --prompt "Reply with exactly one line: the model name you are running as, nothing else." --json
pnpm bb:dev thread tell <thr> --model cursor-grok-4.6-medium --reasoning-level low \
  "Reply with exactly one line: the model name you are running as, nothing else."

Expected: second answer "Cursor Grok 4.6".
Actual:   every answer "GPT-5.4 Mini"; client/turn/requested recorded gpt-5.4-mini-low, then gemini-3.6-flash-low, then cursor-grok-4.6-medium;
          one process served all three: `cursor-agent ... --model gpt-5.4-mini-low acp`.
Bridge recording: runtime→bridge sends the new model on every turn/start; bridge→provider only ever sends session/prompt on the same sessionId (no session/set_model, no respawn).

Same result from the real composer picker (provider locked to Cursor; picked "Cursor Grok 4.6", and in a second independent run "Composer 2.5"). Workaround: bb thread stop <thr>, then send again; that does thread/resume and relaunches cursor-agent --model cursor-grok-4.6-low acp, which answers "Cursor Grok 4.6". Because #1604 never reaps idle ACP sessions, the stale process otherwise lives until the thread is stopped or the daemon restarts.

Reproduced on two fresh dev instances by two independent agents (threads thr_44p2unpauk, thr_cz92hmc6nv).

Origin and what I ruled out

• Came from a user screenshot of a Cursor thread that started on "Claude Fable 5", was switched to "Cursor Grok 4.6 Extra High", and still answered as Fable 5 (Cursor then posted its own "Switched to Claude Opus 4.8 / hit a safety filter" notice). The user read it as a Claude→Cursor provider switch. It is not: the follow-up composer locks the provider, the send request carries no providerId, and all three names are rows of Cursor's model list.
• Not display-only: the process and the answers prove the old model ran.
• Not Active steers ignore model/reasoning changes #1860 / Send the composer's execution selection with steers #2149: that was the client omitting the tuple on steers; here the tuple reaches the bridge and is ignored.

Suggested fix shape

On turn/start and turn/steer, compare params.options (model, reasoningLevel, serviceTier) with the session's pinned selection: native-selection agents apply session/set_model / set_config_option (Pi: its own model change) in place; CLI-flag agents (Cursor, Grok Build) rebuild the session with new launch args and emit session/replaced. Or restore a session classification at the adapter level for bridges that do not reconcile per turn, which fixes Pi and ACP in one place. Suggest retitling to cover both providers.

Investigation thread: bb thr_5cdapt5sfp.

AGENT GENERATED: by Claude Opus 5

[iamhenry]

ty