modelOverrides Setting for Custom Provider Model IDs

Enterprise Model Routing Gets a Dedicated Setting

Claude Code 2.1.73 introduces modelOverrides, a new settings field that gives enterprise teams fine-grained control over how model picker entries map to provider-specific model identifiers. The feature is primarily aimed at organizations running Claude Code against Amazon Bedrock application inference profiles, though it works equally well with other custom provider endpoints.

The Problem It Solves

On AWS Bedrock, enterprise customers commonly create application inference profiles — custom ARNs that wrap specific model versions with organization-specific throttling, logging, and cost controls. Prior to this release, Claude Code's model picker had no way to associate a user-visible name (like "Claude Opus 4.6") with a distinct ARN. All entries within a model family resolved to the same environment variable, making it impossible to switch between a production Opus 4.6 profile and a development Opus 4.5 profile using the /model command.

A parallel bug was also fixed in the same release: subagents configured with shorthand model values (model: opus, model: sonnet, model: haiku) were being silently downgraded to older model versions on Bedrock, Vertex, and Microsoft Foundry. Both issues effectively prevented users from reliably targeting the model version they intended.

How modelOverrides Works

The new setting lives in the Claude Code settings.json file and accepts a map from canonical model name to provider-specific model ID or ARN:

{
  "modelOverrides": {
    "claude-opus-4-6": "arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/opus-46-prod",
    "claude-opus-4-5-20251101": "arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/opus-45-staging"
  }
}

When a user selects one of these models in /model, Claude Code substitutes the mapped ARN in the API call. Entries without an override fall back gracefully to the built-in Bedrock model ID or any inference profile already discovered at startup — so teams can adopt modelOverrides incrementally without needing to map every model upfront.

Managed Settings Support

Because modelOverrides lives in settings.json, it is fully composable with managed (policy-level) settings, which enterprise administrators can push to all users in their organization. This means a platform team can centrally define the canonical ARN mapping for each model, ensuring every developer's model picker routes to the correct organizational profile without requiring individual configuration.