claude-code - 💡(How to fix) Fix [FEATURE] Feature request: session-level override for slash command / agent frontmatter `model:` field

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• 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.
2. CLI flag, e.g. claude --force-model <model-id> or claude --ignore-command-model — same effect, opt-in per launch.
3. 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