[FEATURE]

Resolved 💬 4 comments Opened May 29, 2026 by tmarquart-gmo Closed Jul 2, 2026

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-conversation or a dedicated /pin-model command.
  • This preference is then serialized directly into the local conversation's state metadata file.
  • When a user later executes claude --resume <id> or claude --continue, Claude Code automatically reads the conversation metadata, respects the pinned model/effort tier, and bypasses the global settings.json defaults 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 opus for a single high-effort prompt).

Alternative Solutions

  1. Manual Flag Fatigue: Constantly remembering to append --model haiku --effort low every single time claude --resume or claude --continue is run. If forgotten once, the session defaults to expensive models, wasting tokens.
  2. 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

  1. Step 1: A user opens a Claude Code session in a very large repository to handle routine documentation formatting and minor test syntax updates.
  2. Step 2: Recognizing this task doesn't require maximum reasoning, the user runs /model haiku --this-conversation and /effort low --this-conversation to restrict costs.
  3. Step 3: The user closes their terminal or switches branches to attend a meeting, terminating the active process.
  4. Step 4: The next day, the user returns to the task and runs claude --resume.
  5. 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.json upon 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