Skip to content

[codex] Add default service tier setting#593

Draft
SamsurTee wants to merge 1 commit intoDimillian:mainfrom
SamsurTee:codex/default-fast-mode
Draft

[codex] Add default service tier setting#593
SamsurTee wants to merge 1 commit intoDimillian:mainfrom
SamsurTee:codex/default-fast-mode

Conversation

@SamsurTee
Copy link
Copy Markdown

What changed

This adds a persistent default service tier setting to CodexMonitor and exposes it in Settings under Codex -> Default parameters.

Users can now choose a default Service tier (default / off, fast, or flex) that applies whenever a workspace or thread does not already have a thread-scoped override.

Why this changed

Fast mode was previously only persisted as workspace-local UI state in thread parameter storage. That meant existing workspaces could remember Fast mode once /fast had been used, but newly created projects did not inherit any default and always started with Fast mode off.

Model and reasoning effort already had app-level defaults, but service tier did not. This change makes service tier behave consistently with those existing defaults.

User impact

Users can now set Fast mode as the default for new projects without needing to run /fast in each workspace.

Behavior after this change:

  • existing explicit per-thread service tier overrides still win
  • an explicit thread-scoped off (null) still disables Fast mode
  • when no workspace/thread override exists, CodexMonitor falls back to the saved global default service tier

Root cause

serviceTier was stored only in thread/workspace local storage, while AppSettings persisted only lastComposerModelId and lastComposerReasoningEffort. New projects therefore had no saved __no_thread__ service tier seed to inherit from.

Validation

  • npm run typecheck
  • npm run test -- src/features/app/orchestration/useThreadOrchestration.test.ts src/features/threads/utils/threadCodexParamsSeed.test.ts src/features/settings/components/SettingsView.test.tsx

Notes

I did not run Rust-side compilation in this environment because the local machine did not have the Rust toolchain installed yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant