November 2025 will be remembered as the month the frontier models arrived in a queue. GPT-5.1 on the 12th. Gemini 3 on the 18th. And on 24 November, Anthropic released Claude Opus 4.5, its new top model, aimed squarely at coding, agents and computer use.

Every launch comes with charts showing it beating everything else. Every launch, social media declares a new king. And every launch, the only question that matters for you stays unanswered: is it better on your work?

Let's cover what Opus 4.5 is, and then the more durable part: a simple way to evaluate any new model on your own tasks, in an afternoon, without trusting anyone's leaderboard.

What Anthropic released

Opus is the top tier of Anthropic's Claude family, above Sonnet and Haiku. Opus 4.5 is positioned for the hardest work: complex coding tasks, long-running agents and computer use, where a model operates software through the screen the way a person would.

The other notable change is price. Opus 4.5 comes with lower pricing than previous Opus models. That matters more than it sounds. Until now, many teams used Opus only for the hardest tasks and defaulted to a cheaper model for everything else. A cheaper top model changes that calculation, especially for agents, which can use a lot of tokens on a single task.

For people who use Claude Code daily, as I do, a new top model is directly a change to the tool. But the same is true for Codex users when OpenAI ships, and for Gemini CLI users when Google does. The habit below works for all of them.

Why benchmarks aren't enough

Public benchmarks are useful signals, but they measure someone else's tasks, in someone else's setup. Your codebase has its own conventions, its own framework versions, its own weird corners. A model that's brilliant at algorithm puzzles might still ignore your folder structure, and a model that scores slightly lower might follow your CLAUDE.md or AGENTS.md perfectly.

The fix isn't to ignore benchmarks. It's to add your own, small one.

Build a personal eval set (once)

Collect five to ten real tasks from your recent work. The best ones are tasks you've already solved, so you know what "good" looks like. Mix the types:

• A small feature with a test (for example, a new filter on an API endpoint).
• A bug fix where the cause isn't obvious from the error.
• A refactor that must not change behaviour.
• A task in an older, messier part of the codebase.
• A "read and explain" task: summarise how a module works.

Write each one down with the prompt you'd normally give and how you'll check the result:

[
  {
    "id": "contract-status-filter",
    "prompt": "Add filtering by status to GET /api/contracts, with a feature test.",
    "check": "php artisan test --filter=ContractIndexTest"
  },
  {
    "id": "invoice-rounding-bug",
    "prompt": "Invoices for partial months are off by a few cents. Find and fix the cause.",
    "check": "php artisan test --filter=InvoiceCalculationTest"
  }
]

Store this file in the repo, or somewhere private if the tasks reveal too much. You'll reuse it every time a model ships.

Run the comparison like an experiment

1. Same task, same starting point. A fresh branch from the same commit for each model.
2. Same instructions. Same prompt, same project instructions file, same tools allowed.
3. Compare against what you use today, not against nothing. The question is "is it better than my current setup?".
4. Review blind if you can. Have someone else label the branches, so you don't grade the new model generously because it's new.

What to score

For AI features in production, be stricter

If a model powers a feature your users see (a summary, a classification, a generated reply), a model swap is a deployment, not an experiment:

• Keep a "golden set" of real inputs (anonymised, with no personal data) and the outputs you consider correct.
• Check the things that break silently: JSON that no longer validates, a changed tone, longer responses that cost more or overflow your UI.
• Pin the model version in your config, so the switch is a deliberate pull request you can roll back.
• Roll it out to a small share of traffic first if you can.

So, should you switch to Opus 4.5?

Honestly: run your eval set and find out. It's a serious model for coding and agent work, and the lower price makes it worth testing even if you'd ruled Opus out before. But the same is true of GPT-5.1 and Gemini 3 this month, and it'll be true of whatever ships next.

The developers who handle this pace best aren't the ones who switch fastest. They're the ones who can answer "is it better for us?" in an afternoon, with their own tasks and their own tests.

What's one task you'd put in your personal eval set? I'm always looking for good ones that separate the models.