Sonnet 4.6 Is Out — I Found Out From a Chat, Not a Changelog

"Change one line in the alias resolver." That was supposed to be enough.

In the previous post, I wrote about surviving a Claude API model migration with an alias system. I said at the end of that article that the next migration would be trivial — and it got tested sooner than I expected. The twist this time: I didn't find out about the new model from release notes. I found out mid-conversation with Claude Code.

It started with "which model are we using right now?"

Mid-task, I got curious about my repo's configuration — specifically whether the Claude model used inside our workflow engine was up to date.

❯ Can you check which Claude model we're currently using?

Claude Code (running on Opus 4.6) searched the code and reported back.

● Default is opus (claude-opus-4-6), defined in src/core/claude-agent-client.ts.
  Aliases: opus/sonnet/haiku → claude-opus-4-6 / claude-sonnet-4-5 /
  claude-haiku-4-5.

Opus is on 4-6. Sonnet and Haiku are still on 4-5. That was the latest at the time of the last migration, so it should be correct — but I followed up anyway:

❯ Are Sonnet 4.6 and Haiku 4.6 not out yet?

● Sonnet 4.6 is out (claude-sonnet-4-6). Haiku's latest is still
  4.5 (claude-haiku-4-5-20251001), and 4.6 hasn't been released.

  Your repo is still on claude-sonnet-4-5, so there's room to update.

Oh. It's out.

If I were actively tracking Anthropic release notes I would obviously have known, but honestly I don't have the bandwidth to watch every release, and I'd missed it. My conversations with the tool are doubling as an information-catch-up mechanism. There's something worth chewing on there about how engineers gather information, but let's set that aside for now.

Checking cost and performance

Before deciding to switch, I looked up Anthropic's official pricing and release info.

Pricing (input / output, per million tokens)

Unchanged.

Performance (official benchmarks)

Per Anthropic's published benchmarks, Sonnet 4.6 scores 79.6% on SWE-bench Verified — a clear step up from Sonnet 4.5. The main pitch is improved scores on coding/agent tasks.

In this repo, Sonnet is mostly used in the review step. If review accuracy improves and the revise loop runs fewer times, that's a win on both total cost and latency.

Conclusion: same price, better performance — effectively no downside to switching.

I filed an issue first, then shipped it anyway

In the previous migration, I had Claude Code run the whole thing start-to-finish, same day, commit and all. This time I moved a little differently at first.

❯ OK. I want to switch, so write up an issue for it first.

Rather than jumping straight to implementation, I filed an issue.

● Created: [repo-name]#820
  Title: Update Sonnet alias to claude-sonnet-4-6

My initial thought was "wait until Haiku 4.6 ships, then do both at once." The previous migration had upgraded all three models together, so I was matching that rhythm.

But once the issue was filed, I reconsidered.

"I want to batch it" is a cleanliness preference on my side — it's not the same as user value (where the user is future-me). There's not much reason to hold back a change that keeps pricing flat and improves performance, just for the sake of waiting for Haiku 4.6. When Haiku 4.6 arrives, it's another one-line change. That's fine as a separate PR.

So I ended up shipping just the Sonnet upgrade first.

Thanks to the alias system, the actual work was: change one line — the value of CLAUDE_MODEL_ALIASES.sonnet. With the docs and tests from the previous migration already in place, there was nothing to figure out.

What the third time tells you about "alias design benefits"

In the previous article I said "the second migration is when the design really pays off." What the third time reveals is something different: the point where the benefit becomes taken for granted.

When I first introduced the aliases, I was thinking hard about where to define them, how to test them, and how to keep the docs in sync. The second time, I noticed that the design had made things easy. The third time — I didn't think about any of it. "Change one line" has become the default assumption.

That's not a bad thing. It means good design has reached the point where you no longer have to notice it. In infrastructure and in design alike, "nobody notices it when it's working" is a kind of completed state.

But there's a risk to that too. When the assumptions underlying the design shift (say, if Anthropic materially changes how its alias system works), will I stop and go "wait, about this design..."? That part has to stay on the human side.

Current state and what's next

Here's where things stand.

Opus and Sonnet are now both on the latest generation. Haiku is the remaining one, and 4.6 isn't out yet.

When Haiku 4.6 lands, it'll be another one-line change. That might turn into a fourth migration write-up.

Further reading

If you want to go deeper on Claude Code workflows and the thinking behind alias-style design, these books are good starting points.