Claude Opus 4.6 — what the best AI model means for your .NET code

A few weeks ago, Anthropic shipped Claude Opus 4.6 — and made it the default model in Claude Code. I’ve been using it daily since then. The difference isn’t subtle.

The headline numbers are impressive: 1 million tokens of context (in extended beta), 80.8% on SWE-bench Verified, and extended thinking that lets the model reason step by step before producing an answer. But numbers don’t tell you what it feels like to use it. So let me show you what actually changes when you’re working on .NET code.

The context window changes everything

Previous Claude models topped out at 200K tokens. That sounds like a lot — until you try to refactor a real .NET solution. A typical enterprise project has dozens of .csproj files, hundreds of classes, Entity Framework models, service layers, controllers, and tests. At 200K tokens, Claude would lose track of how your OrderService relates to your PaymentGateway three projects away.

With 1M tokens, your entire solution fits in one session. Every model class, every interface, every DI registration — Claude sees it all at once.

Here’s what that means in practice. Say you want to rename a domain concept across your solution. Your Customer becomes a Tenant because your app is going multi-tenant. That touches models, DTOs, database migrations, API contracts, validation rules, and tests across multiple projects.

// Before: scattered across 40+ files
public class Customer { ... }
public class CustomerService : ICustomerService { ... }
public class CustomerRepository : ICustomerRepository { ... }
public record CreateCustomerRequest(string Name, string Email);

// After: Claude renames everything consistently
public class Tenant { ... }
public class TenantService : ITenantService { ... }
public class TenantRepository : ITenantRepository { ... }
public record CreateTenantRequest(string Name, string Email);

With Opus 4.6, Claude reads your entire solution, understands the relationships between projects, and renames consistently — including the EF Core configuration, the DI registrations in Program.cs, and the test fixtures. With previous models, it would inevitably miss something three projects deep.

Deeper reasoning, fewer mistakes

Opus 4.6 includes extended thinking — the model works through a problem step by step before writing code. You don’t see the thinking process (it happens internally), but you notice the results.

I asked Claude to add soft delete to an existing Entity Framework setup. With earlier models, I’d typically get the IsDeleted property and the global query filter — but it would miss the cascade delete configuration, or forget to update the Include calls that now need to account for deleted related entities.

With Opus 4.6, it caught everything:

// 1. Base entity with soft delete
public abstract class SoftDeletableEntity
{
    public bool IsDeleted { get; set; }
    public DateTime? DeletedAt { get; set; }
}

// 2. Global query filter in DbContext
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Applied to every entity that inherits SoftDeletableEntity
    foreach (var entityType in modelBuilder.Model.GetEntityTypes())
    {
        if (typeof(SoftDeletableEntity).IsAssignableFrom(entityType.ClrType))
        {
            modelBuilder.Entity(entityType.ClrType)
                .HasQueryFilter(
                    GenerateSoftDeleteFilter(entityType.ClrType));
        }
    }
}

// 3. Override SaveChanges to intercept deletes
public override int SaveChanges()
{
    foreach (var entry in ChangeTracker.Entries<SoftDeletableEntity>()
        .Where(e => e.State == EntityState.Deleted))
    {
        entry.State = EntityState.Modified;
        entry.Entity.IsDeleted = true;
        entry.Entity.DeletedAt = DateTime.UtcNow;
    }
    return base.SaveChanges();
}

It also updated the repository methods that needed .IgnoreQueryFilters() for admin scenarios, added the migration, and adjusted the tests. That’s the extended thinking at work — it reasons through all the implications before writing a single line.

What Opus 4.6 vs. Sonnet 4.6 means for your workflow

Claude Code now ships with two models: Opus 4.6 (the default) and Sonnet 4.6. They share the same architecture but differ in where they shine.

The SWE-bench scores are close, but the GPQA Diamond gap (91.3% vs 74.1%) tells the real story. GPQA measures graduate-level reasoning — the kind of thinking you need when debugging a race condition in your async middleware, or designing a multi-tenant data isolation strategy.

My rule of thumb: use Opus for architecture decisions, complex refactorings, and debugging problems that span multiple services. Use Sonnet for quick edits, generating boilerplate, and routine tasks where speed matters more than depth. You can switch between them in Claude Code with /model.

Real-world example: migrating a background job system

Last week I used Opus 4.6 to migrate a Hangfire setup to a custom IHostedService implementation. The existing system had 12 recurring jobs, each with its own retry logic, and a dashboard that showed job status.

With earlier models, I would have needed to break this into smaller tasks — migrate one job at a time, test, repeat. The model couldn’t hold the full picture of how all jobs interacted.

With Opus 4.6, I loaded the entire solution and asked Claude to design the migration. It:

1. Analyzed all 12 job classes and their dependencies
2. Identified shared patterns (retry logic, logging, error handling)
3. Created a base RecurringJobService class
4. Migrated each job to the new pattern
5. Updated the DI registrations
6. Replaced the Hangfire dashboard calls with a health check endpoint
7. Wrote integration tests for the new scheduling

The whole migration happened in one session. Not because Opus is faster — it’s actually slower than Sonnet — but because it could reason about all 12 jobs simultaneously instead of forgetting job #3’s retry logic while working on job #8.

The price question

Opus 4.6 costs 5x more than Sonnet 4.6. That’s significant. At $15 per million input tokens and $75 per million output tokens, a heavy refactoring session can cost real money.

But here’s the thing: the cost isn’t per hour, it’s per token. A complex task that takes Sonnet three attempts (because it keeps missing edge cases) might cost more than Opus getting it right the first time. I’ve stopped thinking about model cost per request and started thinking about cost per completed task.

For most .NET development work, Opus as default makes sense. You’re not writing throwaway scripts — you’re building systems where getting the architecture right matters. The deeper reasoning pays for itself in fewer iterations and fewer bugs that make it to code review.

What hasn’t changed

Opus 4.6 is still Claude Code. The workflow is the same: describe what you want, review what it produces, guide it when it goes off track. The CLAUDE.md file, the git integration, the permission modes — none of that changed.

What changed is the ceiling. Tasks that were too complex for a single session — full-solution refactorings, cross-project dependency updates, architectural migrations — are now within reach. Not because the tool got a new button, but because the model got smarter and can hold more context.

Try it yourself

If you’re already using Claude Code, you’re already on Opus 4.6 — it’s the default. Try something you wouldn’t have attempted before:

• Load your entire solution and ask Claude to find inconsistencies in your error handling patterns
• Refactor a domain concept that touches every layer of your architecture
• Ask it to design a migration strategy for a legacy component, with all the edge cases accounted for

The 1M token context window means Claude can see your whole codebase at once. The extended thinking means it reasons through implications before writing code. Together, they make Claude Code feel less like an autocomplete tool and more like a senior developer who actually read every file in your repo.

That’s the real shift with Opus 4.6. Not just better benchmarks — but better understanding of the code you’re actually working on.