Model Pinning and Plugin Dependency Versions in Claude Code

1.Aliases move, full names pin

You can give Claude Code a model as an alias or as a model name. An alias such as sonnet or opus points at the latest model in that family, so what it resolves to depends on your provider and changes when a new model ships. If you need a fixed version, use the full model name. On Amazon Bedrock that means an inference profile ARN, and on Microsoft Foundry it means a deployment name.

Environment variables such as ANTHROPIC_DEFAULT_SONNET_MODEL and ANTHROPIC_DEFAULT_FABLE_MODEL control what each alias resolves to. That is how you pin a version on a provider that uses its own model IDs. Two values are not ordinary aliases. default clears any override and returns to your account's default, and opusplan plans with opus and then executes with sonnet.

Sources1

2.Which model setting wins

You can set the model in five places: /model during a session, the --model flag at launch, the ANTHROPIC_MODEL environment variable, the model field in any settings file, and ANTHROPIC_DEFAULT_MODEL for new sessions. Putting the model in the committed project settings file sets it for the whole team:

{
    "permissions": {
        "allow": ["Bash(npm run lint)"]
    },
    "model": "opus"
}

When you run /model, it saves your choice to ~/.claude/settings.json, but that choice can be outranked. A model value in project or managed settings, ANTHROPIC_MODEL in your shell, or an organization default that is set to override user choices applies again at every launch. When project or managed settings set the model, the startup header names the file responsible. Some choices last for one session only: --model, pressing s in the picker, and /model in non-interactive mode. A session you resume with --resume or --continue usually keeps the model it was already using.

Sources1

3.Locking the model list with availableModels

A managed model only decides which model a session starts on, and users can still switch with /model. The actual lock is availableModels. It limits /model, --model and the model key in users' own files. It also covers subagent models, skill frontmatter and the alias environment variables.

{
  "availableModels": ["sonnet", "haiku"]
}

Sources1

4.Prompt versioning: what these sources cover

The exam guide lists prompt versioning, but the Claude Code documentation used for this lesson has no mechanism for versioning prompts sent to the Messages API. It only describes versioning the instructions Claude Code itself reads. Project CLAUDE.md files and .claude/settings.json are shared by committing them, so git history becomes their version history. A change to a team instruction is then a reviewed commit, not an edit on one person's machine. For prompts inside your own application, look for versioning practice in API-side material. It is not documented here.

Sources2

5.Plugin dependencies and semver ranges

A plugin declares the other plugins it needs in the dependencies field of its plugin.json. A dependency can be a bare name, or an object with a semver range such as ~2.1.0, ^2.0, >=1.4 or =2.1.0. Claude Code installs the highest git tag that satisfies the range, which means ranges only work if the maintainer tags releases. The convention is {name}--v{version}, for example secrets-vault--v2.1.0, and claude plugin tag --push creates and pushes the tag. The command refuses to run if the tag already exists or if the working tree is not clean.

{
  "name": "deploy-kit",
  "version": "3.1.0",
  "dependencies": [
    "audit-logger",
    { "name": "secrets-vault", "version": "~2.1.0" }
  ]
}

A dependency from another marketplace is blocked unless the root marketplace lists that marketplace in allowCrossMarketplaceDependenciesOn. For local development, claude --plugin-dir ./my-dependency --plugin-dir ./my-plugin loads both plugins without checking versions. If you leave the dependency's --plugin-dir flag off, the dependency shows up as not installed.

Sources34

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Setting "model": "sonnet" pins the team to one Sonnet version.Why is that wrong?

   An alias points at the latest model in its family and resolves differently on each provider. A full model name is what fixes the version.

   Covered in Aliases move, full names pin

2. 2.Putting a model in managed settings stops users from switching to another model.Why is that wrong?

   A managed model only sets the starting model, and /model can still change it. availableModels is the setting that restricts the choice.

   Covered in Locking the model list with availableModels

3. 3.Bumping the version in plugin.json is enough for dependents with a semver range to receive the new release.Why is that wrong?

   Ranges resolve against git tags, so the maintainer has to create a {name}--v tag for the release, for example with claude plugin tag --push.

   Covered in Plugin dependencies and semver ranges

Practise it for real

Watch model precedence decide which model a Claude Code session starts on

1. 1.Add "model": "opus" to .claude/settings.json in a test project and launch claude.

   Why: A model in project settings applies at every launch.

   You should see: The startup header names the settings file that set the model.

2. 2.Exit, then launch claude --model sonnet in the same project.

   Why: --model applies to this session only.

   You should see: The session runs on sonnet, and your saved default in ~/.claude/settings.json is unchanged.

3. 3.Launch plain claude again, then run /model sonnet and press s in the picker.

   Why: Pressing s switches the model for this session only.

   You should see: The next plain launch goes back to the opus model set in project settings.