Claude Code release notes: 2.1.175 locks model policy

This is not a huge Fable launch. For many teams, it is more useful than that: Claude Code 2.1.175 makes it harder for an agent to land on the wrong model just because Default points there.

Claude Code is Anthropic's coding agent in the terminal and IDE. A model policy is the list and rule set that says which Claude models a team may use. In 2.1.175, admins can enable enforceAvailableModels, so availableModels constrains the Default model too. If Default would resolve to a disallowed model, it falls back to the first allowed model, and user or project settings can no longer widen a managed list.

Source: Claude Code changelog 2.1.175

Why Claude Code 2.1.175 matters for practical teams

Once Claude Code moves into real workflows, model choice becomes an operations question, not just a preference. One developer may want to test Fable 5. Another team may want to stay on Sonnet for cost and speed. A school organization or agency may need the same model choice across projects, so the work can be explained afterward.

The useful release notes signal is that Default does not have to be a side door around the managed list. That makes the policy easier to review: which models are allowed, which model is used when someone selects Default, and what happens if a local setting tries to go wider than the policy?

Anthropic also documents that Claude Code settings have several scopes: Managed, command line arguments, Local, Project, and User. Managed has the highest priority and cannot be overridden. That is the level to use when a team wants the same baseline rules on several machines.

Source: Claude Code settings: configuration scopes

2.1.174 gives better receipts around model choice

The strongest signal today is 2.1.175, but 2.1.174 makes the same theme more useful day to day. It fixes several things around the /model picker, including how Opus and Sonnet appear on different plans and how a saved advisor model behaves when availableModels blocks it.

The same version adds usage attribution in the VS Code Account & usage view (/usage): cache misses, long context, subagents, and breakdowns per skill, agent, plugin, and MCP server over 24 hours or 7 days. MCP, the Model Context Protocol, is the standard Claude uses to connect to external tools and data sources.

Source: Claude Code changelog 2.1.174

How to use this signal this week

Do not start with a big policy exercise. Start with one workflow where Claude Code already helps, such as code review, documentation updates, or test generation. Write down three things before changing anything:

• Which models may the agent use for this workflow?
• Who may change the Default model?
• Where is the receipt saved: version, selected model, usage, transcript, and human approval?

For safe integration, simple controls often go a long way: scoped API keys, secrets in a secret manager, environment variables instead of pasted keys, redacted logs, approval gates, and a short audit log per run. That lets agents work against real repos and tools without turning everything into informal chat work.

This is Tool Forge territory: connect Claude to files, repos, MCP servers, and internal tools, but make model choice, permissions, and receipts understandable before adding more agents.

Try this prompt this week

Human step: Check the installed Claude Code version through your team's normal routine. The docs say claude --version shows the installed version. Then put your Claude Code settings, any availableModels policy, and a recent /usage screenshot or export beside the workflow.

Source: Claude Code changelog: version check

Read our Claude Code configuration, availableModels rule,
and latest usage receipt for [workflow].
Tell me which model Default should actually resolve to,
which local settings would break the policy,
and what human approval is needed before the next run.
Suggest one small first change. Do not change anything until I approve.

Good output should show:

• Which model is used when someone selects Default
• Whether a local or project setting is trying to widen the policy
• Which /usage or log receipt should be saved
• What a human must approve before the agent continues