fix(muse): keep thread effort for background follow-ups#25506

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — Background follow-ups will inherit the thread’s reasoning effort instead of the Muse host default, with compatibility fallback for older hosts. Human review is required for this effective default change and its resource-use and latency implications.

No code changes detected at eb249bf. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Baseline: a03d9bc · PR result: eb249bf · Source CI: success

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: maria/takeover-pr-24929
• File: .coderabbit.config.ts
• Commit: 71c34c7
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 778e36e1-7bd7-46c2-b427-84ccc35a91de

External image Commits

Reviewing files that changed from the base of the PR and between 5878b98f49bc8ae734935c5b61a3f6e6f4efe391 and 71c34c70c718267d7b6b67ea1e2feead309e9211.

External image Files selected for processing: 10

• apps/server/src/orchestration-v2/testkit/fixtures/multi_turn/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/muse_permission/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/muse_subagent_approval/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/muse_subagent_interrupt/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/muse_workflow/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/simple/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/subagent_v2/muse_transcript.ndjson
• apps/server/src/orchestration-v2/testkit/fixtures/turn_interrupt/muse_transcript.ndjson
• packages/provider-muse/src/server/adapter.test.ts
• packages/provider-muse/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

Verified in a real dev environment

result: unverifiable for the changed muse behavior at 5878b98f49bc8ae734935c5b61a3f6e6f4efe391.

ran vp i and the real dev app on github/main (9bc4138923) in /home/user/main, then stopped main by its captured process-group pid before starting the exact pr head. the pr server used an explicit isolated home, /home/user/t3code/.t3. drove both apps with repo playwright and /usr/bin/google-chrome.

on both revisions, settings → providers → add provider → muse code reached a real provider probe: "muse code cli (muse) was not found", with zero models. a real muse thread-start request on the pr failed; the server recorded Error: spawn muse ENOENT. no mock or replay provider was used.

created a project pointing at the real git repo through the running server cli. two real codex gpt-6.1-sol turns completed through thread start and thread send. a third turn sent from the web composer completed and rendered "web client codex control passed". these are control checks for project creation, provider execution, follow-up messaging and web rendering, not evidence of the muse fix.

main, muse setup blocker:

main: enabled muse instance reports missing executable and zero models

pr, same muse setup blocker:

pr: enabled muse instance reports missing executable and zero models

codex web control, not muse verification:

recording playback was verified separately; github strips the external video player. the completed web turn is shown below.

real codex web composer turn completed on the pr head

command transcript.

existing ci reports 29 successful checks, zero failing or pending. no source changes, commits or pushes were made. no new automated checks were run because the live provider prerequisite failed.

Not verified

could not reproduce the original muse background-follow-up bug on main or prove the fix on the pr: this vm has no muse executable or configured muse runtime. codex uses a different adapter and cannot substitute for the muse session/setReasoningEffort path.

still needed on a muse-enabled host: select max, launch background work that finishes after the parent turn, confirm the muse-started follow-up actually uses max, then repeat with low. also unverified: muse ordinary turns, resume/relaunch cache reset, older-host method-not-found fallback, and non-method-not-found setter errors through a real host. native desktop, ios and android were not exercised on this linux vm.

no change to merge readiness is claimed from the codex controls or passing ci.

The automated pipeline stopped on this pull request and will not merge it:

these checks fail on 71c34c70c7, also when run again: Check, Test Web, and the rework changed nothing:

Nothing changed: both failing checks are unrelated to this PR. Test Web fails only in apps/web/src/components/RightPanelTabs.browser.test.tsx ('a flick that scrolls the tab strip to its left edge keeps the thread, a swipe from the edge goes back'). That test came from main's 11611419f3 (#33396), the branch does not touch apps/web, and the test fails the same way on origin/main (c82e1ba515), which I reproduced locally. Check is only the aggregate gate failing because Test Web failed. The Muse change (setting the session reasoning effort before user turns so provider-started follow-ups inherit the thread's effort, with a fallback for hosts without the setter) is unchanged and its tests pass.

