24 - Opus 4.6 e Sonnet 4.6: Adaptive Thinking e 1M Context

Opus 4.6 e Sonnet 4.6: Adaptive Thinking e 1M Context

Febbraio-marzo 2026 segna un punto di svolta decisivo nella evoluzione dei modelli Claude. Anthropic ha introdotto due versioni nuove che ridefiniscono il panorama dell'AI destinata a sviluppatori: Claude Opus 4.6 (5 febbraio 2026) e Claude Sonnet 4.6 (17 febbraio 2026). Questi modelli portano tre innovazioni cruciali: adaptive thinking (ragionamento profondo automatico, senza budget manuale), 1M context window (un milione di token, senza sovraccarichi), e Compaction API (beta, per sessioni infinite).

Per gli sviluppatori che lavorano su monorepo complessi - come il nostro stack Spring Boot + Angular + FastAPI - queste capacità rappresentano un salto qualitativo. Una singola richiesta API può ora inghiottire il codebase intero, il thinking avviene in background senza drenare il budget manuale, e le sessioni lunghe si compattano per continuare indefinitamente.

In questo ventiquattresimo articolo della serie Claude, analizzeremo le specifiche tecniche, i modelli di prezzo, i pattern di migrazione dal vecchio budget_tokens, e come sfruttare queste capacità nel workflow di pair programming e agentic development.

1. Cronologia: Febbraio-Marzo 2026

La timeline è cruciale per capire il roadmap e i deprecation schedules:

2. Claude Opus 4.6 (5 Febbraio 2026)

Opus 4.6 è il modello flagship di Anthropic per il 2026, specializzato in task di complessità massima. Non è solo una iterazione; è una reinvenzione dell'approccio al ragionamento profondo.

Benchmark e Performance

Opus 4.6 stabilisce nuovi standard su tre benchmark critici:

• SWE-bench 80.8% (vs Opus 4.3: 72.4%) - Comprensione codebase, refactoring, bug fix autonomi
• Terminal-Bench 2.0 65.4% SOTA (state-of-the-art) - Task complessi al terminale, orchestrazione comandi, debugging
• Humanity's Last Exam leader - Test benchmark multidisciplinare (matematica, fisica, storia, legge)

Questi benchmark non sono semplici numeri. Riflettono l'abilità del modello di comprendere contesto complesso, pianificare risoluzioni multi-step, e auto-correggersi. Per sviluppatori, significa che Opus 4.6 può leggere un intero monorepo (1M token), capire le interdipendenze fra moduli, e suggerire refactoring che preservano la semantica del codice.

Novelty: Adaptive Thinking (Deprecation budget_tokens)

La feature più rivoluzionaria di Opus 4.6 è l'adaptive thinking. Nel modello precedente (Opus 4.3 con extended thinking), il developer doveva scegliere manualmente il budget_tokens - quanti token dedicare al ragionamento interno. Troppo poco = ragionamento superficiale; troppo = latenza insostenibile.

Con adaptive thinking, è Claude che decide quando e quanto ragionare. La configurazione non è più:

// Python SDK - Extended Thinking old style (DEPRECATO)
response = client.messages.create(
    model="claude-opus-4-3",
    max_tokens=16000,
    thinking={
        type="enabled",
        budget_tokens=10000  # Scelgo manualmente
    },
    messages=[{
        role="user",
        content="Analizza questo codebase di 500KB..."
    }]
)
print(response.content[0].thinking)  # Ragionamento interno
print(response.content[1].text)      # Risposta finale

Bensì:

// Python SDK - Adaptive Thinking NEW
response = client.messages.create(
    model="claude-opus-4-6",  # oppure "claude-sonnet-4-6"
    max_tokens=16000,
    thinking={
        type="adaptive"  # Claude decide automaticamente
    },
    messages=[{
        role="user",
        content="Analizza questo codebase di 500KB e suggerisci refactoring..."
    }]
)

# Accedi al ragionamento interno (se esiste)
for block in response.content:
    if block.type == "thinking":
        print(f"Thinking tokens: {len(block.thinking.split())}")
        print(block.thinking)
    elif block.type == "text":
        print("Response:", block.text)

