[FEATURE] Feature request: session-level override for slash command / agent frontmatter `model:` field

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

Problem Statement

Slash commands and agents support a model: field in their YAML frontmatter
that pins the command to a specific model. This field always takes precedence
over the session's active model — there is no way to override it.

This becomes a problem when launching Claude Code against a model that differs
from what the commands were pinned to (for example, a local Ollama model or
an OpenAI-compatible endpoint). Every command in the user's library still
tries to dispatch to its pinned Anthropic model, ignoring the session's actual
configuration.

Users with libraries of model-pinned commands currently have no clean way to
run those commands against a different model without modifying the .md
files themselves — by stripping model: lines, maintaining mirror
directories, or creating project-local shadow .claude/ folders. All of
these workarounds are fragile, require careful cleanup on session exit, and
risk leaving the command library in an inconsistent state if the session
crashes.

The current precedence is fixed and one-directional:

Frontmatter model: > Session model (/model or --model flag) > Default

There is no mechanism to invert this precedence for a given session, even
though the use case — "run my entire command library against a different
model temporarily" — is legitimate and increasingly common as users mix
hosted and local models in their workflows.

Proposed Solution

Summary

Allow a session-level mechanism (env var or CLI flag) to override the model:
field set in slash command / agent frontmatter, so that all commands invoked
in that session run on the chosen model regardless of their pinned value.

Motivation

The model: frontmatter field is a powerful way to pin specific commands to
specific models (Haiku for cheap mechanical tasks, Opus for design work, etc.)
and I use it heavily across my workflows.

However, when I launch Claude Code against a local model (e.g. via an Ollama
wrapper / OpenAI-compatible endpoint), every command still tries to dispatch
to its pinned Anthropic model. There is currently no way to say "for this
session, ignore all model: overrides and use the session model instead."

Workarounds today all involve mutating the .md files themselves (stripping
or commenting model: lines, maintaining mirror directories, project-level
shadow .claude/ folders, etc.), which are fragile and require trap-based
cleanup to avoid leaving workflows in an inconsistent state on crash.

Proposed solution

Any one of the following would solve it:

1. Env var, e.g. CLAUDE_FORCE_MODEL=<model-id> — when set, takes

precedence over model: in command/agent frontmatter for the session.

1. CLI flag, e.g. claude --force-model <model-id> or

claude --ignore-command-model — same effect, opt-in per launch.

1. Settings key, e.g. forceModel in ~/.claude/settings.json or

per-project settings, with the same precedence rule.

Option 1 or 2 would be the most useful for wrapper scripts launching local
models.

Current precedence (for reference)

Frontmatter model: > session model (/model or launch flag).

Requested precedence (when override is active)

CLAUDE_FORCE_MODEL / --force-model > frontmatter model: > session model.

Use case

I maintain a library of workflows pinned to specific Anthropic models for
cost/quality reasons. I also want to occasionally run the same workflows
against a local model (Ollama / qwen / etc.) for offline work or
experimentation, without editing or duplicating the workflow files.

Additional context

Related: there's no CLAUDE_COMMANDS_DIR env var to redirect command
lookup either, so the only non-destructive workaround today is generating
a project-local .claude/commands/ mirror — which conflicts with projects
that already have their own .claude/ directory.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_