# \[Bug\]: New threads in the same project do not preserve the last-used model and working-mode settings · Issue \#6508 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/6508)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/6508)

---

### Before submitting

- [x] I searched existing issues and did not find an open issue covering the full same-project preference behavior.
- [x] I included enough detail to reproduce or investigate the problem.

### Area

apps/web (including the desktop app's shared web UI)

### Steps to reproduce

1. Open an existing project and start a new thread.
2. Select a non-default provider/model.
3. Change one or more model options, such as reasoning/effort, fast or service tier, context window, or thinking.
4. Optionally change the runtime/permission mode or interaction mode.
5. Send the first message so those settings are actually used.
6. Create another new thread in the same project.
7. Inspect the new-thread composer settings.

### Expected behavior

A new thread should consistently inherit the target project's last successfully used safe composer preferences:

- provider instance and model;
- the complete model-options snapshot;
- runtime/permission mode;
- interaction mode.

Every new-thread entry point should use the same precedence:

1. Explicit choices already made in the unsent draft.
2. An explicitly configured project default model, when present.
3. The target project's last-used working mode.
4. Global/provider defaults.

Web/desktop and mobile should resolve these defaults consistently.

Branch, worktree path, environment mode, and start-from-origin should not carry implicitly; those should continue to use their configured workspace defaults.

### Actual behavior

The new thread can reset model settings or inherit global/currently viewed-thread state rather than remembering the settings last used in the target project. The behavior depends on how and from where the new thread is created.

### Impact

Major degradation or frequent failure

Repeatedly reselecting the model and its options is error-prone. Starting with the wrong reasoning level, service tier, permission mode, or provider instance can also affect cost, limits, and the permissions granted to the turn.

### Version or commit

Current desktop app; exact build not available.

### Environment

Desktop client using the shared web UI.

### Logs or stack traces

No relevant logs observed.

### Screenshots, recordings, or supporting files

None currently available.

### Workaround

Manually re-check and reselect every composer setting before starting each new thread.

### Related issues

- #1276 tracked the model-only same-project case and was closed as fixed, so this report may be a regression or a remaining entry-point gap.
- #5796 tracks an explicit project default being overridden by another project's sticky model.
- #2662, #2324, and #1991 track narrower permission-mode, per-model reasoning, and plan-mode defaults.