It stays open for a person to finish or close.

@maria-rcks I ran the live check you asked for, and it shows the fix. On main, the turn Muse starts by itself after background work finishes runs at the Muse host's default effort. On this PR it runs at the thread's effort: max, then low after I switched the same thread.

What I ran.

• Muse Code 1.4.15, signed in with an account login.
• Model: Muse Wonder 1.0.
• Host default effort set to medium, so it differs from both selections.
• Before: main a0efdaeb89. After: this PR at 71c34c70c7.
• The head is now eb249bfb05, a merge of main. The PR's own patch is line-for-line identical between the two heads, and no Muse provider file changed, so the run holds for it.
• Each revision ran as its own vp run dev --no-seed server with its own home and a synthetic demo repo.
• I typed every prompt and clicked every effort pick in T3 Code's Browser panel, which reached the test server through an SSH port forward.
• The background work comes from this prompt, taken from the muse_workflow replay fixture: "Use your workflow tool to launch a workflow with exactly TWO agents: one labeled 'ping' that replies with the word PING, and one labeled 'pong' that replies with the word PONG. Launch it and end your turn; do not wait for it." Muse ends the turn, the workflow finishes, and Muse starts its own turn to report it, which T3 Code adopts.

Muse 1.4.15 does not log the effort of a model call. To read it, I put a pass-through relay between Muse and its model API. The relay forwards requests unchanged and records only the model, the reasoning field and the session id headers. The effort below is from the thread's own Muse session; the workflow and reminder agents use other session ids.

The screens look the same on both revisions; the difference is the effort each follow-up ran at.

Main, thread at Max. The follow-up after "Background task finished" ran at medium:

main: thread at Max, Muse's own follow-up after the background workflow

This PR, thread at Max. The follow-up ran at max:

PR: thread at Max, Muse's own follow-up after the background workflow

Main, same thread switched to Low. The follow-up ran at medium again:

main: thread switched from Max to Low, Muse's own follow-up

This PR, same thread switched to Low. The follow-up ran at low:

PR: thread switched from Max to Low, Muse's own follow-up

On this PR, Muse's session log records each setter call from T3 Code (actor t3_code): max before the first turn, low after the switch, x_high after the next switch, and a noop re-send after a server restart. Main has no such record in its session log.

Ordinary user turns ran at the selected effort on both revisions (xhigh with Extra High selected). After I restarted the PR's test server, T3 Code sent the setter again before the next turn, and the follow-up ran at xhigh. Muse 1.4.15 had already kept the session's effort across the restart and recorded that re-send as noop. So the restart run shows the cache reset and the re-send, not a case where the re-send changes the effort.

Not checked:

• The method-not-found fallback: I only hold a current Muse host (1.4.15), which accepts the setter.
• Other setter errors through a real host: a real host accepts the call.
• macOS, Windows, desktop and mobile clients, and Muse API-key setups. Every run used the web client on Linux with an account login.
• A reconnect with the Muse host kept alive: I only ran a full server restart.

The automated pipeline stopped on this pull request and will not merge it:

the proof has no capture anyone can open:

• Permanent blocker: Muse is explicitly unavailable on this VM, preventing real background-work follow-ups and effective-effort diagnostics.
• Max effort inheritance and the subsequent change to low remain unverified on both commits.
• Older-host setter rejection compatibility remains unverified.
• No captures were produced or uploaded; ghdrop was not invoked because no valid runtime evidence existed.

It stays open for a person to finish or close.

@juliusmarminge My signed-in Muse run in https://github.com/pingdotgg/t3code/pull/25507#issuecomment-6788865026 covers the max-then-low item on both commits, with captures in a gist anyone can open. On main a0efdaeb89, Muse's own follow-up ran at the host default medium. On this PR at 71c34c70c7, it ran at max and then low, and the PR's own patch is identical at eb249bfb05. The older-host setter rejection is not covered there, because I only hold a current Muse host, which accepts the setter.