Il vantaggio è immediato: non serve più fare tentativi e tuning. Claude sa quando è necessario un ragionamento profondo (refactoring architettura, debug complesso) vs. quando basta una risposta veloce (chiedere la lista di file). Adaptive thinking fa anche da regolatore automatico della latenza: per task semplici, output arriva in pochi secondi; per task complessi, prende il tempo necessario.

Effort Parameter GA

Accompagnando adaptive thinking, è arrivato l'effort parameter. Se hai comunque bisogno di più controllo (ad es. "questa è una task critica, spendi quello che serve"), usi:

// TypeScript SDK - Effort parameter
const response = await client.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 16000,
  thinking: {
    type: "adaptive",
    effort: "high"  // Spingi Claude a ragionare più profondamente
  },
  messages: [{
    role: "user",
    content: "Redesign la logica di caching Redis in produzione per il nostro monorepo..."
  }]
});

// Costi approssimativi per effort:
// - "low":    ~20% meno thinking + 10% faster
// - "medium": baseline (default)
// - "high":   ~50% più thinking + latenza +2-3x
// - "max":    thinking massimo, latenza fino a +10x ma risultati premium

Pricing: Invariato

Nonostante le capacità ampliate, Anthropic ha mantenuto il pricing invariato rispetto a Opus 4.3:

• $5 / 1M input tokens
• $25 / 1M output tokens
• Nessun surcharge per 1M context (beta GA 13 feb 2026)
• Thinking tokens conteggiati come input (costo standard, non extra)

1M Context Window (Beta → GA 13 feb)

Opus 4.6 supporta 1M token context window a nessun costo aggiuntivo rispetto ai 200K standard. Significa che puoi inviare:

• Intero codebase monorepo (Spring Boot + Angular + FastAPI + Infra) = ~200-400KB = 50-100K token
• 100 articoli blog in markdown = ~300-500K = 75-125K token
• Dataset CSV con 100K righe = ~400KB = 100K token
• Sistema completo di prompt + context = 500K token + immagini
• Supporto 100→600 immagini per singola request (vs 20 prima)

Per sviluppatori su monorepo, è una game-changer: invece di mandare file singoli uno per uno (prompt engineering complesso), invii il codebase intero e dici "capisco il contesto". Claude ha la visione olistica e fa suggerimenti coerenti fra layer (dominio, application, infrastructure, presentation).

3. Claude Sonnet 4.6 (17 Febbraio 2026)

Se Opus 4.6 è il modello flagship, Sonnet 4.6 è la scelta pragmatica: 70% delle performance di Opus, a 1/5 del costo, e spesso sufficientemente smart per task quotidiane.

Benchmark Sonnet 4.6

• SWE-bench 79.6% (vs Sonnet 4.5: 75.2%) - Quasi pari a Opus 4.3
• OSWorld 72.5% - Automazione desktop e webapp complesse
• Agentic search 2x migliorata - Trova informazioni rilevanti più velocemente
• Preferito 70% nei trial vs Sonnet 4.5 - Sviluppatori scelgono 4.6 per trade-off latenza/qualità

1M Context (Beta → GA 13 mar)

Sonnet 4.6 supporta 1M context window in beta da 17 feb, con GA annunciata per 13 marzo 2026. A GA, il pricing è:

Il premium è pagato solo se usi context oltre 200K. Se mandi richieste sotto 200K, paghi standard. È un modello equo: non punisce chi non ha bisogno della capacità extra.

Extended Thinking Support

Sonnet 4.6 supporta extended thinking con adaptive thinking, uguale a Opus 4.6. Molti developer preferiscono Sonnet 4.6 per task quotidiane proprio per questo: ragionamento + velocità + costo basso.

4. Adaptive Thinking: Meccanica e Configurazione

Adaptive thinking non è magia. È il risultato di training sofisticato dove il modello ha imparato quando il ragionamento interno migliora la qualità della risposta. Analizziamo come funziona dal lato pratico.

Esecuzione: Cosa Accade in Background

Quando invii una richiesta con thinking: { type: "adaptive" }:

1. Claude valuta la task - È semplice (informazione diret) o complessa (reasoning multi-step)?
2. Decide il budget di thinking - Alloca token per ragionamento interno (0 fino a ~20K, dipende da task)
3. Ragiona in background - Esplora ipotesi, rivede assunzioni, debugga logica
4. Genera risposta - Basandosi sul ragionamento interno, produce output finale
5. Ritorna pensiero + risposta - API response contiene sia thinking che text

Caso d'Uso 1: Task Semplice (Niente Thinking)

Quando chiedi "quali sono le dipendenze nel pom.xml di questo progetto?", Claude vede che è una task di lettura diretta. Niente thinking: va al punto, risponde subito.

// Richiesta
{
  "messages": [{
    "role": "user",
    "content": "Estrai tutte le dipendenze Maven dal seguente pom.xml:\n\n[pom.xml content ~5KB]"
  }],
  "thinking": { "type": "adaptive" }
}

// Response: ~150ms (no thinking block)
{
  "content": [
    {
      "type": "text",
      "text": "Dipendenze principali:\n- spring-boot-starter-web\n- spring-data-jpa\n- ..."
    }
  ]
}

Caso d'Uso 2: Task Complessa (Adaptive Thinking ~5K token)

Quando chiedi "redesign l'architettura di questo sistema monorepo per migliorare la testabilità e le performance", Claude sa che serve ragionamento profondo. Attiva thinking automaticamente.

// Richiesta
{
  "messages": [{
    "role": "user",
    "content": "Analizza questo monorepo [Spring+Angular+FastAPI, ~150KB] e proponi una architettura target per:\n1. Separazione responsabilità fra servizi\n2. Migliorare test coverage dal 45% all'80%\n3. Ottimizzare latenza API da 500ms a 200ms"
  }],
  "thinking": { "type": "adaptive", "effort": "high" }
}

// Response: ~3-5 secondi (con thinking block)
{
  "content": [
    {
      "type": "thinking",
      "thinking": "L'utente chiede una redesign architetturale. Devo:\n1. Analizzare i layer attuali\n2. Identificare violazioni di SRP\n3. Proporre splitting dei moduli\n4. Calcolare impact di testing\n5. Valutare trade-off latenza vs. consistenza\n\n[5K token di ragionamento interno, invisibile all'utente]"
    },
    {
      "type": "text",
      "text": "Proposta architettura target:\n1. Separare Domain dal Presentation layer...\n2. Usare pattern Repository per testabilità...\n..."
    }
  ]
}

5. Compaction API (Beta): Agenti che Lavorano 8+ Ore

Anche con 1M context, una sessione lunga (agente che lavora per 8+ ore continuative) prima o poi riempie il buffer. Compaction API è la soluzione: riassume automaticamente la conversazione passata, mantenendo il contesto critico, e continua indefinitamente.

Il Problema: Context Window si Riempie

Immagina un agente sviluppatore che:

1. Ore 09:00 - Analizza il monorepo (200K token rimanenti su 1M)
2. Ore 10:00 - Scrive test per 5 moduli (500K token usati, 300K rimanenti)
3. Ore 11:00 - Refactoring service layer (750K token usati, 150K rimanenti)
4. Ore 12:00 - Aggiunge logging e monitoring (900K usati, 50K rimanenti)
5. Ore 13:00 - CRASH: Context pieno, non può continuare

Senza Compaction, l'agente sarebbe fermo. Con Compaction:

Soluzione: Compaction API

Prima che il context si riempia, l'agente chiama Compaction API che:

1. Legge la conversazione completa (900K token di historia)
2. Riassume criticamente - "L'utente richiede refactoring di Spring Boot monorepo per 80% test coverage. Abbiamo già fixato 5 moduli, implementato logging, identificato 3 anti-pattern in SecurityConfig"
3. Compatta il context - Converte 900K token in ~100K token di summary strutturato
4. Continua la sessione - Agente riprende con 900K token liberi e la conversazione compattata

Implementazione (Beta Header)

Compaction API è in beta (marzo 2026), accessibile via header speciale:

import anthropic

client = anthropic.Anthropic()

# Invia il messaggio con header beta
response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=16000,
    system="Sei un code-review agent. Lavora continuativamente finché non ricevi uno stop explicit.",
    messages=[
        {
            "role": "user",
            "content": "Analizza il monorepo su 8 ore. Refactor, test, documenta. Se ctx quasi pieno, compatta automaticamente."
        }
    ],
    # Richiedi compaction automatica
    extra_headers={
        "anthropic-beta": "interleaved-thinking-2025-05-14"
    }
)

# Ciclo agente
conversation_history = []
total_tokens_used = 0
MAX_TOKENS = 1_000_000

while True:
    # Monitorizza uso contesto
    tokens_remaining = MAX_TOKENS - total_tokens_used

    if tokens_remaining < 100_000:
        print("[Agent] Context quasi pieno, compatto...")

        # Chiama Compaction API
        compaction_response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=1000,
            system="Riassumi criticamente questa conversazione di lavoro.",
            messages=[
                {"role": "user", "content": "Compatta questa conversazione"},
                *conversation_history
            ],
            extra_headers={
                "anthropic-beta": "interleaved-thinking-2025-05-14"
            }
        )

        # Uso il riassunto compattato per continuar e la sessione
        conversation_history = [
            {
                "role": "assistant",
                "content": f"[CONVERSAZIONE COMPATTATA]\n{compaction_response.content[0].text}"
            }
        ]
        total_tokens_used = 100_000  # Reset conteggio, ora sotto controllo

    # Continua il loop agente
    print("[Agent] Continuo analisi...")
    # ... logica agente ...

Caso d'Uso: Code Review Automatico 8 Ore

Scenario pratico: lancio un agente che revisiona il nostro monorepo Spring Boot + Angular per 8 ore continuative:

1. Ore 09:00 - Analizza 50 file Java, 30 TS, infra config (150K token)
2. Ore 11:00 - Genera 20 test unitari, 5 integration test (500K usati)
3. Ore 13:00 - Compaction auto-attivato. Converte 500K storia in 80K summary
4. Ore 13:30 - Agente riprende con 920K liberi. Continua refactoring SecurityConfig
5. Ore 16:00 - Deliverable: codebase refactored, 80+ test nuovi, documentazione ADR, tutto senza interruzioni

6. 1M Context Window: Cosa Entra?

1M context è astratto finché non pensi a quanto codice/dati effettivamente entra. Ecco una tabella concreta:

Traduzione pratica: col 19.5% di contesto usato (195K token), hai ancora 800K token liberi per il lavoro effettivo - task description, prompt engineering, output generato. È uno spazio enorme.

Immagini: 100→600

Un miglioramento concreto di 1M context è il supporto a 600 immagini per request (vs 20 su 200K context). Use case:

• Analizzare 300 screenshot di una webapp per replicarla (design → codice)
• Processare 500 diagrammi architetturali per estrarre pattern
• Analizzare 200 grafici finanziari per detectare anomalie

7. Breaking Changes: Modelli Ritirati e Migrazione

Ogni release Anthropic porta deprecation. È importante saperlo per non rimanere bloccati.

Deprecation già attivo (febbraio 2026)

• Sonnet 3.7 - Rimosso da marketplace 19 feb 2026, supporto termina 19 apr
• Haiku 3.5 - Rimosso da marketplace 19 feb 2026, supporto termina 19 apr
• budget_tokens parametro - Deprecato 5 feb (extended thinking old style). Usa effort al posto

Deprecation prevista (aprile 2026)

• Sonnet 4 - Anteprima 14 apr 2026, retired 15 giu 2026
• Opus 4 - Anteprima 14 apr 2026, retired 15 giu 2026

Migrazione: Checklist

8. Fast Mode Preview: 2.5x Output Rate

Una feature in preview su Opus 4.6 è Fast Mode: output 2.5x più veloce sacrificando un po' di qualità. È utile per interazioni reali-time (IDE autocompletion, chat interattivo).

Quando usare Fast Mode

✅ Sì, usa Fast Mode per:

• IDE inline autocomplete (resposta < 500ms desiderata)
• Chat interattivo con utente (percezione di responsiveness)
• API gateway con SLA 1s (microservizio helper)
• Batch processing non-critico (generazione dummy data)

❌ NO, non usare Fast Mode per:

• Code review architetturale (priorità: qualità)
• Agente autonomo che scrive test / refactor (priorità: correttezza)
• Analisi compliance/security (priorità: completezza)
• Generazione documentazione tecnica (priorità: precisione)

// TypeScript - Fast Mode (preview, header beta)
const response = await client.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 1000,
  messages: [{
    role: "user",
    content: "Suggerisci 3 function name alternatives per 'handleUserAuthStateChange'"
  }],
  extra_headers: {
    "anthropic-beta": "fast-mode-2025-05-14"
  }
});

// Latenza attesa:
// - Normal mode: ~1.2s
// - Fast mode:  ~500ms (2.5x più veloce)

9. Casi Pratici: Monorepo Spring + Angular + FastAPI

Vediamo come sfruttare Opus 4.6 / Sonnet 4.6 con il nostro stack reale.

Use Case 1: Full Monorepo Code Review (1M Context)

Scenario: Code review completo del monorepo portfolio (backend 150KB, frontend 100KB, ml-service 30KB, infra 20KB). Senza 1M context, dovrei mandare file singoli. Con 1M context, mandata tutto.

import anthropic
import subprocess

client = anthropic.Anthropic()

# 1. Raccogli intero monorepo
def gather_monorepo():
    result = subprocess.run(
        ["find", ".", "-type", "f",
         "-name", "*.java", "-o", "-name", "*.ts", "-o", "-name", "*.py",
         "-o", "-name", "*.yml", "-o", "-name", "*.yaml"],
        capture_output=True, text=True
    )

    monorepo_content = ""
    for file_path in result.stdout.strip().split('\n'):
        if file_path and len(monorepo_content) < 900_000:  # Lascia 100K per prompt
            try:
                with open(file_path, 'r') as f:
                    monorepo_content += f"# File: {file_path}\n"
                    monorepo_content += f.read() + "\n\n"
            except:
                pass

    return monorepo_content

# 2. Code review con adaptive thinking
monorepo = gather_monorepo()
print(f"[Info] Monorepo size: {len(monorepo):,} characters (~{len(monorepo)//4:,} token)")

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "effort": "high"
    },
    messages=[{
        "role": "user",
        "content": f"""Analizza questo monorepo completo e fornisci:

1. **Violazioni architetturali** (Clean Architecture, 4-layer pattern)
2. **Opportunità di refactoring** (DRY, SOLID, testing)
3. **Performance bottleneck** (database query, caching, API latency)
4. **Security issue** (input validation, XSS, SSRF, SQL injection)
5. **Test coverage gap** (unità mancanti, edge case)

Focus: Priorità P0 (critico), P1 (importante), P2 (nice-to-have)

Monorepo:
{monorepo}
"""
    }]
)

# 3. Output
for block in response.content:
    if block.type == "thinking":
        print(f"\n[Claude Thinking]\n{block.thinking[:500]}...")
    elif block.type == "text":
        print(f"\n[Code Review Report]\n{block.text}")

Use Case 2: Agente Autonomo 8 Ore (Compaction API)

Scenario: Lancio un agente che lavora autonomamente per 8 ore: analizza test gap, scrive test, refactor, aggiorna documentazione. Con Compaction API, non si incaglia.

import anthropic
import time
from datetime import datetime

client = anthropic.Anthropic()

class AutonomousCodeAgent:
    def __init__(self):
        self.conversation = []
        self.total_tokens = 0
        self.start_time = datetime.now()

    def add_message(self, role, content):
        self.conversation.append({"role": role, "content": content})

    def run_iteration(self, task):
        """Esegui una iteration dell'agente"""
        self.add_message("user", task)

        # Chiama Claude
        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=8000,
            thinking={"type": "adaptive", "effort": "medium"},
            messages=self.conversation
        )

        # Accumula tokens
        self.total_tokens += response.usage.input_tokens + response.usage.output_tokens

        # Aggiungi risposta al conversation
        assistant_message = ""
        for block in response.content:
            if block.type == "text":
                assistant_message += block.text

        self.add_message("assistant", assistant_message)

        # Compaction se context sta per riempirsi
        if self.total_tokens > 900_000:
            self.compact_conversation()

        elapsed = (datetime.now() - self.start_time).total_seconds()
        print(f"[{elapsed:5.0f}s] Tokens: {self.total_tokens:,} | {task[:60]}...")

        return assistant_message

    def compact_conversation(self):
        """Compatta la conversazione via Compaction API"""
        print("[Agent] ⚡ Compacting conversation...")

        compaction_prompt = "Riassumi questa conversazione di lavoro in 2K token, mantenendo solo le info critiche."

        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=2000,
            messages=[
                *self.conversation,
                {"role": "user", "content": compaction_prompt}
            ]
        )

        summary = response.content[0].text

        # Sostituisci conversazione con summary
        self.conversation = [
            {"role": "user", "content": "Ecco il riassunto della nostra conversazione precedente:\n" + summary}
        ]

        # Reset token counter
        self.total_tokens = 0

# 3. Run agente per 8 ore di task
agent = AutonomousCodeAgent()

tasks = [
    "Analizza il file backend/src/main/java/.../UserService.java e identifica test gap",
    "Scrivi 5 unit test per il metodo login() in UserService",
    "Refactor il SecurityConfig per rispettare OWASP Top 10",
    "Aggiungi logging estrutturato in formato JSON per debug",
    "Aggiorna la documentazione API nel README.md",
    "Suggerisci ottimizzazioni di performance per la query findByEmail",
    "Valuta coverage del test suite attuale e identifica weak point",
    "Implementa circuit breaker per il call esterno (Firebase verificazione)"
]

for task in tasks:
    response = agent.run_iteration(task)
    time.sleep(1)  # Rate limiting

10. Quando Scegliere Quale Modello

La scelta fra Opus 4.6 e Sonnet 4.6 dipende da task, budget, e SLA. Ecco una guida pratica:

11. Migrazione da budget_tokens a Effort Parameter

Se avevi codice che usava extended thinking con budget_tokens manuale, ecco come migrare.

// Python - Extended Thinking OLD STYLE (deprecato 5 feb 2026)
response = client.messages.create(
    model="claude-opus-4-3",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 8000  # Scelgo manualmente
    },
    messages=[{
        "role": "user",
        "content": "Analizza questo monorepo e proponi refactoring architetturale..."
    }]
)

# Problema: devo indovinare il budget. Troppo poco = risultato superficiale, troppo = latenza +10s

// Python - Adaptive Thinking NEW STYLE (GA 5 feb 2026)
response = client.messages.create(
    model="claude-opus-4-6",  # Update model ID
    max_tokens=16000,
    thinking={
        "type": "adaptive",      # Claude decide automaticamente
        "effort": "high"         # Linea guida opzionale: low|medium|high|max
    },
    messages=[{
        "role": "user",
        "content": "Analizza questo monorepo e proponi refactoring architetturale..."
    }]
)

# Vantaggio: no tuning manuale. Claude alloca il budget necessario automaticamente.

Mapping budget_tokens → effort

Se avevi budget_tokens: X, puoi mappare a effort così:

12. Parametri Rinominati e Novità API

Oltre a thinking e effort, Opus 4.6 / Sonnet 4.6 introducono piccole variazioni:

13. Calcolatore Costi Realistico

Quanto costa una sessione di pair programming con Opus 4.6 / Sonnet 4.6 nel mondo reale?

14. Conclusione: Opus 4.7 in Arrivo

Opus 4.6 e Sonnet 4.6 rappresentano un salto significativo. Per gli sviluppatori di monorepo complessi, l'impatto è immediato: 1M context significa no più splitting di prompt, adaptive thinking significa no più tuning manuale, Compaction API significa agenti veramente autonomi.

Ma Anthropic non si ferma. Le voci di Opus 4.7 (anteprima Q2 2026) parlano di:

• SWE-bench 87.6% (vs Opus 4.6: 80.8%) - Gap tra Claude e dev umano ancora più ridotto
• xhigh effort mode - Thinking ancora più profondo per task architetturali critiche
• Compaction API GA - Esce da beta, SLA garantito
• Multi-modal thinking - Analisi immagini con ragionamento interno

Per ora, Opus 4.6 rimane il modello di scelta per pair programming serio e agentic development. Sonnet 4.6 è il workhorse economico che copre il 70% dei task con il 20% del costo.

Prossimi passi:

1. Migra il tuo codebase da budget_tokens a adaptive thinking
2. Testa la 1M context window con il tuo intero monorepo
3. Prova Compaction API se hai agenti long-running
4. Valuta Fast Mode per chat interattivo
5. Monitora il roadmap Anthropic per Opus 4.7 (Q2 2026)

Riferimenti Ufficiali

• Anthropic - Claude Opus 4.6 Announcement
• Anthropic - Claude Sonnet 4.6 Announcement
• Claude Platform - Release Notes
• Claude Docs - Extended Thinking & Adaptive Thinking
• Claude Docs - Models Overview