Een paar weken geleden bracht Anthropic Claude Opus 4.6 uit — en maakte het meteen het standaardmodel in Claude Code. Ik gebruik het dagelijks sindsdien. Het verschil is niet subtiel.
De cijfers zijn indrukwekkend: 1 miljoen tokens context (in extended beta), 80.8% op SWE-bench Verified, en extended thinking waarmee het model stap voor stap redeneert voordat het een antwoord geeft. Maar cijfers vertellen je niet hoe het voelt om ermee te werken. Dus laat ik je laten zien wat er concreet verandert als je met .NET code werkt.
Het contextvenster verandert alles
Eerdere Claude-modellen hadden een maximum van 200K tokens. Dat klinkt als veel — totdat je een echte .NET solution probeert te refactoren. Een typisch enterprise project heeft tientallen .csproj-bestanden, honderden klassen, Entity Framework models, service layers, controllers en tests. Bij 200K tokens raakte Claude het overzicht kwijt over hoe je OrderService zich verhoudt tot je PaymentGateway drie projecten verderop.
Met 1M tokens past je hele solution in één sessie. Elke modelklasse, elk interface, elke DI-registratie — Claude ziet het allemaal tegelijk.
Dit is wat dat in de praktijk betekent. Stel dat je een domeinconcept wilt hernoemen door je hele solution. Je Customer wordt een Tenant omdat je app multi-tenant wordt. Dat raakt models, DTO’s, database-migraties, API-contracten, validatieregels en tests in meerdere projecten.
// Ervoor: verspreid over 40+ bestanden
public class Customer { ... }
public class CustomerService : ICustomerService { ... }
public class CustomerRepository : ICustomerRepository { ... }
public record CreateCustomerRequest(string Name, string Email);
// Erna: Claude hernoemt alles consistent
public class Tenant { ... }
public class TenantService : ITenantService { ... }
public class TenantRepository : ITenantRepository { ... }
public record CreateTenantRequest(string Name, string Email);
Met Opus 4.6 leest Claude je hele solution, begrijpt de relaties tussen projecten, en hernoemt consistent — inclusief de EF Core-configuratie, de DI-registraties in Program.cs, en de test fixtures. Met eerdere modellen miste het onvermijdelijk iets drie projecten diep.
Dieper redeneren, minder fouten
Opus 4.6 heeft extended thinking — het model werkt stap voor stap door een probleem voordat het code schrijft. Je ziet het denkproces niet (dat gebeurt intern), maar je merkt het aan de resultaten.
Ik vroeg Claude om soft delete toe te voegen aan een bestaande Entity Framework setup. Met eerdere modellen kreeg ik meestal de IsDeleted-property en de global query filter — maar het miste de cascade delete-configuratie, of vergat de Include-calls aan te passen die nu rekening moeten houden met verwijderde gerelateerde entiteiten.
Met Opus 4.6 pakte het alles mee:
// 1. Base entity met 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)
{
// Toegepast op elke entity die SoftDeletableEntity overerft
foreach (var entityType in modelBuilder.Model.GetEntityTypes())
{
if (typeof(SoftDeletableEntity).IsAssignableFrom(entityType.ClrType))
{
modelBuilder.Entity(entityType.ClrType)
.HasQueryFilter(
GenerateSoftDeleteFilter(entityType.ClrType));
}
}
}
// 3. Override SaveChanges om deletes te onderscheppen
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();
}
Het paste ook de repository-methodes aan die .IgnoreQueryFilters() nodig hadden voor admin-scenario’s, voegde de migratie toe, en stelde de tests bij. Dat is extended thinking in actie — het redeneert door alle implicaties voordat het één regel schrijft.
Wat Opus 4.6 vs. Sonnet 4.6 betekent voor je workflow
Claude Code wordt nu geleverd met twee modellen: Opus 4.6 (standaard) en Sonnet 4.6. Ze delen dezelfde architectuur maar verschillen in waar ze uitblinken.
| Opus 4.6 | Sonnet 4.6 | |
|---|---|---|
| SWE-bench | 80.8% | 79.6% |
| GPQA Diamond | 91.3% | 74.1% |
| Context | Tot 1M tokens | 200K tokens |
| Snelheid | Langzamer, dieper | Sneller, lichter |
| Prijs | $15/$75 per M tokens | $3/$15 per M tokens |
De SWE-bench scores liggen dicht bij elkaar, maar het GPQA Diamond verschil (91.3% vs 74.1%) vertelt het echte verhaal. GPQA meet redeneren op academisch niveau — het soort denken dat je nodig hebt bij het debuggen van een race condition in je async middleware, of het ontwerpen van een multi-tenant data-isolatiestrategie.
Mijn vuistregel: gebruik Opus voor architectuurbeslissingen, complexe refactorings, en debugging van problemen die meerdere services overspannen. Gebruik Sonnet voor snelle aanpassingen, boilerplate genereren, en routinetaken waar snelheid belangrijker is dan diepgang. Je kunt wisselen in Claude Code met /model.
Praktijkvoorbeeld: een achtergrondtakensysteem migreren
Vorige week gebruikte ik Opus 4.6 om een Hangfire-setup te migreren naar een eigen IHostedService-implementatie. Het bestaande systeem had 12 terugkerende jobs, elk met eigen retry-logica, en een dashboard dat de jobstatus toonde.
Met eerdere modellen had ik dit in kleinere taken moeten opsplitsen — één job tegelijk migreren, testen, herhalen. Het model kon niet het volledige plaatje vasthouden van hoe alle jobs op elkaar inwerkten.
Met Opus 4.6 laadde ik de hele solution en vroeg Claude om de migratie te ontwerpen. Het:
- Analyseerde alle 12 jobklassen en hun afhankelijkheden
- Identificeerde gedeelde patronen (retry-logica, logging, foutafhandeling)
- Maakte een basis
RecurringJobService-klasse - Migreerde elke job naar het nieuwe patroon
- Paste de DI-registraties aan
- Verving de Hangfire dashboard-calls door een health check endpoint
- Schreef integratietests voor de nieuwe scheduling
De hele migratie gebeurde in één sessie. Niet omdat Opus sneller is — het is eigenlijk langzamer dan Sonnet — maar omdat het over alle 12 jobs tegelijk kon redeneren in plaats van de retry-logica van job #3 te vergeten terwijl het met job #8 bezig was.
De prijsvraag
Opus 4.6 kost 5x meer dan Sonnet 4.6. Dat is significant. Bij $15 per miljoen input tokens en $75 per miljoen output tokens kan een stevige refactoring-sessie echt geld kosten.
Maar hier is het punt: de kosten zijn niet per uur, maar per token. Een complexe taak waarbij Sonnet drie pogingen nodig heeft (omdat het steeds edge cases mist) kan duurder uitpakken dan Opus die het in één keer goed doet. Ik ben gestopt met denken over modelkosten per request en denk nu in kosten per afgeronde taak.
Voor de meeste .NET development is Opus als standaard logisch. Je schrijft geen wegwerpscripts — je bouwt systemen waar de architectuur er goed uit moet komen. Het diepere redeneren verdient zichzelf terug in minder iteraties en minder bugs die de code review halen.
Wat niet veranderd is
Opus 4.6 is nog steeds Claude Code. De workflow is hetzelfde: beschrijf wat je wilt, bekijk wat het oplevert, stuur bij als het de verkeerde kant opgaat. Het CLAUDE.md-bestand, de git-integratie, de permission modes — niets daarvan is veranderd.
Wat wel veranderd is, is het plafond. Taken die te complex waren voor één sessie — refactorings door je hele solution, cross-project dependency updates, architectuurmigraties — zijn nu binnen bereik. Niet omdat de tool een nieuwe knop kreeg, maar omdat het model slimmer is en meer context kan vasthouden.
Probeer het zelf
Als je Claude Code al gebruikt, werk je al met Opus 4.6 — het is de standaard. Probeer iets wat je eerder niet zou hebben geprobeerd:
- Laad je hele solution en vraag Claude om inconsistenties te vinden in je error handling patronen
- Refactor een domeinconcept dat elke laag van je architectuur raakt
- Vraag het om een migratiestrategie te ontwerpen voor een legacy component, met alle edge cases meegenomen
Het 1M token contextvenster betekent dat Claude je hele codebase tegelijk kan zien. Extended thinking betekent dat het door implicaties redeneert voordat het code schrijft. Samen maken ze Claude Code minder als een autocomplete-tool en meer als een senior developer die daadwerkelijk elk bestand in je repo heeft gelezen.
Dat is de echte verschuiving met Opus 4.6. Niet alleen betere benchmarks — maar beter begrip van de code waar je daadwerkelijk aan werkt.