Model operations: models are configuration

The model id in your code is not a constant; it is a deployment decision wearing a constant's clothes. Change it and the platform's behavior, cost, latency, and failure modes all shift at once, which is exactly the profile of a change that deserves engineering process rather than a one-line commit. This closing chapter of the model plane covers that process: pinning versus tracking, the upgrade playbook, degrading gracefully when the plane has a bad day, and the portfolio discipline that decides which model earns which job.

Pin or track

The id dialects encode a real choice. A dated snapshot id (...claude-opus-4-5-20251101-v1:0) pins: the same weights forever, reproducible to the byte, and eventually deprecated out from under you. An undated id (anthropic.claude-opus-4-8) tracks: the vendor's current revision of that model, fresher behavior, and the possibility that Tuesday's model is subtly not Monday's.

The platform answer is boring and correct: pin in production, track in evaluation. Production fleets run a pinned id that changes only through the playbook below; a standing eval job tracks the latest and reports drift, so upgrades are decisions made on evidence rather than surprises absorbed in production. And the id itself lives in configuration (per environment, per role), never inline in code, because "which model does the verifier fleet use in staging" must be answerable and changeable without a deploy.

Don't be confused: alias vs snapshot. An undated id is an alias, a pointer the vendor moves; a dated id is a snapshot, a value that never changes. The git analogy holds precisely: branch versus commit. You would not deploy production from main without knowing which commit you got; the dated id is how you know.

The upgrade playbook

A model upgrade is a deploy of the platform's most influential component, so it ships like one. Five steps, none optional at fleet scale:

1. Baseline. Your eval suites (Part 9) run continuously against the pinned production model, so today's scores exist before any candidate appears. Without a baseline, step 2 produces numbers with nothing to mean.
2. Evaluate the candidate. Same suites, candidate id, plus the replay corpus: recorded production ledgers from Chapter 10 re-run against the new model, diffed for behavioral shifts on your traffic, not the vendor's benchmarks.
3. Expect the meters to move. New model generations can count tokens differently (tokenizer changes have historically shifted counts by double-digit percentages), which silently re-prices budgets, quota math, and context headroom. Re-run the lab catalog arithmetic with measured counts; never carry token budgets across a model boundary unexamined.
4. Canary. A slice of production traffic (one tenant, one work-unit type, a few percent of runs) moves to the candidate behind the config flag, with the token ledger and eval gates watching. Agent regressions are behavioral and emerge across turns; canaries catch what suites cannot.
5. Roll out with the rollback written first. The old pin stays in config, one edit away, until the new one has survived a full workload cycle. Remember from caching that entries are model-scoped: the switchover hour runs cold, so budget a transient cost bump in both directions, including the rollback you hope not to execute.

When the plane degrades

Model planes have bad days: a region browns out, latency triples, error rates climb. The platform's posture comes from the reliability half of the production bar, applied to the model as a dependency like any other, with one agent-specific twist per mechanism:

• Timeouts with intent. A hung model call holds a worker, its lease, and its budget. Set timeouts from your own latency ledger (generous for long-thinking turns, not infinite), and treat a timeout as a retryable event in the event store, which makes hangs visible and countable instead of mysterious.
• Retry with the storm in mind. Chapter 14's lesson applies to errors too: fleet-wide synchronized retries against a degraded region are a second storm. Jittered backoff through the governor, and the circuit-breaker pattern (after N consecutive failures, stop trying for a cooling period and fail fast) protect both you and the recovering service.
• Fallback chains, in order of sameness. First choice: the same model through a wider profile (global. routing exists precisely so a regional bad day is survivable without behavioral change). Second: a pinned sibling model known to your eval suite, accepting measured behavioral drift to stay alive. The chain is configuration, exercised in drills, because a fallback first executed during an outage is a hypothesis, not a mechanism. And every fallback decision lands in the event ledger, so post-incident analysis can separate "the model was degraded" from "our handling of it was."

Degradation, like everything else on this plane, is a portfolio property: if the fleet's phases already run on different models and tiers, a bad day for one is a limp, not a halt.

The portfolio

Which brings us to the discipline the whole part has been building toward. A fleet that sends every call to the frontier model is overpaying in the exact way the use-case gallery warned against: spending judgment tokens on non-judgment work. The tiers (using the book's snapshot prices per million tokens) differ by an order of magnitude:

The portfolio pattern assigns models to roles, not to the platform: the planner that shards a run thinks with the frontier model; workers execute shards on the middle tier; a small model pre-filters findings before the frontier-tier verifier panel spends real tokens on what survives. Hive's configuration makes the assignment explicit per role, which also means steps 1 through 5 above run per role, and a Haiku-tier upgrade never waits on an Opus-tier canary.

Two cautions keep the pattern honest. Cheap models are cheap per token, not per outcome: a small model that needs three attempts and a repair pass can out-cost the middle tier doing it once, so portfolio decisions cite eval scores and the ledger, not the price table alone. And verification deserves the best judge you can afford, not the cheapest that usually agrees: Part 6 returns to this when the verification mesh gets designed, with numbers.

The model plane, closed

Part 2 in one breath: requests authenticate with IAM and enter through three doors (Chapter 11); caching turns the stateless re-reading tax into a 4x discount for anyone who freezes their prefix (Chapter 12); control belongs on the lowest rung that can express it (Chapter 13); the quota is a shared pipe that deliberate fleets share deliberately (Chapter 14); and the models themselves are configuration, upgraded through gates and assigned to roles by evidence. The model plane is now a component with an operating manual, which is what the swarm chapters ahead require it to be.

👉 Next, per the map: Part 3 dissects AgentCore, the managed runtime, component by component against the DIY equivalents this book builds. Those chapters land after the parts they compare against; the map tracks what is written.