I merged a PR today that updated every reference to claude-3-haiku in Sabine Super Agent to claude-3-5-haiku-latest. Not exactly the kind of work that makes for exciting product announcements, but it's the kind of maintenance that keeps production systems healthy.
Why This Matters
Anthropic deprecated the original claude-3-haiku model identifier in favor of the new versioning scheme. When you're running an autonomous agent that handles everything from email intelligence to shopping coordination, you don't want to wake up to deprecation warnings—or worse, broken API calls.
Sabine uses Haiku extensively for fast, lightweight tasks: parsing emails, extracting metadata, generating quick summaries. It's the workhorse model that handles high-frequency operations where speed and cost matter more than maximum reasoning capability. That makes this migration table stakes—if Haiku stops working, Sabine stops working.
What Changed
The update touched every part of Sabine's codebase that specifies model identifiers: agent configuration files, API client initialization, fallback logic, and test fixtures. The -latest suffix is Anthropic's new convention for automatically tracking the most recent stable version of a model family without requiring constant manual updates.
This is the kind of change where you want to be deliberate. I didn't just find-and-replace across the repo. I reviewed each reference to understand context: Is this a default? A fallback? A test fixture? Does this path handle model version mismatches gracefully? Better to spend 20 minutes now than debug a production issue later.
What I Learned
Running an autonomous agent in production means you're dependent on external APIs in a very real way. Model versioning, deprecation schedules, and breaking changes aren't abstract concerns—they're operational risks. This is one reason I track Anthropic's changelog and have alerts set up for their API updates.
It also reinforced something I've been thinking about: the value of boring infrastructure work. Sabine didn't get smarter today. No new features shipped. But the system is more resilient, and I prevented a future failure mode. That's the kind of work that doesn't show up in demo videos but makes the difference between a prototype and a production system.
What's Next
This migration is complete, but it surfaces a broader question: how do we handle model versioning systematically across all Strug City products? Sabine, Strug Works, and the platform layer all interact with multiple LLM providers. I'm considering building a centralized model registry—a single source of truth for which model identifiers we use where, with automated checks to flag deprecated references before they become production issues.
For now, Sabine is current, healthy, and ready to keep doing what she does best: managing the chaos so I can focus on building.