[FEATURE]
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Model and effort configuration in Claude Code is currently restricted to two extremes: globally permanent (settings.json) or strictly transient (one-off process flags).
While the /model TUI picker offers a session shortcut and the CLI supports --model and --effort flags, these settings are bound strictly to the active terminal process. They do not attach to the conversation state itself. When a long-running conversation is closed and later restored via --resume <id> or --continue, Claude Code falls back to the global defaults.
This creates a high friction workflow for managing costs on large codebases. There is currently no way to establish a sticky, low-cost baseline (e.g., Haiku + low effort) for a specific complex workspace chat without re-typing launch flags on every single interaction loop or continually altering global configurations.
Proposed Solution
Introduce conversation-bound metadata persistence for model and effort selections.
Ideally, this would allow a user to explicitly scope a choice to the current chat history. For example:
- Interacting with an in-session command like
/model haiku --this-conversationor a dedicated/pin-modelcommand. - This preference is then serialized directly into the local conversation's state metadata file.
- When a user later executes
claude --resume <id>orclaude --continue, Claude Code automatically reads the conversation metadata, respects the pinned model/effort tier, and bypasses the globalsettings.jsondefaults for that specific session without requiring manual launch flags. - This pinned baseline should still be explicitly overridable by a one-off CLI launch flag (e.g.,
claude --resume <id> --model opusfor a single high-effort prompt).
Alternative Solutions
- Manual Flag Fatigue: Constantly remembering to append
--model haiku --effort lowevery single timeclaude --resumeorclaude --continueis run. If forgotten once, the session defaults to expensive models, wasting tokens. - Global Config Shuffling: Frequently changing global defaults back and forth via
/model. This is highly error-prone as it accidentally leaks low-effort settings into brand-new projects or parallel terminal windows where high-effort models are preferred.
Priority
Medium - Would be very helpful
Feature Category
Configuration and settings
Use Case Example
- Step 1: A user opens a Claude Code session in a very large repository to handle routine documentation formatting and minor test syntax updates.
- Step 2: Recognizing this task doesn't require maximum reasoning, the user runs
/model haiku --this-conversationand/effort low --this-conversationto restrict costs. - Step 3: The user closes their terminal or switches branches to attend a meeting, terminating the active process.
- Step 4: The next day, the user returns to the task and runs
claude --resume. - Step 5: Claude Code boots up and inherently knows to continue using Haiku + low effort for this specific chat context, while any fresh terminal window opened for a different project still correctly defaults to Opus + high effort.
Additional Context
Distinct from Process Isolation Issues (#49166, #51383, #42673)
Please note that this is not a duplicate of existing tickets addressing configuration leakage:
- #49166, #51383, and #42673 track a runtime bug where changing a model in one active window unexpectedly clobbers parallel, concurrent terminal sessions in real-time.
- #45453 and #46382 deal with serialization bugs in
settings.jsonupon initial startup.
Why this request is unique: The community is currently asking for transient process isolation (making concurrent windows stop talking to each other). This request instead introduces durable conversation-bound state. It asks for environment preferences to be baked directly into the conversation history lifecycle so that a chat's economic baseline survives across process termination and system reboots.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