Model Version Pinning for the Claude Developer Exam

Why pin a model version

Configuration management is about making a system's behavior deliberate and reproducible, and the model your application calls is one of the most consequential pieces of configuration you set. Model version pinning is the practice of specifying a fixed model version so the application behaves the same way across deployments. Instead of asking for "the latest" and accepting whatever that resolves to, you pin an exact version and get the same behavior every time you deploy. The Claude Certified Developer - Foundations (CCDV-F) exam covers this under Task Statement 2.6, Configuration Management, at understand level.

Pinning is part of the same discipline as the rest of Task Statement 2.6. Just as CLAUDE.md and settings.json configuration makes standards and operational behavior explicit and shared, model pinning makes the model explicit and stable. And it slots into the broader release picture described in prompt versioning and plugin dependencies, where the model, prompt, and plugin versions are tied together into one coherent, reproducible release.

Reproducibility is the payoff

The core reason to pin is reproducibility. A pinned model version keeps behavior stable across deployments: the outputs you validated last week are the outputs you get this week, because the model producing them has not changed underneath you. That stability is what lets you reason about your application at all. If the model can shift at any moment, then every behavior you observed yesterday is only provisionally true, and you can never be sure whether a change in output came from your own code or from the model quietly moving.

That is exactly the failure an unpinned model creates. An unpinned model can shift its outputs without any change to your code, because an upstream model update changes what "the latest" resolves to. Nothing in your repository changed, yet the application now answers differently, formats differently, or makes different tool-use decisions. The exam wants you to recognise that this is a reproducibility break: the same inputs no longer reliably produce the same behavior, and the cause is configuration you left unfixed rather than a bug you introduced.

Upgrades are deliberate, and revalidated with evals

Pinning does not mean freezing forever. Models improve, and you will want to move to a newer version. The point of pinning is that the move becomes a deliberate decision rather than something that happens to you. Because a model update can change behavior, an upgrade is treated as exactly what it is: a change. And like any change that can alter behavior, it is revalidated with evals before it reaches production.

This is the piece candidates most often drop. It is not enough to pin and then, when upgrading, simply bump the version and ship. A newer model can behave differently on your specific prompts and tasks even when it is better on average, so you rerun your evaluation suite against the new version to confirm the behavior you depend on still holds. Only then does the upgrade go out. Pinning gives you the control; evals are how you exercise that control responsibly. Together they turn model changes from surprises into managed, verified transitions.

What the exam tests you on

Model pinning sits in Domain 2, Applications and Integration, the highest-weighted domain on the CCDV-F exam at roughly 33 percent, and it is assessed at understand level. Two traps recur, and they are mirror images of each other.

The first trap is leaving the model unpinned and being surprised when behavior changes after an upstream release. Any scenario where an application's outputs shift with no code change, and the model was requested as "latest" rather than a fixed version, is exhibiting this fault. The fix is to pin the version so behavior is stable and changes only when you choose.

The second trap is upgrading a pinned model without rerunning evals. Pinning is only half the discipline; the other half is validating each upgrade. A team that bumps to a new model version and ships without re-evaluating has surrendered the very reproducibility that pinning was meant to protect, because they cannot be sure the new model still behaves as their application requires. The correct instinct is to gate every model upgrade behind an eval pass.

Worked example

How it shows up on the exam

Questions usually describe behavior that changed without a code change and ask for the cause, where the answer is an unpinned model that moved after an upstream release, or they describe a team upgrading and ask what step is missing, where the answer is rerunning evals. Hold the pairing in mind: pinning buys stability, and evals are how you spend a deliberate upgrade safely. An application that does both keeps its behavior reproducible and its improvements verified.

Model pinning rarely stands alone. It is one strand of the same release discipline as prompt versioning and plugin dependencies, and it rests on the configuration foundations in CLAUDE.md and settings.json configuration.