Feature Request: Expose Claude Code Version and Full Model Context to LLM and Scripts

Title: Feature Request: Expose Claude Code Version and Full Model Context to LLM and Scripts

(Updating this issue with new context based on the latest model documentation, which highlights a complex landscape of model versions, providers, and naming conventions.)

Is your feature request related to a problem? Please describe.
Currently, there is no programmatic way for the Claude LLM or for custom scripts (like hooks or slash commands) to know which version of the Claude Code client is running or which model is active. This problem is more complex than just "Opus vs. Sonnet." The specific model identifier changes significantly based on the service provider (Anthropic API, AWS Bedrock, GCP Vertex AI), and developers often use aliases (e.g., claude-opus-4-1) which point to specific snapshot versions (e.g., claude-opus-4-1-20250805).

This critical environmental context is currently only available to the user through interactive commands like /status, /model, or claude --version. The LLM agent itself and any automation scripts are blind to this information, which limits their ability to be robust, context-aware, and intelligent.

Describe the solution you'd like
I propose a comprehensive solution to make this information programmatically accessible:

1. Contextual Information in System Prompt
The Claude Code client should automatically prepend a line of context to the system prompt, making the LLM aware of its precise environment.

Example:
You are running on Claude Code v1.0.83 using the model claude-opus-4-1-20250805 via the Anthropic API provider.

This would allow the LLM to tailor its responses and tool usage based on its known capabilities and the specific model version's features (like extended thinking or parameter constraints).

2. Rich Environment Variables for Subprocesses
When Claude Code executes a subprocess for a hook or a custom slash command, it should inject a rich set of environment variables describing the session.

Example Environment Variables:

• CLAUDE_CODE_VERSION: 1.0.83
• CLAUDE_CODE_MODEL_PROVIDER: anthropic (or bedrock, vertex)
• CLAUDE_CODE_MODEL_ID: claude-opus-4-1-20250805 (The full, provider-specific model ID)
• CLAUDE_CODE_MODEL_FAMILY: opus (A simplified family name for easier logic)

This would empower scripts with robust conditional logic.

Describe alternatives you've considered

• Scraping /status output: Not feasible, as the LLM cannot run slash commands. This would be a brittle and unreliable workaround for scripts.
• Hardcoding values: This is not scalable given the matrix of models, versions, and providers. It's manual, error-prone, and becomes instantly outdated.

Use Cases and Importance
This feature is essential for building advanced, reliable automations.

1. Provider-Aware Logic: A custom command could adapt its behavior based on the API provider, which has different model naming conventions and potential feature variations.

``bash
# in a custom slash command script
if [ "$CLAUDE_CODE_MODEL_PROVIDER" = "bedrock" ]; then
echo "Using AWS Bedrock-specific instructions..."
else
echo "Using standard Anthropic API instructions..."
fi
``

1. Model-Specific Capabilities: A /review command could leverage the superior reasoning of Opus 4.1 for deep architectural analysis, while falling back to a standard review for Sonnet 4, all within the same script.

``bash
# in a custom /review script
if [ "$CLAUDE_CODE_MODEL_FAMILY" = "opus" ]; then
echo "Performing deep architectural review suitable for an Opus-class model."
else
echo "Performing standard code review."
fi
``

1. Ensuring Production Stability: Scripts could detect if a user is running on a floating alias (e.g., claude-3-7-sonnet-latest) versus a pinned snapshot version, and warn them about potential non-reproducible results in a CI/CD context.

1. Smarter Debugging: Users could ask, "What exact model version am I using?" and get a precise answer like claude-opus-4-1-20250805, which is crucial for reproducing behavior or reporting bugs.

1. Enhanced Telemetry: Custom logging hooks could capture the exact CLAUDE_CODE_MODEL_ID and CLAUDE_CODE_VERSION for precise cost attribution, performance analysis, and A/B testing of different models.

Exposing this context would be a small change with a massive impact, significantly improving the intelligence, robustness, and programmability of the entire Claude Code ecosystem.