Claude Code’s New Model-Switch Hooks, Explained

A new way to control what model your session runs on

Claude Code’s August 2026 changelog added something genuinely new to the hooks system: PreModelSwitch and PostModelSwitch events. Until now, a model switch mid-session – moving from a faster model to a stronger one, or vice versa – happened silently as far as your hook configuration was concerned. These two new events make model-switch hooks a first-class part of Claude Code’s automation surface, alongside the existing PreToolUse, PostToolUse and SessionStart hooks.

What PreModelSwitch and PostModelSwitch actually do

PreModelSwitch fires just before a session’s model changes, and can block the switch outright, ask for confirmation, or simply annotate what’s about to happen. PostModelSwitch fires immediately after, so you can log the change, adjust downstream tooling, or trigger anything else that depends on knowing which model is now active.

• Block – stop a switch from happening at all, e.g. preventing a downgrade mid-task on work that needs the stronger model throughout
• Confirm – require an explicit yes before the switch proceeds, useful on cost-sensitive or compliance-sensitive setups
• Annotate – just record that it happened, without changing the outcome, for audit logs or team dashboards

Why this matters more than it sounds

Model choice has always been something you set at session start and mostly left alone. Claude Code’s own effort-dial and auto-routing features increasingly change models during a session based on task complexity – which is powerful, but previously invisible to anything watching from outside. Model-switch hooks close that gap: a team running Claude Code behind a spend-limited gateway, or with strict policy about which model can touch which repo, now has a real enforcement point instead of relying on developers to self-police.

A simple example

A minimal PreModelSwitch hook that blocks any switch to a lower-tier model on a specific project might look like this in your hooks configuration:

{
  "PreModelSwitch": [
    {
      "matcher": "downgrade",
      "hooks": [{ "command": "./scripts/block-downgrade.sh" }]
    }
  ]
}

The script itself just needs to exit non-zero to block the switch – the same pattern already used by PreToolUse hooks, extended to a new event type.

The other August change worth knowing: Claude Fable 5.1

Alongside the hooks update, Claude Fable 5.1 became the default Fable model, now running with a 1M-token context window. Fable models are tuned differently from the main Claude line – if your session or subagents lean on Fable for specific tasks, the larger context window means noticeably less need to trim or summarise long inputs before handing them off.

Where this fits with the rest of August’s changes

• Live streaming of a foreground subagent’s tool calls to Remote Control clients (background subagents still show status-only) – a separate observability improvement, distinct from model-switch hooks but shipped the same month
• SessionStart resume hooks now receive session staleness and an estimated re-cache cost, so a hook author can decide programmatically whether resuming is worth it versus starting fresh

Should you write a model-switch hook?

1. If you’re on a shared or cost-limited setup, a PreModelSwitch hook that confirms or blocks unexpected switches is a genuinely useful guardrail worth setting up now
2. If you just want visibility, a lightweight PostModelSwitch hook that logs to a file or webhook is a five-minute addition with real audit value
3. If your workflow never changes models mid-session anyway, this is safe to ignore for now – it’s additive, not a breaking change to existing hook configurations

Small, mechanical-sounding changes like this tend to matter more in practice than they look on a changelog line – model-switch hooks are the kind of thing you don’t need until the one time a switch happens somewhere you didn’t expect it to.