Pinned model, versioned prompts and plugin dependencies

Four services read the model from the same environment variable, CLAUDE_MODEL. Someone updates it to the newest model to take advantage of it in one of them, and two of the other three break that same afternoon. At the same time, support asks what the onboarding prompt said three weeks ago, and nobody knows. Both problems have the same name: configuration management.

What configuration is in a Claude system

Everything that changes behavior without changing the application code:

• the model ID and its parameters (max_tokens, effort, enabled tools);
• prompts and their templates;
• in Claude Code, CLAUDE.md, .claude/settings.json, skills, agents and plugins (where each one goes is in the Claude Code lesson);
• keys, which are not versioned configuration: they go in a secrets manager, never in the repo.

The general rule: whatever defines behavior lives in versioned files, changes through a pull request, and there’s a record of which version ran at each moment.

Pinning the model version

Every API model ID is a fixed version (a snapshot): it doesn’t change behavior on its own. Model version pinning means each service declares its explicit ID in its versioned configuration and changes it like any other change:

1. The new model is tested against that service’s evaluations.
2. If it passes, the ID is updated in that configuration, through a pull request.
3. It’s rolled out gradually, with a way to roll back.

A variable shared across services pushes the same change into all of them at once, untested. Each service has its own evaluations and its own pace.

Versioning prompts

Prompt versioning treats the prompt as code:

• it lives in version control, not in a dashboard anyone can edit live;
• it’s deployed with the same pipeline as everything else, with its regression tests;
• every call records which prompt version it used (and which model ID), along with the request ID.

That way you can answer which text was in production for any conversation, compare versions with data and roll back one that made things worse.

Plugins and their dependencies

In Claude Code, plugins package skills, agents, hooks and MCP servers. So the whole team has the same ones:

• the internal marketplace is declared in extraKnownMarketplaces and the plugins in enabledPlugins, inside the project’s .claude/settings.json;
• the plugin manifest (plugin.json) has a version field; when it’s set, users stay on that version until the author changes it;
• if a plugin needs another one to work, it’s declared in its dependencies, in the same plugin.json, with the name and, if needed, a compatible version. That way, installing the plugin also brings the one it needs.

Asking everyone to install by hand whatever an announcement says ends with machines missing plugins and mixed versions.

The typical traps

• Using a shared variable or “the latest model” in production, without per-service evaluations.
• Editing prompts live with no version control and no record of which version ran.
• Putting keys in the same configuration file that gets committed.
• Resolving dependencies between plugins with a message in the team chat.
• Thinking a pinned model is forever: models get retired and the migration has to be planned.

On the exam

If a service broke because the model changed “by itself”, look for the explicit per-service ID in versioned configuration, changed after passing evaluations. If nobody knows which prompt was running, look for prompts in version control with the version recorded on each call. If a plugin fails because another is missing, look for dependencies in its plugin.json.