Repository navigation
feat(mothership): keep each chat's reasoning effort, default to medium, restore Low - #8634
Conversation
…m, restore Low The simple picker offers Low / Medium / High / Extra High again, each sending exactly that effort. New chats and chats never changed run at medium instead of high. An effort the user picks is stored on the chat (copilot_chats.config) through a new PUT /api/mothership/chats/[chatId]/effort and at turn admission, and later turns of that chat keep it. The global last-used effort is no longer persisted. The Sim Chat block defaults to medium.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
4 issues found across 21 files
Confidence score: 3/5
- In
mothership-chats.ts, a failed earlier request can roll back a later effort selection, so the next turn may use the wrong effort. Only restorepreviousEffortif the failed request still owns the current selection. - In
mothership-chats.ts, an in-flight detail query can overwrite the optimistic effort after the PUT succeeds, and this mutation does not refetch on success. Cancel the detail query before applying the optimistic update. - In
store.ts, abandoning a new-chat composer after choosing Low leaves that choice on the next untouched chat. Clear the pending effort when the new-chat draft is abandoned. - In
use-chat.ts, adopting a recovered chat after a 409 can leavenewChatEffortset even though the server recorded it. Clear the pending choice when adoptingconflictChatIdso it does not carry into a later new chat.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="apps/sim/stores/mothership-effort/store.ts">
<violation number="1" location="apps/sim/stores/mothership-effort/store.ts:18">
P2: A pending effort choice leaks across unsent chats: abandoning a new composer after selecting Low leaves the next untouched new chat on Low instead of Medium. Clear this pending value when the new-chat draft/surface is discarded, or scope it to the draft/chat identity.</violation>
</file>
<file name="apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts">
<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts:3742">
P2: A deduplicated retry of a new-chat send can leave `newChatEffort` set after the server has already recorded it on the recovered chat. Clear the pending new-chat choice when the 409 `conflictChatId` is adopted so the next new chat returns to the default.</violation>
</file>
<file name="apps/sim/hooks/queries/mothership-chats.ts">
<violation number="1" location="apps/sim/hooks/queries/mothership-chats.ts:609">
P2: Cancel the detail query before applying this optimistic update. An in-flight GET can otherwise restore the old effort after the PUT succeeds, and this mutation does not refetch on success.</violation>
<violation number="2" location="apps/sim/hooks/queries/mothership-chats.ts:621">
P2: Guard this rollback against a newer optimistic pick. When an earlier request fails after a later selection, restoring its `previousEffort` replaces the newer value, so the next turn can send the wrong effort.</violation>
</file>
There was a problem hiding this comment.
All reported issues were addressed across 21 files
Requires human review: Auto-approval blocked because this review re-detected 4 unresolved issues already reported by Cubic.
Fix all with cubic | Re-trigger cubic
…d saves and abandoned new chats
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
…st attempt stored
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
…e new-chat composer
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
…-chat surface is open
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
This branch was previously deployed
1 participant
Summary
Mothership Chat's reasoning effort now belongs to each chat, the default drops to
medium, and Low is back in the simple picker.Merge is gated: this waits on the main agent's medium-vs-high benchmark. Do not merge until that result is in.
Behaviour
medium(the new default, washigh), unless the user picks one before the first sendmedium(it has no stored choice, so it follows the default)medium; Low is available. Saved blocks keep their stored value. A block with no stored value now runs atmediumlow,medium,high,xhigh). Simple mode no longer turnslowintomedium. It still mapsmaxtoxhighandnoneto the default, because it only offers those four.lowpasses through unchanged for GPT-6 Astra. The worker sends it as OpenAIreasoningEffort(Anthropicefforton Opus/BYOK) without remapping it.nonestays limited to GPT-6 Sol, as before.Where the per-chat choice lives
It lives in the existing
copilot_chats.configjsonb, undereffort, besideconversationMode. No migration. The key is only present when the user picked an effort, so "picked" and "following the default" stay separate. Reads go through one SQL selection,chatEffortSelection, which treats any value outside the protocol's effort range as no pick.There are two write paths:
PUT /api/mothership/chats/[chatId]/effort(new contract andmothership.chats.set_effortuse case). Changing the picker in an existing chat saves it immediately, so a reload keeps it even before the next message. It works for workspace, organization and workflow-panel chats, owner only.The server resolves each turn's effort as: the effort on the send, else the chat's stored pick, else the default. A client that hasn't loaded the chat yet still runs it at the right effort.
The chat GET responses (and the legacy workflow-panel GET) return
effort(the stored pick, ornull). The composer reads it through React Query. A pick made in this tab is kept in an in-memory per-chat map and takes precedence over the loaded value, so a detail refetch or a save still in flight can't revert it. Saves for one chat run one at a time (mutationscope), and a failed save drops its pick only if no newer pick replaced it. Admission stores the effort the turn actually runs at.Global last-used preference: removed for effort
Before this change the composer saved one global "last effort" in localStorage and applied it to every chat. That conflicts with the per-chat rule (a new chat, or one never changed, must use the default), so effort is no longer saved globally, and any saved global value is ignored. New chats start from the default, not from the last pick. A pick made in a new-chat composer is held in memory until that chat's first send records it, and it is dropped if the composer closes without sending. The model and Fast mode selections (advanced flag) are still saved globally, as before.
Production still runs the Go copilot, which ignores the request
effort, so this changes effort behaviour on worker-backed environments only.Test plan
post.test.ts: the effort a turn runs at for a chat with no stored pick (medium), with a stored pick (high,low), and a send pick overriding the stored one; plus simple mode now sendinglowaslow. These failed on the pre-change code (4 red: defaulthigh,lowcoerced tomedium).set-effort.integration.ts(real Postgres): a pick round-trips through the chat load and keepsconversationMode; an untouched chat resolves tomedium; a later pick replaces an earlier one; an out-of-range stored value reads as no pick; another user cannot change the chat.admit-turn.test.ts: the admission write records the send's effort only when one was sent.store.test.ts: a saved global effort is dropped, a new-chat pick is not saved, and Fast mode is still restored.